Spring RTS Engine

Interestign how peopel complain my suggestions is to complex and too micro.

yet every other suggestion is either more ocmplex or require more micro.


all the basic code for my style is essentially allready in the game,

Ammo, just rip off the Fuel code, only slight rewrite needed to add buildtime per ammo and costs. but again this code is also allready int he game, it's all recycling.

The only new code would be to allow unit to be a missile type weapon that returns when itself is out of ammo or fuel.


it's simple and nearly all the code is there. it's mostly a matter of copyign, adapting and adding. and you have a very usefull new feature that does NOT add any Micro management, AND gives you usefull and working carriers, and not just a refuel and repair station.

Carriers like that were in OTA but the planes aren't protected when landed and the carrier can only hold two planes at once as an airfield. It will also not relay orders to the planes so the carrier can't get any attack orders. And it can't produce the planes itself.

Hawkman if u think its so simple do it yourself. Telling us its so simple but not doing it yourself seems stupid, at least to me.

hawkman the itnernals arent wired that way.

Yes you could do it but it's more work than you think and the end result would be hackish and the patch would never be accepted by the devs as a result. The whole protoss style aircraft bound to the carrier goes against the basic concept that drives the unit system currently which allows each and every unti to eb assigned individual commands and properties, whereas this would make units dependant on their parent unit aka the carrier.

In roder for this to eb implemented ina non hackish way, the best method would eb tot otally overhaul the entire unit code system.

That means UnitDef, the entire Sub AI system, Command AI, the Skirmish+GroupAI interfaces, and the GUI bindings. All a very big chunk fo the core of the engine.

I'd say fiallt eh devs started on this we could have everything back to what it currently is but with your carriers by christmas, no AI updates, no new releases, no lobby work, no new features, just your carrier stuff.

However one thing I am interested in is how exactly you intended this to be defined. Sure its all good saying we should be able to do this in our mods, but how? How do I define my carrier as being a carrier?

And what about any GUI implications that may be invovled? How do i select seperate units and reassign them if the carriers destroyed? Do I select the carrier if I try to select one of its child units? Can I tell individual units to attack their own targets or will all my nuke bombers go after the single peewees all together at ocne 1 at a time because of my carriers command queue?

For some reason it seems your trying to keep an idea alive so it can be implemented in the next release despite the fact this is more likely to be a spring 2.0 feature than a spring 0.8 feature..

I don't necessairly intend for it to be in the next sprign release, but I do think it shoudl be implemented.

As for goign against the system of being able to control individual units. Yeah well, that may so be, but if it makes for better carriers(for the mods that choose to use it). that why not.

I would do it myself, but 1. I'm not a c++ coder, and 2. I'm not a game coder, but I am a coder. How easy it would be to implement would of course depend on how good the code design and modularity of the code is.

As for fighters belonging to dead carriers... to start with I suppose they would just do like missiles and kamikaze, later it could be wired to have them reassigned to other carriers with available space, or self destruct if non available.

but the point is you need to stop focusing on the fighrers as units, the fighters are just the weapons of the carrier in this implementation.

And when I say it's easy, everything is relative. it certainly far easier than many other "unecessary"/non gameplay enhancing features being done. Not that I complain about these I think all additions to the engine are good. But in terms of complexity, this patch dont' rank as high up as many other things

Higher than adding those newunit tags that was suggested int he bounty thread, but quite a bit lower than a dynamic water renderers or new reflective water renders.


btw AF. you type worse than me even :p typical typos of people who type to fast, like me :p

HawkMan, if you aren't a C++ coder and u aren't a game coder how can u possibly say that u know this will be easy to code. Im not saying u don't have any skills im just saying in the area that were are dealing with ur lacking practical experience. Have u look at the code at all? i have and let me say what ur proposing would not be easy. As AF stated, there are so many interlinking systems that a redo in for carriers would force a good deal of the core code of the engine to be redone. Again i mean no foul against u im just saying u making a lot of leaps and assumptions that i don't think u aware of their consequences.

For the love of god why does everyone keep saying that the devs are adding and i quote you, ""unecessary"/nongameplay enhancing features"?!?!?! what the hell are u smoking? PCP? God the engine has undergone such a large improvement in the next version. if u don't believe me read the changelog. its in the development links thread.

Oh and ur carriers are definitely below the tags that Caydr asked for. Do u even realize what those allow modders to do? things like repair tanks (which only repair and can' relcaim, assist, etc) will be possible in .74 which is something the mods need to develop beyond TA style systems.

For what hes asking for, go look at Empire Earth's aircraft carriers, almost. Combine the ability to define a target by giving the carrier an attack order with the carrier ability from EE/EE2 and you've probably got exactly what he wants, apart from the ammo thing, and thats probably codeable using a modded copy of the fuel code...

Weapons create projeciles. Projectiles cannot be attacked except by antinukes, projectiles cannot do anything besides impacting, they cannot shoot, they cannot fly attack patterns and they cannot return to their base.

A simple airfield that can store a larger number of planes (I think currently airfields aren't meant to be used for storing planes and may be too limited in number to work for a large carrier) and automatically relays orders to them would allow using units as the planes, if the carrier is destroyed the unit will keep fighting normally and when its fuel is low seek another airfield to get refueled. One of the rules of Spring is that you shouldn't force behaviour in a single, complicated rule (carrier rule, for example) but define many smaller rules (carrier can refuel planes, planes have limited fuel) that end up with the same effect. The simpler the rules the more flexible they are.

But then again I haven't tried making a unit with airfields yet.

Weapons would thus need to be units in order to make them work like that.

The entire weapon system si so completely different to the idea of a weapon being a unit it'd need to be torn out and rewritten.

I've looked at the code making all these things work and I'm sure the core devs would agree with me if I said it just isnt feasable and the work involved simply isnt worth the end result at this stage.

Well, it might be possible to do this through a "transports that build Units" thing, but I have serious doubts about the feasibility of "transports that don't build units, but also serve as Airbases and have an AI that gives them automated attack commands plus GUI support"

The problem with ideas like this... again... is not that you can't do it. It's whether it'd be a good idea in the context of Spring any time soon. We need to fully abstract the model system, the animation system, make the New GUI actually happen and also get making new UnitAI to the point where projects like this are reasonably attractive... not to mention the amount of raw work required to make a piece of uber-complex content like this work. Think of the scripting required... and the complexity of the model, if you want this to be convincingly portrayed, and not just look lame and rushed. And lord knows, I cannot imagine any coder willing to work on something like this unless the content is going to kick major ass


Sooo... HawkMan, if you really want this, I'd suggest putting in the work on the content end. Make us a really awesome carrier, with all the moving parts it will need to depict aircraft being deployed, etc. At the worst, you'll end up with an awesome model and have to just code it up as a transport that can hold flying things and heal things inside itself (this is quite possible). At the best, you might get people excited enough about it that they'll actually do it. Or you'll sit down like the rest of us who've reached a certain level of ... creative frustration... and learn how to code for Spring yourself

I'm allreayd workign on modellign the carriers as well as other stuff.

I'm just beign lazy about MAX


and that damn BF 2142 beta...

HawkMan wrote:I'm allreayd workign on modellign the carriers as well as other stuff.

I'm just beign lazy about MAX


and that damn BF 2142 beta...

Pity modelling the carriers isn't the bit we actually need.