Request list mk.2

[Gnomre]

We could make that now with no effort at all... that's not much of a request.

[SwiftSpear]

In my opinion Spring isn't finished until modders have the ability to build mods that looks nothing like TA at all. We really need the capability to make things like our own projectiles, muzzle flares, smoke, and just a plethora of other effects that are currently handled on the game engine level. We also need to be able to define our own menus and menu GUIs, set up totally different resource and construction systems (spring is already way ahead of TA for construction systems) and really, just expound whatever we want from a RTS prespective.

Things like weapon dependacies, switch types, smoke timing, and two phasing really need to be possible for scripters to manage on thier own without the devs having to add new tags for all of them. If we keep using the add tag system the engine is impossible to finish from a development standpoint and our lists of usable tags becomes just insanely long and bloated.

[jcnossen]

Things like weapon dependacies, switch types, smoke timing, and two phasing really need to be possible for scripters to manage on thier own without the devs having to add new tags for all of them. If we keep using the add tag system the engine is impossible to finish from a development standpoint and our lists of usable tags becomes just insanely long and bloated.

Exactly, the tag system is not maintainable. Me and dj_oldfield will write a script language that should eventually replace the tag system. Yes there will be some backwards compatibility involved, but it does mean most of these new tags don't get added, but will be scriptable in the new system.

[SwiftSpear]

Things like weapon dependacies, switch types, smoke timing, and two phasing really need to be possible for scripters to manage on thier own without the devs having to add new tags for all of them. If we keep using the add tag system the engine is impossible to finish from a development standpoint and our lists of usable tags becomes just insanely long and bloated.

Exactly, the tag system is not maintainable. Me and dj_oldfield will write a script language that should eventually replace the tag system. Yes there will be some backwards compatibility involved, but it does mean most of these new tags don't get added, but will be scriptable in the new system.

Awesome... I had high hopes that the lua implimentation would be doing that, but I honestly don't care as long as someone trys to do it.

[Dragon45]

Zaphod:

Couldn't a proper LUA implementation take care of most of this? It would have to link directly into most of the engine functions and functionality, but if you made a very general implementation, the modding community could take care of most of the rest of it on its own.

[Pxtl]

Well, I would hope that unit configuration would still be done through tags. It is a good system - just that tags would be accessed as a dictionary in Lua, rather than each tag having an explicit functionality.

For example, say I add code to my mod to make things explode into a puddle of goo when destroyed. So, I write Lua script for the puddle of goo and add code to the "on unit destroyed" event thingy. This code checks if the "Explodes_Into_Puddle_Of_Goo" tag is present on the unit, and if so it creates the puddle of goo.

Thus, the tag system becomes extensible.

[jcnossen]

Well, I would hope that unit configuration would still be done through tags. It is a good system - just that tags would be accessed as a dictionary in Lua, rather than each tag having an explicit functionality.

It would be easier to put these "tags" as constants in the unit script file than to have a seperate FBI file.

Couldn't a proper LUA implementation take care of most of this? It would have to link directly into most of the engine functions and functionality, but if you made a very general implementation, the modding community could take care of most of the rest of it on its own.

It could, but it would be a lot slower than a new scripting language, and require a lot more interface code to get it connected to the spring engine.
And with spring already requiring a fairly fast PC, I only want to decrease the minimum requirements(If possible) and not increase them with using lua.

[Pxtl]

Well, I would hope that unit configuration would still be done through tags. It is a good system - just that tags would be accessed as a dictionary in Lua, rather than each tag having an explicit functionality.

It would be easier to put these "tags" as constants in the unit script file than to have a seperate FBI file.

Couldn't a proper LUA implementation take care of most of this? It would have to link directly into most of the engine functions and functionality, but if you made a very general implementation, the modding community could take care of most of the rest of it on its own.

It could, but it would be a lot slower than a new scripting language, and require a lot more interface code to get it connected to the spring engine.
And with spring already requiring a fairly fast PC, I only want to decrease the minimum requirements(If possible) and not increase them with using lua.

Umm, you want a new scripting language that is powerful and verbose, and also fast, and not off-the-shelf like Lua. At this point, you're basically saying "I want a pony! And a car! And a ponycar!"

Making a language from scratch is hard enough without trying to make it fast and friendly too.

[AF]

It could, but it would be a lot slower than a new scripting language, and require a lot more interface code to get it connected to the spring engine.
And with spring already requiring a fairly fast PC, I only want to decrease the minimum requirements(If possible) and not increase them with using lua.

Zaphod are you not speaking to the other SY's at all?!?!!?!?!? All the itnerface code for lua is provided by luabind, which reduces the glue functions down to a measly line of code to bind a function.

Lua is prooven, and already implemented. What happens when Supreme comamdner comes aroun and people demand cross compatability, "Oh sorry btu we spent lots of time replacing a perfectly good interpreter with a new oen we wrote ourselves"

Even when lua has bene sued in many other commercial games, and already has a strong abse to support it, adn you're going to go ahead withr epalcing it with some new foreign thing??!?!?!?!?!

I dont know about everyone else btu there are enough problems already in the spring project that need fixing without expeirments going on tthat are of that sort of size. Go fix the new GUI code, ro sort out the errors I've found from using the AI itnerface, such as untis forgetting how they work and simpyl stopping having to be force stopepd to continue, or units getting trapped in factories causing terible overflow errors that lag the game to hell, ever wodner why half my shots of AI battles ahve blast marks in the middle of well defended bases? It's where a freaker has gottn caught and I've manually selfdestructed the factory. I didnt even know it was happening because I ahd to search through 2GB+ logfiles to fidn it.

What about GAIA player support? Fixed yardmaps? Jumping and strafing in FPS? Custom FPS gui? fixing closestBuildSite in the AI itnerface? Integrating the ghost switch I added, and prioritized messaging?

So you see, there are more important things than integrating a script itnerpreter you made and adding to it heavily and integrating.

Work on the more important things. People want new features, they dont want to ahve to learn about a new interpreter and howto use it.

[jcnossen]

Umm, you want a new scripting language that is powerful and verbose, and also fast, and not off-the-shelf like Lua. At this point, you're basically saying "I want a pony! And a car! And a ponycar!"

I have done it already, before I started on spring I created a scripting language very similar to UnrealScript, that compiles to native x86 code. I agree that if this was not the case, it be too much work to pull off. But now that dj_oldfield is also agreeing with me (In fact he proposed to write a new script language to begin with), I think this is a good idea.
Originally I wanted to release it as a scripting library, but I got interested in writing an AI.

Zaphod are you not speaking to the other SY's at all?!?!!?!?!? All the itnerface code for lua is provided by luabind, which reduces the glue functions down to a measly line of code to bind a function.

Newsflash for you, the SY's are not actively working on spring at all. A lot of dev people just disappeared. Of the SYs only fnordia is helping with releases and other things, since he started the lua binding, I'm still waiting for his thoughts about this. What is known as the "linux team" is reduced to pretty much Chris Han only, and I have contacted him and he agreed with me that it is a good idea.

Lua is prooven, and already implemented. What happens when Supreme comamdner comes aroun and people demand cross compatability, "Oh sorry btu we spent lots of time replacing a perfectly good interpreter with a new oen we wrote ourselves"

Lua is proven and slow, too slow for simulating 1000+ units. People demanding cross compatility? People can demand anything, but it is the people who do the work that make the decisions, and this is a decision of all the people that work on the engine. (That is, once fnordia agrees with me)

Even when lua has bene sued in many other commercial games, and already has a strong abse to support it, adn you're going to go ahead withr epalcing it with some new foreign thing??!?!?!?!?!

If it does a much better job, yes. Besides lua is holding up the port now because luabind doesn't work on GNU C++.

I dont know about everyone else btu there are enough problems already in the spring project that need fixing without expeirments going on tthat are of that sort of size.

This is not an experiment, it's a long-term goal for the project. Making it a more general rts engine too.

People want new features, they dont want to ahve to learn about a new interpreter and howto use it.

You need a good base to build on, this code is made for TA, it's not very good for a general rts, and it is quite bloated too. You can't endlessly continue with adding new tags to the system.

It can be made backwards compatible with the current unit/feature tag system, it will only add more flexibility for new units/mods/maps, so really I don't see why this is such a problem.

[AF]

Well then, compiling to x86 code sounds nice-ish, but it'll be faster than lua, and I didnt knwo you had compelted the whole thign already.

But support lua syntax, and the existing api from luabind, otherwise it might become a problem in the future.

As for there only being a single SY left on the project, I think you should have pushed this topic as urgent before now. Many a person would be surprised by that, and it is not a good sign at all.

I suggest to you then that you replace the current registry handler so that ti supports your new interpreter, so that the settings files are stored in files. That way you can just set the script.txt to have a settings= tag then I can set up settings.exe to do proper option profiles for graphics etc.



I still dotn see ghosted buildigns and prioritized messaging in the cvs or in 0.66, I posted the code on fileunvierse ages ago for SJ and it's been prooven to work, as the changes arent that major anyway.

And my version fo settings.exe is prettier imho.

[jcnossen]

I've added the ghosted buildings options earlier myself, together with betalord. Your version just read it from the registry, which is not solving the problem (It needs to be a lobby option).
I've added the prioritized messages. I did a lot of changes though, chitchat is changed to verboselevel, which is imo a more standard term for filtering output. Your code also didn't consider the new gui, so basically I changed all your code

For information, messages are shown if MessagePriority <= VerboseLevel, with VerboseLevel=0 being the default.

But support lua syntax, and the existing api from luabind, otherwise it might become a problem in the future.

Lua syntax is nice yes, it is very readable to people who just start scripting. Keeping luabind is not a good idea, because it can't be compiled on GCC.

[Nemo]

Uh. Quick note.

I love you Zaphod.

Tag-free system is a great idea. Unit making will be less newb friendly (at least, newbs without coding experiance..like me <_<) but the huge gain in flexibility and power is well worth it.

From a novice standpoint, being able to script a tag and then call it in a FBI-like file is something I like, but if there's an easier way to go about it with script only, I can understand.

The future is looking bright, brilliant job thus far.

[zwzsg]

In terms of transports, I just want to see transports be able to drop units on the fly. So they swoop down, let their unit go, and fly off, without losing any speed. Would infinitely increase the usefulness of units, and make them look cool too.

Sound doable right now, if we can mount hover/ship transport scripts on planes. So that the loading can be done normally. While loading I'd store the unit ID, and when the attack button is used I'd "drop" all those unit ID.

And if can't mount hover/ship transport scripts on planes, I can still go for the full zwzsg way, such as the one Under_ware use on his Operation Polaris, which will work for sure, but has the inconvenient of requiring a known, fixed, unitlimit, and of not using the load/unload button anymore.

Also, zwzsg has said his bridges... kind of work in Spring, but a couple fundamental changes need to be made to the engine's internal structure before they're usable. Since spring currently has the same bridge limitations as TA, zwzsg's way is the only way you're going to get a bridge; therefore, if you want a bridge, changes need made to the engine.

If you want to try, here is a bridge for Spring: FlatBridgeV8spring.ufo. This is just TA:Cataclysm's script with the addition of a transportcapacity tag. The only engine change I'd request for this bridge would be a way for a script to know what is the range of valid ID for units. Oh and this brige hasn't been optimised for Spring, so it's often hidden by the terrain, it's too short, and it's hard to find the entry spot. I haven't taken the time to optimise it for Spring, it's just my old TA bridge with a single tag added to make it work under Spring.

[GrOuNd_ZeRo]

OMFG...don't tell me tags will be removed...

I can't CODE! I suck at coding and I don't know barely SHIT about C++, the only thing I know about it is what I learned in TA scripts and QuakeC which are inferior versions of it...

And now you expect us modders to just deal with it? Tags make these mods possible! I want tags to be supported and added gradually so we simply have all the tags available we need.

Otherwise modding will be RESTRICTED to programmers...i'll be EXTREMELY unpleased and i'll walk out of the TA community because I don't have the time to learn another programming language, i'm too busy with life right now to learn anything else.

This does not bode well, I was already DREADING that crazy ass LAU shit and now we are more than likely will have another programming CODE-O-Hell...that's real great...kill the average modder..fine...

Yes, i'm extremely frustrated by this and I wish I could do the programming my self, but I can't, I don't have the time to learn C++ since I have other things on my mind, like a wife to maintain, pets, setting up a job, immigration...lots of shit...how am I gonna learn a programming language that MORE THAN LIKELY will aproach C++? there is no way...

[FireCrack]

It's not code, it's just script...


If you can make the scripts for units now, and even if you cant, it's not that hard, youl get the hang of it...


FYI i dont think anyone is suggesting reverting to C++ for mods, just a proprietary scripting language, like lua, but more intuitive, more powerfull, and faster.

[GrOuNd_ZeRo]

As long as it's user friendly I wont bitch, but with so many variables it will be quite hard.

Yeah I started freaking out about the LAU, i've seen it and it's not even remotely user-friendly.

as long as it's as easy as scripting TA scripts or better yet, easier,i'll be happy.

[SwiftSpear]

From what I understand the goal isn't to remove tags, it's to replace them. All the old tags will still be supported via backwards compatability, but rather then adding new tags to fill holes the engine will simply allow much wider access to it's more basic functions. Rather then just making tags to cover every possible function a unit can possibly preform, we write a scripting language that lets the player tell the engine exactly how he wants the game to handle his unit.

The add tag system just isn't sustainable, we will need to add tags for every possible behaviour and function, because none of the tags are general enough to really do all the things the engine could possibly do in the most efficient way. Eventually we would need dictionarys of tags and figuring out what all of them do would be virtually impossible without looking it up.

[PauloMorfeo]

...
Lua is prooven, and already implemented. ...
Even when lua has bene sued in many other commercial games, and already has a strong abse to support it, adn you're going to go ahead withr epalcing it with some new foreign thing??!?!?!?!?!
...

I also considered that and thought it was a nice idea.
Still consider, the LUA implementation was still beeing tested, it was not defined yet. LUA has been tested meaning, if they change it to something else, they must have had they're reasons. On the Linux porting effort mail-list, some good arguements have been discussed about that. Also,

... LAU, i've seen it and it's not even remotely user-friendly.
...

Still, Zaphod,

...
I can't CODE! I suck at coding and ...
Otherwise modding will be RESTRICTED to programmers...

If Spring is really going to follow that path, you better show off something before it gets too deep so the modders can check it out and see if it will really kill they're modding or if they can live with it.

As long as it's user friendly I wont bitch, ...

[jcnossen]

how am I gonna learn a programming language that MORE THAN LIKELY will aproach C++? there is no way...

If you refuse to learn a scripting language, then simply think of it as tags moving to another filetype The idea is to have an extendible system instead of fixed tags. You could for example derive your unit from another unit script class and only override the scripts constant values (ie: comparable to setting tags now). Even if none of the modders write any script at all and only derive from base script classes, it's still a better situation for the coders because they can extend the system much easier/faster.