Spring RTS Engine

Removing nano particles & nanoframes form the engine and replacing with lups & a shader would be a boon; currently you can't even use custom shaders on a unit being constructed because of some technical issue with clip planes that can result in switching to software rendering or something (ask jK).

The point is what you may think "isn't doing any harm" not only is a maintenance burden but can hold back development in other areas.

I agree what gajop said about adding compatibility with one of the main standardized 3d model formats, but disagree about removing compatibility with legacy ones.

FLOZi wrote:Removing nano particles & nanoframes form the engine and replacing with lups & a shader would be a boon; currently you can't even use custom shaders on a unit being constructed because of some technical issue with clip planes that can result in switching to software rendering or something (ask jK).

The point is what you may think "isn't doing any harm" not only is a maintenance burden but can hold back development in other areas.

What if I don't want to use LUPS?

economy....nanoframes..... if we call most stuff inherited from TA legacy stuff then yes there's some work involved in maintaining them, but calling them a burden? I don't buy that. Especially the need to remove those legacy features. Why not just make them optional through game options?

Engine devs can refactor and move the code to separate legacy files if they want to keep the "core" clean, but should keep them in the engine.

smoth, gajop, FLOZi, and most current engine devs apparently have one thing in common : you don't play or maintain TA-like games. Conflict of interest there.

Currently the engine still has some bugs in unit and weapon behavior, some pathfinding issues,etc. Yesterday I found another one. Should I expect the next version that has them fixed to also break or remove of some of the legacy stuff I use?

Maybe this is why it's taking so long for TA mod communities to move in.

There is no point in keeping in any hard coded game logic in the spring engine, when moving towards a general rts engine. It creates unneeded burden on the engine devs when it comes to maintaining game logic, when the burden should rest on the game devs.

raaar wrote:What if I don't want to use LUPS?

economy....nanoframes..... if we call most stuff inherited from TA legacy stuff then yes there's some work involved in maintaining them, but calling them a burden? I don't buy that. Especially the need to remove those legacy features. Why not just make them optional through game options?

THIS ISN'T THE TA 2 engine. LUA based implementations will give you MORE flexibility. even allowing you to implement proper reclaim like IN OTA. If you don't like LUPS then maybe you should implement something better? Why should all other projects be held ransom to you guys who are just distributing content that frankly is stolen, altering defs and calling yourselves legitimate projects? For years this has burned in my mind, yes, by all means, lets have a bunch of people who are violating the OTA EULA(which did exist) and distributing a bunch of files based on stolen content!

The reason BAR has my full support is they are doing a modernization, with their OWN content, so to say such a thing is not possible is bunk. Gundam WAS 3dos 100% and still has a few, i did a bang up job replacing that content with models and art generated by my own effort, all the while constantly bobbing and weaving around all the TA "features" in engine that was shaping my game in ways that was undesireable.

You guys have not had the run of the house for 7 years now. Tons of stuff in the engine has been done for the TA crowd and the engine has revolved around you guys much to it's detriment. The ta projects largely are modifications of old total annihilation files. Sure some have some extra features and enhancements built in over the years. However, to act like modernizing your projects by converting your models to s3o or even better dae files is asinine. There IS a bos->lua converter. As soon as I get behe's 3do conversion script I am so using it to convert all of EE.

It is the TA projects that have been holding the engine back for years now and refuse to allow it to advance. Having LUA based implimentations of certain engine features only makes sense. The effort to update your core content files is SO small compared to the work NON-ta projects have had to do for years.

raaar wrote:Engine devs can refactor and move the code to separate legacy files if they want to keep the "core" clean, but should keep them in the engine.

Why? why not just put the stuff into a proper library and then not force it on projects unless they want it? A proper library can be altered and enhanced(see ota reclaim)

raaar wrote:smoth, gajop, FLOZi, and most current engine devs apparently have one thing in common : you don't play or maintain TA-like games. Conflict of interest there.

No, no, you are right. I don't play TA games or "maintain" them. How's that working out for this community? Oh the TA games have become stale and are dying slowly? YEP. Oh, they have eaten man YEARS out of my time, flozi's time etc because we have had to work AROUND an engine that for YEARS favored hard coded gameplay patches to your projects? What would the engine have been like if you guys were instead given lua implimentations instead that you could have extended and made better?! I shudder before the thought of the beauty that we would have seen.

What is your effort level to even BEGIN to cry about being inconvenienced but the OTA stuff being moved into a lua library? You wouldn't be as incovienced as you think, if anything you might LIKE IT

AGAIN, it is just running your content through a converter and getting a pile of new files to replace yours with. The interface for my material system alone easily took 10x that effort.

raaar wrote:Currently the engine still has some bugs in unit and weapon behavior, some pathfinding issues,etc. Yesterday I found another one. Should I expect the next version that has them fixed to also break or remove of some of the legacy stuff I use?

slippery slope fallacy. They change pathfinding all the time. I am amazed at my aircraft crashing into the ground now in GRTS. Even with the changes(say kloots pathfinder) when I raised issue about units jamming up and a feature I needed being broken, with evidence and a clear definition of what I wanted as far as behavior, kloot banged out a fix rather fast :).

raaar wrote:Maybe this is why it's taking so long for TA mod communities to move in.

Who the do you think flozi, nemo, spiked, z, myself and countless others ARE?!? We were the OTA modding community. Caydr? AA was an OTA mod built on uberhack! Seriously what part of that dessicated community is left for us to pull in?

Super Mario wrote:There is no point in keeping in any hard coded game logic in the spring engine, when moving towards a general rts engine. It creates unneeded burden on the engine devs when it comes to maintaining game logic, when the burden should rest on the game devs.

We are advocating a LUA implimented alternative to the economy and nanoframes. After that the burden would be on the content dev to disable or even augment it. At least in the case of this nanoframes/nanos discussion


Spring is NOT THE TA2 engine. The TA modding community already came here!

The devil's in the details. What are the current built-in behaviors you'd like to bypass but can't? You guys mentioned economy, nanoframes/nanoparticles, also some limitation about shaders. None of it implies removing stuff from the engine.

How hard is it to just add some game options to disable built-in behavior? I think you are overestimating the burden they represent.

You say keeping the TA stuff in the engine is holding spring community back. Prove it! That's false. One way to read it as neutral is it pulls players from trying other games. Maybe that's your problem. But that's something that's gonna happen to someone when multiple games are available on the same hub.

Me and others could probably make/adapt lua gadgets for the stuff that would be removed, but why should we have to?

If this trend continues, it may be easier for game devs who want TA mechanics to just use forked versions of the engine with cherry-picked fixes from the "main" one. That way less time is spent discussing these issues on both parties.

Current engine devs, what are your opinions about this?


EDIT: btw, about the TA modding community having already migrated here, that's false:
- TA escalation
- TA zero
- TA mayhem

raaar wrote:The devil's in the details. What are the current built-in behaviors you'd like to bypass but can't? You guys mentioned economy, nanoframes/nanoparticles, also some limitation about shaders. None of it implies removing stuff from the engine.

How hard is it to just add some game options to disable built-in behavior? I think you are overestimating the burden they represent.

You are simply misinformed here. For the sake of illumination;

1. Are you a trained programmer?

2. Have you ever compiled Spring?

3. Have you ever discussed any of the above changes with either jK or kloot?

raaar wrote:

EDIT: btw, about the TA modding community having already migrated here, that's false:
- TA escalation
- TA zero
- TA mayhem

You're assuming that they are interested in moving their mods to spring.

FLOZi wrote:

raaar wrote:The devil's in the details. What are the current built-in behaviors you'd like to bypass but can't? You guys mentioned economy, nanoframes/nanoparticles, also some limitation about shaders. None of it implies removing stuff from the engine.

How hard is it to just add some game options to disable built-in behavior? I think you are overestimating the burden they represent.

You are simply misinformed here. For the sake of illumination;

1. Are you a trained programmer?

2. Have you ever compiled Spring?

3. Have you ever discussed any of the above changes with either jK or kloot?

1. yes

2. I wanted to avoid it and focus on the game, but after a few years...yes

3. Not really. They're the ones wanting to do breaking changes (or do they? I don't see their opinions here), not me. Also Kloot likes "shouting"...That's not an incentive to talk to him.

raaar wrote: economy....nanoframes..... if we call most stuff inherited from TA legacy stuff then yes there's some work involved in maintaining them, but calling them a burden? I don't buy that. Especially the need to remove those legacy features. Why not just make them optional through game options?

Engine devs can refactor and move the code to separate legacy files if they want to keep the "core" clean, but should keep them in the engine.

Sure they are a burden. They limit what you can do with them and actually get in the way if you're not making a TA clone. For example, engine supplied economy is pretty much worthless as it's limited to energy/metal, and even though you can rename it, the way it functions will greatly reduce its use or require you to hack around it. It needs to be more flexible. It should be possible to abstract that and still allow TA-clones to specify metal/energy in a economy.lua engine def.

raaar wrote:Currently the engine still has some bugs in unit and weapon behavior, some pathfinding issues,etc. Yesterday I found another one. Should I expect the next version that has them fixed to also break or remove of some of the legacy stuff I use?

Yep, legacy stuff is getting removed! I think they're looking into removing engine-based fuel next. NOTA (I guess it counts as legacy mod?) devs said that they're capable of reimplementing it in Lua.

raaar wrote:Maybe this is why it's taking so long for TA mod communities to move in.

Not our goal imo. Smoth said it well, this isn't TA2.

raaar wrote:Me and others could probably make/adapt lua gadgets for the stuff that would be removed, but why should we have to?

Because it's usually easier to customize specific behavior from a generic API than it is to hack around a specific API.

I mentioned that engine commit of yours once. It just adds extra specialization/burden to the engine by making it a configurable TA-clone instead of a generic (RTS) engine. We need fewer TA-only behavioral unitdef tags.

you aren't answering my question : why is it better to remove legacy behavior than to keep it in the engine AND add the option to disable it.

If it weren't already there and devs were redoing the engine from scratch, i'd agree with you, but there's lots of legacy content around, and the behaviors are already coded in and working (for the most part).

the option to disable it allows for the best of both worlds. Whoever wants to keep using them, can. Whoever wants to just disable them all, can too. The cost? A bit higher maintenance, but can be low if code is factored properly, which I suppose it should be by now. I don't see how it can be higher than the cost for game devs of rewriting it from scratch.
Who's we? Who owns spring? I wouldn't call it "the" goal, but if it's good for it, I wouldn't screw it either.

Sometimes you need to take a step back before being able to take two steps forward. Sometimes that'll just leave you one step behind...

The changes I proposed weren't TA-specific, but that has its own thread

raaar wrote: why is it better to remove legacy behavior than to keep it in the engine AND add the option to disable it.

1. It places the burden of debug/maintenance on game devs rather than on the engine devs.
2. It's allows flexibility, in terms of implementation.
3. Easier to implement game mechanics in lua than in cpp, as you don't have to compile every time you edit the code.

Legacy behavior as engine default puts noticeable constraints in both engine and new game development.
If you already have a working legacy game, then I don't see why you wouldn't be happy with just using an (old) legacy engine version when worried about changes.
You can't have new features coming in if you want guaranteed legacy support. Certain abstractions have to be made as Spring transfers from TA-like engine to general purpose (RTS) engine. Additionally, if Spring ever enters maintenance only mode it will probably be the end of it.

Regarding the "not TA2 engine":
It's pretty clear that this has been the goal for Spring with rebranding from TA Spring as well as a number of code changes to kill taisms (which in itself is considered a pejorative).

Do you really need me to supply links where default engine behavior is causing issues and better abstractions could help it? It's pretty easy, but I'm on the phone so a bit lazy.

BOS/COB HAVE NO MERIT
3D0 is a junk format.
S3O is only less so because I hate the z is up issues with DAE.
TDF files are garbage and there is no reason to NOT convert beyond just not wanting to spend a few minutes running the lua that allows you to generate lua unit defs

Of the above, I can see sheer laziness with respect to bos/cob/tdf. I can see why some people might like 3do because it allows you to slap, and I mean slap colors and random textures on faces to produce ugly art. I don't think that the format is worth keeping and has major rendering issues. S3o I don't want to see go as I think it is good for the engine to have an internal format, and again y is up on s3o. Either way, if someone gave me a converter for my s3o files to go into a y is up DAE I would not sleep until I converted ALL of my prior models.

Nanospray SHOULD be a widget/gadget
nanoframe should be a widget/gadget

There is no reason this should be internal to the engine, it is a visual thing that IMO belongs on a project specific level. As others said we have to GO OUT OF OUR WAY to disable this and honestly, that is silly.

the economy should not be hard coded as part of the engine.

The economy should be a gadget, once 1 gets done to replace the economy everyone that doesn't have an irrational fear of things would reasonable move to it as an entirely lua implementation grants a great deal more flexibility. I have not used the internal garbage for over 5 years. However it is still ticking in the background affecting countless things that I am not 100% sure about. Mass, target priority are a few that I can think of.

In the past they removed health bars from the engine.. DOOM AND GLOOM! Oh wait, imma grab a widget that does it even better. Just sayin.

Not everything should be suddenly nor would it be suddenly ripped out of the engine. However, I feel that work should continue because it is unfair to insist code is being actively run in projects that are NOT using them and taking whatever performance hits or gameplay affects are caused by them.

So to answer your question, bloating the code with something like a bunch of ifdefs is even WORSE than the bloat we currently have. That is abusing ifdefs. however, moving functional code like the economy, nanorendering etc to widget/gadget/addon land is smart because we can easily disable it by NOT INCLUDING IT. We can also alter it a lot more readily, again, think proper ota style nano-reclaim.

Funny to see people talk about tdf, cob vs lus, Lua vs engine in 2015.
Perhaps was interessting in 2009, all has been said and done about it long ago.
Back then people were screaming "Oh noooo a hacky Lua thing! But I want it in engine!"
Now the same people are screaming "Oh nooo a hacky engine thing! But I want a Lua!"


Engine has grown around TA, that is simply how history is.
Perhaps engine would have been "cleaner" and "more general" if it had been planned from ground up.
Or maybe it would have died before any playable content was made, simply because then nobody might have cared.
Perhaps other mods would have been made, however not by the same persons.
Everybody knew the TA roots, so years of hating on OTA and "TA"-Spring was super dumb. Still is.

Especially dumb those marketing attempts with profiles/websites about "Spring" but then somehow all screenshots were of their one game and no other mod was listed.
Or leave out anything considered unworthy TA-content.
Makes it embarassing to ever have worked on non-TA mods that gets listed on such crappy pages, but more longlifed projects that actually get played are left out.

Stolen content:
Nobody cares if some project uses files from a long dead game.
Atari does not care. Players do not care. Websites do not care. Developers do not care.
TA content was perfect kickstart excactly because 'nobody' owns it: When a modder quit someone else can re-use it without huge drama about theft.

More general functionality Lua yes nice blabla. But most arguements for removing things do not convience me.
Imo the ideas for new resource system like on https://springrts.com/wiki/GSoC_Engine_ ... bstraction are inconsequent.

Engine level abstraction of resources wrote:The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

That is exactly the stuff that can be Lua, completly.
None of the Lua functions about resources like Spring.AddTeamResource() or Spring.UseUnitResource() are nessecary. They do not need to be expanded to work with third, fourth or n-th resource, such things do not make it any different. Really flexible would be to remove all this.

The engine does not need to handle resouces, at all.
Lua has variables, there is functions to create & manipulate units: That is enough to make own resource/building system.

All* mods on https://springrts.com/wiki/Games use .tdf / .fbi / .3do / .cob files in varying amount.
All mods use TAisms in engine, even if sometimes they think they have replaced a "kludgy" engine mechanism.
But actually is still the engine handling much stuff, gadget just manipulating it a bit with AllowBuildStep() and so on.
Or fumbling around with some stuff before feeding it to engine and end-result is 100% the same.

Converting .cob to .lua has little advantage.
Either the script is boring or it could be more elegantly rewritten in Lua.
Most .cob scripts are finished, no need to touch again, ever. Even a seconde on it is wasted time.
Arbeitsbeschaffungsmaßnahme = busywork with no value.

Some mods use .3do for projectiles or wreckage where graphics do not matter.
Waste of time to make new model for tiny missiles that ends up looking the same.

*one single exception seems to be conflict terra, at least from quick look.

8611z wrote: Engine has grown around TA, that is simply how history is.

No, that is called appeal to tradition fallacy.

Would a Domain Specific Language to Write a quick RTS via RTS-Def be any help?
It might draw more people in, if you could generate a playable prototype generator, which does not require to learn to code?

As knorke pointed out, there is a different interest between gamedevs and enginedevs.
Enginedevs want to broaden the scope of what can be created (even if it breaks existing games) and gamedevs want most of all stability, cause its rated frust (frust-rating-scale) to fix stuff that was considered perfectly fine just one engineversion ago.

Needs more compromises- as in, enginedevs provide transitionscripts, that fix code that must be replaced.
Gamedevs promise to stay closer to the engine, so it gets actually tested.

@SuperMario:

The engine wouldnt be there if it had not grown around a game. Engines only grow around games. However , once they are grown the support for the origfinal core game remains a nice to have.


We should however avoid scope-creep. Spring should not try to be a jump and run.

PicassoCT wrote: @SuperMario:

The engine wouldn't be there if it had not grown around a game. Engines only grow around games. However , once they are grown the support for the origfinal core game remains a nice to have.

Who's arguing against support for the original game? Game mechanics such as economy should be implemented via lua, implementing it should not be a problem for a self declare trained programmer.

Super Mario wrote:

raaar wrote: why is it better to remove legacy behavior than to keep it in the engine AND add the option to disable it.

1. It places the burden of debug on game devs rather than on the engine devs.
2. It's allows flexibility.
3. Easier to implement game mechanics in lua than in cpp, as you don't have to compile every time that you edit the code.

point 1 is true. But this isn't necessarily a good thing. The others are irrelevant if we have the option to disable built-in behavior.

I'd agree some parts of it should not be in the engine (like economy), but it's already there, and it works!

are we to expect the lua replacements to be less buggy and more performant than the engine code?

I'm here to have fun playing games, make my own and contribute to the community as an active member. I'm not here to care about what someone else thinks programmers/game devs should or shouldn't do.

this is related to my suggestion for first priority in this thread. Built-in gameplay feature set almost works right but never quite does. There's always something wrong with it, whether it is aircrafts' landing pads, transports, or whatever. This points to a worrying trend of removing broken features instead of fixing them.

game devs using old engine version with discontinued legacy features and bugs they want fixed have an incentive to fork the engine and fix them there instead of using lua workarounds.

raaar wrote:

Super Mario wrote:

raaar wrote: why is it better to remove legacy behavior than to keep it in the engine AND add the option to disable it.

1. It places the burden of debug on game devs rather than on the engine devs.
2. It's allows flexibility.
3. Easier to implement game mechanics in lua than in cpp, as you don't have to compile every time that you edit the code.

point 1 is true. But this isn't necessarily a good thing. The others are irrelevant if we have the option to disable built-in behavior.


I'd agree some parts of it should not be in the engine (like economy), but it's already there, and it works!

are we to expect the lua replacements to be less buggy and more performant than the engine code?

I'm here to have fun playing games, make my own and contribute to the community as an active member. I'm not here to care about what someone else thinks programmers/game devs should or shouldn't do.

this is related to my suggestion for first priority in this thread. Built-in gameplay feature set almost works right but never quite does. There's always something wrong with it, whether it is aircrafts' landing pads, transports, or whatever. This points to a worrying trend of removing broken features instead of fixing them.

game devs using old engine version with discontinued legacy features and bugs they want fixed have an incentive to fork the engine and fix them there instead of using lua workarounds.

You keep missing the point, if spring is aiming for a generic rts engine, then ALL OF IT'S GAME LOGIC SHOULD BE IMPLEMENTED AT THE LUA SIDE. Forcing to keep the hard coded logic in forces the engine devs to maintain and debug it, sucks time from the development that is already slow process. There is no point in keeping the old code when the game dev can create THE SAME MECHANIC IN LUA and NOT RELYING ON THE ENGINE DEVS TO FIX IT.
Your "disable feature" suggestion is ASINE, as it still REQUIRE MAINTENANCE AS IT CAN POSSIBLY BE FUCKED UP IN THE FUTURE.

The car that is spring development is running at 10 mph, I have given ideas/suggestions to speed the car up(bounty features/crown funding/etc), but the results that I have gotten so far is a temporarily 20 mph boost with the feature bounty suggestion. I have given up on that and join smoth crusade on having all game mechanics implemented on lua side so that car can remove unneeded luggage so it can go faster.

If you don't like where the engine is going then fork it.

ALL OF IT'S GAME LOGIC SHOULD BE IMPLEMENTED AT THE LUA SIDE

I disagree, I do see the engine dealing with some of the hairier stuff (movetypes, targeting) and some of the very common stuff (resources).