What do those do? I searched both the forums and the wiki. I didn't find any references to them except in this thread. Is there some documentation available, or does one need to dig around in the source code to find stuff like this?jK wrote:He refers to CMD_TIMEWAIT, CMD_DEATHWAIT, CMD_SQUADWAIT and CMD_GATHERWAIT.
You have to bind them yourself in uikeys.txt
widget: CustomFormations v2.2 (17 Jan 08) *PLEASE UPGRADE*
Moderator: Moderators
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
I'm not, but the thing is that I don't want my abilities to be crippled where my mod is concerned by people who cry "Wolf!" any time they see something that worries them.DemO wrote:Why do you need to be so narrow minded? We're not talking just about your mod.
Once again, you could simply disable user side widgets but it would be a damn shame to see that happen.
However this discussion is going in circles so I'm going to go ahead and bow out of it. You have 3 options:
1. Leave things as they are.
2. Disable user side widgets.
3. Incorporate certain widgets/gadgets into the engine (And this probably won't happen)
So therefore I am not seeing a solution to this argument.
What spring is about? I thought spring was an engine that's about letting mod makers create stuff. The mod maker decides what his mod, or as it might be more appropriately called in certain cases, game, is about.KDR_11k wrote:Spring is about strategy. Anything that involves no conscious decisions shouldn't be gamebreaking if automated. Something like this could be done tediously by hand but that tedium is annoying. If any step there involves thought the widget won't perform optimally anyway (e.g. a widget that attempts to play the game for you would fail easily because it'dprobably not be a good AI).
Imagine someone wrote a "widget" for Starcraft that would remove the 12 unit selection limit. Sure that'd be an advantage to him but isn't it only removing an inefficiency in the game's interface rather than doing anything about the game design itself? Should an alteration like that really be able to break a game? Is your game design based on the idea that the player cannot effectively communicate his plans to the game?
Zpock: Futile. Someone could just compile his own version of Spring that ignores the tag while still looking like the official version to the server.
People can make hacked exes (or lets call it, if you prefer, alternative spring versions). So what? They could probably make map hacking cheats and stuff too. And there's a big difference between having 50% using legit LUA widgets to get advantages and potentially break some mods, and 1% using a separate version to outright cheat. As long as your playing with known players the latter isn't a problem. Not to mention someone with the knowhow to make the cheater version and intent to do it has to actually make it in the first place.
I don't see what the problem is with letting the mod decide if LUA widgets is ok or not, most mods would probably allow them. And if some modder (content creator) disables it it's probably for a good reason.
-
TechnoTone
- Posts: 165
- Joined: 23 Aug 2005, 22:02
http://spring.clan-sy.com/phpbb/viewtop ... 838#140838RogerN wrote:What do those do? I searched both the forums and the wiki. I didn't find any references to them except in this thread. Is there some documentation available, or does one need to dig around in the source code to find stuff like this?jK wrote:He refers to CMD_TIMEWAIT, CMD_DEATHWAIT, CMD_SQUADWAIT and CMD_GATHERWAIT.
You have to bind them yourself in uikeys.txt
THAT IS THE POINT!Forboding Angel wrote:How about in my mod you let me control how easy is is for the player to accomplish something, mmmk?
We want the modder to control things like this. If you want this encircling thing or the theoretical auto-building mexxes or whatever in your mod, no one is complaining about that! We're saying it's a bad idea for it to be purely user based--Zsinj's flamethrower example is a good one.
Widgets should be simple things to re-arrange or otherwise modify the GUI at most. Basically, skinning as in things media player applications. If that means interfacing with a mod gadget to enable/disable a function such as this one, that's fine.
Anything more gives us modders (yourself included!) a headache since we have to assume users are dicks and will use any advantage they have. Balance flaws are bad enough for that, adding things like this to cut down the necessary time to order units around is even worse if it's not a gadget built into the mod. Then the playing field is even, although player skill likely isn't.
It's true that a widget like this won't make a crappy player a god. But if you take two equal players who both know the importance of micro in any given situation, and give only one of them this kind of enhancement, it's pretty certain who's going to come out on top. The guy with the widget doesn't have to interface with the game as much, leaving him time to concentrate on other larger things instead of ordering each unit one by one, which isn't fair because it's an advantage only he has. Naturally there are still occurances where he'll lose, but it'll still benefit him more than hurt him. But if both players have the same tools available to them, the playing field is even again.
I'm not against improving the interface with the game. I'm not against removing needless micro (for example, ordering a group of units into a line/circle/whatever is needless; focusing on one or two single raiding units to keep them alive longer to do more damage is not). I'm simply against giving unfair advantages to players simply because they spent more free time browsing forums/UF, and I'm against what this unfair advantage implies for mod balancing. These things need to be available to all players, which means building them into/packaging them with the engine, or packaging them into a mod.
Yeah, I can simply include this widget in my mod, but what about the next widget which incites this debate? And the next? Am I expected to release a new version of my mod with these new gameplay enhancing widgets along with any necessary balance changes every time they come out to ensure players have a fair playing field? This is what we call "ass backwards."
There's a slight problem: we've crossed the point of no return. The sources are out there and Lua stuff is pretty self-contained, so it'd be easy if not trivial to reintroduce any functionality that would be removed in a future version.
Modders simply (yeah, I know) need to design mods with widgets in mind. UI simply isn't a limiting factor anymore and there's no going back - not because the devs don't want to, but because it's not possible.
PS+BTW: IMHO this widget is a new quality in the whole RTS genre. Idea behind this is so simple that after you get used to it (which takes 30 secs, as was mentioned), games without this feature are FAIL.
Modders simply (yeah, I know) need to design mods with widgets in mind. UI simply isn't a limiting factor anymore and there's no going back - not because the devs don't want to, but because it's not possible.
PS+BTW: IMHO this widget is a new quality in the whole RTS genre. Idea behind this is so simple that after you get used to it (which takes 30 secs, as was mentioned), games without this feature are FAIL.
Great points by demo above. I think this widget should be implemented in the engine, actually, as imbaczek says, it introduces new quality into the RTS game (not too much unlike shift queuing and some of the other things OTA introduced). I also worry that I will be at a disadvantage, as the widget does not work with my current setup. Someone please fix! 
Personally, I think that this is wonderful, and does nothing that I don't expect players to do less efficiently with micro right now.
However, I'd have to vote that we need an "anti-widget" so that if a particular game design will really, really, really not work if Widget X is introduced, then it will not be allowed to run.
Right now, game designers could build this anti-widget, by just including a do-nothing copy of the Widget in their games, with the same starting Function name.
However, that isn't allowed to work, because Trepan made precedence in favor of the players, instead of in favor of the game designers. So, if players download a seperate copy of Widget X and know where to put it, then they can override the game's copy, defeating this form of "protection". And, of course, there aren't any ways to stop people from just re-naming a couple of files and escaping from even that very crude level of self-protection.
I think that this creates a lot more problems than was probably anticipated. However... tbh, I don't think that I've seen a Widget yet that even slightly scares me. Stuff like this, that makes micro tasks less cumbersome, are welcome additions to me, and I think that a truly robust game design will not fall apart if things like this get better, frankly, nor do I think that they steer us towards a single game design by default.
However, I'd have to vote that we need an "anti-widget" so that if a particular game design will really, really, really not work if Widget X is introduced, then it will not be allowed to run.
Right now, game designers could build this anti-widget, by just including a do-nothing copy of the Widget in their games, with the same starting Function name.
However, that isn't allowed to work, because Trepan made precedence in favor of the players, instead of in favor of the game designers. So, if players download a seperate copy of Widget X and know where to put it, then they can override the game's copy, defeating this form of "protection". And, of course, there aren't any ways to stop people from just re-naming a couple of files and escaping from even that very crude level of self-protection.
I think that this creates a lot more problems than was probably anticipated. However... tbh, I don't think that I've seen a Widget yet that even slightly scares me. Stuff like this, that makes micro tasks less cumbersome, are welcome additions to me, and I think that a truly robust game design will not fall apart if things like this get better, frankly, nor do I think that they steer us towards a single game design by default.
-
BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
Okay further testing shows the same behavior in both linux and windows dual screen mode (I test on my laptop). So this isn't a linux bug but something to do with dual screens. Has anyone who uses dual screens gotten this widget to work, and if so, can you give details on what's in your luaUI folder?
I also try turning off all other widgets and reloading luaUI and still the issue in dual screen mode.
Edit: To summarize my bug here is the following:
*The version posted on UF works fine in single screen mode, but in dual screen mode right mouse actions are completely suppressed when more than one unit is selected (you can't even click the default move action).
*jK also sent me another version with additional changes (here). This version also works in single screen mode, but has a different problem in dual screen mode. With this version, you get the default behaviour of right click drag.
Adding mx = mx + 1280 after Spring.GetMouseState didn't help.
I also try turning off all other widgets and reloading luaUI and still the issue in dual screen mode.
Edit: To summarize my bug here is the following:
*The version posted on UF works fine in single screen mode, but in dual screen mode right mouse actions are completely suppressed when more than one unit is selected (you can't even click the default move action).
*jK also sent me another version with additional changes (here). This version also works in single screen mode, but has a different problem in dual screen mode. With this version, you get the default behaviour of right click drag.
Adding mx = mx + 1280 after Spring.GetMouseState didn't help.
Dualscreen:
It is/was a spring engine issue. I wrote a .patch to fix it and 1 other bug (mantis).
Btw, it only occurs if the map is on the left side.
Linux users should be able to patch their binaries (the patched code should be unsynced) and windows users have to w8.
It is/was a spring engine issue. I wrote a .patch to fix it and 1 other bug (mantis).
Btw, it only occurs if the map is on the left side.
Linux users should be able to patch their binaries (the patched code should be unsynced) and windows users have to w8.
