Big Bug thread for 0.82.2/3 - Report bugs here
Moderator: Moderators
Re: Big Bug thread for 0.82.2/3 - Report bugs here
why jpeg?
png is the right thing for that (accuracy, detail). that is why we have png as default format for spring screen-shots.
png is the right thing for that (accuracy, detail). that is why we have png as default format for spring screen-shots.
Re: Big Bug thread for 0.82.2/3 - Report bugs here
Because it took me 1 minute and 24 seconds to load all the images.hoijui wrote:why jpeg?
png is the right thing for that (accuracy, detail). that is why we have png as default format for spring screen-shots.
Last edited by Jazcash on 20 Aug 2010, 23:28, edited 1 time in total.
Re: Big Bug thread for 0.82.2/3 - Report bugs here
Units using spheres rather than custom vols should just read the radius defined in the s3o, if someone broke that they are a tremendous idiot.
Re: Big Bug thread for 0.82.2/3 - Report bugs here
didn't think to check s3o's. They seem to be the same. So I guess it's just 3do.
Re: Big Bug thread for 0.82.2/3 - Report bugs here
I didn't consider 3dos (as its a silly outdated format noone has any reason to use )Thor wrote:didn't think to check s3o's. They seem to be the same. So I guess it's just 3do.
Guess something did change then; seems silly to change that behaviour after such a long time. Maybe it was part of the refactor of model loading.
Re: Big Bug thread for 0.82.2/3 - Report bugs here
Another quite common bug since update - People respawn in a random place when game starts even though they clicked somewhere else
Example:
http://replays.adune.nl/?2709
Example:
http://replays.adune.nl/?2709
Re: Big Bug thread for 0.82.2/3 - Report bugs here
Another bug which isn't on your list is the fact that all replays are desynced, watching replays is pretty much broken so its quite serious
whole replay site is evidence
only happens since this update
whole replay site is evidence
only happens since this update
Re: Big Bug thread for 0.82.2/3 - Report bugs here
2 most likely ATI related bugs with graphics settings (using Radeon 4870 with Catalyst 10.7 Beta OpenGL ES 2.0 drivers):
-atioglxx.dll driver crash if you have dynamic clouds and high-res clouds activated AT THE SAME TIME (works fine if you have only one of the two settings activated, enabling both worked fine in last Spring version)
-if using bump-mapped water, using shorewaves ONLY works (fine, as in previous Spring version) on maps WITH water, but will cause the driver crash for maps WITHOUT water
Confirming most of the other bugs for me, especially pathfinding, replay desync, bright factories in idle builders widget, unit highlighting widgets turning great parts of the screen green and invisible bomber projectiles.
One more POSSIBLE thing (which i will have to test a bit to confirm or deny though): In several BA games i THINK i have noticed nano turrets (on roam) sometimes not properly executing the patrol command properly (like in previous Spring versions) and getting kinda freezed instead. Can someone confirm/deny that (could also have been lag or whatever)?
I would check replays but since they desync they currently can't be trusted...
-atioglxx.dll driver crash if you have dynamic clouds and high-res clouds activated AT THE SAME TIME (works fine if you have only one of the two settings activated, enabling both worked fine in last Spring version)
-if using bump-mapped water, using shorewaves ONLY works (fine, as in previous Spring version) on maps WITH water, but will cause the driver crash for maps WITHOUT water
Confirming most of the other bugs for me, especially pathfinding, replay desync, bright factories in idle builders widget, unit highlighting widgets turning great parts of the screen green and invisible bomber projectiles.
One more POSSIBLE thing (which i will have to test a bit to confirm or deny though): In several BA games i THINK i have noticed nano turrets (on roam) sometimes not properly executing the patrol command properly (like in previous Spring versions) and getting kinda freezed instead. Can someone confirm/deny that (could also have been lag or whatever)?
I would check replays but since they desync they currently can't be trusted...
Re: Big Bug thread for 0.82.2/3 - Report bugs here
Klopper, the problem you describe with nano turrets could be a combination of:
* nano turret not always turning correctly
* max particles reached -> it is not visible that nano turret does something.
* nano turret not always turning correctly
* max particles reached -> it is not visible that nano turret does something.
Re: Big Bug thread for 0.82.2/3 - Report bugs here
I managed to trim down the minimap bug a bit. The screen fadeflashes green whenever there are any nano particles showing on the map whilst a minimap widget is enabled. So anything such as restoring, reclaiming, building or anything that shows nanos particles would trigger this.
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: Big Bug thread for 0.82.2/3 - Report bugs here
Does this issue apply to my above quoted bug? I notice there is no mention of "cannon" in it, only missile.CarRepairer wrote:Projectile models are not visible anymore for weapons of the type 'cannon'. They were visible before the update.
http://springrts.com/mantis/view.php?id=2030
Re: Big Bug thread for 0.82.2/3 - Report bugs here
Fixed http://github.com/spring/spring/commit/ ... 9efc369883CarRepairer wrote: Does this issue apply to my above quoted bug? I notice there is no mention of "cannon" in it, only missile.
http://springrts.com/mantis/view.php?id=2030
- very_bad_soldier
- Posts: 1397
- Joined: 20 Feb 2007, 01:10
Re: Big Bug thread for 0.82.2/3 - Report bugs here
You probably already know about this crash, but just to be sure:
I get this one here quite regularly usually in the first minutes, seems to be related to aiInterfaceCallback_DataDirs_getWriteableDir().
http://pastebin.com/XFhhwNuj
I get this one here quite regularly usually in the first minutes, seems to be related to aiInterfaceCallback_DataDirs_getWriteableDir().
http://pastebin.com/XFhhwNuj
Re: Big Bug thread for 0.82.2/3 - Report bugs here
i would say it is probably rather this:
aiInterfaceCallback_DataDirs_getWriteableDir is just the last exported symbol of spring.exe, so it just shows a lot of/most stuff after that as an offset to that symbol (my guess). it surely is not involved an the crash.
as the crash happened in the same frame in which you switched to bumpmapped.[ 2526] Set water rendering mode to 1 (reflective)
[ 2629] Set Shadows to 1
[ 2752] Set water rendering mode to 3 (reflective&refractive)
[ 2864] Set water rendering mode to 4 (bumpmapped)
[ 2864] [BumpWater] water-shader compilation error: Vertex info
-----------
0(88) : error C1013: function "main" is already defined at 0(88)
Fragment info
-------------
0(120) : error C1038: declaration of "reftexcoord" conflicts with previous declaration at 0(120)
0(133) : error C1013: function "convertDepthToZ" is already defined at 0(133)
0(179) : error C1013: function "main" is already defined at 0(179)
[ 2864] Spring 0.82.3.0 (0.82.3) has crashed.
[ 2864] Exception: Access violation (0xc0000005)
[ 2864] Exception Address: 0x14a40538
aiInterfaceCallback_DataDirs_getWriteableDir is just the last exported symbol of spring.exe, so it just shows a lot of/most stuff after that as an offset to that symbol (my guess). it surely is not involved an the crash.
- very_bad_soldier
- Posts: 1397
- Joined: 20 Feb 2007, 01:10
Re: Big Bug thread for 0.82.2/3 - Report bugs here
Ok thanks, I will try to disable FPSManager widget, that should stop that water switching.
I get that shader error nearly every game but I usually get away with it without crashing.
EDIT:
Regarding the function addresses: So the stack is corrupted?
I get that shader error nearly every game but I usually get away with it without crashing.
EDIT:
Regarding the function addresses: So the stack is corrupted?
Re: Big Bug thread for 0.82.2/3 - Report bugs here
no, does not mean the stack is corrupted. it just makes no sense that addr2line does use this symbol in translation. do not know the details why it gets used.
Last edited by hoijui on 01 Sep 2010, 08:50, edited 1 time in total.
Re: Big Bug thread for 0.82.2/3 - Report bugs here
A really really wierd bug: dragon teeth randomly disappear.
Edit: Correction, they are still visible from far view (billboards) but not visible up close. (from spectator mode)
Edit: Correction, they are still visible from far view (billboards) but not visible up close. (from spectator mode)
- very_bad_soldier
- Posts: 1397
- Joined: 20 Feb 2007, 01:10
Re: Big Bug thread for 0.82.2/3 - Report bugs here
I still get this one in 0.82.5 even without switching the water renderer.very_bad_soldier wrote:You probably already know about this crash, but just to be sure:
I get this one here quite regularly usually in the first minutes, seems to be related to aiInterfaceCallback_DataDirs_getWriteableDir().
http://pastebin.com/XFhhwNuj
Re: Big Bug thread for 0.82.2/3 - Report bugs here
Been fighting a lot with MinGW builds. Seems pretty flakey in general.
I'm trying now with MinGW 4.5.0 (from the installer) and I get a strange error, not sure what to make of it
I've turned off parallel building to see if the processes are fighting for the same files and I'm deactivating the "Program Guard" feature of Online Armour but if anyone knows why this might be happening let me know.
What I do know is the disk isn't full and the temp directory is writable.
I'm trying now with MinGW 4.5.0 (from the installer) and I get a strange error, not sure what to make of it
Code: Select all
g++.exe: CreateProcess: No such file or directory
process_begin: CreateProcess(C:\Temp\make2784-1.bat, C:\Temp\make2784-1.bat, ...
) failed.
make (e=5): Access is denied.
mingw32-make[2]: *** [spring-multithreaded.exe] Error 5
mingw32-make[1]: *** [rts/builds/GML/CMakeFiles/spring-multithreaded.dir/all] Er
ror 2
process_begin: CreateProcess(D:\Apps\CMake\bin\cmake.exe, D:\Apps\CMake\bin\cmak
e.exe -E cmake_progress_report D:\SpringTest\debug\CMakeFiles, ...) failed.
make (e=5): Access is denied.
mingw32-make[2]: *** [rts/builds/HL/CMakeFiles/spring-headless.dir/__/__/Game/UI
/KeyBindings.cpp.obj] Error 5
mingw32-make[2]: *** Waiting for unfinished jobs....
[ 25%] mingw32-make[2]: *** [rts/builds/default/CMakeFiles/spring.dir/__/__/Game
/UnsyncedGameCommands.cpp.obj] Error 1
mingw32-make[2]: *** Waiting for unfinished jobs....
What I do know is the disk isn't full and the temp directory is writable.
Re: Big Bug thread for 0.82.2/3 - Report bugs here
bogus createprocess failures may mean several things, most often:
- command line too long (had that problem last time i tried to rebuild spring)
- path too long (there are some workarounds for that IIRC, but I don't know whether they work with mingw)
- command line too long (had that problem last time i tried to rebuild spring)
- path too long (there are some workarounds for that IIRC, but I don't know whether they work with mingw)