Is it possible...

[eyu100]

to selectively disable gadgets by modifying the engine source code?

[rattle]

Yes

[Tobi]

Not easy though, since the engine does not know about gadgets at all. (This is managed by the gadget handler, which is written entirely in Lua and is usually included with the mod/game.)

Also note that if this are gadgets which actually modify the game behaviour (which is what most gadgets do), then having one disabled means you won't be able to play online with that configuration. (You'd desync.)

If you actually want to do it (there are no good reasons to do so IMO), the easiest way would be to modify CFileHandler::Init to always look at the raw VFS first, and put an empty .lua file with same name as gadget you want to disable in the LuaRules/Gadgets/ folder in one of your Spring data folders.

[YokoZar]

Also note that if this are gadgets which actually modify the game behaviour (which is what most gadgets do), then having one disabled means you won't be able to play online with that configuration. (You'd desync.)

Don't some gadgets only limit the players ability to send otherwise valid commands? Would disabling these still cause a desync?

[Kloot]

yes (gadgets cannot prevent sending, they can only allow or disallow execution after receiving)

[Regret]

Is it possible to modify engine behavior by modifying engine source code?

Fixed.

[eyu100]

Is it possible to modify engine behavior by modifying engine source code?

Fixed.

Oops. Should have said "is it easily possible"

[lurker]

Can you explain this more? I can't imagine any scenario where you would want to disable parts of a game from the engine.

[eyu100]

Can you explain this more? I can't imagine any scenario where you would want to disable parts of a game from the engine.

If you could it would be problematic because people could cheat by disabling gadgets (like the unit_prevent_load_hax one in BA).

[thesleepless]

you're talking about Widgets not Gadgets

Widgets are user interface things that the player can disable and add their own
Gadgets are part of the mod

[lurker]

'load_hax'? I guess I'll just have to test myself if the rapid load orders actually screw the transport movement or just compensate for a longstanding bug, since no one answered my question. But that gadget doesn't stop you from giving orders, as Kloot said, and you could give orders from outside of normal channels anyway. That's why the gadget works when orders are received. Have any other examples?



thesleepless, I read the topic again to see... I think you need to read the topic again.

[eyu100]

'load_hax'? I guess I'll just have to test myself if the rapid load orders actually screw the transport movement or just compensate for a longstanding bug, since no one answered my question. But that gadget doesn't stop you from giving orders, as Kloot said, and you could give orders from outside of normal channels anyway. That's why the gadget works when orders are received. Have any other examples?



thesleepless, I read the topic again to see... I think you need to read the topic again.

You could give load orders, but the gadget would stop them from napping moving coms (?). Without the gadget, you can give orders normally and nap moving coms with a widget. Another example: the surrender gadget in S44 gives certain units to Gaia. A player might be able to gain an advantage if those units were not given.

[yuritch]

If one player's game 'thinks' the units are given to GAIA and another player's game don't, how do we call that? A desync! That's why disableng gadgets on one player side is not feasible, they are the same for all players in a given game.

[YokoZar]

While what Kloot said is true, I'm beginning to worry about gadgets that send commands on behalf of the player.

If one player's game 'thinks' the units are given to GAIA and another player's game don't, how do we call that? A desync! That's why disableng gadgets on one player side is not feasible, they are the same for all players in a given game.

The problem is when the gadget is trusting the player to do the right thing in some cases. If the mod author assumes everyone has the gadget (generally a good assumption), then the mod author might assume that the gadget can be trusted to issue the right commands (eg "give away my units"). If the player has the gadget but doesn't activate it due to engine hacking, then he'll never send those commands, and there won't be a desync since the other players won't receive them either.


In other words any gadget that requires sending commands would be vulnerable -- the only solution I can see is to have each player independently generate the commands the gadget would have sent.

Then again that may be the way it is already I don't know.

[Auswaschbar]

Seriously, if people start hacking the engine source to get an ingame advantage the least thing I would care of is if they disable certain gadgets.

[imbaczek]

you could disable a purely unsynced gadget without anybody noticing... i guess. it's about as easy as anything else.

[Licho]

All gadgets that "block" something do it in synced code. You would desync if you disable such thing. Blocked action would only perform on your client but not on others.

Unsynced parts of gadgets mainly perform visualisation or talk to luaui.

This is not a way to hax.