Thoughts on lua
Moderator: Moderators
Thoughts on lua
Trepans work on lua GUI shows that there's a lot of gimmickery and pretty useful stuff that can be done, but the scripts could be used to implement core gameplay, automate correct or augment unit behaviour, and the amount of gadgetry available means given a good setup it could be a very useful alternative to the groupAI interface.
The problem comes when the user flicks the off switch. Essential game rules and features would be turned off, and in a game of 3 players, 1 player could switch off their lua GUI and break the rules of the game mechanics and break the mod, or even create their own lua UI to get around limits imposed by the modder via lua UI game mechanics.
Thus there needs to be a modder option to force the modder GUI regardless of the users settings, just like with team coloured nanospray.
And with regards to lua animation, its been said that the reason it isnt considered is because nobody here knows how to implement it for multiple scripts and not a single script.
Thus has it been considered that multiple lua environments be used? Or that all the scripts classes be stored in an index lua table using the index table (indexed via unit ID) to get the objects and make calls, like map<int,unitscript> scripts; in C++.
The problem comes when the user flicks the off switch. Essential game rules and features would be turned off, and in a game of 3 players, 1 player could switch off their lua GUI and break the rules of the game mechanics and break the mod, or even create their own lua UI to get around limits imposed by the modder via lua UI game mechanics.
Thus there needs to be a modder option to force the modder GUI regardless of the users settings, just like with team coloured nanospray.
And with regards to lua animation, its been said that the reason it isnt considered is because nobody here knows how to implement it for multiple scripts and not a single script.
Thus has it been considered that multiple lua environments be used? Or that all the scripts classes be stored in an index lua table using the index table (indexed via unit ID) to get the objects and make calls, like map<int,unitscript> scripts; in C++.
Re: Thoughts on lua
I don't support that at all. The user should have the last say over GUI stuff, as much as is feasible. Particularly with the spate of moders who don't play their mods online much.AF wrote:Thus there needs to be a modder option to force the modder GUI regardless of the users settings, just like with team coloured nanospray.
Um, I'm probably not really qualified to ask this, but as LUA is an interpreted language, what advantages, if any, would there be in implementing changes to core gameplay through LUA rulesets?
To look at this another way... if the core of Spring, "unit.cpp" was actually a command that passed a bunch of LUA to a compiler so that it would run quickly in-game, instead of what it currently is now (a big, scary set of nested loops)... could we then have a Spring that is truely open to new game designs (multiple resources, for example) without having to have multiple versions of Spring?
I'd really like this approach, which is fundamentally similar to the Command Engine concept, because it would allow Spring to become a 3D interface and multiplayer environ for multiple games, each sharing commonalities but far fewer than at present.
But there are a huge number of obvious obstacles that have not been addressed yet, and I'm really not sure if it would be smart to sink a lot've time into looking at this when Command Engine at least theoretically could provide complete control over wider areas, because it is creating better modularity from the start. One of the biggest problems with Spring is that so much of the code is not really modular- that was the single biggest reason Command Engine was a good idea. I'm just a wee bit concerned that implementing stuff like what you're talking about here AF would just make Spring even more of a spaghetti-loop mess...
[EDIT]And on the whole "should modders have absolute control over GUI elements, if they want to?" question, my answer is, "yes- the market will punish them if they don't do a good job". In short... everybody's fears about modders controlling the GUI are mis-founded... for a long time, Spring's coders were the sole controllers over Spring's GUI, and while it wasn't perfect, it was certainly "good enough" to attract a wide playerbase. Ultimately, if a modder makes an interface that really is a better product, then they will not have players wanting to change it, because players won't really have a better idea. That said, I have a hard time imagining an interface that makes every possible user happy.
To look at this another way... if the core of Spring, "unit.cpp" was actually a command that passed a bunch of LUA to a compiler so that it would run quickly in-game, instead of what it currently is now (a big, scary set of nested loops)... could we then have a Spring that is truely open to new game designs (multiple resources, for example) without having to have multiple versions of Spring?
I'd really like this approach, which is fundamentally similar to the Command Engine concept, because it would allow Spring to become a 3D interface and multiplayer environ for multiple games, each sharing commonalities but far fewer than at present.
But there are a huge number of obvious obstacles that have not been addressed yet, and I'm really not sure if it would be smart to sink a lot've time into looking at this when Command Engine at least theoretically could provide complete control over wider areas, because it is creating better modularity from the start. One of the biggest problems with Spring is that so much of the code is not really modular- that was the single biggest reason Command Engine was a good idea. I'm just a wee bit concerned that implementing stuff like what you're talking about here AF would just make Spring even more of a spaghetti-loop mess...
[EDIT]And on the whole "should modders have absolute control over GUI elements, if they want to?" question, my answer is, "yes- the market will punish them if they don't do a good job". In short... everybody's fears about modders controlling the GUI are mis-founded... for a long time, Spring's coders were the sole controllers over Spring's GUI, and while it wasn't perfect, it was certainly "good enough" to attract a wide playerbase. Ultimately, if a modder makes an interface that really is a better product, then they will not have players wanting to change it, because players won't really have a better idea. That said, I have a hard time imagining an interface that makes every possible user happy.
Well one immediate example that comes to mind is the artillery in s44, a lua UI could automate the process of loading and unloading, as has been requested many a time in the form of groupAI.
However I do like the idea of implementing CUnit and CComandAI in lua or at least exporting an interface todo so.
However I do like the idea of implementing CUnit and CComandAI in lua or at least exporting an interface todo so.
Well some end users will be a little ahead of the modmaker, for example I have been using a modified GUI in AA and now BA for quite some time, and those improvements have just now been incorporated into BA. Additionally, end users often spend more time playing the game in a real setting than modmakers (BA is the exception, it seems). The user ought to be able to add features he thinks are useful, and this is a big improvement over the previous situation when no one could modify the GUI. Giving exclusive control to the modmaker is a step backwards. That's not to say I don't think you could make a great nanoblobs GUI Argh.Argh wrote: [EDIT]And on the whole "should modders have absolute control over GUI elements, if they want to?" question, my answer is, "yes- the market will punish them if they don't do a good job". In short... everybody's fears about modders controlling the GUI are mis-founded... for a long time, Spring's coders were the sole controllers over Spring's GUI, and while it wasn't perfect, it was certainly "good enough" to attract a wide playerbase. Ultimately, if a modder makes an interface that really is a better product, then they will not have players wanting to change it, because players won't really have a better idea. That said, I have a hard time imagining an interface that makes every possible user happy.
I have asked once on the mailing list whether it should be so that mod has final control, and the answer was no: user should have final control over all files.
This applies to your teamcolor setting too, if you always want it on, just make a gamedata/modinfo.tdf file that overrides the mod file that disables it and voila, you can still override the mod...
I think the rest falls under unit scripting MTR (is it MTR'ed already?). I doubt it'll happen soon but feel free to submit patches.
This applies to your teamcolor setting too, if you always want it on, just make a gamedata/modinfo.tdf file that overrides the mod file that disables it and voila, you can still override the mod...
I think the rest falls under unit scripting MTR (is it MTR'ed already?). I doubt it'll happen soon but feel free to submit patches.
I have argued in in mirc and everywhere else. I do not want the user changing the ui in gundam. The reason is that it is not AA or TA really, if I do something specific in the ui i would do it for good reason but many TA:S players come into gundam with too many TA:S assumptions as it is. I don't want someone using a TA:S ui in gundam because I will be implementing some stuff that as far as the design of gundam goes will be important.
Odds are LordMatt, unlike some moders, I am not behind most users on programing. Although I find it amusing how many coders and artists in spring sit idle doing nothing to help the devs.
TA:S is just my way of loting all the Total annihilation mods in one batch. I call spring spring.
Odds are LordMatt, unlike some moders, I am not behind most users on programing. Although I find it amusing how many coders and artists in spring sit idle doing nothing to help the devs.
TA:S is just my way of loting all the Total annihilation mods in one batch. I call spring spring.
-
- Posts: 272
- Joined: 30 May 2006, 17:06
Re: Thoughts on lua
If game limits are dependant on a UI file that users can edit without desync, then you're just opening an avenue for cheating that will be much harder to close in the future.AF wrote:1 player could switch off their lua GUI and break the rules of the game mechanics and break the mod, or even create their own lua UI to get around limits imposed by the modder via lua UI game mechanics.
Because of the simulated nature of spring, the most you could get by patching spring.exe would be a map hack. Much more and you will desync the game. If a repop time to a command was added in the engine, there would be no way around it, but if added to a lua file, a hacked file could allow it to execute thirty times a second and all of the engines would remain in sync. The only way to prevent this would be to somehow add syncing to parts of the lua code, but I don't see how that could be done.
As for cheaters being immediately found out, lets say there is a command with a 30sec repop. If a cheater dropped that to 20sec or so, it is still a long enough time that it would probably not be noticed in the chaos of the battlefield, and, depending on the strength of the command, could change the tide of the battle.
As for cheaters being immediately found out, lets say there is a command with a 30sec repop. If a cheater dropped that to 20sec or so, it is still a long enough time that it would probably not be noticed in the chaos of the battlefield, and, depending on the strength of the command, could change the tide of the battle.
command repop?
No I mean it would be obvious because the cheating player would have information he shouldnt or abiliies he should or units he shouldnt.
For example, lua GUI limits whats built somehow by hiding buildpics. User patches spring to use their own GUI and gets around it. User then uses the cheat to win a game. The other players see he has more of this unit than is possible and label him a cheat. This gets around and nobody plays the cheater anymore. Nice and simple social based nontechnical implementation of anticheating.
No I mean it would be obvious because the cheating player would have information he shouldnt or abiliies he should or units he shouldnt.
For example, lua GUI limits whats built somehow by hiding buildpics. User patches spring to use their own GUI and gets around it. User then uses the cheat to win a game. The other players see he has more of this unit than is possible and label him a cheat. This gets around and nobody plays the cheater anymore. Nice and simple social based nontechnical implementation of anticheating.
-
- Posts: 272
- Joined: 30 May 2006, 17:06
I don't think that is realistic. Players don't have the time or inclination to be policemen. A fair game is something that must be provided by the engine, and not by gentlemen's agreements.AF wrote:This gets around and nobody plays the cheater anymore. Nice and simple social based nontechnical implementation of anticheating.
There are some problems here - first is that GUI-based Lua and game-based Lua need to be seperate. Hacking GUI-based Lua is just client-customization. Hacking game-based Lua is cheating.
For game-based Lua, if every single variable and every single gluecode-event is synched, then the Lua would be nearly indistinguishable from in-game code. And if the Gui-Lua needs to talk to the game-lua, it goes through the synched-event interface. That way, if you want to have button for "upgrade unit X" on the main gui, you have the button trigger the event and then the game-lua handles "change attribute Y for every unit X of team Z" - which all happens as synchronized events. Any limitations, etc. happen in the game-lua, not the gui-lua - GUI-lua is graphical only, because it is client-side-unsafe.
Or am I completely missing the point? I really have no idea what I'm talking about.
For game-based Lua, if every single variable and every single gluecode-event is synched, then the Lua would be nearly indistinguishable from in-game code. And if the Gui-Lua needs to talk to the game-lua, it goes through the synched-event interface. That way, if you want to have button for "upgrade unit X" on the main gui, you have the button trigger the event and then the game-lua handles "change attribute Y for every unit X of team Z" - which all happens as synchronized events. Any limitations, etc. happen in the game-lua, not the gui-lua - GUI-lua is graphical only, because it is client-side-unsafe.
Or am I completely missing the point? I really have no idea what I'm talking about.