Some Problems i forsee with Spring

[dinocool]

Hello, I love spring its such a great engine!

well, what I really should be saying is "i love TA and all its colourful offspring"

this is the main problem spring faces. The spring engine is nowhere near as flexible as it should be.

The engine itself is designed to be TA.

where infact this is how it should be done.

Base engine handles drawing gui (from specification!), drawing models, pathfinding, map loading, map generation, syncing and multiplayer.

you know, what an engine is MEANT to do.

instead you have it defining things like drawing nanosprays, how resources behave, how structures are built, creating a commander, how units behave(though this debatedly should be half bit in spring and the rest in definitions)

And its because all of this that springs mods have become TA clones. because to be honest you HAVE to use TA's resources, you HAVE to use TA's way of building, you HAVE to use TA.

if anything what SHOULD have happened is the spring engine be created with a MOD co existant with the default TA standards. IE how the TA resources are used .ect

Currently what is happening is lua bypassing the engine code. this should NEVER happen. every feature of spring should be optional and modular. ie. you can ditch it. this could be done in a number of ways, you have your DLL option, your boolean on/off option, and your lua option.

Please correct me if i'm wrong in assuming all of this, but currently this seems to be the way the engine is structured.

[Acidd_UK]

The engine was designed originally to play TA replays in 3D. It was not originally designed to be a general purpose engine, it was just hoped it would go that way, and it is, thro Lua.

[imbaczek]

patches welcome.

[lurker]

There is no way to have every possible way of making buildings, for example, hardcoded. That's what lua is for. There are already simple flags to turn off nanospray and the building graphics, the units don't behave that much like TA units, and I don't believe for a second that spawning a unit at game start is a TA feature. Using a scripting language is the good way to do custom behaviors, such as the power and exotic resources in gundam, or the area cloakers and jumpjets in CA. All off the built-in gui elements can be turned off with a simple switch. I don't understand what you have against lua; there are other games that let you create entire guis in it too.

[Auswaschbar]

THIS, FIBRE etc. Thesis disproved.

[Otherside]

LUA /thread

[smoth]

hey chief watch this video:

spring is not ta

[hoijui]

first thing, dino, you need better com skillz
second, think about it, think, think about it
you will not ever convince everyone you had to convince with your idea, even with good com skillz.
with good enough com skillz, you had better stuff to do then worry about things like this.
... back to the point:
you have to start a fork of spring, or even better, rewrite it from scratch (i suggest using an other language then C++). i would support that.

[Gnomre]

The engine was designed originally to play TA replays in 3D. It was not originally designed to be a general purpose engine, it was just hoped it would go that way, and it is, thro Lua.

The only thing the 3D TA demo replayer and Spring have in common is that the SYs coded both. Spring is the super-evolved form of some OpenGL tutorial SJ was following.

[AF]

Actually the engine was designed to be a 19th century RTS, but faced with a lack of content and the SY's utter innability to create good original content, they turned to XTA (not TA, but XTA ), their only major stash of content inhouse.

Until about 2 year ago there were still references to a 3rd resource named supply that wasnt being used in the main code being stripped out by the current developers, amongst other clunky things.

[dinocool]

i know c++ so i know what can be done;

what i'm trying to get at is this.

things like nano sprays, vreation of com and such should NOT been in the engine to begin with. fullstop. no "turning off" just leave them out and make them in lua.

we want a SPRING engine not a TA engine

otherthings you may want to think about is a particle class to handle lua particles MORE eficiently and a lua -> opengl interface

i'll try and make a couple of patches .ect to help with these issues if you'll let me ^.^

[smoth]

I am all for that, but expect people to cry and get butthurt if the devs did that.

[dinocool]

why? is it because mods would then have to update alot of stuff?

[smoth]

because the ta mods live in this sort of protected status. The lua is fine, I use a lua econ. Spring is a good engine but people seem to think that spring revolves around ta because that is currently that main thing.

In a way the ta shit is kinda like a test case for the engine as there are no large projects complete as of yet. However, the ta stuff only touches the ta aspects of the engine when it is capable of so much more. CA is the only ta mod that bothers to do something utilizing the engine.

[hoijui]

dinocool, if you want, you can have a look at the caiinterface, and there at the files under rts/ExternalAI/Interface. In case you do not know: a new AI interface is in the works, and i would like ti to be as generic as possible. for example, it does not know about energy and metal, it just knows resources in general, abstracting springs hardcodedness there.
i am possibly looking at this code for too long already, so if you want to give suggestions of what else should be changed, you could tell me, or even send me patches (though you had to remember that these files are getting parsed by scripts, so you could not fiddle with the format a lot).

[malric]

things like nano sprays, vreation of com and such should NOT been in the engine to begin with. fullstop. no "turning off" just leave them out and make them in lua.

In principle this would be a nice idea, but in practice who would benefit ? Of course, you can code it if you want, but why not pick something people would use immediately ?

As example of usefull things I know about and me personally would care more about: multithreading, load/save game (I know it used to work, but does it now ?), campaigns (also, people are working on it, but do they have everything they need in the engine ?).

[BrainDamage]

things like nano sprays, vreation of com and such should NOT been in the engine to begin with. fullstop. no "turning off" just leave them out and make them in lua.

In principle this would be a nice idea, but in practice who would benefit ?

allows more generalization of the functions, writing/adding new features in a better layered engine would be less troublesome to maintain, not to mention it would ease the work of anybody who doesn't want any hardcoded "feature" because he could turn it off rather than writing workarounds for it.
EDIT: for instance, spring checks sync by hashing together current stored metal&energy + unit positions on the map, I imagine that a modder would want his custom resource to be checked for sync instead of a non-used one.

As example of usefull things I know about and me personally would care more about:
multithreading

if you just want "multithreading", spring's path cacher is now threaded, zerver maintains a branch with GL calls in a SMP structure and video recorder is threaded, altought none of those gives serious impact over the game performance.
The only "threading" change that would have some impact in the game would be multithreaded sim, but needs to be planned in every single detail, would require to rewrite most of sim engine with huge efforts by multiple devs and risk of constants desyncs for minimal errors

load/save game (I know it used to work, but does it now ?)

saving works as in the game gets saved to disk, but often crashes immediately afterwards
loading is completely broken
i've been poking devs about this one since a while but none seems really interested in fixing it

campaigns (also, people are working on it, but do they have everything they need in the engine ?).

yes

[lurker]

The only "threading" change that would have some impact in the game would be multithreaded sim, but needs to be planned in every single detail, would require to rewrite most of sim engine with huge efforts by multiple devs and risk of constants desyncs for minimal errors

Not all of sim has to be multithreaded. It's possible to pull pathfinding and los map updates into threads 'relatively' easily.

[zerver]

The only "threading" change that would have some impact in the game would be multithreaded sim, but needs to be planned in every single detail, would require to rewrite most of sim engine with huge efforts by multiple devs and risk of constants desyncs for minimal errors

The threaded pathing shows it can be done. The biggest issue is that from a threading perspective A+B != B+A. This means every thread must be more or less independent to ensure the ordering is consistent for all calculations.

[Satirik]

i think people should make patches before talking because we already have a lot of people doing nothing but talking around

we all know how a good engine should be ... we all know how a perfect Spring Engine should be, we all know what is missing