Spring RTS Engine

I think a widget "trader" would be a very useful tool, sooner or later. Would do a good job of leveling the playing ground I think. I'm not in a hurry for it though, and I guess I might even try to put one together when I do find it necessary...

aegis wrote:

CarRepairer wrote:they'd have to do it over again.

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

But it has to be run using the game ID as part of the encryption code...

CarRepairer wrote:

aegis wrote:

CarRepairer wrote:they'd have to do it over again.

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

But it has to be run using the game ID as part of the encryption code...

Which you can get out of the altered spring...

Argh wrote: For example... let's say I want to build a really accurate historical simulation of the Vietnam war. Obviously, it's a big deal, if it's literally hard for me, as the commander in my simulated helicopter command post, to see the enemy, just like it was IRL.

First - Caydr, show some respect. Kloot's one of the primary engine devs, and has a vastly better technical "clue" than anyone else in this thread. Not to play the "you made a basic mistake so you're disqualified from talking" game, but gadgets = SYNCED code which is included in the game or mod which controls gameplay. For example, S44 has a gadget which controls ammo for tanks. Widgets = UNSYNCED code which can be included in a game or mod, but more often are installed by the user in the main LuaUI folder - they obviously can't set the ammo level of units in S44, but they can issue orders and do various graphical/interface things.

Argh: To my mind, if you want something to be invisible to the enemy player, you make sure its invisible to everyone, not just people with monitors of a specific brightness/contrast level/whatever. So make those units cloak in foliage - make them FUNCTIONALLY invisible, not just obscured by interface. Like...it would kind of screw stuff up when your camo'd units got auto-targeted, eh?

The only way to make sure that all players are seeing the same exact thing on their screen during gameplay is to keep the screen pitch black at all times. Some players have 40" screens with 1ms response times which would render any kind of camouflage WAY less effective than someone playing on a junky old CRT with the brightness turned down. Widgets are basically extensions of that interface difference, except rather than only being available to people with lots of cash, anyone can grab them.

Some widgets undoubtedly make the game easier to play; custom formations is utterly brilliant, and saves many clicks. Defense ranges is certainly handy (although it does nothing that a player can't do themselves by holding shift on an enemy unit). I don't think these represent anything which can ruin a game. If a player loses a few times -specifically because- of a widget disadvantage, they'll either learn how to game that automated advantage (if its an AI-type widget) or they'll get the widget themselves (if its an interface advantage) in which case everybody wins because the focus of the interaction between those two players returns to the decision making and gameplay style of the players, rather than their relative proficiency with the interface.

I think that widgets create a minimum-complexity bar for designers who want people to play their games, which is fine by me. If you create a game so simple that an automated process can win against a skilled player (and did not intentionally do so), you need to think hard about your game and work out whether you'd be better off designing screensavers, rather than games.

To expand on that: if someone codes a widget which has such a perfect sequence of commands that it renders itself untouchable, perhaps your game lacks depth somewhere along the line. The kindly widget writer has just happened to point out to you that your problem (game) has an optimal solution simple enough that it can be performed by the current state of AI, DESPITE all of the variables* complicating the situation for that AI (HELPING you reach the minimum complexity point at which widget-AIs aren't all that effectuve).

Most likely, this is because your problem (game) relies too heavily on players playing against the game, rather than players playing against players.

The final scenario I view as vaguely plausible for serious widget-based advantages consist of player-assisted AI, or AI-assisted player, I guess. If you have a widget which can optimally perform some small part of the game (say, managing focus-firing - a candidate for a pretty wicked widget, I'd say), you can potentially end up with a player who has a distinct advantage over another by virtue of their vastly increased supplies of attention.

Here, the designer has a choice to make. If that part of the gameplay represents a fundamental mechanic by which players interact, then

• 1) its already too complex for widgets to successfully automate
• 2) it probably needs more depth to prevent successful automation and keep it a really interesting mechanic for players.

or if that part of the gameplay is NOT fundamental, then the designer can say "hey, thanks widget-coder, now players can focus more on the REALLY fun part." At this point, that AI-ish widget has become an interface widget.

That said, I'd have to think hard to avoid being miffed if someone created a really effective focus-fire widget for S44, since it could probably give a huge advantage in the infantry game. It would force me to rethink things a bit, and decide whether the behavior created by the widget could be turned against the using-player (in which case, no problem, it just evolves the balance a bit), or if it negatively impacted a core part of the game. If I felt that it really messed up something critical without presenting a weakpoint for the using player, I'd have to work on that part of the design to have a bit more depth, or create those weakpoints for players making use of automation.


TL;DR
Basically, my broader point is that widgets end up either improving the interface for players, or forcing the designer to think harder about his or her game. I don't see either of those as bad.

*The variables inherent in the choice of map alone are immense. Add in player behavior, unit handling (if your game includes it) and unit makeups (if your game allows more than one unit makeup/has viable counters as part of the design), and there's very little chance of a successful widget-ification outplaying a savvy human player over the course of many games.

lurker wrote:

CarRepairer wrote:

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

But it has to be run using the game ID as part of the encryption code...

Which you can get out of the altered spring...

But the validator program uses the game ID as well as checking "unknown parameters" of the spring.exe in its folder. So running it with the altered spring gives a "I am not legit" while running it with unaltered spring gives a "I am legit." Also, if someone tries to join a game using both (while suppressing the communication of the validator in the altered spring folder), could the host detect that you have a smurf or tried to make two connections to the same game? This is also a requirement.

Repeated disclaimer: I am a newb who knows nothing. There are still people in this thread who talk like they know more than spring devs and I don't claim this for myself. I'm only asking these questions out of my own curiosity.

1. connect to game using hacked client
2. inject game id or unique string to validator
3. run validator on normal spring install
4. intercept "I am valid" message and send it wherever it needs to go

aegis wrote:1. connect to game using hacked client
2. inject game id or unique string to validator
3. run validator on normal spring install
4. intercept "I am valid" message and send it wherever it needs to go

You have hacked my system. You win a sad cookie

Its really no problem to force self-validation thing to read different binary from the one that is actually being run. Even if it is somehow reading code as it is in RAM.

SeanHeron wrote:I think a widget "trader" would be a very useful tool, sooner or later. Would do a good job of leveling the playing ground I think.

A widget trader like Argh is suggesting?
Personally I dont want to get "flooded" with every widget the players have in the game I join. I dont think this is a good idea.
Besides that, most widgets require knowledge of their existence or even knowledge on how to use them. Just copying every widget out there to the player's HDD does not solve the problem IMO.

very_bad_soldier wrote:

SeanHeron wrote:I think a widget "trader" would be a very useful tool, sooner or later. Would do a good job of leveling the playing ground I think.

A widget trader like Argh is suggesting?
Personally I dont want to get "flooded" with every widget the players have in the game I join. I dont think this is a good idea.
Besides that, most widgets require knowledge of their existence or even knowledge on how to use them. Just copying every widget out there to the player's HDD does not solve the problem IMO.

"Oh hey my ally is using unit_micro_advantage.lua ill just download it off them and turn it on.. oh no its a joke widget that self-d's everything if the owner isnt named TheFatController!"

widget exchange is also a potential security risk. use wisely.

Ah, the saga of PYB continues...

Yes, I meant a widget "trader" similiar to Argh's description.

I wouldn't make the widgets activatable immediately - I wouldn't even put them in the widgets folder for that matter, and you can encourage people to look at them before using, so I think the security risk can be minimised (and practically made zero for people paying attention).

And of course it doesn't need to be default to grab them from the other players - and if it was it could definitely be switched on and off.

What I'd see as two real potential difficulties is:
- one that people obfuscate their code to make it difficult for people to use/ check for security issues (wouldn't think this is to great a problem though)
- the other is that if you copy every instance of every widget from every game, it's probably going to be too many files to be useful. But checking for which widgets are the same is probably difficult to do in a way that can't be evaded (same name certainly doesn't work, hash comparison cI don't see any serious concerns with the concept yet - except perhaps the problem can be gimped, maybe just actually parse the whole thing and see if it matches one to one ?)

Nice to see some people interested, anyway :D !

From now on I'll most definitely be playing with "Ghost Radar". It allows you to see what any unit is that you've seen before. I'm disgusted, this is an intolerable situation.

It took me all of 5 minutes to find this widget. How can you people claim with a straight face that there's no problem so there's no reason to worry? I can tell exactly which radar dot is a commander from across the map. Are you touched in the head? Being able to tell what a unit is without seeing it is the definition of a cheat!

This just ruins it for me. What is the point. Why spend hours of my life making a game so that it can be raped by LUA while you're all relaxing sipping tea insisting there's no problem?

Caydr wrote:From now on I'll most definitely be playing with "Ghost Radar". It allows you to see what any unit is that you've seen before. I'm disgusted, this is an intolerable situation.

It took me all of 5 minutes to find this widget. How can you people claim with a straight face that there's no problem so there's no reason to worry? I can tell exactly which radar dot is a commander from across the map. Are you touched in the head? Being able to tell what a unit is without seeing it is the definition of a cheat!

This just ruins it for me. What is the point. Why spend hours of my life making a game so that it can be raped by LUA while you're all relaxing sipping tea insisting there's no problem?

The engine devs fixed it so ghost radar no longer works, like 6 months ago. Where did you take that screenshot?

Got the screenshot a few minutes ago... what do you mean "where"?

Was playing Spring, most recent version, with BA, also most recent version. Am I missing something obvious, like the engine completely changes how it handles LUA if you're playing single player just to confuse me?

Never mind, I just looked it up. I was thinking of a different widget that purposely took advantage of a bug in spring (can't remember the name). Ghost radar just shows the unit if it's already been in your line of sight and then back into radar coverage. In other words, it doesn't tell you any new information or cheat in any way. So calm yourself.

Calm myself?
.
.
.
Right, I'm calm now. I can see where my enemy's commander is from across the map by simply building a 50m radar tower. Life is peachy.

....

I'm posting in a forum for a multiplayer-centric engine whose developers think that being able to see your enemy's units without LoS is fair game. Perfectly calm.
.
.
.
Don't panic, Caydr. LUA can't be used to cheat. Don't be so paranoid. It'll only do things that a player can do, using information a player has access to. Like a unit's unique ID which can be used to detect exactly what sort of unit a blip belongs to. Thereby providing you with LoS across the map by building a radar tower. It's harmless.

...

...

I think I'm going to have a stroke.

very_bad_soldier wrote:Once you had line of sight to an enemy unit you see the unit ghosted near the radar dot.

(emphasis added)

And before we continue I will mention that being that this is a widget, the widget has no information about where the unit actually is due to radar wobble.

Try to follow me. I attack the enemy at some point in the early game with, let's say, 3 weasels. I see his Commander once. Now I porc to hell and build L2 bombers and a single radar tower. Game over.

Possible solutions:
- Don't play on comm-ends (eliminating an entire game mode which happens to be my preference), meaning you now have a nuke in your base which *fortunately* won't end the game immediately, it will merely cripple you.
- Use radar jammers, which can be defeated with a single shot from a Juno.
- Hide behind a rock, permanently making Commanders nothing more than a liability in any game mode.
- Don't use a special icon for Commanders

It occurs to me that if a widget is able to remember a unit ID and assign that to a radar blip, it can just as easily remember exactly what sort of unit that is, which means that using a special icon for Commanders is only going to last until someone modifies the widget.

So I need to redesign my game now, to counter a widget. Just one widget.