BITMAP Custom ExplosionGenerators - Page 2

BITMAP Custom ExplosionGenerators

Requests for features in the spring code.

Moderator: Moderators

User avatar
Dragon45
Posts: 2883
Joined: 16 Aug 2004, 04:36

Post by Dragon45 »

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 ~_~
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

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 ;)
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10454
Joined: 24 Jan 2006, 21:12

Post by PicassoCT »

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 ?
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

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?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

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.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

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.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

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.
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

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.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

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 :roll:
User avatar
Dragon45
Posts: 2883
Joined: 16 Aug 2004, 04:36

Post by Dragon45 »

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.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

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.
User avatar
Caydr
Omnidouche
Posts: 7179
Joined: 16 Oct 2004, 19:40

Post by Caydr »

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.
User avatar
PauloMorfeo
Posts: 2004
Joined: 15 Dec 2004, 20:53

Re: BITMAP Custom ExplosionGenerators

Post by PauloMorfeo »

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).
Post Reply

Return to “Feature Requests”