Widget signing gadget (request)

[Caydr]

Ok, yes, someone can probably adapt the code so that units are also artificially inaccurate if they don't *really* have LoS while letting the player still see.

Woo. I don't care. Read my last paragraph. This doesn't need to be perfect, and indeed it can't be. Everyone knows that, but thanks for repeating yourself the ninth time. That last one really hit home and your slightly different phrasing has opened my eyes to the pure knowledge of the world. Your post was a spiritual experience and I don't think I'll ever really see things quite the same again. My world is awash in awe and delight, and my old life has lost all meaning. So now, o great guardian of cherished wisdom, go on with your life, secure in the knowledge that you've really and truly fulfilled your obligation to inform everyone of the patently obvious, for all time.

[Kloot]

Ok, yes, someone can probably adapt the code so that units are also artificially inaccurate...

They wouldn't need to.

No matter how many times you harp on the "we can't make cheating impossible, but we can make it hard" point, it's Not Going To Happen at least as far as engine development is concerned, simply because (apparently this needs to be repeated to you once again) the "we can make it hard" part is already wrong SINCE EVEN THE WORST CHEATS ARE IN PRINCIPLE UNDETECTABLE assuming the cheater is careful enough. But by all means, line up your demo-watching squads to try anyway.

[zwzsg]

If a widget doesnt support xyz game it should fail gracefully. Widgets that can test if they work or certain preconditions are meetable should test for them.

When the widget fails or a known incompatible game is being played or necessary conditions aren't met, the widget should disable itself and fail gracefully.

Of course widgets crash, but this isnt about bugs in code, this is about sloppy coding and game environment checks

As such I blame the widget maker not the content developer

Widget crashing is not an issue, 95% of the time a sloppy coded crashing widget will just be disabled by the widget handler as it crashes. You've got to try very hard to make a gadget take anything else than itself down when crashing.

So rather than have the whole head ache of it all, it is a good idea to restrict the game to only work with approved known compatible widgets. If such support existed for white lists then it would be EASY to add a mod option to allow for an unsafe mod in which all widgets are permitted. So when players want to develop new widgets or play with stuff that maybe isn't intended they could set unsafe mode on.

If you just want that, it's doable. I have a widget that enable some widgets when present, and disable the rest. People can still press F11 to renable their own widget if they really want.

[dizekat]

more often than not a player will enable a widget thinking it will work the same in X as it does in Y and it doesn't. They then will annoy the modder/content dev about the lack of support for said widget. While such requests are of course healthy we all have ample to do as it is and in the backlogs of our projects supporting stuff that isn't in the main design will end up next to forgotten.

Right so they won't annoy modder about enabling widgets X,Y,Z if mod just disables all widgets outright [edit: except for whitelist]. Actually, that is correct, modder is quite unlikely in fact to get significant number of widget support requests, I can even tell you why but you won't like it.
To be fair, I'd guess even if you somehow convert entire BA&DSD userbase to your mod, and all BA widgets totally glitch out in your mod, you won't get a lot of requests about it.

The only [actually possible, not hypothetical] problem for modder which i can see is when modder makes some UI that he believes to be beautiful (and which players don't like), and mod is actually good so someone bothers to fix iceui or something similar up a little to work with this mod. Which might cause massive emo reaction.

edit: yea, and by the way. BA and spring engine updates routinely break a lot of widgets. Even worse, some widgets are not compatible with eachother. Where's those supposed super problems?

[Argh]

If such support existed for white lists

Been using that support for months now.

That part seems to keep slipping under the radar here.

P.U.R.E. operates with certain Widgets that ship with it, and nothing else, short of hacking the executable. That solution is available in a nice modular form, just get the Demo or the game's sourcecode distribution.

I like zxzwg's solution, though, I'll check it out. I'd rather give people the choice to use things that didn't ship with it, I just didn't like it that people had stuff like IceUI enabled and it totally borks, since my UI is a Gadget. I'll add Defense Ranges to the collection, so that anybody who installs P.U.R.E. has that, which since it's the main Widget that I see as very clearly crossing the line, at least gives that to everybody.

My whole "why can't players simply trade Widgets" is about addressing the whole unfairness issue between newbies and vets.

[imbaczek]

trading widgets is great in principle, but it can be hacked around as easily as everything else.

also, it's probably doable now with some lua message hackery.

[eyu100]

In case I didn't make it abundantly clear yet. You're very sure that your mod will be far more popular than BA? If no, quit requesting bullshit. How comes neither BA nor CA has a problem with widgets, but you would immediately have? And don't give me bullshit that you can't cheat BA or CA with a widget. (though, i wouldn't want to play a game which is all about the kind of micro which can be practically and game-winningly automated anyway)

I'm not making a mod. I want the gadget to exist so it will possible for mod makers to disallow certain widgets if they want or need to.

[aegis]

so it will possible

pretty much nothing you do will make it possible.

[eyu100]

so it will possible

pretty much nothing you do will make it possible.

I said that wrong: I want it to be a little bit harder than it is right now to load widgets that the mod maker doesn't want loaded. Of course, no solution is even close to perfect, but almost every solution will make it harder to load unwanted widgets, since you can basically use any widget with any mod (except those that ban external widgets) at this point. Even if a solution only decreases the number of unwanted widgets in use by 10%, it is still a partial solution.

[CarRepairer]

Nooby question #47:

What if there was a small executable, closed source, named verify.exe. This file is put into your spring folder. It gets run when spring is run. Using unknown parameters, it verifies that your spring build is legit and sends encrypted information to a live server which then transmits to other players whether your spring is real or hacked. If this difficult-to-decode message is not transmitted, or it sends an elaborate "this spring is not legit" message, host kicks you.

Licensing issues aside, is this idea feasible? Particularly the part where I state "using unknown parameters" is important.

Disclaimer: I am not an argh and I don't claim to know anything. I fully admit my ignorance in relation to coders around here and I am asking this question out of curiosity.

[Kloot]

Not really feasible because you wouldn't need to be able to decrypt the data sent by verify.exe to bypass it, or even know how said data was generated. Just delete the official verify.exe and compile your own version that always transmits the "I am a legitimate Spring build" message (which would be easy to sniff) in its raw form. Distribute to the masses for extra points.

[imbaczek]

see also: punkbuster, battleeye. both aren't perfect.

[CarRepairer]

Not really feasible because you wouldn't need to be able to decrypt the data sent by verify.exe to bypass it, or even know how said data was generated. Just delete the official verify.exe and compile your own version that always transmits the "I am legit" message (which would be easy to sniff) in its raw form. Distribute to the masses for extra points.

Could you encode this "I am legit" message using, say, the battle ID from the host which is different every time?

If yes, also do this:

Regularly re-release new verify.exe files (with modifications to the live server so that it expects a new verification code) so that even someone eventually when cracks the code, they'd have to do it over again.

[imbaczek]

you want an example of a closed source arms race? check out WoW warden and bot developers. and that's as closed source as it gets.

[aegis]

they'd have to do it over again.

except I can just put it in a legitimate spring folder and run it there.

[lurker]

You can definitely share files right now without a heavy investment in lua code. I could make a widget sharer if anyone is interested.

[Argh]

I'd be happy to deploy such a thing, and I'd bet that CA would also support this.

[smoth]

So rather than have the whole head ache of it all, it is a good idea to restrict the game to only work with approved known compatible widgets. If such support existed for white lists then it would be EASY to add a mod option to allow for an unsafe mod in which all widgets are permitted. So when players want to develop new widgets or play with stuff that maybe isn't intended they could set unsafe mode on.

If you just want that, it's doable. I have a widget that enable some widgets when present, and disable the rest. People can still press F11 to renable their own widget if they really want.

that is not what I am suggesting.

Unsafe mode default off:
Players cannot activate or deactivate any widgets, the game decides that and it is a set list.

Unsafe mode on:
allows users to enable whatever widgets they fucking please

momfreek understood exactly what I was on about.

[Forboding Angel]

^^ Now that seems like an optimal solution.

[Niobium]

Are there widgets which give a large advantage to players with them, over players that don't have them? No.

Will there be any widgets like that in the immediate future? No. (Widgets have been around for how long now?)

Can a widget do anything a skilled player couldn't? No.

Because of the above, would you be able to tell if a player was using such a widget? No.

If the game from your point of view seems normal, regardless of whether the widget is actually being used, then is their a problem with having the widget around? No.

Given that there isn't actually a problem with current widgets, and unlikely with future widgets, should any effort at all be expended on creating ways to block/monitor widgets which don't actually exist? No.

Note: This post is solely in response to all those arguing the side of widgets giving a play advantage as a reason for blocking/monitoring.