Range Widget, Alpha 2

[Ashnal]

I don't think we are really arguing the issue of cheating here, considering cheating is defined as one player having a natural advantage over another. If you have your widget display ranges standard for all players, then there is no cheating at all. We're actually arguing whether the game plays better if players know this information or not.

Argh, wouldn't games be more fun and satisfying if you win by actually out-strategizing, outmaneuvering, and countering your opponent, rather than winning by a few pixels mistake on your enemies part? I know I would rather be guessing what my opponent is building and where rather than guessing the range of stuff I already know is there.

[el_matarife]

I don't think we are really arguing the issue of cheating here, considering cheating is defined as one player having a natural advantage over another.

You mean an "unnatural" or "unfair" advantage.

If you have your widget display ranges standard for all players, then there is no cheating at all. We're actually arguing whether the game plays better if players know this information or not.

Argh, wouldn't games be more fun and satisfying if you win by actually out-strategizing, outmaneuvering, and countering your opponent, rather than winning by a few pixels mistake on your enemies part? I know I would rather be guessing what my opponent is building and where rather than guessing the range of stuff I already know is there.

You're right, if everyone uses the same widget or can use the same widget there's no unfair advantage. I think it is more than little short sighted to argue "My playerbase is uninformed about widgets / too lazy to install widgets / doesn't know how to install widgets". If that's the case, the problem is with the playerbase not the widgets themselves.

[Ashnal]

Yes I meant unfair, thanks for clarifying. And yeah, if the playerbase doesn't care enough to know about it, then they probably don't care about it being used against them if thats the case. However I still think you should consider making enemy ranges show by default in the game, for less guesswork based gameplay.

[Argh]

The fairness issue is not the only issue, although I think it's quite important.

Take Forb's request, for example. Hey, he thinks you should see enemy ranges too.

That's cool, it's his game, he thinks it'll be handy for newbies. That's a choice, and it's a proper one. He's the game designer, he thinks the feature would be beneficial. I'm 100% cool with that. I think some of y'all think I'm just some control-freak... no, I just think that the relationship between people writing Widgets and people making games is a little off. We're working at cross-purposes, and it's been very frustrating up until the point where I got the first whitelist working, frankly.

Moreover I'm not cool with the frequent assumptions I see a lot of Widget writers making:

A. Widget code runs in a vacuum.

Widgets run in games. Without the games, they have no purpose at all.

But the code is frequently not QA'd properly, and it's code that barely reaches the "good enough" level.

I've seen borked displays on various screen sizes, static fontmaps that look like shit at larger screen resolutions... UI that should have been written so they could be moved, but are entirely static.

Hey, I know that making stuff static is easier... but why haven't y'all been talking about making mobile window code, so that you're going to break less stuff? Meltrax wrote all of that swish windowing stuff... get with him, do something powerful about that issue.

I guess that my final thought on this is that y'all need to communicate more with one another, and talk more about dealing with the fundamental issues- that there's only so much space, you don't know what rez or dimensions it'll have... and that some of it is always going to be taken up by static, game-based stuff.

Your own work should, ideally, be mobile, stackable, dockable, page-based... whatever. Not how it is now... where most of it's static.

B. Widget writers often write stuff with static lists that are specific to BA (or, in some really horrible cases, to numbers within a game design, subject to change), even though that tends to make the Widgets distinctly non-portable and become broken in the long term.

Why do people write this terrible crap? It's terrible, terrible practice, and makes your code non-portable and break if games change.

Just use a separate config file, or require game designers to include customParams, if they want to be compatible. It's not like that's hard.

Or write better automation, and allow customParams to override it, for games outside the OTA box. When I see more Widget writers deliberately allowing me and other people to shut features of their code OFF, I'll know we're making some progress on this.

C. If the engine allows it, it must be OK.

My comment on this last point is that this is basically solved now. Game designers should have control over that aspect... and now we do. We can say, "no, that's not allowed to run in my game, if people are playing seriously"... and that's entirely proper, it puts the relationship back where it should be.

Up 'til now, if I told some Widget writer, "hey, your thing breaks my game", if they didn't address that, I was screwed. Most of you guys haven't done any game design work, so you probably aren't ever going to understand how worrying that is... trust me, it's not good, to know that if Player A has Widget B, then Player C is hosed, if he / she doesn't also have it, and know how to use it.

If players prefer the "anything goes" version of P.U.R.E., that's totally fine with me. Let people have that choice, by all means- if I didn't, somebody would just write a mutator anyhow.

But as a game designer, I'd like to know that I have at least one version that runs exactly as I wanted it to, that people can play competitively.



As for the rest of it... I'm actually working on packaging a small compilation of Widgets that don't break UIs, are bug-free, and do something useful (or pretty), that aren't my work (since, generally speaking, my work is designed that way by default, unless it's clearly meant to be game-side code).

Thus far, it's a depressingly short list. A lot of Spring's default Widgets are either fairly useless tech demos at this point, compared to what's available, or aren't compatible with every game.

And many useful Widgets aren't designed to play nice with UIs that aren't Spring-standard, and make a lot of stupid assumptions about where they are on the screen, etc.

For example, somebody made a Widget that shows the Tooltip for a given Unit when you mouse-over a button, right near the selection arrow, so that you know your mouse is over say, a GunTank (unit in P.U.R.E.). Handy for newbs, right?

It's borked, because it goes off the right side of the screen, if the buttons are on the right. Bad QA on the part of the writer, who should have made it adjust to relative positions. Easy thing to fix... it's just pure laziness that it wasn't.

I see a ton of that stuff, because my game's been outside the Spring UI box for nine months now... which is why I've been grumpy about it. You guys have no idea, really, and won't until you can see RC4.

At any rate... sorry for the TL:DNR, lazy people, but meh... if you wanna talk constructively about all of this, here's what I think right now. I really think if we're going to have a confab about all of this, it shouldn't be in this thread, though

[Evil4Zerggin]

Regarding point B:

Unfortunately, that's the nature of Spring right now. BA consistently makes up two-thirds of all player minutes. CA (unfortunately still not free from the scourge of IP, but that's another story) tends to make up about half of the rest. After that, BA Chickens, XTA, and NOTA tend to make up most of the rest. What does this mean to you, the aspiring widget dev?

• If your widget doesn't work with BA (and all of BA's idiosyncracies), it will not get used.
• Even if your widget is 100% hardcoded to work with BA, it has a large (in current Spring terms) potential audience.
• Even if your widget is 100% hardcoded to work with BA, you probably don't have to worry about the underlying mod changing on you.
• Even if your widget is 100% hardcoded to work with *A, you will lose less than 5% of your potential audience.

Do I wish this weren't the case? Hell yeah! And I try to use automatic unit recognization rather than static lists (I find the former more interesting to write anyhow). But the fact is there isn't a whole lot of incentive for good coding practices right now. Not to mention that it takes quite some experience to know what good coding practice is.

About customparams: I believe customparams with automatic system fallback is the best system. Requiring customparams (outside of mod-specific widgets) is probably bad news--you can't expect every mod team to keep with the every widget in existence. Hell, I can hardly keep up with my own widgets :s

As for the other points, all I'll say for now is that UI is a bitch.

I've added a few brief dev notes to the bottom of the first post of several of my widget threads.

[Gota]

Because you have to mouse-over, which requires micro-time and requires that the Unit is actually in LosState.

Anything past that is a cheat, imo. Being able to fly a Unit over enemy defenses and see their exact ranges displayed, so that you know where to put your counters... is a cheat, pure and simple. Dunno why this isn't totally obvious, tbh. I suspect it's because the hardcore players just don't tell you coders how useful having that kind of information is, frankly.

It's like the old "headshot models" in CS- it didn't make your aim any better, but it told you WHERE to aim, very clearly. Which is why replacement models were banned from most serious servers. Giving players information that the game designer decided not to give them... is cheating, there's no other way to define it. It's not "helpful", it's giving people stuff they weren't supposed to have in the first place. Weapon ranges are a very important mystery- it's almost as important, tactically, as knowing what your enemy's economic output would be strategically...

I personally have mentioned it and other player have as well if I'm not mistaken.
I remember i was told that widgets cannot be blocked and since defense range did it and was released there is nothing that can be done.
Thing is,it was unavoidable until now cause modders can make it so that certain widgets will not work in a mod.

[tombom]

I really don't see how your last post ties into the cheating aspect. Which still makes no sense at all.

[Peet]

Remove the resource bars - the player should have to check the resource output/usage of each unit and add them together himself. Giving him that info freely gives him an unfair advantage, because otherwise he has to spend valuable micro time.

[Ashnal]

Why bother showing ranges for your own units? You should have to guess that too!

[SpikedHelmet]

Now you're just being stupid and trollish.

You shouldn't have to guess your units ranges. It should print the range in numbers in the unitinfo so that you can measure it. This will also necessitate a Ruler unit to facilitate this measuring. A compass too, for that matter.

"Guessing", sheesh, how silly...

[CarRepairer]

For example, somebody made a Widget that shows the Tooltip for a given Unit when you mouse-over a button, right near the selection arrow, so that you know your mouse is over say, a GunTank (unit in P.U.R.E.). Handy for newbs, right?

It's borked, because it goes off the right side of the screen, if the buttons are on the right. Bad QA on the part of the writer, who should have made it adjust to relative positions. Easy thing to fix... it's just pure laziness that it wasn't.

I wrote that widget. It's called InlineTip-BM and it took me all of 10 minutes. Two things:

1) It was designed for CA and included only in CA. I didn't release it to this forum for use in other mods, nor did I ever intend for it to be.

2) I stopped caring about it when there grew a greater prospect within CA-dev for our nested buildmenus, created by Evil4Zerggin. This was ALSO designed for CA in mind (although he did release it on the forum, that's fine), nullifying my widget.

I'm hardly lazy, I am constantly working on different things and finding time to actually play about 2% of the time that I'm on here. I am sure you feel very bad for the harsh words and I forgive you.

[very_bad_soldier]

Its strange that you have to explain yourself for something you did for fun and released for free. Not to mention to be accused of cheating which is highly subjective.

[tombom]

Its strange that you have to explain yourself for something you did for fun and released for free. Not to mention to be accused of cheating which is highly subjective.

welcome to argh's posting

[1v0ry_k1ng]

if the widget is publicly released its not cheating, because everyone can use it thus creating the oppourtunity for an equal playing ground. if some people are too dumb, ignorant or lazy to download and employ it, that is entirely their fault.

making an epic widget and keeping it to use yourself on the otherhand, is cheating, because the other player does not have the ability to play on an equal playing field

[BaNa]

if the widget is publicly released its not cheating, because everyone can use it thus creating the oppourtunity for an equal playing ground. if some people are too dumb, ignorant or lazy to download and employ it, that is entirely their fault.

making an epic widget and keeping it to use yourself on the otherhand, is cheating, because the other player does not have the ability to play on an equal playing field

why not they could code said epic widget too no?

If widgets/ai where actually more useful then this could be like a MMORPG with the leveling up and grinding replaced by coding and super players would have custom coded unit ais that could take on other units 10 to 1 :D

[Argh]

Remove the resource bars - the player should have to check the resource output/usage of each unit and add them together himself. Giving him that info freely gives him an unfair advantage, because otherwise he has to spend valuable micro time.

LOL.

Ok... let's pretend. What if a game designer removed them for some reason, and a Widget "put them back". After all, the game designer used an element that's in Spring, and accessible to Widgets. The engine "allows" this. No problem, right? Well, no, it's a major problem- you're now cheating.

It's not hard to imagine a situation where you'd run into this. In Merc Squad, I don't show Energy, I just show Metal (and call it "money"). I just used Metal because it was convenient, since it's built into the engine already. But I don't want people seeing energy, because at the very least, it's confusing.

But I can think of several game designs where I'd want to hide that from people for other reasons. And if a Widget displayed it... well, that would be a cheat.

See my point here? Game designers working on UI are quite aware that we're not giving you every single piece of information that's potentially available. That is game design, people.

I mean... why have LOS, when we could just see everybody's units? Wouldn't that be "better"? Hmm. Might be cheating.

Why not be able to see the economy of every player? Hmm.

Why not be able to see what your enemies are building right now? Hmm.

Why not be able to see cloaked units? Hmm.

Game designers deliberately hide information... because it enhances gameplay. It's just part of a game design, folks.

if the widget is publicly released its not cheating, because everyone can use it thus creating the oppourtunity for an equal playing ground. if some people are too dumb, ignorant or lazy to download and employ it, that is entirely their fault.

That's a silly argument.

"Publicly released" does not mean everybody has it. "Publicly released" does not mean everybody knows it exists.

Just sounds like an excuse for cheaters, to me- "oh, yeah, that thing I use to auto-micro my Zippers with... it's on website http://www.cheatersRus.com... it's publicly released, u could have had it 2... so stfu nub, you got pwnd by mah mad Widgets, bitch".

Like a guy using something like that would even tell people he was using it. No, IRL, he'd just say nothing. Anybody who's played serious games competitively knows what I'm talking about- the guys with aimbots aren't about to tell you that, they know they'll get banned.

So... meh, that's a silly argument. We know that most players cannot even be arsed to read the Wiki here... yeah, right, they're going to regularly review what Widgets are available, and stay "informed"!

And yeah, right, we should let "who can find / write the best Widgets" become a part of Spring's gameplay.

Its strange that you have to explain yourself for something you did for fun and released for free. Not to mention to be accused of cheating which is highly subjective.

Cheating is not subjective. It has an objective definition. It's not complicated, either.

Cheating, in a video game, is defined as "a player of a video game creating an advantage beyond the bounds of normal gameplay, usually to make the game easier".

This is not "glitching", btw- that's taking advantage of a bug in the game design, and while that's lame, imo, it's not cheating.

Only game designers are allowed to decide who gets what, who sees what, who can affect whom. If third-party tools cross that line, they're cheats. It's not complicated, and there aren't any gray areas.

If I make a game where one side's units are blind, and you make a Widget that allows them to see... that's a cheat. Pretty simple, right?

However, most cheats are more subtle than that, like the headshot models that people used to put in CS. They don't technically improve your skill... they "merely" make it easier to do target recognition, which eats up precious tenths of a second. Pretty big advantage in a FPS with serious competitive play, where a tenth of a second may be the difference between missing that guy's head and pulling a header... which is why it's a cheat.

There isn't any difference between stuff that automatically shows you things in a RTS that you cannot possibly have through the game... and a headshot model in a FPS- and they're both cheating.



The reason why people try to be wibbly and wobbly is that Spring's default UI is so underwhelming... that the urge to improve it has led people to a bunch of improvements that are cheating, technically, but are big improvements.

I'm entirely OK with that, actually. I understand the urge to fix things that aren't perfect.

However... there isn't any gray area about stuff like Defense Ranges. It's a cheater's tool, if it's not included with the game. I think that BA and CA both include it... so it's not a cheat in those games, btw.

Spring, by default, makes you micro to see defense ranges, so if a game has left that default in place, and you're using that Widget, you're cheating. It's not very complicated.

So... quit pretending there's a gray area here... there really isn't. The question is, what do we do about it? Well, here are the choices:

1. Game designers make a "pure" version of their game using a mutator, with NoCheat, and you just can't use the Widgets. There ya go, problem solved.

2. Game designers label the "unpure" version so that players know that people can and will be using stuff that isn't approved by the game designer.

There ya go- and at that point... it's totally fair to everybody. If players prefer playing "unpure" games, maybe that's a sign that there's something in the Widget world that is actually making the game more fun.

That's just fine, and should be a normal part of things. If Widgets really do improve gameplay (which they certainly can) then that's great, people can then include them in "pure" games.

But this can't just continue onwards forever, without any changes, which is why I wrote WhiteList and cobbled together NoCheat. The end was coming sooner or later, guys- as people's coding skills have improved and the engine improved, it was inevitable.

In the FPS world, who plays on servers that openly say that hacks are allowed? In RTS games like WC3, where Lua Widget-like behavior is implemented, who lets you use third-party cheats?

Only in Spring, and only until this week, did we have a situation where ALL games were played with cheats allowed. And now we don't have to. Whether or not anybody else on the game-design end decides that this is a model worth implementing is irrelevant to me, the capability is here. It's as simple as that, really.

If this is mainly worrying about BA, since most Widgets are written for it... take it up with NOiZE, it's not like implementing a "pure" game is arbitrary, and I have no intention of making a mutator or whatever, that's NOiZE's prerogative. NOiZE has traditionally balanced the game for competition play, so frankly I wouldn't be surprised if he was interested in this.

[Evil4Zerggin]

The reason why people try to be wibbly and wobbly is that Spring's default UI is so underwhelming...

Or maybe because nobody, mod developer or otherwise, is complaining half as loudly as you are? I can understand why you don't want certain widgets in your game, and I fully support giving mod developers the ability to restrict widget use in their mods. But...

However... there isn't any gray area about stuff like Defense Ranges. It's a cheater's tool, if it's not included with the game.

If this were true, every mod, present or future, without exception, would lock LuaUI now (since by your reckoning any widget not in the mod isn't meant to be there). Not including a widget in a mod, in and of itself, doesn't necessarily mean the mod developer didn't want it in the game, any more than not locking LuaUI, in and of itself, means that the mod developer wants everything to be fair game. Only an explicit statement from the mod developer, or locking LuaUI as can be done now, can determine that. Just because there hasn't been the capability to lock LuaUI until recently doesn't mean that all mod developers were waiting to take advantage of it; maybe some of them liked it that way for their mod even if you didn't. Absence of evidence is not evidence of absence and all that.

As such, there most certainly is a grey area, which we can now fortunately make smaller with locking LuaUI. I think the problem here is that you have insulted nearly the entire Spring community by saying the following:

• If you make a widget and make it available publicly, your work is a cheat.
• If you use /Spring/LuaUI, you are a cheater.

These are very serious accusations, they apply to nearly the entire community, and you made them without communicating absolutely firm ground to stand on. Is it any wonder why people are in a row over this?

[Argh]

Or maybe because nobody, mod developer or otherwise, is complaining half as loudly as you are?

I'm not complaining. I actually did something about the problem. And hell... I'm damn-near always the Lightning Rod of Controversy anyhow, so it's not like this is new or something.

The rest of this is just explaining my POV- my goal is to educate people about the issues, and also to reassure people that I am not being arbitrary about this stuff. I didn't see much point in bothering before, considering how badly people behave when people merely ask for help around here.

So... I offered NoCheat in a format that's easy to install and use via a Mutator, so that it's not an integration hassle... and provided WhiteList PD, for situations where the game designer just wants some minor control. It's not a either / or.

If this were true, every mod, present or future, without exception, would lock LuaUI

Meh... I'm sure everybody will choose whatever they like... now that they have that choice.

Other than CA, nobody had a locked LuaUI working before this week (so far as I know), and CA guys wouldn't tell anybody how to do it, despite being asked.

So... you're basically just arguing about decisions that haven't even been made yet. I would not be at all surprised if every major game designer is at least thinking it over, though.

If I were you, I'd worry about writing Widgets that were good code and did something useful. It's not your problem, if game designers are too stupid to recognize that your work could really improve their games.

Not including a widget in a mod, in and of itself, doesn't necessarily mean the mod developer didn't want it in the game

That's a piece of circular logic. What are you guys, mind readers?

Seriously... if a mod / game designer likes a Widget, they can include it in a future release of a "pure" game, and until then, it can be available to "unpure" versions.

[Evil4Zerggin]

Not including a widget in a mod, in and of itself, doesn't necessarily mean the mod developer didn't want it in the game

That's a piece of circular logic. What are you guys, mind readers?

Seriously... if a mod / game designer likes a Widget, they can include it in a future release of a "pure" game, and until then, it can be available to "unpure" versions.

I didn't say that it shows that the mod developer does want it in the game. I just said it doesn't show that they didn't. What are you, a mind reader? ;)

I don't disagree with any of what you just said. My point was simply the following:

• NOT to say that mod developers should lock LuaUI or that they shouldn't lock LuaUI.
• You couldn't tell their intentions regarding whether their game should be played with user widgets or not.
• Given this, it is not fair (or wise for that matter) to accuse everyone who uses user widgets to be a cheater.

[bwansy]

Not including a widget in a mod, in and of itself, doesn't necessarily mean the mod developer didn't want it in the game

That's a piece of circular logic. What are you guys, mind readers?

Then are you a mind-reader? Are you saying that you know the devs don't include those widgets because they don't want people to use them? Hell, if a widget is free for anyone to install, then it is not unfair, therefore, not cheating. In contrast, people who write private widgets that let them see the whole map are the real cheaters. Simple as that. Now go back to your own little universe where you are the infallible supreme overlord.