R&D to Increase Squad Size

[Bertilsson]

That is my current plan. Not sure if I will find time to experiment with it before the weekend though :(

 

I expect it will take somewhere between 0.5 hours and forever to figure out how to call Barracks().DEMOAddNewSoldiers(127) from within XGChooseSquadUI.UpdateView().

Adjusting DEMOAddNewSoldiers should take almost no time at all.

[XMarksTheSpot]

Great work, fellas. In the next Long War Beta.

 

The flicker of default stances when the shift happens doesn't bother me. The soldiers appearing in the wrong slot (atop another guy) feels like more of an issue. (It is fixed by shifting one spot in either direction). I might suggest refreshing the screen every time a new soldier is loaded -- the flicker might be concealed by the choose-soldier UI, anyway, which is what appears to happen when a new pawn appears.

The pawn cycling still leaves a lot to be desired, but it's a start.

 

Refreshing the positions every time a change is made to the loadout sounds like a good idea, but you'd need to retrieve the current cycle offset value in some way. Currently the offset is only locally available as part of a mouse event callback object, I'm not sure if it's possible to query individual flash components directly to get at that value.

One other possiblity would be to persistently store the offset value in some otherwise unused instance variable of one of the classes involved in the cycle method call chain. Or alternatively the current fill order array inside UISquadSelect_SquadList could be queried and compared to the default fill order, in a similar fashion as I did in the innermost block of my proposed DEMOAddNewSoldiers() method, but in reverse.

[johnnylump]

 

 

also, it seems as though if you guys have made some changes to the ui this patch, its made things much harder to click on. I have trouble clicking on base prompts and soldiers in the field regularly now, it takes several clicks to get them to recognize and the highlighter box doesn't come up when hovering over a soldier reliably.

 

Had this from a player from latest Long War Beta (2.1b2). I haven't observed the issue the player is reporting in my testing, but the only UI and mouse related change in the Beta is the UISquadeSelect_SquadList.OnMouseEvent.

 

EDIT: No one else is seeing it, so it may be specific to that player's system, or it may require a complex set of triggers that no one else has found (including me).

Edited September 22, 2013 by johnnylump

[Bertilsson]

Refreshing the positions every time a change is made to the loadout sounds like a good idea, but you'd need to retrieve the current cycle offset value in some way. Currently the offset is only locally available as part of a mouse event callback object, I'm not sure if it's possible to query individual flash components directly to get at that value.

One other possiblity would be to persistently store the offset value in some otherwise unused instance variable of one of the classes involved in the cycle method call chain. Or alternatively the current fill order array inside UISquadSelect_SquadList could be queried and compared to the default fill order, in a similar fashion as I did in the innermost block of my proposed DEMOAddNewSoldiers() method, but in reverse.

How about letting DEMOAddNewSoldiers store the current offset in m_arrFillOrderIndex[12] every time the function is called and iNumSoldiers <127 ?

 

It would require some checks to verify the length and code to expand the array the first time.

 

Then later idx could be set to m_arrFillOrderIndex[12] or iNumSoldiers depending on if iNumSoldiers <127 or not, basically selecting between refreshing or shifting.

 

Edit: In case that is a viable option this would be the hex-code for calling DEMOAddNewSoldiers(127) from XGChooseSquadUI.UpdateView (offset 2712941)

 

 

2D 23 00 00 AB 1F 00 00 00 00 00 00 2D 23 00 00 91 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1A 01 00 00 28 1F 00 00 99 00 00 00 EC 00 00 00 1B C6 2B 00 00 00 00 00 00 16 1B F0 2B 00 00 00 00 00 00 16 05 7E 08 00 00 00 01 7E 08 00 00 0A 6E 00 25 1B 1A 2C 00 00 00 00 00 00 16 1B DA 2B 00 00 00 00 00 00 16 1B 97 2B 00 00 00 00 00 00 16 19 1B F4 02 00 00 00 00 00 00 16 0C 00 54 28 00 00 00 1B B1 07 00 00 00 00 00 00 24 7F 16 06 8C 00 0A 89 00 26 1B 95 2B 00 00 00 00 00 00 16 1B 97 2B 00 00 00 00 00 00 16 06 8C 00 0A FF FF 1C 91 08 00 00 16 04 0B 53 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 00 00 00 02 00 02 00 29 2C 00 00 00 00 00 00 

 

 

Edited September 21, 2013 by Bertilsson

[johnnylump]

I have what appears to be a SHIV-related AAR bug ...

Blinding Throne, AAR (Slingshot #1)

http://steamcommunit...s/?id=180382541

Fading Summer #1, AAR, (large scout UFO raid)

http://steamcommunit...s/?id=180382595

Fading Summer #2, AAR, played from mid-mission reload and had this alternative outcome

http://steamcommunity.com/sharedfiles/filedetails/?id=180559401

* clicking Thunder-1's box takes us to the barracks/promotion screen of the soldier who should be in that slot, a medic who achieved a promotion during that mission.

Purple Dirge (abductions), dropship UI before launch (to help locate squad members' positions)

http://steamcommunity.com/sharedfiles/filedetails/?id=180560181

Purple Dirge, AAR

http://steamcommunity.com/sharedfiles/filedetails/?id=180560181

(XCom immediately fled the mission)

What I think is happening is the SHIV is showing up in the wrong position on the list. On the "Fading Summer #1" screenie, the SHIV was in the sixth (rightmost) slot on the dropship equip screen. Here it shifted to the third slot, overwriting an injured soldier (who safely returned to the barracks), and leaving the SHIV slot blank.

As far as I can tell, it's merely an presentation issue with no effect on gameplay. (Amineri doesn't think this is an issue with Long War's post-mission code).

Any ideas? Any more info I can provide?

[XMarksTheSpot]

How about letting DEMOAddNewSoldiers store the current offset in m_arrFillOrderIndex[12] every time the function is called and iNumSoldiers <127 ?

Yeah, sounds feasible, though a bit opaque. The significance of the value 127 and an additional array element wouldn't be immediately apparent to other people, but I suppose that's the price you pay for piggy-backing existing systems due to the strict limitations of UnrealScript hexing... you just have to make sure everything's properly documented :smile:

 

I have what appears to be a SHIV-related AAR bug ...

Good catch, I haven't tested the Debrief UI with SHIV units or else I would have noticed that instance of erroneous code copy-pasting :psyduck:

It seems I've referenced the wrong variable in one line of ActionScript code, but fortunately a fix is rather simple:

change … 00 96 0B 00 04 0D to … 00 96 0B 00 04 05, that should do the trick :smile: The hex sequence should be unique in the Debrief file I posted, let me know if SHIVs keep misbehaving :wink:

Edited September 22, 2013 by XMarksTheSpot

[johnnylump]

 

 

that should do the trick

 

That worked, thanks! My only remaining question is what combination of punctuation does one type in to get that strange ducklike critter in your post? :)

Edited September 23, 2013 by johnnylump

[Amineri]

: psyduck : = :psyduck:

[Bertilsson]

 

How about letting DEMOAddNewSoldiers store the current offset in m_arrFillOrderIndex[12] every time the function is called and iNumSoldiers <127 ?

Yeah, sounds feasible, though a bit opaque. The significance of the value 127 and an additional array element wouldn't be immediately apparent to other people, but I suppose that's the price you pay for piggy-backing existing systems due to the strict limitations of UnrealScript hexing... you just have to make sure everything's properly documented :smile:

 

I'll test it as soon as I have completed the new version of the jump assistant (any day now).

[XMarksTheSpot]

That worked, thanks! My only remaining question is what combination of punctuation does one type in to get that strange ducklike critter in your post? :smile:

Glad it worked, I wasn't sure it was the only instance where I messed up, I was just quickly reviewing the file I posted (no time to test! :laugh:).

As for the emoticons, the advanced editor under More Reply Options features a button that'll show a selection of smileys to choose from and will display their corresponding :code: on mouseover.

For that particular Pokémon it's :рѕiduck:, as Amineri pointed out :smile: (Note that I used a similarly-looking unicode character in place of the p)

 

Also, regarding

also, it seems as though if you guys have made some changes to the ui this patch, its made things much harder to click on. I have trouble clicking on base prompts and soldiers in the field regularly now, it takes several clicks to get them to recognize and the highlighter box doesn't come up when hovering over a soldier reliably.

I'm not sure I understand this correctly, but it appears that person is having trouble selecting stuff in the tactical game? I find it hard to believe, that a change to a flash-related UI method in the strategy game has any effect on the tactical game, so I'd dismiss this case as coincidental and more likely to be due to the general shoddiness of the game's mouse input implementation :laugh:

For instance, I also noticed that the game often does not register when I have moved the mouse cursor from one highlighted element to another, e.g. in the case of the soldier loadout screen's item boxes or really any kind of list of buttons (which applies to pretty much all menus).

This leads me to believe that controller input was developed as the primary means of input and mouse input has been somewhat neglected as it's far from perfectly implemented :geek:

Edited September 23, 2013 by XMarksTheSpot