"living stuff" reclaiming ai?
Moderator: Moderators
"living stuff" reclaiming ai?
You know that situation when due to limited ressources or building space, you wanna reclaim lots of stuff (windmills when you already have fusions for example), but have to select everything one by one? So what i'd like to see is an ai quite similar to the mex upgrader ai, only that you can somehow choose a certain building (maybe select one before you activate the ai) and the cons assigned to that ai start to reclaim the selected building (like mex upgrader ai where they reclaim mexes, only that they wouldn't replace the stuff with something different, a similar area/all selection would be handy too...). Could be quite useful in certain situations imho (for example on Charlie in the Hills when you started on the mountain and thus have limited building space, or on Greenfields when you have spammed windmills and metalmakers everywhere and want to get rid of them, but don't want to blow up the precious metal by self-destructing them).
- SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
I think we just need smarter, more comprehensive upgrade code that realizes that you're "retiring" a class of Unit, and either makes it reclaim itself, or does a smart replacement with whatever supersedes the older unit.
Er, now that we have upgrade code, I guess I should find something else to whine about, eh?
Er, now that we have upgrade code, I guess I should find something else to whine about, eh?
Drag reclaim is a must, self-reclaim too, but I propose a more general and mod-friendly solution:
I don't know if Spring already does that, or how the commands are done at all, but:
In object-oriented programming terms, whenever you select something, or drag a area to select all the objects, this action should generate an Object or a List of Objects.
When issuing a command, it should take the give Command object and couple it with the Object or List of Objects:
or if there's an unit or more than one to receive such commands:
or maybe if you queue the commands (and more simply):
(But, to be honest, I believe the command queue shouldn't be done here, but I have no reason why not)
For every command, the engine should find(lookup) the method that implements the interface (or throw an exception if none are found).
The implementing methods should be scriptable and mod-controlled, so for every command they want to do different(or even new, mod-exclusive commands), they should inherit the default Spring command implementation and overload the commands they want.
This way, a self-D could call its own AI, which would decide a less damaging place to blow up, or to ask the next c-unit/building to reclaim itself. Although I believe this self-reclaim should be done with a separated self-reclaim command, or by overloading the reclaim command.
Since it's scripted, the user can also create his own commands.
I don't know if Spring already does that, or how the commands are done at all, but:
In object-oriented programming terms, whenever you select something, or drag a area to select all the objects, this action should generate an Object or a List of Objects.
When issuing a command, it should take the give Command object and couple it with the Object or List of Objects:
Code: Select all
doCommand(Command c, GameObject target);
doCommand(Command c, List<GameObject> target);
Code: Select all
doCommand(Command c, GameObject source, GameObject target);
doCommand(Command c, GameObject source, List<GameObject> target);
doCommand(Command c, List<GameObject> source, GameObject target);
doCommand(Command c, List<GameObject> source, List<GameObject> target);
Code: Select all
doCommand(List<Command> commandQueue, List<GameObject> source, List<GameObject> target);
For every command, the engine should find(lookup) the method that implements the interface (or throw an exception if none are found).
The implementing methods should be scriptable and mod-controlled, so for every command they want to do different(or even new, mod-exclusive commands), they should inherit the default Spring command implementation and overload the commands they want.
This way, a self-D could call its own AI, which would decide a less damaging place to blow up, or to ask the next c-unit/building to reclaim itself. Although I believe this self-reclaim should be done with a separated self-reclaim command, or by overloading the reclaim command.
Since it's scripted, the user can also create his own commands.
For a modding based solution, you could just reduce the self-d on winds and metal makers so it does no damage, though you'd probably need to modify the .cob so it leaves wreckage (though doesnt matter for MM's as its only 1 metal).
But then andy cant micro self-d of his winds to take out enemy jeffies...
But then andy cant micro self-d of his winds to take out enemy jeffies...
- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
On reclaim orders:
If you do a reclaim order of any kind (area / point etc) on a feature or the map floor, then only reclaim features
If you do a reclaim order of any kind (area / point etc) on a unit (and by 'on a unit', you start the order by clicking on a unit and dragging or whatever), then only reclaim units. Maybe have it only reclaim that type of unit if you press alt or something
If you do a reclaim order of any kind (area / point etc) on a feature or the map floor, then only reclaim features
If you do a reclaim order of any kind (area / point etc) on a unit (and by 'on a unit', you start the order by clicking on a unit and dragging or whatever), then only reclaim units. Maybe have it only reclaim that type of unit if you press alt or something