Spring RTS Engine

Would you be interested in making a mod-info for the new site at some time?

What kind of? Straight implementation from the current version to the Spring site ?

I think its best to be at own page, easy to use, and doesnt have anything useless crap there, only the modinfo crap.

Some simplified version could be better, was that what you ment at the first hand?

A simplified version that was prettier would indeed be better, perhaps with a hefty dose of caching for loadtime speedups....

TradeMark wrote:What kind of? Straight implementation from the current version to the Spring site ?

I think its best to be at own page, easy to use, and doesnt have anything useless crap there, only the modinfo crap.

Some simplified version could be better, was that what you ment at the first hand?

I'm trying to get site development to work requirement based. So we would need an mod-info implementation that matches the needs of the site users.

I guess the casual Spring gamers would like to have some more general statistics of the most recent version of the more playable mods.
Dedicated gamers would like to have all the statistics of all the versions of all mods but I don't really know. Maybe they would also like to know the changes from version to version?

Is this still the mod-info code from way back? I can't find the topic anymore but do you know what I mean?
Who (are the people that) wrote the mod-info code?
Who is developing it now?
Is it still possible to download the code somewhere?

Tim Blokdijk wrote:I'm trying to get site development to work requirement based. So we would need an mod-info implementation that matches the needs of the site users.

I didnt understand the point... i might be tired, or its just my bad english.

Tim Blokdijk wrote:Is this still the mod-info code from way back? I can't find the topic anymore but do you know what I mean?
Who (are the people that) wrote the mod-info code?
Who is developing it now?
Is it still possible to download the code somewhere?

mod-info (real name Modit (but nobody uses that word, so we call it modinfo)) is still in development, and its first version was made by me few years ago. Im still developing it, though it hasnt developed much in past year.

I have gave the PHP-code to some people to test it, or just use it for their own purposes.

I havent released any public versions, because modit is basically a mod editing tool (but it works fine as modinfo tool too), and it has many bugs in which i havent had time to fix or seek. To release it, i need to look through the whole (crap) code and know how it exactly works, and that how fix all the possible bugs.

If i made that modinfo thing, simple and small, or anything, i would like to use the same database as which i use in the http://modinfo.unknown-files.net because then its 2 times easier and faster to update the data and add new mods. But i dont know would this site owners allow me to create own subdomain, and give me 500 megs free space, or more.

So what im talking about, is simply that i dont want to upload twice the same files to different servers (one for the big modinfo page, and one for the simple modinfo page in the spring site).

Requirement based.. It means we would try to make a site that meets the needs of the site users.

I don't worry about the bugs your work has, they can be fixed.

Fnordia owns and manages the Spring server, I don't expect any technical limitations on itself.
It's more the discussion about how to implement something like this. Duplication of unknown-files features is not that productive but combining the translation system I wrote for Springs new site with mod-info could be interesting for example.
Anyway I don't plan on picking up on this in the immediate future it's something that would be possible later on when the site is in production (in use).

Would you like to be involved in developing the Spring site btw? Unrelated to your mod-info work?

Tim Blokdijk wrote:I don't worry about the bugs your work has, they can be fixed.

Well as i said, the bugs only exists in the mod editing tool, though that mod viewer still has some bugs, but those bugs arent critical.

Tim Blokdijk wrote:Would you like to be involved in developing the Spring site btw? Unrelated to your mod-info work?

I dont think i have time (or interest), but i can make some modinfo viewer, thats all.
I wouldnt be very productive because im very tired after my work, only weekends i have some lifetime, but thats not enough to get into coding so deep.

A well, if you ever feel the need to get involved with the site just let me know.

BTW: Complete Annihilation Beta 2.1 has been released for how many days now, and it's still not on modit? Trademark, upload please.

Yeah, later, i had problems adding it in there, some errors in the files... i go sleep now, i try to fix it tomorrow.

Added XTA 9.1 and NOTA 1.31

TDF -> LUA

There's been a recent commit that changes the way that unitdefs,
featuredefs, and weapondefs are loaded from mods. They now
use the LuaParser class to load the gamedata/unitdefs.lua, etc...
files, which return the definition tables.

There are default lua scripts included in the spring base archive
that will parse the current TDF definition files, so it is backwards
compatible. A problem will arise once someone starts using the
new LUA based system, your current code won't be able to
handle it (unless you're doing something with the raw spring
exec to dump the values rather than parsing yourself).

I didnt get what you mean...


This is new code of spring?

LuaUnitDefs.cpp So how has that anything to do with modinfo page? I still use my own TDF reader, and i read all vars, even when they arent used by spring.

Anyways, looks better now, i can see all the possible vars there at one single page, though, i cant know which vars can be used from units FBI files...

What he means TradeMark, is that eventually not all mods will use .fbi's, stats might be defined completely in Lua, and .fbi's will be made obsolete.

No, thats not what he means. What has been changed is the following:

In the past (before a few commits ago), Spring was hardwired to use the built-in TDF parser to parse UnitDefs and FeatureDefs. These TDFs were also expected at hardcoded locations in the mod.

Now, Spring expects some LUA script to fill a table with UnitDefs and FeatureDefs. The default implementation of the LUA script, that is to be shipped with Spring, will just do the same as the original hardwired code did: parse TDFs, and return their data to Spring.

However, mods can override this script to do something else: they can override it with an XML parser script for example, if they prefer to edit all their unit values in XML. Or they can move directories around by modifying that in the script. Or, what the real benefit of this change is: they can use LUA to define the units/features. This way they can use includes to reduce duplicate tags, they can relate tags to other tags, use variables, calculations etc.

In each of these situations, simply parsing the TDF will not give the expected results, since it is possible the mod doesn't even contain TDF files!

OMG

So it will be even more fucked up than now. Will require tons of hours to code all that with PHP. >__>

I dont see why that should be changed, like what was the problem with old style? It was okay, but had some fuckd up things, but those could be fixed instead of making totally new system which is even more complicated... I just dont see any advantages with this new shit, and i dont even understand it till i see some sample code.

It's still up to the modder to decide whether they want to be fucked or not wrt modinfo

I can imagine some better solution for 3rd party mod reading would need be written sometime (sort of a unitsync next generation ) which could encapsulate all this trouble to go through when reading maps/mods.

EDIT: Remember that nothing changes for you unless the modder decides to use the new system.

Tobi wrote:EDIT: Remember that nothing changes for you unless the modder decides to use the new system.

>_> thats whole point, my modinfo program should be able to read any mods, if they works with newest spring version...

So basically i need to create LUA scripting language for PHP ?

no need for that, just use a lua interpreter and some lua code that hooks up to the parser and spits out data that your php can use, read this trough a pipe and voila.

argh i just hate lua