gamedata/LockLuaUI.txt

Post by **trepan** » 08 Oct 2007, 05:14

http://spring.clan-sy.com/fisheye/chang ... g/?cs=4528

Suggested gamedata/LockLuaUI.txt file content:

gamedata/LockLuaUI.txt
----------------------
If this file exists in the mod's gamedata/ directory,
then the LuaUI base file (gui.lua) can only be loaded
from the mod's filesystem. This essentially puts the
mod in full control of what can be done with LuaUI.

MetalSkin · Post by **MetalSkin** » 08 Oct 2007, 05:31

But then couldn't an end user just delete the file to remove the lock?

Unless spring validates that all the files required for the mod exist and have the same checksum as the server or similar, it's going to be easy to get around.

Snipawolf · Post by **Snipawolf** » 08 Oct 2007, 05:32

O___o

If I change a single thing in my mod, I then can't play with anybody else with the "same" mod.

Just a single character would make it unplayable, I think.

Post by **trepan** » 08 Oct 2007, 05:35

MetalSkin
Take that train of thought a step further, you could make a slight
modification to your exec to remove the lock for all mods. There are
no real unsynced client side security measures.

Example: In this case, a single instance of "//" will do the trick

smoth · Post by **smoth** » 08 Oct 2007, 05:36

*sighs* it is in the MOD file not spring, which means if you remove it you would not match the other player's file. MOD side, meaning part of the mod.

MetalSkin · Post by **MetalSkin** » 08 Oct 2007, 05:38

trepan wrote:Take that train of thought a step further, you could make a slight
modification to your exec to remove the lock for all mods. There are
no real client side security measures.

Didn't realise that, but then I presume the Spring community doesn't include the type of personalities who feel the need to use hacks to get an edge in-game. 0_o

But it's a good idea. I reckon the need for mod specific and mod restricted luaui is important. :)

:edit:

smoth wrote:*sighs* it is in the MOD file not spring, which means if you remove it you would not match the other player's file. MOD side, meaning part of the mod.

Ahhh, no worries.. sorry for the creation of exasperation. o_O

smoth · Post by **smoth** » 08 Oct 2007, 05:42

it's no big deal man, I just hate seeing people freak about features that are options. Just sighing out of frustration.

It basically will give us "moders" control over what lua we allow in our project. This is important when some of us have features that could be spoilted by widgets or say our own ui that would be borked by say, ICEUI.

As far as hacks, it has happened in the past and I have considered some nasty ones in the past.

Forboding Angel · Post by **Forboding Angel** » 08 Oct 2007, 16:01

Thank god for this. I have needed something like this for a while. Good to see that I actually have some small form of control now.

Fanger · Post by **Fanger** » 08 Oct 2007, 16:55

What did I do.. I swear I didnt mean to do it..

it was an accident.. darn it..

Post by **trepan** » 08 Oct 2007, 22:50

Forboding Angel
Your god had nothing to do with this addition

Forboding Angel · Post by **Forboding Angel** » 08 Oct 2007, 22:58

trepan wrote:Forboding Angel
Your god had nothing to do with this addition

Just had to get the random prayer thrown out there

Post by **trepan** » 08 Oct 2007, 23:00

Blessed be thee, my son.

Zpock · Post by **Zpock** » 08 Oct 2007, 23:33

trepan wrote:Your god had nothing to do with this addition

One of mine did tough

Warlord Zsinj · Post by **Warlord Zsinj** » 09 Oct 2007, 00:17

Trepan, thanks for listening to our concerns :)

Neddie · Post by **Neddie** » 09 Oct 2007, 03:22

trepan wrote:Forboding Angel
Your god had nothing to do with this addition

Wait, can I worship Trepan now?

SwiftSpear · Post by **SwiftSpear** » 09 Oct 2007, 06:15

neddiedrow wrote:
trepan wrote:Forboding Angel
Your god had nothing to do with this addition
Wait, can I worship Trepan now?

Pretty much, ya.

KDR_11k · Post by **KDR_11k** » 09 Oct 2007, 11:43

Can we make it selective so we can disable only widgets known to cause problems? This would be not for preventing widgets from giving an advantage, just to prevent conflicts between the mod's GUI and the widgets a user may have.

Warlord Zsinj · Post by **Warlord Zsinj** » 09 Oct 2007, 12:02

While that would be good for a mod that needs to disable certain widgets to ensure playability, but is happy to leave things open (which means the modder doesn't have to update their mod to include new widgets), it would be pretty difficult to achieve. Say you have a supermega cheating widget, or, a super megabreaking widget that the modder doesn't want to allow, so he puts it on the 'ignore this widget' list, the user could just change the name of the widget, and circumvent the protection.

quantum · Post by **quantum** » 09 Oct 2007, 13:14

You can edit the widget handler so it only forwards the API functions that you like.

Forboding Angel · Post by **Forboding Angel** » 09 Oct 2007, 16:29

Well, regardless, I would hope that most modders would include all the best (and considered necessary) widgets with their mod.

For example, my mod is going to require the xray widget, because that's how the teamcolor is getting applied (looks awesome on s3o's, pretty crappy on 3do, I assume because 3do is a face by face type of deal and the fact that the vertecies are not smoothed by the renderer at all - or something like that - also it seems to respond interestingly to reflectivite on the uv map) and so far it looks great, not too intrusive, just enough to see that it's there.

But my main point is that and widget that makes playing the game more fun, and easier I will generally include as a default. The dps widget is another great example, having a visual representation of damage done is very helpful to players because seeing an orange or red bar is only marginally helpful in comparison.

Spring RTS Engine

gamedata/LockLuaUI.txt

gamedata/LockLuaUI.txt