Spring RTS Engine

Scripter source is unorgainzed as hell. Its a pain to read. Add that to th efact that its a somewhat sophisticated compiler/IDE and you have a big mess that needs to be torched and rebuilt.

Lord knows how KhalvKhalash built it in hte first place ~_~

If anybody can clean it up, I'm guessing AF could. He likes dealing with weird clunky things and making them work.

Still, I'm not going to be surprised when he gets done looking at it and understanding why I proposed this workaround

Just a stupid throw in- at least in Old TA, the Explosions were visible even out of sight, so if every unit has such a Particle System, that is visible, - even in the (fog of war-that is no fog)...
Can such Particle Gen Simulations be disabled, by unit, if out of sight ?

hmm, the scriptor source contains subprojects specifically a bos compielr and decompiler. Thus wouldnt adding new functions simply be a matter of adding them in there and ignoring scriptors IDE portion?

I dunno. I've never gotten it to compile.

If so... well, gee... that'd open up a whole lotta stuff.

That said, you'd need to be veeeeeery careful and coordinate this with the main devs, as Fnordia's code assumes that a bunch of values are already taken. The compiler basically just turns things like SET MAX_SPEED to a series of numbers in the COB. Fnordia's code reads the COBs and basically acts like OTA's engine did. One mis-assigned value... and I have a feeling Spring will crash, hard.

I know how it works, it's bytecode.

I'm feeling that a lua implementation of the interface that the bos->lua program creates is becoming more and more needed, especially as it would bring along with it a miriad of enw functions and possibilities with object oritented code and existing lua libraries, aswell as support for data types that would allow more data to be pulled out of the engine, maybe even communication between scripts and AI or improved cross script communication. Not to mention a hardened lua compiler complete with optimisation routines.

Hey, I'm completely convinced that you, JC and Tobi are right about all of that. No doubts here. All I'm looking for is a stopgap to cover the next nine months or so- I doubt if the rework of the model/script/animation system's going to be any faster than that... and that's if nothing bad happens to derail development, like sudden RL problems with key developers or something. This is a conservative, back-end, non-optimistic workaround that would utilize what we currently have, plus a relatively small change in Spring.

Sure you can add a bunch of hacky additions to COB, but it is really worth to put time in that? Microsoft did the same with VB and they ended up with VB6 which really sucked compared to languages designed directly from the ground up. Not that VB6 proves anything, but my point is COB is lacking so much important stuff that isn't simply added with a bit of extra code.

no floating point values, no strings and no structures, to name a few, which really hurt any use of COB as a real scripting language.

Again, no argument. I'm the last guy on Earth who's going to say COB is perfect as-is... now that I know its big problems in more depth

AF wrote:hmm, the scriptor source contains subprojects specifically a bos compielr and decompiler. Thus wouldnt adding new functions simply be a matter of adding them in there and ignoring scriptors IDE portion?

Ha ha NO.

Its a mess. From what i remember, there's obscene vaiolations of encapsulation and abstraction on many levels, not to mention ints basically uncommented and messy oh god it might as well just use GOTOs.

I think all of the stuff pertaining to how a given line gets parsed and compiled is in the compiler.cfg (at least it looks like both a grammar definition and a definition of bytecode equivalents). If you could figure that out you could add commands at will.

This'd be way too much work to apply to a mod the size of AA on a large scale, but for smaller mods like Gundam, GEM, AAS, etc, I'm sure it would open the door to very interesting possibilities.

Argh wrote:Without getting into all of the details, ...
I am building new, GPL-friendly code for all of the commonly-used Includes used for COB scripts. Everything is getting altered enough to qualify as "original Art"
...

Don't know if you already know but:

You don't need to alter stuff just enough to be diferent. In fact, you should not.
To qualify as original art, you need to make it without copying it or without basing your work on the other, even if the resulting work is very similar or the same (which can hapen in simple stuff).