Very simply, I'd like to get rid of the major distinctions between Features and Corpses and Units.
There's no good reason for having an entirely different set of systems and commands for these two things.
Features/Corpses should just be unit types that have associated BOS instructions, just like normal units, but are created after the death of another unit or placed onto a map by a mapper. The TDF value IsFeature should still apply, so that any future code that applies to Features/Corpses should be used (such as gradual reclaim) but it should be possible to do the following:
1. Have animated Features, that run commands based on what is called on Create. Think how much more interesting maps could be, if we could have cities where the buildings turn lights on/off in random cycles, could dynamically depict damage with animations (i.e., watch a building gradually disintigrate) have corpses that twitch or smoke or shoot out sparks occasionally, etc., etc.
2. Have Units that die and become another Unit, which could name yet another Unit on its death event, and so on. Among other things, this could give us units that can "resurrect", by having the second unit have a negative value for AutoHeal which will eventually kill it, allowing it to become the original unit again.
3. With a few more controls in place, this would make it possible to have "independent locations" on maps that do things like defend themselves... with appropriate AI, they could even be aggressive, and play a part in a game design.
Basically... I think it would be very beneficial to do these things. It would also get rid of yet another major redundancy in Spring's code.
Features/Corpses and BOS
Moderator: Moderators
Re: Features/Corpses and BOS
The problem is that features don't do much. They don't move, don't attack, don't have AI, etc. This means that very little information needs to be sent about them to other players, so maps can have lots of features without wasting bandwidth. While more functional features would be nice for a large number of reasons, I don't think that unifying features and units is a good ultimate goal.
Personally, I'd rather have "spawnunit(s)" be something you can do with explosions. Then you can have weapons that spawn units on impact and units that create others on death, rather than working through features.
Personally, I'd rather have "spawnunit(s)" be something you can do with explosions. Then you can have weapons that spawn units on impact and units that create others on death, rather than working through features.
well, couldn't a unified unit/corpse/feature have a set of tags like 'isanimated= ', 'canmove= ' etc etc, which if set to 0, make the engine ignore (not calculate or send) any associated variables?
A unified system like this would also allow things like starting units etc, since units and features would essentially be the same thing
Even if my ideas aren't realistic (I think they are, but I'd like to hear a dev comment) I still agree that this is an area well worth looking into
A unified system like this would also allow things like starting units etc, since units and features would essentially be the same thing
Even if my ideas aren't realistic (I think they are, but I'd like to hear a dev comment) I still agree that this is an area well worth looking into
AFAIK a unit only uses bandwidth in a multiplayer game when a player issues it a command. Otherwise it's behaviour is entirely deterministic and can be simulated without external input. So features that are static units shouldn't use up any more network bandwidth than they already do upon creation / destruction / reclaim. That's my take but you still need a dev to confirm it. It would be a fairly major engine change in any case...
