Posted: 05 Dec 2006, 13:58
Hmm if it's between 0.60 and 0.73... that could easily be thousands of revisions...
Spring RTS Engine
Open Source Realtime Strategy Game Engine
https://springrts.licho.eu/phpbb/
About the FPS bug
Page 2 of 2
Posted: 05 Dec 2006, 16:01
Well, yeah..... that's why I proposed not wasting any time checking out old revisions :)
Posted: 05 Dec 2006, 18:39
The original fix must have been put in SVN before 5/18/06 when Fizwizz reports is as fixed in Mantis #105. There were complaints about it up until 3/27/06 which means that it was probably broken in .70 betas 1-3. My guess is the fix was released in .71b1 since the changelog says "Fixed several FPS exploits" since that fits the timeline. The reversion must have snuck in this version.
Posted: 05 Dec 2006, 20:43
Problem is, this is not an exploit. There is no way that you can exploit this directly, just hope that your opponent runs into the bug when you can get him. (Yes, yes, it would be possible to position yourself to the northwest of your enemy, but any GOOD enemy would probably compensate. And in any case, I still wouldn't call this an "exploit".)
Posted: 06 Dec 2006, 00:31
"Fixed several FPS exploits" referred to the unintentional range bonus and better weapon manouvreability in FPS mode, I remember that. Very well possible that reintroduced it, will take a look sometime once I have time..
Posted: 06 Dec 2006, 00:42
Thanks :D
Posted: 06 Dec 2006, 22:22
I was suggesting that it was fixed in .71 but got broken after the .73 release. The "Fixed several FPS exploits" entry just indicated work got done around then, possibly making it when someone (I have no idea who) fixed that bug, or it may have even been a "collateral damage" fix, where fixing some other bug fixed it too. I suggest looking at SVN revisions between .70b3 and .71b1 for the original fix, so we can figure out what .74 code reverted the bug.
Posted: 07 Dec 2006, 20:45
Fixed.
Was caused by some lame copy paste coding and only fixing the non-FPS-mode version of it afterwards...
Was caused by some lame copy paste coding and only fixing the non-FPS-mode version of it afterwards...
Posted: 07 Dec 2006, 20:51
Alright, thanks man. So when's the patch release?
Posted: 07 Dec 2006, 21:05
When its ready. 
Posted: 07 Dec 2006, 21:46
=(
Posted: 07 Dec 2006, 22:48
Yay! :D Three cheers for the devs! Here, have a bunny. HAH! Didn't expect that one did you?!?Tobi wrote:Fixed.
Was caused by some lame copy paste coding and only fixing the non-FPS-mode version of it afterwards...
Posted: 14 Dec 2006, 00:05
YAY :D. Thanks so much :). Most problems in code normally come from things like mass editing
edit:
Okay I know this is asking a bit much, just consider it as more of suggestions:
IMO, they should start developing the fps mode a bit more. Like adding another .tdf file in the gamedata folder called "fpsmode.tdf" or something. In it it could have a bunch of tags like (of course all mod-specific):
- Turn off auto-aim completely (as in, it doesn't avoid or lock on to anything)
- Make it reselect your unit when you're in fps mode
- Force fps mode or disable it completely
- Disable free-fire mode
- etc.
Or maybe even unit-specific like no fps mode on certain units, etc.
What would also be nice was if they added a tag that acted like the on/off feature (in terms of scripting), but had more settings. As in, unless it was programmed to do something it wouldn't do anything. The only reason for this would be so that units can have more than two weapons, while only having one active at a time. You can do it with the on/off feature (while get activation sleep 1000, etc.), just that's limited to two weapons or weapon sets. More would be nice :). They could probably do this by making an fbi tag like "weaponsets=x" where x is the ammount of different weapons or weapon sets that the unit has. In-game this could be shown with a button that just showed like "Weap x", etc. In the cob file it could be used like "while currentweapon==x sleep 1000". Like I said, all this will do is let modders add more than two weapon sets per unit.
edit:
Okay I know this is asking a bit much, just consider it as more of suggestions:
IMO, they should start developing the fps mode a bit more. Like adding another .tdf file in the gamedata folder called "fpsmode.tdf" or something. In it it could have a bunch of tags like (of course all mod-specific):
- Turn off auto-aim completely (as in, it doesn't avoid or lock on to anything)
- Make it reselect your unit when you're in fps mode
- Force fps mode or disable it completely
- Disable free-fire mode
- etc.
Or maybe even unit-specific like no fps mode on certain units, etc.
What would also be nice was if they added a tag that acted like the on/off feature (in terms of scripting), but had more settings. As in, unless it was programmed to do something it wouldn't do anything. The only reason for this would be so that units can have more than two weapons, while only having one active at a time. You can do it with the on/off feature (while get activation sleep 1000, etc.), just that's limited to two weapons or weapon sets. More would be nice :). They could probably do this by making an fbi tag like "weaponsets=x" where x is the ammount of different weapons or weapon sets that the unit has. In-game this could be shown with a button that just showed like "Weap x", etc. In the cob file it could be used like "while currentweapon==x sleep 1000". Like I said, all this will do is let modders add more than two weapon sets per unit.
Posted: 14 Dec 2006, 13:10
Judging from the tone of the developers, they are a bit pissed. Actually, it seems that pissed is not a powerfull-enough word anymore. They are actually closing in on a level thats formerly only occupied by Microsoft coders. And thats serious.
We just have to accept the fact that when a project grows bigger and more complicated, it also means that there will be more bugs. Spring was not originally designed to be a engine like it is today. If you take a look at the first releases you can see what i mean. It has grown and grown to the point it is now.
This is one reason why they started the OSRTS project. To get a fresh start thats from the beginning planned modern and to do what spring has unsuccesfully tried to evolve into for some time now, a RTS engine.
We just have to accept the fact that when a project grows bigger and more complicated, it also means that there will be more bugs. Spring was not originally designed to be a engine like it is today. If you take a look at the first releases you can see what i mean. It has grown and grown to the point it is now.
This is one reason why they started the OSRTS project. To get a fresh start thats from the beginning planned modern and to do what spring has unsuccesfully tried to evolve into for some time now, a RTS engine.