Multi-group membership for droids?

For AI and campaign script related discussions and questions
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Multi-group membership for droids?

Post by Per »

I am rewriting the group code for qtscript, and when doing that, made it possible for droids to be member of multiple groups and for each scripting context to have its own groups (right now they'd overwrite each other's group information if they try to group the same droids).

Now, about the former change, I noticed that the code would have been far simpler and much faster (in terms of algorithmic complexity for inserts and removals - I did not actually do any measurements), if a droid could only be a member of one group at a time (in each scripting context, of course). So, is this a functionality you would make use of if it existed / something that would be missed if not? I'm leaning towards removing it, since I do not see that many use cases. Comments?
User avatar
Shadow Wolf TJC
Regular
Regular
Posts: 1047
Joined: 16 Apr 2011, 05:12
Location: Raleigh, NC

Re: Multi-group membership for droids?

Post by Shadow Wolf TJC »

I've seen StarCraft 2 allow players to assign the same unit into multiple groups. For example, let's say that the player greated a large ground force consisting of Marines, Marauders, Medics, and Reapers. They could assign the entire group as group 1, have all the Marines as group 2, have the Marauders as group 3, have the Reapers as group 4, and have the Medics as group 5. The player can now both easily macromanage the entire group, as well as each of the smaller groups that comprise the whole, allowing the player to quickly order the Marines to shoot down flying Mutalisks or use Stimpacks, the Marauders to blast apart armored Roaches or Stalkers, the Reapers to take down structures or leap to higher ground, and the Ghosts to lay down a well-placed nuke.

Such a change would allow players to micromanage and macromanage their forces in a similar way. For example, let's say that the player had a task force consisting of heavy tanks armed with Heavy Cannons, light tanks armed with Lancers, light tanks armed with Assault Guns, hovercraft armed with Pepperpots and Incendiary Mortars, Cyborg Flamers, and a hovercraft equipped with a Sensor Turret, while back at base, there's a group of Hellstorm-armed tanks back at base, ready to lay down fire support. All the units in the group, except for the Hellstorms, would be grouped into group 1 for moving the entire group, including when ordering a mass retreat.

The heavy tanks armed with Heavy Cannons, and the light tanks armed with Lancers could be put into group 2 for dealing with enemy tanks. Moreover, the Lancers could be put into group 3 and the heavy tanks into group 4 in case you want the heavy tanks to tank hits for the lighter tanks. The Assault Gun tanks could be placed into group 5 for dealing with enemy Cyborgs. The Cyborg Flamers could be put into group 6 to charge them against enemy tanks, Cyborgs, or bunkers, and keep them from going near hardpoints. The Sensor hover, Pepperpot hovers, and Incendiary Mortar hovers could be put into group 7 in case you need them to move to water to attack from a different front than the rest of the assault force. The Sensor hover would be put into group 8, and the Pepperpots and Incendiary Mortars put into group 9 for taking favorable positions for laying down fire support. Finally, the Hellstorms (which were kept separate from group 1 due to their long range) could be put into group 0 for the same reasons as the mortar hovers.

And if the entire assaulting force needs to retreat, well, since we assigned them as group 1, we could quickly order them to withdraw with a single press of a hotkey, and a single click of the mouse. See how easier it would be to micromanage an entire assault force?
Creator of Warzone 2100: Contingency!
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: Multi-group membership for droids?

Post by aubergine »

Personally, I would avoid having droids in multiple groups. While it might sound like a good thing to have, all that's going to happen is that scripts will need loads of extra code when processing groups to try and make sure that orders given to group A are not conflicting with orders given to group B, etc. In other words, multiple groups will be confusing.

Note: I'd very much like to see transports have their own "cargo" group -- so when a transport is created, a new group is made straight away just for it's cargo. I can then look at the .cargo property of a transport, enumGroup(transport.cargo) to get a list of droids currently on the transport.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: Multi-group membership for droids?

Post by Per »

@ShadowWolf - This has nothing at all to do with player groups. This is only for scripting. These two kinds of groups are totally unrelated. I know, this is somewhat confusing...

@aubergine - Transport groups will become unrelated with script groups with my changes. If you need to access the cargo list directly, we'd need a new interface for that. Cargo in general is a bit tricky, since they are not part of the main droid lists, so eg enum*() do not see them.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: Multi-group membership for droids?

Post by aubergine »

@Per - I listed a few ideas that would make transports fully usable by scripts here: viewtopic.php?f=35&t=9668#p107678
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
NoQ
Special
Special
Posts: 6226
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: Multi-group membership for droids?

Post by NoQ »

My current code in NullBot assumes that once you add a droid to another group, it gets removed from its original group. I don't think providing a compatibility layer on my end will be a problem though (remove droid from its original group iff the function for removing is defined).he original one.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: Multi-group membership for droids?

Post by Per »

Ok, dropped the multi-group feature. It is now committed otherwise to master. New features compared to the old way: Each scripting context has its own groups - no more overwriting each other's groups if you put enemy droids in groups. Also does not share groups with transports and commanders. If a group becomes empty, an eventGroupEmpty(groupid) is triggered. This is quite useful for campaign scripting. Yet another thing - you can add pre-defined groups in labels.ini like this:
[group_0]
label = "scavgroup1"
player = 7
members = 1, 2, 3, 4
then query it with label("scavgroup1") and get a GROUP type object, which has an .id property giving you ID of the automatically created group for this label. All scripting contexts share the same label groups, you cannot create new ones from inside the scripting system, and they have negative array indices to avoid conflicts. (Yes, you read that right. Javascript is funny that way.)

Finally, a new global sparse array groupSizes[] can be queried directly for group size information. We already have groupSize(), but this is now deprecated. I figured I needed a place to store this info for each context anyway, so why not make it accessible.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: Multi-group membership for droids?

Post by aubergine »

Would it be possible to standardise on a 'group object', just like we have other object types?

So maybe a group object could contain the following properties:

* id = id of the group
* type = GROUP
* player = player who owns the group (doesn't mean they own the droids in it)
* label = label associated with the group (null if no label)

Or something like that? And keep groupSize(id) function as that's more in-keeping with the way the rest of the JS API works. enumGroup() would be used to get a list of members in group as it is currently. Possibly rename groupSize() to countGroup() so it's using similar naming convention to countDroid() and countStruct()?

However, if groupSizes[] is more desirable for some reaosn, consider the implications of that for a possible future "multiplayer script environment" as discussed elsewhere :hmm:

Will there be some sort of "group" type thing for droids attached to commanders / sensors?

Also, instead of eventEmptyGroup() would it be better to have eventGroupResize(groupID, previousMembers, currentMembers)? That would allow us to see when units are added to or removed (destroyed or put in another group) from the group. If numMembers==0 then we know the group is empty. But other times, I might just want to make the group retreat when it gets down to 5 members.

I think listening to the event would be better approach than constantly polling groupSizes[] array.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
NoQ
Special
Special
Posts: 6226
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: Multi-group membership for droids?

Post by NoQ »

Offtopic: may i ask again whether the workaround for 3.1 would be applied, as in #3684? Since last time we talked on IRC (a long time ago), i investigated how it's done in wzscript and found out it's almost exactly the same as i proposed (hence no debugging was ever possible and the argument in comment:9 doesn't seem valid). But since then i didn't receive any reply :(
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: Multi-group membership for droids?

Post by Per »

NoQ wrote:Offtopic: may i ask again whether the workaround for 3.1 would be applied, as in #3684? Since last time we talked on IRC (a long time ago), i investigated how it's done in wzscript and found out it's almost exactly the same as i proposed (hence no debugging was ever possible and the argument in comment:9 doesn't seem valid). But since then i didn't receive any reply :(
Done.

I've also changed the new event above into eventGroupLoss(object lost, group id, new group size), see 4ce8d2d03f09c20c3eceb0dc4b56bd73f3179717. Note that this means that eventGroupEmpty is now gone.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: Multi-group membership for droids?

Post by aubergine »

If any type of object can be added to the groups in wz 3.2, would it be worth renaming groupAddDroid() to groupAddObject()?

Also, will feature and structure objects be getting a .group property?
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: Multi-group membership for droids?

Post by Per »

aubergine wrote:If any type of object can be added to the groups in wz 3.2, would it be worth renaming groupAddDroid() to groupAddObject()?
Added groupAdd() in dc46de746baa6238f66b51831954b1ae3954d515 which can add non-droids. This deprecates groupAddDroid().
aubergine wrote:Also, will feature and structure objects be getting a .group property?
Is the .group property all that useful in the first place? I found no use for it, myself...
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: Multi-group membership for droids?

Post by aubergine »

Without .group, we'd have to iterate through enumGroup() for every group to try and find which group contains the object.

For example, if I have an attack group and a droid in it gets attacked, I can quickly get a list of all the other droids in that group as follows:

Code: Select all

function eventAttacked(victim, attacker) {
  var cluster = enumGroup(victim.group);
  cluster.forEach( function droid(to) {
    orderDroidObj(to, DORDER_ATTACK, attacker);
  } );
}
It will also be useful (in terms of having .group on structures / features) of checking health after an attack, checking positions, armed status of VTOLs, etc.

Also, I just noticed newGroup() is deprecated -- how to create new groups in WZ 3.2?
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: Multi-group membership for droids?

Post by aubergine »

Ah, just seen the note about using own number scheme for groups.

Why not have newGroup() just groupSizes.push(0) then return groupSizes.length-1? It will be more semantic and clear where groups are being created in scripts.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: Multi-group membership for droids?

Post by aubergine »

Should groupAddArea() just adds droids, or all objects in WZ 3.2?

EDIT: Or maybe a new typeFilter param that defaults to DROID, but can be DROID, STRUCTURE, FEATURE or ANY_OBJECT?
Last edited by aubergine on 12 Dec 2012, 18:39, edited 1 time in total.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Post Reply