Providing Spring with a more robust data structure

dj_oldfield · Post by **dj_oldfield** » 15 Nov 2005, 04:33

This is one of a few topics that I intend to post which are derived from another which I hope will be ignored completely.

What I am proposing for discussion is the idea of making several modifications to Spring which I believe will extend it's abilities to function more as a client for a plethora of gaming experiences... thereby extending possibilities for TotalA gaming as well as the possibility of other games custom written for the Spring Application.

I presently lack the time to actually go into detail... but I decided that it would serve its purpose to list the changes out so that all you Spring Chickens can post your thoughts... and hopefully help me to consider all angles prior to intensive development.

I would like to make the datastructure more flexable by making more flexable simple datatypes and more robust class architecture. I would like the property list as well as the unit command text to be dispatchable through a suedo text parser with the capability of compiling and caching scripts which are ready for use.

The proposed structure would provide an interface dispatch module not too dissimular from Microsoft's COM archatecture... whereby all properties and methods would be indexed and retrievable as interface pointers and integer sized indexes pointing to the available connection points of each class.

Further still, this functionality would be consolidated within a seperate object model and would be the baseclass for all memory objects created. This would enable scripting interfaces to manage everything from Camera Controls, to mapping flags, units, weapons... and any newly introduced archatecture produced for the client after it's release.

This would also enable the production of Static libraries to be developed seperate from the Spring client to serve the same purpose... which would presumably have a series of predictable interfaces which the dispatch module would wrap to "use" the newly introduced archatecture.

For scripts... versioning would be an issue at this point... as an entire game would be scriptible in this context. Published scripts would come with a GUID released from a central server upon registration... provided that the developer wishes nott o register the script... it would simply retain a name, version, and an embedded GUID which would be generated from the System Date and the MAC Address on the machine which compiled the innitial script. Provided that a reference was made to a script by name without a flag noting it's version or GUID... then the latest version would be loaded.

This feature would enable new rendering mechanisms to be built, new mapping controls... new unit definitions... and expansibility in every other possible way. I believe that it will also speed the loading of the application as these scripts must only be compiled once and from then on will operate at standard execution level. They would use a lower memory overhead, because variables will not be created unless they are needed... and they will provide a more realtime linking of memory objects as this would be built dynamically... and the various procedures designated for determining an objects relationship to other objects will no longer require a systematic check of all memory objects.

Finally, it would provide more localized code... it would be easier to write updates for Spring... and it would be easier to fix broken pieces (because there would be less code to repair). A simular correction for all unit definitions would be headquartered within a single class instead of making the same changes in multiple classes... and and these changes should be more easily performed with the ability to use and modify the scripts in text format without having to manually compile each time.

Overall...this seems like a win/win situation. It seems to target many of the current problems with Spring simultaniously... be it directly or indirectly.

Ill post more on this later, as I am currently working with some people to help me to produce a representation of the complete product.

GrOuNd_ZeRo · Post by **GrOuNd_ZeRo** » 15 Nov 2005, 04:36

Well, what i'd like to know is, how much more will this complicate matters for mod devs? and will it be backwards compatible?

dj_oldfield · Post by **dj_oldfield** » 15 Nov 2005, 04:53

Before I can answer the question about backwards compatability... I would have to gain a more clear understanding of exactly what the official structure would be. My best guess is that the old scripts should run as well if not better then before on the new client... but I still have to figure out how to keep LUA before I can make that promise.

Mod devs will in fact become easier with the new extension... as you can create script compilations to serve all purposes.... for example... code like the following would enable such a mod....
... before you get too curious... this is based on the current software platform that I wrote and own. This may not actually represent the new embedded scripting.

ALSO NOTEWORTHY... LUA WILL STILL EXIST... I will not extract it because too many people want it. Both will be usable... but I will not take the time to link LUA to the newly introduced functionality... because it will require enough work just to keep LUA linked in as much as it is. I imagine someone else won't waste much time doing that anyway.

Please note that code autowraps because of HTML... dont let that confuse you please! :)

root::Unit modCMDR wears( root.units.prototypes.commander );
modCMDR.hitpoints.max = 1000000;
modCMDR.actions["buildCity"] = root.libs.extensions.custom.myCustomScript.myCustomProcedure;
modCMDR.Attributes["newWeaponAMO"] = new Int( 0,100,2,100);//min,max,radix,default(innit value)
/// other customization definitions here.

/// Starting game innit script...
namespace game : Public root.game
{
void game_start()
{
root::game::objects::player objPlayer;
for( int idx = 0; idx < this->players.length; ++idx )
{
objPlayer = this->players[ idx ];
objPlayer.units["Commander"] = modCMDR.FetchCopy();
}
}
}

SwiftSpear · Post by **SwiftSpear** » 15 Nov 2005, 05:18

lua is only half the battle. What I think most mod makers want is backwards compatability with the old tag system... Possibly even the ability to define their own tags within the new scripting language... At least half and half compatability is nessicary to keep the modders satisfied. Without tag system support it will take just too much work to fully port over a mod, but without some integrated compatability we will just be stuck with old outdated mods that are too much work to port and impossible to update.

dj_oldfield · Post by **dj_oldfield** » 15 Nov 2005, 06:27

That is quite a sensible arguement...

but it might be (unfortunately) a choice between keeping things the way they are or moving on to something that might work better.

Either way... I can't see any reason that this can't be XML enabled... perhaps the xml support could reduce the time required for migrating?

SwiftSpear · Post by **SwiftSpear** » 15 Nov 2005, 07:25

Any chance it would be possible to get the game to read/understand the old FBI's and TMD's and what not for some units that are specifically specified to do so at least? If there isn't some reasonably simple way to either convert units, or leave ones that don't need to use newscript calls to work using oldscript, then this might as well not happen. You will lose all your modders the moment you finish because you have destroyed all thier mods, and XTA along with them.

dj_oldfield · Post by **dj_oldfield** » 15 Nov 2005, 07:37

Yea... but I know as well as you do that I won't be able to be certain of the compatability until I get the application done...

Once I get done however... I am very certain that if I investigate the reader... I can probebly make an engine that will do a decent conversion of the origional unit definitions. I suppose the only question is how much additional modifications will be required to make these work. I imagine however... I can probebly automate the entire process if I really worked at it.

dj_oldfield · Post by **dj_oldfield** » 15 Nov 2005, 07:48

Actually ... you are probebly familiar enough with the code to tell me...

do you think that there is a way that I can use the existing unit definitions source code to derive a class from both my object model and that one... and then use a series of parser constants for the conversion? If so... then perhaps the import can be implicit? ...

umm... that probebly ... wasn't very clear. What I mean is... link constants that I would use to parse the unit definitions... to constants that I would use to provide the same functionality in the new model...

I suppose that it would require a semi-predictable file structure.

SwiftSpear · Post by **SwiftSpear** » 15 Nov 2005, 09:56

dj_oldfield wrote:Actually ... you are probebly familiar enough with the code to tell me...

do you think that there is a way that I can use the existing unit definitions source code to derive a class from both my object model and that one... and then use a series of parser constants for the conversion? If so... then perhaps the import can be implicit? ...

umm... that probebly ... wasn't very clear. What I mean is... link constants that I would use to parse the unit definitions... to constants that I would use to provide the same functionality in the new model...

I suppose that it would require a semi-predictable file structure.

I'm quite an amiture coder... I do understand a bit about the spring units right now... but I'm really not able to put what I already know into context with what you are planning. I THINK (think being the key word) the current way the add tag features are implimented is basicly that the low level engine functions are under the surface, and they just kind of touch on whatever functions they need to work... This gives me the impression that it should be possible to code a deeper delving scripting language that allows modders to acctually explore the low level functions, where currently we are restricted to high level functions that are translated through code already by the SY's tag items. I don't know if there's much continuity or restriction as to the places the tags are manipulating... I kind of doubt that they all currently go through a parser or something that would theoretically allow you to just keep all the old functionality, while simply building a new scripting langues as a parrallel head... It might be the case though, SJ is known to be a really talented programmer (how experiance he was before spring I don't know). There might be something to work with since at some point it's translating tag calls to machine code out of text files.

I'm really sorry, I wish I could help more.

[edit] Ok... it looks like all the unit handling in the current tag system is done buy a somewhat bloated unit handler definitions class, which contains all the tags and thier definitions... So depending how much modification has to be done to the existing engine code to make it work properly for a more open scripting engine, it might be possible to work around the current definitions entirely... possibly even possible to make units from both scripting environments play together properly, as long as the new scripted units don't break any current interaction rules when interacting with old units...

GrOuNd_ZeRo · Post by **GrOuNd_ZeRo** » 15 Nov 2005, 14:42

What I personally would like is the old TA file system but upgraded.

A way to define my own tags easilly, .qc style, compiles automatically when the game is run and creates a .DLL file with the new code, kinda like a mod on the engine it self, that would be quite useful IMHO.

I also URGE to have backwards compatibility, otherwise my mod is doomed for Spring, LUA seems to complex still to me, I get confused seeing all that void this crap, root that crap...I like a practical way to create units, something that doesn't take alot of time, even if I had to have a HUGE library of tags to browse to, it's more easy to make applications for it that can make the files with tags in it along with descriptions of the tags when hovering over them in a frontend program like FBIeditor and such.

Torrasque · Post by **Torrasque** » 15 Nov 2005, 15:47

Backward compatibility is really needed. Who will remake all the ota, aa units? certrainly nobody.

But there is certainly a way to transforme transparently old config and scrit files into a new one.

dj_oldfield · Post by **dj_oldfield** » 15 Nov 2005, 17:05

One way or the other, I am sure that there will be a way to link the old to the new so to speak.

With respect to ground_zero's comment... I hate to inform you but robust and simple is not all that easy to do. I am sure that at some point I or someone else would have a wysiwyg tool of some sort, but to do anything advanced will still require some coding in a c style language.

As far as compiling to DLL, I have no intention of compiling these pieces into dll files. Honestly, things of that nature written for Spring can be written with Visual Basic... why should I reinvent the wheel there? I am just going to compile it to byte code so that it links to the existing datasystem... on first use and each update.

Post by **jcnossen** » 15 Nov 2005, 17:33

I would like you to read

http://spring.clan-sy.com/phpbb/viewtop ... 5&start=20

We already discussed somewhat how to keep some backwards compatibility there, by using FBI tags as constants in the script.

AF · Post by AF » 15 Nov 2005, 20:55

Unit loading in spring.

There is a class that parses the fbi files and such for tags that the engien requests.

For example untihandler when ti laods a unti will create a new variable fo type UnitDef. It will then ask SUNParser for each tag spring uses thats in teh unti fbi, changing the data in the UnitDef structure it made to suite.

Then ti will put it in a vector<> container, and then the rest fo the engine pulls out the unit from that cotnainer.

Unit ID's are the position in the cotnainer, hence why build menus arent ordered because they follow the cotnianer etc (tho I may be wrong ti explains why i cant specifically define untiID's I have to sue unti names in AI dev).

I believe that parsing code script would be better if it took the plain text and covnerted it into a unviersal format specifically for the engine. That way multiple convertors can deal with multiple styles of syntax, be they lua based, or c style etc. LUA support was mostly wanted by me, as I stressed it most, but really as long as the syntax is there and the support for it then I dotn midn the core beign something different given the same lua code behaves the same under spring.

hmm I'm not familiar with COM.

dj_oldfield · Post by **dj_oldfield** » 15 Nov 2005, 21:30

for the most part... I was thinking that it would be something simular to that flow...

Anyway... I thinkt aht before I blow any more smoke onto this thread... I am going to get the final concept together. Ill post more in a while!

Dragon45 · Post by **Dragon45** » 15 Nov 2005, 22:11

So you're basically proposing a bottom up re-write of some very crucial components of the Spring engine. Good. Now, you're proposing these ideas without properly putting them into a design doc.

Pardon my skepticism.

dj_oldfield · Post by **dj_oldfield** » 15 Nov 2005, 22:14

lol... What makes you think that I have no documentation on what I am doing?

I just needed some feedback to help me to complete the process.

Post by **jcnossen** » 15 Nov 2005, 22:19

So you're basically proposing a bottom up re-write of some very crucial components of the Spring engine.

He's proposing a rewrite of the unit class system (which is now a mess because of FBI files) and script integration for parts of the rest of the spring engine.

It's also a waste to spend time on a design doc and have it discarded because your idea is not accepted.

mongus · Post by **mongus** » 16 Nov 2005, 00:09

edit: erased previous post bc it was cheap.

btw, is your "OS" thing Open Source dj ?

aGorm · Post by **aGorm** » 16 Nov 2005, 00:11

More like... lots of bits of a new unit format are on the way... so by teh end of teh process, you'll be able to make a unit with justt eh all new stuff.

aGorm

Spring RTS Engine

Providing Spring with a more robust data structure

Providing Spring with a more robust data structure