R&D to Increase Squad Size

[Bertilsson]

Something like this psuedo code should probably do the trick:

ignoreCounter = 0
foreach GetWorldInfo().AllActors(class'XGUnit', kUnit)
  {
    if(kUnit.RoomLocation == 1)
    {
      ++ ignoreCounter
      if (ignoreCounter > 5)
      {
        kUnit.xlocation = kUnit.xlocation - someoffsetvalue
      }
    }    
  }

However I am not even close to translating that into something real, so in the end it is a safe bet I won't be the one doing it :)

[Bertilsson]

Unless someone can figure out how to make the below code shorter in bytes it looks like we may be stuck with linear fillorder after all...

simulated function Init(XComPlayerController _controller, UIFxsMovie _manager, UI_FxsScreen _screen, XGMission kMission, bool bNav)
{
  local XGShip_Dropship kSkyranger;

  PanelInit(_controller, _manager, _screen);
  bCanNavigate = bNav;
  kSkyranger = kMission.GetAssignedSkyranger();
  iNewIndex = 0;
  m_iMaxSlots = kSkyranger.GetCapacity();
  tmpIndex = m_iMaxSlots / 2;
  J0xAF:
  // End:0xF6 [Loop If]
  if(iNewIndex < m_iMaxSlots)
  {
    m_arrFillOrderIndex.AddItem(tmpIndex);
    tmpIndex += 1; //Only 16+1 bytes left to replace 1 with (((iNewIndex%2)*2)-1)*(iNewIndex+1)
    ++ iNewIndex;
    // [Loop Continue]
    goto J0xAF;
  }
  m_arrUIOptions.Add(m_iMaxSlots);
  //return;  
}

Reference to iNewIndex is 5 bytes each... That leaves 7 bytes to do two multiply operations, one add operation, one minus operation and a modulus operation...

 

So at least short term, which poison is worst?

Pawns not alligned leaving first soldier in middle of the screen but belonging to slot at far right? Or soldier pawns alligned with slots placing first soldier in the right corner?

Edited August 9, 2013 by Bertilsson

[XMarksTheSpot]

Unless someone can figure out how to make the below code shorter in bytes it looks like we may be stuck with linear fillorder after all...

[snip]

Wouldn't that code create wrong fill orders for any skyranger capacity that is not 12?

I believe tmpIndex would always have to start at 6.

Not that it matters if you can't fit in that formula in the loop, hmm... I'll try and think some more about how to optimize that... :/

 

Edit: same goes for m_arrUIOptions.Add(m_iMaxSlots), I think, needs to be 12 instead of m_iMaxSlots, also in the loop conditional, I guess?

 

Edit2: WolframAlpha suggests (-1)ⁿ*n for the alternating index summation (-1, +2, -3, +4, ...), looks simpler to implement to me, so how about

simulated function Init(XComPlayerController _controller, UIFxsMovie _manager, UI_FxsScreen _screen, XGMission kMission, bool bNav)
{
	local XGShip_Dropship kSkyranger;

	PanelInit(_controller, _manager, _screen);
	bCanNavigate = bNav;
	kSkyranger = kMission.GetAssignedSkyranger();
	m_iMaxSlots = kSkyranger.GetCapacity();
	iNewIndex = 1;
	tmpIndex = 6;
	J0xAF:
	// End:0xF6 [Loop If]
	if(iNewIndex < 13)
	{
		m_arrFillOrderIndex.AddItem(tmpIndex);
		tmpIndex += -1**iNewIndex * iNewIndex
		++ iNewIndex;
		// [Loop Continue]
		goto J0xAF;
	}
	m_arrUIOptions.Add(12);
	//return;  
}

Edited August 9, 2013 by XMarksTheSpot

[Bertilsson]

I think I finally agreed with myself and I that this was the different wanted fillorders for each kSkyranger.GetCapacity()-scenario:

1  = [0]
2  = [1, 0]
3  = [1, 0, 2]
4  = [2, 1, 3, 0]
5  = [2, 1, 3, 0, 4]
6  = [3, 2, 4, 1, 5, 0]
7  = [3, 2, 4, 1, 5, 0, 6]
8  = [4, 3, 5, 2, 6, 1, 7, 0]
9  = [4, 3, 5, 2, 6, 1, 7, 0, 8]
10 = [5, 4, 6, 3, 7, 2, 8, 1, 9, 0]
11 = [5, 4, 6, 3, 7, 2, 8, 1, 9, 0, 10]
12 = [6, 5, 7, 4, 8, 3, 9, 2, 10, 1, 11, 0]

And from that i find that kSkyranger.GetCapacity() / 2 is correct for first item in all scenarios.

 

m_arrUIOptions.Add(kSkyranger.GetCapacity()); works in all scenarios I have tested.

It results in same number of slots shown as skyrangercapacity in DGC.ini and it increase the number of available slots when OTS upgrades are bought. (The ots-naggers are never shown)

 

I will definitively look closer into the wolframalpha suggestion later tonight.

[XMarksTheSpot]

I think I finally agreed with myself and I that this was the different wanted fillorders for each kSkyranger.GetCapacity()-scenario:

[snip]

And from that i find that kSkyranger.GetCapacity() / 2 is correct for first item in all scenarios.

 

m_arrUIOptions.Add(kSkyranger.GetCapacity()); works in all scenarios I have tested.

It results in same number of slots shown as skyrangercapacity in DGC.ini and it increase the number of available slots when OTS upgrades are bought. (The ots-naggers are never shown)

Irrespective of the actual skyranger capacity there are currently 12 slot sprites which are always physically there, so to speak - this means the fill order should always begin at the center slot (in slot index terms, not capacity terms). If the capacity is lower than the total possible number of slots (in the UI) this essentially means that only up to <capacity> items will actually be used, the rest remain hidden.

To re-iterate, slot sprite 6 is the one aligned with the leader pawn and should always come first in the fill order array :smile: Like so:

1  = [6]
2  = [6, 5]
3  = [6, 5, 7]
4  = [6, 5, 7, 4]
5  = [6, 5, 7, 4, 8]
6  = [6, 5, 7, 4, 8, 3]
7  = [6, 5, 7, 4, 8, 3, 9]
8  = [6, 5, 7, 4, 8, 3, 9, 2]
9  = [6, 5, 7, 4, 8, 3, 9, 2, 10]
10 = [6, 5, 7, 4, 8, 3, 9, 2, 10, 1]
11 = [6, 5, 7, 4, 8, 3, 9, 2, 10, 1, 11]
12 = [6, 5, 7, 4, 8, 3, 9, 2, 10, 1, 11, 0]

Edited August 9, 2013 by XMarksTheSpot

[TheOldOne822]

I haven't looked at it in detail, but I think the arrSmallItems array is initialized to hold up to 16 elements, so additional items beyond the standard two should be accessible in there. Even if the backpack label would be re-jiggered to be used as another item label this would still not be enough for mods introducing more than 3 small item slots.

What I'd propose is a different direction: I'd do away with the second item label, make the first one larger and able to auto-scroll vertically (perhaps sacrificing its horizontal auto-scrolling behavior in the process, but I'd call that acceptable). Instead of providing single strings to various variables the snippet above should then be re-coded to loop through the whole arrSmallItems array, concatenate all non-empty name strings with line breaks in-between and storing it all in item1.

How's that sound? :smile:

I like that idea and feel it would be the best thing we can do with the "backback" list.

 

I don't know much about unreal but would this code work for the loadout

simulated function Init(XComPlayerController _controller, UIFxsMovie _manager, UI_FxsScreen _screen, XGMission kMission, bool bNav)
{
    local XGShip_Dropship kSkyranger;

    PanelInit(_controller, _manager, _screen);
    bCanNavigate = bNav;
    kSkyranger = kMission.GetAssignedSkyranger();
    m_iMaxSlots = kSkyranger.GetCapacity();
    iNewIndex = 1;
    tmpIndex = m_iMaxSlots / 2;
    J0xAF:
    // End:0xF6 [Loop If]
    if(iNewIndex <= m_iMaxSlots)
    {
        m_arrFillOrderIndex.AddItem(tmpIndex);
        tmpIndex += -1**iNewIndex * iNewIndex
        ++ iNewIndex;
        // [Loop Continue]
        goto J0xAF;
    }
    m_arrUIOptions.Add(m_iMaxSlots);
    //return;  
}

Edit: forgot the code tag

[Bertilsson]

Irrespective of the actual skyranger capacity there are currently 12 slot sprites which are always physically there, so to speak - this means the fill order should always begin at the center slot (in slot index terms, not capacity terms). If the capacity is lower than the total possible number of slots (in the UI) this essentially means that only up to <capacity> items will actually be used, the rest remain hidden.

To re-iterate, slot sprite 6 is the one aligned with the leader pawn and should always come first in the fill order array :smile: Like so:

1  = [6]
<snip>
12 = [6, 5, 7, 4, 8, 3, 9, 2, 10, 1, 11, 0]

The problem with doing it that way is that it results in at least 7 slots shown regardless of skyranger capacity.

Even if skyranger capacity is 1 you will still end up with a soldier in slot 6 and you would have slot 0-5 turned into the weird empty kind where you can load soldiers that doesn't show up on mission.

 

So it would then require some other mechanism to make sure the unused slots are either hidden or disabled...

[XMarksTheSpot]

The problem with doing it that way is that it results in at least 7 slots shown regardless of skyranger capacity.

Even if skyranger capacity is 1 you will still end up with a soldier in slot 6 and you would have slot 0-5 turned into the weird empty kind where you can load soldiers that doesn't show up on mission.

What you're describing is a side-effect of the fill order and UI options array having different lengths, as long as you call m_arrUIOptions.Add(12) you should be fine from my understanding.

[Bertilsson]

I have now implemented this:

simulated function Init(XComPlayerController _controller, UIFxsMovie _manager, UI_FxsScreen _screen, XGMission kMission, bool bNav)
{
  local XGShip_Dropship kSkyranger;

  PanelInit(_controller, _manager, _screen);
  bCanNavigate = bNav;
  kSkyranger = kMission.GetAssignedSkyranger();
  m_iMaxSlots = kSkyranger.GetCapacity();
  tmpIndex = 6;
  I = 1;
  J0xA4:
  // End:0x105 [Loop If]
  if(I <= m_iMaxSlots)
  {
    m_arrFillOrderIndex.AddItem(tmpIndex);
    tmpIndex += ((-1 ** I) * I);
    ++ I;
    // [Loop Continue]
    goto J0xA4;
  }
  m_arrUIOptions.Add(12);
  //return;  
}

with the plan to modify updatedata to use presence in m_arrFillOrderIndex to determine if slot should be disabled true or false.

 

But tmpIndex += ((-1 ** I) * I); does not seem to handle the flip flop mechanism properly... It starts of well with slot6 slot5 and then it goes starts taking jumbo steps...

 

Edit: Perhaps it should be tmpIndex += (-1 ** (I * I)) ?
Guess I'll just have to calculate them manually to see what it does... :smile:

Edit2: ehrm...**( i * i) would become very large very quick so I think I can abandon that theory right away...

Edit3: -1 ** i can only be -1 or +1 depending on odd or even i... And that is the same as the left part of this ((i%2)*2-1) * (i+1);.... Which I did test calculate without problems.... So I guess it can only be +1 missing... Should be simple to test.

Edited August 9, 2013 by Bertilsson

[XMarksTheSpot]

I have now implemented this:

[snip]

with the plan to modify updatedata to use presence in m_arrFillOrderIndex to determine if slot should be disabled true or false.

 

But tmpIndex += ((-1 ** I) * I); does not seem to handle the flip flop mechanism properly... It starts of well with slot6 slot5 and then it goes starts taking jumbo steps...

 

Edit: Perhaps it should be tmpIndex += (-1 ** (I * I)) ?

Guess I'll just have to calculate them manually to see what it does... :smile:

Nice work so far :thumbsup:

I still believe the loop condition should be if(I <= 12), though. You don't need to modify UpdateData(), it already has a mechanism in place to mark slots exceeding the capacity as unavailable, but for this to work m_arrUIOptions and m_arrFillOrderIndex have to have the same length, I can't stress this enough :sweat: That's why the loop always needs to fill 12 items into m_arrFillOrderIndex.

 

No idea about the flip-flop formula, looks like an order-of-operations problem to me :confused:

The -1**I part is for alternating the sign of the summand, -1**(I*I) doesn't make much sense here, you'd always get the negative square of I that way, but perhaps this is what's happening although UE Explorer decompiles the assignment as ((-1 ** I) * I). *math fail* :wacko: you'd only get -1 or +1 out of that formula.

Have you tried changing the order around a bit, e.g. += I * (-1 ** I)?

 

Edit3: -1 ** i can only be -1 or +1 depending on odd or even i... And that is the same as the left part of this ((i%2)*2-1) * (i+1);.... Which I did test calculate without problems.... So I guess it can only be +1 missing... Should be simple to test.

The i+1 part was only in the original formula because the loop index started at 0 instead of 1 as it is now, so I don't think that's the culprit. Can't hurt to try though :smile:

Edited August 9, 2013 by XMarksTheSpot