UI Mod - Bigger Perk Tree

[Amineri]

I'm really sorry about the miscommunication about the layout of the GetPerkInTree functions.

 

I thought I had read that you were going to go with the bit-packing method since it allows up to 4x11 perks to be defined, compared with 25 perks total (but possibly more than 4 in a rank).

 

I've got the protoype code working to allow for a simple level of branching, which takes advantage of having 4 perks per rank defined.

 

It will likely need some more to make it more generally applicable, as the current version also defines separate weapon options based on perk selected at the first rank.

 

----------------

 

All that said, I don't consider the 4x11 version "final". I would love it if anyone came up with a better way to pack more perk options into the code. This could allow more customization of allowing later perk choices to be based on earlier ones.

 

One quasi-limitation currently is the number of perks available. I've been working on adding more, but am starting to run into the limitation in the BuildPerkTables function of (a) space to create perks (b) perk IDs that aren't used an © finding icons for new perks.

 

There are a lot of great ability icons defined, but so far I've been unable to use any of them for perks :(

 

I might eventually work on some "pseudo-perks" that aren't perks in the usual manner, but instead apply permanent stat changes (basically in the same way as leveling up, but selectable). However, finding icons to represent stat increases remains a problem.

[bokauk]

I'm really sorry about the miscommunication about the layout of the GetPerkInTree functions.

 

I thought I had read that you were going to go with the bit-packing method since it allows up to 4x11 perks to be defined, compared with 25 perks total (but possibly more than 4 in a rank).

No worries, there was probably mis-communication on my part too :smile:

 

I did use your bit-packing method, but the order of the bytes differed slightly:

return (2293766 >> Option) & 255;
// as opposed to
return 255 & (2293766 >> Option);

It's not an issue though; I've made a workaround so that it should now detect your EPT Custom Mod settings and I've also integrated it into ToolBoks, so hopefully it should work fine now :smile:

 

I haven't tested it extensively, but it looks like it's working in ToolBoks 1.3.0 :smile:

 

As always, keep up the excellent work! :smile:

[Bertilsson]

Would it be very difficult from a technical point of view to create an alternative mod with a gigantic perk tree (>8 perks freely selectable per rank) for one class only?

 

The goal would be to discard the class system completely and replace it with a single class for all soldiers in which the player freely shapes the soldiers into whatever he/she wants.

 

I know this is not the current plan for this mod, I'm just curious if it is realistic or not :)

[Amineri]

Effectively there are only two limitations:

 

1) Freeing up enough bytes in the actionscript to add more perk icons to the UI. This sprite was not created to grow procedurally -- every icon has to be explicitly placed.

 

2) Finagling the GetPerkInTree functions to return enough perks. The functions aren't very big -- currently I've squeezed in 44 perks total. However, if there were only 1 class you could make use of all of the functions. Perhaps designate each of the classes as a type of perk.

 

 

If you you were willing to put the psi perks into the same "single class", then you could use both ability trees that are currently available, with 3 perks displayed per, to get 6 perk options per rank. 6 perks * 7 ranks = 42 perks, which is getting pretty close to the complete number in vanilla. Bumping the UI up to handle 4 icons (which is fairly realistic) would give 8 perks per rank * 7 ranks = 56 possible perks.

 

Since this would be a significant rewrite, the way that the level-ups are stored could be modified so that more than 1 perk per level could be chosen, if desired.

 

Making a single class system mod would go beyond just the perks, though. The equipping / inventory system would need some reworking, particularly with regard to the Rocket Launcher and the 2nd large item slot. Essentially all soldiers would need to display:

1) armor slot

2) 2 large item slots

3) pistol slot

This leaves room for at most 2 small item slots, even with them squeezed together.

 

Now that I'm a bit more familiar with the actionscript modding, I might go back again and see if I can't get a scroll bar working for the inventory list in the armory UI.

[Bertilsson]

Thank you for the very quick and in dept reply as always!

 

Regarding the problem with rockets...

Another option would be to simply leave either pistols or rockets out of the game by chosing or not chosing the heavy as the one and only class.

 

If a soldier was given deep pockets, grenadier and bombardier perk, would he really miss rockets?

If soldiers had a little more ammo to begin with, would they really need the pistol? The guy with sniper rifle might feel a bit naked but he would simply have to chose between throwing a grenade or run away if an alien got to close for comfort.

 

I'm also guessing a heavy without the fire rocket perk would not be able to fire any rockets, so it could be made one of the later perks in order to avoid every soldier having a rocket launcher.

 

A more worrying issue would probably be abuction rewards and the sling shot reward guy. If heavy is the only existing (and working) class it would be kind of uncool to receive a broken sniper sergeant.

 

The biggest hurdle to overcome still seems to be putting in a gigantic perk tree.

[Amineri]

Okay, I've been stuck on this issue for too long and still can't come up with a good solution, so I'm going to put out a call for help.

 

The new perk tree has an issue regarding the keyboard/gamepad interface in that only perks in rows 0 and 1 are selectable. The mouse works fine, but it makes for a less-than-perfectly-enjoyable experience for those that prefer using a gamepad.

 

The issue comes about in XGSoldierUI. There are four functions that handle moving the perk selection cursor up, down, left and right. (The mouse interface uses a completely different mechanism)

 

The issue is this:

XGSoldierUI.OnPromotionLeft looks like this:

function OnPromotionLeft()
{
    SetAbilityTreeOption(1);
    PlayScrollSound();
    //return;    
}

Basically pressing the "left" key/button sets the cursor to select row 1.

 

Similarly, XGSoldierUI.OnPromotionRight looks like:

function OnPromotionRight()
{
    SetAbilityTreeOption(0);
    PlayScrollSound();
    //return;    
}

which sets the cursor to row 0.

 

In contrast, the function XGSoldierUI.OnPromotionUp looks like:

function OnPromotionUp()
{
    local int newBranch;

    newBranch = (GetAbilityTreeBranch()) - 1;
    // End:0x31
    if(newBranch < 1)
    {
        newBranch = 1;
    }
    SetAbilityTreeBranch(newBranch);
    PlayScrollSound();
    //return;    
}

This subtracts 1 from the current branch (corresponds to rank) and then bound limits the rank selection to be no less than 1. OnPromotion down is similar except it adds, and bound limits to 7 or 3 depending on whether the current tree is psi or ability.

 

This is the crux of the problem. To increment / decrement the row properly the current row has to be retrieved, added to, bound checked, and then the new row value set. The existing left/right functions are so small that I can't figure out any way to get some sort of working code in there.

 

Any suggestions or ideas would be most appreciated.

 

---------------------------

 

In case you are curious how the mouse interface works, it is driven by a callback from the Actionscript. One of the callback parameters is the name of the icon label that the mouse is hovering over (e.g. 'icon3_1'). The code breaks out the row and column numbers from the icon label and then set the row/branch using those values. The code is in UISoldierPromotion.OnMouseEvent.

 

[Bertilsson]

Just a little brainstorming to get that big brain of your running at full speed again :smile:

 

Is it possible to sacrifice Right function to make Left function bigger?

 

Is it possible retrieve current selection as a number 0-3 and use ++ operator to change the value and using Mod operator to enforce boundaries? Basically making 3+1 = 0.

 

Edit:

Psuedo code:

function OnPromotionLeft()
{
    SetAbilityTreeOption((GetAbilityTreeOption()+1)%4); 
}

Edited June 25, 2013 by Bertilsson

[Amineri]

Unfortunately I haven't been able to move bytes between functions in the upk code (which I have been able to do with the actionscript). The best I could do is use one as a helper function called from the other. Unreal Engine has big table computed at compile time that index where all of the functions are, so changing the size of a function would mean reworking where all those tables are (as best I understand it anyway).

 

The current selection row can be retrieved with GetAbilityTreeOption(). This takes 10 bytes. The OnPromotionLeft function has a total of 21 usable bytes in it. I've tried it before and had no success with trying to apply the increment operator to the return value of a function. The value is increased but only the copy returned by the function.

 

GetAbilityTreeOption() also cannot be replaced with a class variable reference:

simulated function int GetAbilityTreeOption()
{
    // End:0x30
    if(m_iCurrentView == 2)
    {
        return m_kSoldierPsiTree.Option;
    }
    // End:0x4D
    else
    {
        return m_kSoldierAbilityTree.Option;
    }
    //return ReturnValue;    
}

[Bertilsson]

Humm... Not following...

 

Would this be too long or the math not carried out?

SetAbilityTreeOption((GetAbilityTreeOption()+1)%4);

 

Also ignoring possible issues attempting to select perk 1 when only 0 and 2 exist...

[Amineri]

Scarily enough that target code is too long:

 

SetAbilityTreeOption takes 10 bytes. GetAbilityTreeOption takes 10 bytes. "+" operation takes 2 bytes. "%" operation takes 2 bytes. Int const 1 is 1 byte. Int const 4 is 2 bytes. That adds up to 27 bytes, and only 21 are available in the function.

 

It's definitely a headscratcher ...