Thoughts on lua

Thoughts on lua

Discuss Lua based Spring scripts (LuaUI widgets, mission scripts, gaia scripts, mod-rules scripts, scripted keybindings, etc...)

Moderator: Moderators

Post Reply
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Thoughts on lua

Post by AF »

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++.
User avatar
LordMatt
Posts: 3393
Joined: 15 May 2005, 04:26

Re: Thoughts on lua

Post by LordMatt »

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

Post by Argh »

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

Post by AF »

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.
User avatar
LordMatt
Posts: 3393
Joined: 15 May 2005, 04:26

Post by LordMatt »

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.
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. :-)
Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Post by Tobi »

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.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Post by smoth »

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.
CautionToTheWind
Posts: 272
Joined: 30 May 2006, 17:06

Re: Thoughts on lua

Post by CautionToTheWind »

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

Post by AF »

No, because thats how it is at the moment.

If players where forced to use the modders GUI then they'd have to modify the mod archive to change it. This would desync the player in the lobby and the battle would never start. Cheating averted.
User avatar
ILMTitan
Spring Developer
Posts: 410
Joined: 13 Nov 2004, 08:35

Post by ILMTitan »

Only if they didn't have a hacked lobby which would spoof the checksum which would probably only require a change in a very small part of the base code.
I'm not saying this is not a risk we can accept, just pointing out that it is not nearly as secure as core engine limitations.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

A cheating player would immediatly be found out by the other players.

And someone willing to goto those lengths wouldnt bother and instead patch spring.exe to give the correct checksum and use those sorts of hacks.
User avatar
ILMTitan
Spring Developer
Posts: 410
Joined: 13 Nov 2004, 08:35

Post by ILMTitan »

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

Post by AF »

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.
CautionToTheWind
Posts: 272
Joined: 30 May 2006, 17:06

Post by CautionToTheWind »

AF wrote:This gets around and nobody plays the cheater anymore. Nice and simple social based nontechnical implementation of anticheating.
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.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Post by Pxtl »

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

Return to “Lua Scripts”