Squad LUA theory

[Guessmyname]

This is just an idea I had. I'm tossing it up here to see how plausible it is.

This works off the basis that squads are built by ordering the construction of a dummy unit that, once built, spawns the squad units and removes itself from the game-world. Which I'm assuming is how S44 does it.

When the spawn dummy starts being built, it generates a squadID (four digit random number), and is passes this down to its 'child' units when they spawn.

When a child unit is selected, it searches for all other units with the same squadID on the same team and adds them to the selection.

That's quite literally it. The random number generator should prevent duplicates (or at least have so many combinations that it's highly unlikely to) and limiting the search to your team prevents the off-chance of a squad on another team having the same ID (possible, if my understanding of random number generators is correct. Same-team duplicates shouldn't be, I don't think). Theoretically speaking, using the squadID, you should be able to confer status affects and abilities too.

Some questions though:
What would be the best way to store squadIDs?
Would this have to be synced? (I'm guessing no, but it's worth checking)
Would this method work with multiple squads?
Could this be done in reverse to deselect single squads? Ie when a unit is deselected (though not by being killed), remove all same squadID units from selection.
This whole thing relies on there being a LUA callin when a unit is selected. I'm quite new to LUA, and thinking mostly in terms of an I/O system... does this 'OnSelect' style callin actually exist?

[Evil4Zerggin]

There is a SelectionChanged callin; however, not all mods implement it. IIRC it is not in the default widgethandler.

[Tobi]

You don't even need a random number generator. Could just use a global lastSquadID and for each new squad increment & assign that. It will take a while before you get any issues with overflow / wraparound. (like 2^24 squads or so)

Disadvantage ofc is that the value in this case must be private, otherwise a widget/player can figure out how many squads opponent made by observing the increase in squad ID.

Advantage is that squadIDs generated this way are guaranteed to be unique, even over all teams.

[Saktoth]

I dont really see the value, other than to frustrate the players ability to individually select his units.

Squads would be useful if they actually behave as a group in some way (IE, taking cover as a group, re-enforcing as a group, assigning weapons or specific tasks that count the group as a whole etc). But on top of the current system, not really.

The best use of squads would be to reduce the huge pathing lag you seem to get in games like s44 (Im just guessing that thats what it is, i havent really tested it extensively). Making it one unit with several models would help with that, but i dont see how this system would.

[Guessmyname]

It will be useful if you want several units (like, say, infantry) to work as one, both to reduce the number of units the player has to keep track of whilst still having stupidly large armies and the force diversity of units (for example, a player would not be able to spam rocket infantry because they come in squads mixed in with all the other types, for example)

Stop thinking in terms of BA and CA. Shock and horror, not all people subscribe to your ideas of gameplay and balance. The Total War series has you moving around units in hundred-strong regiments, and you don't hear anyone bitching about not being able to select a single swordsman. DOW too, uses a squad system, and again: no complaints. If you don't want it, you don't have to use it, it's not like I'm going to make it then go "BAAAAAAW! YOU MUST ALL USE MY LUA!", am I?

[SpliFF]

I'll be using a system like this for Metalstorm. My thinking was that it would probably be easier to simply assign all squadmates to guard one real squad unit and use that units id as the squad/leader id. If this unit is killed simply pick the first unit returned by deadunit:GetGuardingUnits(), assign it the dead units order queue, update the leader id on the squad mates, and reassign them to guard the new leader. This way you always have an accessible reference for a units leader, and overall your code would be quite simple and fast. In addition you solve the issue of generating unique squad ids since unit ids are already unique.

You'd probably want a couple of checks to ensure the new leader is roughly the same type as the old (ie, there's no point making an engineer or ship lead a land assault group).

If any squad member is selected check if it's leader id == it's own id and if not reassign the selection to the squad leader. This makes squad selection easier and prevents units being accidentally detached from the squad. You'd still want some kind of visual cue that the selection was made, perhaps a yellow outline for squadmates and green for the leader.

You can allow individual unit selection when a meta key is held. The selected units could then be assigned to other squads with a guard order or split into a new squad by simply issuing any other order.

An alternate method is to flip the logic and only select squads when a meta key is pressed. I think this would cause squads to get split up too much though.

I'm still working on my models but once I get to this part I'll be curious to see what you've come up with.

[zwzsg]

Err, why is the topic Squad LUA theory, and why are you talking in future and conditional tense, considering The Cuberor's Finest has been released?

[Pressure Line]

because the thread is almost 2 months old?

[zwzsg]

Look at the date of SpliFF post just before mine.

[lurker]

There was squad code well before this thread; why are you pointing to the most recent example rather than an older one?

[1v0ry_k1ng]

the main problem with squads like this is that unit behavior and pathfinding is often a bit retarded

[SpliFF]

I'd just make the leader a "pusher" unit (there's an FBI tag for that) and the squad members set to guard. This should mean that even if the leader is blocked in he can push his way out of the pack and the rest would then follow. In theory.