Inheriting buildqueues and guardgroups

Targ Collective · Post by **Targ Collective** » 04 May 2006, 11:01

Fast on the heels of my last query... And a sight more complicated.

If a group is guarding a unit, and the unit is destroyed, the entire group goes inert. If a con-unit is programmed with a buildqueue and the con-unit is destroyed, the guards do not inherit the buildqueue and go inert.

Why not assign a new leader in a group, inheriting the group's commands (if applicable - a Tech 1 con unit can't build fusions, an AK or Peewee can't build full stop...)

This is way up there in bells-and-whistles land, but I thought it worth mentioning in case any of the devteam have a spare moment. I'm aware that this sort of dynamic grouping would be a nightmare to code, and I'm aware that the particular commands attached to construction complicate matters further. This has never stopped the devteam before to my knowledge; otherwise I wouldn't mention it.

So am I asking too much...?

AF · Post by AF » 04 May 2006, 16:02

groupAI group AI groupAI GROUPAI!!!!!!!

Felix the Cat · Post by **Felix the Cat** » 04 May 2006, 22:58

AF wrote:groupAI group AI groupAI GROUPAI!!!!!!!

GroupAI really needs to not be tied to group numbers. You can't bind a unit with group AI to a numbered group and still retain the AI; you can't bind a member of a numbered group to a groupAI and still retain the group number.

Until then, this limits a lot of your "GROUPAIGROUPAIGROUPAI" spam.

AF · Post by AF » 05 May 2006, 14:18

Why not just shove the lot under the groupAI then?

i dotn knwo why this couldnt easily be doen with a groupAI, assign the helpers to a grouPAI then tell them all to help the cosntructor, then once the cosntructor is destroyed you can make the grouPAI fire off the necessary comamdns and autodestruct itself thus leaving the cons to do what ti said.

Or better yet simply assign ti to a wind generator soemwhere, you dont need to actualyl assign it to a unti to be able to make it have control, it'll just act globally doing it for all instances fo untis -> guarding cosntruction unit.

Thus you CAN have a group where some of the units are subject to groupAI's and some are not.

So please if I didnt know what i was talking about I wouldnt be praising the idea of groupAI.

Would you rather we waited with this at the end of a very long Todo list? Or implement a groupAI in a day?

Targ Collective · Post by **Targ Collective** » 05 May 2006, 14:36

Hmm. Would this have to be assigned to a unit at all? If you could run this from an AI program like NTAI, it would be fantastic.

AF · Post by AF » 05 May 2006, 14:49

GrouPAI sending comamdns and what nto ahev the same callback interface as a global AI minus a cheat itnerface.

So all you need to do is assignt he groupAI to any single unit and then it'll be able to exercise control voer any of your units.

That's how the cursor AI worked, it was assigned to an idle building like a wind gen or a fusion reactor (could have used a peeweee even but greater chance that it'd be killed), and the AI worked untill either you unassigned it or that building/unit was killed.

I'll consider doing this groupAI for tomorrow, but any groupAI's like this I'm going to force them to be attached to targetting facilities (I wont make it dependant on arm/core tho).

Targ Collective · Post by **Targ Collective** » 05 May 2006, 15:17

I'm not sure if that's such a good idea. This facility would be most useful in the early game when cadres of C-units are a-wondering the map mith mexspots in mind. By mid to late game this type of micro would be less important.

EDIT: How about linking it to the Commander? That would be incredible, there would be a balanced penalty to commbombing which makes the commander less of a mobile nuke.

AF · Post by AF » 05 May 2006, 15:18

hmmm, I'll have to find another solution then....

edit:: Yah ti seems I'll have todo that, though rather I'd make it check if you still have a commander every minute and then it'll disable itself and unassign once that happens, so you could keep the feature by building decoy commanders, or use them to regain the feature

Targ Collective · Post by **Targ Collective** » 05 May 2006, 15:25

That'd be cheating! Decoys can't commbomb.

AF · Post by AF » 05 May 2006, 15:27

Yes but you'd have to goto lvl 2 and get the resources and spend the time whereas the other player with their commander cna enjoy it from the very beginning......

Targ Collective · Post by **Targ Collective** » 05 May 2006, 15:29

Yes, but you can save your commander and build a decoy to take over. Which would give you a 'free' commbomb, for a unit with a weak laser and decent building capabilities.

AF · Post by AF » 05 May 2006, 15:33

At that point you have the resources to build whats needed to kill an enemy com or do it anyways by building farks and a laod fo energy/metal storage.

Eitherway I have no way of making a distinction between decoy commanders and ordinary commanders while keeping it mod independent

Targ Collective · Post by **Targ Collective** » 05 May 2006, 15:37

I don't follow. Mods don't even have to have decoys.

AF · Post by AF » 05 May 2006, 15:40

To detect the commander I have the following statement

if(ud->sicommander == true)

but that is true for both Commanders and decoy commanders, thus I cannot tell the difference.

Thus I would ahev to do

if(ud->name == string("ARMCOM") etc..

And that would break compatability with other mods such as EE, or gundam, or WD or AATA etc....

I term it as a abd practise to release mdo dependant AI's now, especially after I got rid fo the nasty hardcoded buildtrees of NTAI 0.28 in favor fo the unviersal build trees and moddable routines that came afterwards....

Targ Collective · Post by **Targ Collective** » 05 May 2006, 17:08

I can see that would be a problem. Unitname would have to be the way to go, as far as you can do it anyway.

To make things as mod-compatible as possible you could ask the user to edit a given textfile from the console in the case of an unrecognised mod. The more popular ones could be written into the AI itself using a wildcard system to get around version numbers, like you suggested Submarine should use for config files.

You could even affect a player's economy based on the Commanders's presence this way, theoretically. Now that would turn commbombing into a sacrifice...

EDIT: Didn't read all of your last post, sorry. Until the Spring engine can distinguish between commanders and decoys in a universal fashion, this is the only way. Which means asking the devteam to create a Decoy flag...

AF · Post by AF » 05 May 2006, 17:52

I have an idea that might solve that, manually parsing sidedata.tdf

Sadly I cant get chat messages from the console with groupAI's, I'd have to do a little trickery involving Ntai which means I'd need to have an instance of Ntai actively running (beat NTai before the end and the whole thing falls apart =( )

Felix the Cat · Post by **Felix the Cat** » 05 May 2006, 20:42

A "global groupAI" interface would be nice, just a popup with a list of installed groupAIs that you can apply to all of your units at once without creating a group and that would not be dependent upon units continuing to live.

AF · Post by AF » 05 May 2006, 20:46

You cna have globalAI helpers which would be sorta like that but there arent any atm, and there's no support in any of the lobbys/guis

Spring RTS Engine

Inheriting buildqueues and guardgroups

Inheriting buildqueues and guardgroups