Widget / Gadget Interaction, serious bug

[Argh]

Basically, I've developed a Widget that can totally hose a Gadget's behavior. I'd really like to know why.

I developed a Widget, at the last second, to select all of the infantry in a given Building in P.U.R.E., if you select the building they're "in". Since they aren't really "attached" to the Building, this took a bit of doing.

However, I've had to scrap the Widget. It caused a number of weird behaviors, several of which seem to qualify as genuine engine bugs:

1. The Widget tries to select Units that aren't on my Team. This means that if one guy's using the Widget, it caused the other player to lose their selection focus!

2. The Widget somehow interferes with the actions of the main Gadget code, causing error spam and in some cases causing drastic errors to occur (among other things, by manipulating the Building a bit, I was able to replicate my troops for free, which should have been entirely impossible).

Finding the cause of these issues, or getting the Widget / Gadget combo to work properly, is going to require some help on the engine side. It really appears to me that there are some serious underlying problems here, and they may even be exploitable (among other things, I'm 100% sure you can write a Widget that will deny other players the ability to reliably select their Units- a pure griefer's tool).

Here's the Widget / Gadget that's causing all of this trouble.

Buildings.lua works just fine, so long as SelectInBuildings.lua is not operating. I probably need to emphasize that, before I get blown off for writing buggy code. However, the Widget actively interferes with the Gadget. To see this in action, download P.U.R.E., and put SelectInBuildings.lua into PURE_CORE.sdz's LuaUI folder. Watch what happens, when you turn the Widget on, then off.

None of what you will observe should be happening at all. I put in multiple checks, to try and prevent the Widget from selecting stuff it wasn't allowed to, etc., but to no avail. I think there's a very serious problem with Widgets, where they're being allowed to reach across Team lines and attempt to select things. I also strongly suspect that the actions of the Widget selecting everything in Buildings is causing a major bug that's somehow causing the Units that are spawned to be multiplied, perhaps because it's delaying crucial parts of the code too long, futzing up the returned values, etc.- it's difficult to pin down from my end.

[lurker]

Selection itself is unsynced; there is nothing wrong with selecting enemy units. I'll take a look at the code.

[Argh]

Why would you ever want to select enemy Units? I'm curious about the use-case there. Search for them, sure. Put them into a group of UnitIDs if their LOS state returns true, sure.

Select them in any way that allows for manipulation or possible view of the other players' UI states... no.

I mean... if there's a safe way to do the desired behavior, I'm all ears, trust me.

I just don't see why the logic I wrote should even allow Bad Things to happen. None of the variables match, and I wrote all sorts of safeguards into the Widget, trying to prevent borks... still borks.

And this isn't the only time it's happened. Google_Frog was able to cause various problems with Widgets that aren't included in the "pure release" of the game.

[jK]

sounds like the gadget is broken/bad written ...

[Argh]

Sure, it could be there. But it works just fine, until the Widget gets involved. So my call on that is no, it's the Widget. If you see a specific problem with the Gadget's logic, let me know, I thought it was pretty straightforward.

[jK]

Couldn't find any mistakes in the gadget nor in the widget.
So define "error spam" and what are the lines of code that causing those. And are you 100% sure it is that one gadget which cause them. (did you tried to disable all other gadgets etc.)

[Argh]

The errors I've seen occur here, line 204, Buildings.lua, when the Widget's active:

x,y,z = GetUnitPiecePosDir(u,piece)

I get an error back that says that it's trying to evaluate a table, not a number. Which should be impossible.

At any rate, I'll try turning every other Gadget / Widget off and report the results, but it'll be about 24 hours.

[lurker]

Select them in any way that allows for manipulation or possible view of the other players' UI states... no.

The UI state is unsynced, come on Argh, you know the network only sends commands and messages. Selecting enemy units allows you to get a cost appraisal, see some capabilities, etc. It has uses.

Sure, it could be there. But it works just fine, until the Widget gets involved. So my call on that is no, it's the Widget. If you see a specific problem with the Gadget's logic, let me know, I thought it was pretty straightforward.

Gadget working until the widget get involved means nothing. The widget can only do things the player can do. It's either the gadget or maybe a bug in spring, never the widget. The unit creation call is in the gadget.

On a slightly related note, are you still using that widget blocker that can be ignored without changing the game contents or spring.exe?

[Argh]

No, I'm not using the NoCheat one, not the WhiteList. So it's that modified WidgetHandler.

[lurker]

I'm sorry I wasn't clear. NoCheat brand widget handler can be exploited to reload your own widget handler by changing some of the secondary files in LuaUI\. Take any of the files it includes() and add a hijack to them. Only a few minute effort tbh. That's why I developed the version that has luaui.lua patch all VFS calls to zip-only and needs a copy of a full spring install's LuaUI folder.

[Argh]

Lovely. Is there any way to mitigate this atm? I'm sure that's causing issues, and I know for a fact that Google_Frog reported these errors first, and said that he was using non-approved Widgets at the time.

In the end, that feature has to work, guys. You can't have a serious multiplayer game where people are exploiting problems or buggy areas in the underlying UI code, or making Gadgets behave in unexpected ways. Even if all behaviors that I consider to be cheats are excluded or mitigated, this remains a very serious issue.

[lurker]

Sorry that I keep editing my posts to add info while you're replying. >_>

In the end there is nothing you can do to stop people hacking the mod archive, but you can definitely make your code block anything short of that.

[Argh]

Why doesn't hacking the mod archive cause desync?

That's why I developed the version that has luaui.lua patch all VFS calls to zip-only and needs a copy of a full spring install's LuaUI folder.

Link? I'll install that today.

[MidKnight]

wait, a hacked mod archive still syncs?

[lurker]

Merely changing the mod archive causes a desync.
Hacking the mod archive includes ensuring it ends up with the same CRC32.

[Auswaschbar]

Why doesn't hacking the mod archive cause desync?

Because the used checksumms are weak and its easy to find collisions.

[Argh]

Ok, that is what it is. I know making that work better is on the long list of Things To Do.

Still, it sounds like I need to install Lurker's changes asap

[lurker]

Link? I'll install that today.

http://spring.clan-sy.com/phpbb/viewtop ... 14&t=17743
Note how you suggested it be a mod option, I delivered a few minutes later, and then it was forgotten forever.

[Argh]

<sigh> Yes. Done. It'll be in the next patch.

[lurker]

You got the one on the second page, right? It would be nice if it was harder to get around lockluaui entirely, but I can't think of any ways to make it particularly hard.