Sauerbraten - Bug reports |
by Gilt
on 11/28/2004 19:49, 574 messages, last message: 06/30/2007 22:00, 520713 views, last view: 09/30/2024 08:11 |
|
So yeah, since I don't feel like doing a whole lot of testing anymore, I may as well leverage my resources, and shove that responsibility to all of you. Hopefully, this will allow for more updates, and a less buggy engine.
The Format:
-----------
What: A *short* description of the bug / problem.
How: point form of relevant steps to reproduce the bug.
When: revision of exe. OS, video card... yeah I don't know, anything that might be relevant. keep it short.
Detail: any other stuff that might be relevant. like pics. http://www.imageshack.us/ if needed.
-----------
new releases here:
http://cvs.sourceforge.net/viewcvs.py/sauerbraten/sauerbraten/sauerbraten/bin/sauerbraten.exe?view=log
for each new version, I will list fixed bugs. you are then responsible to make sure that it really is fixed, and then confirming it in this thread.
!!! NOTE !!!: this thread is not for feature requests, design discussion, bitching, moaning, yadda yadda, etc. there are other threads for that. plus, a forum thread already does not afford great organization. please no garbage.
Keep reports short. I have a habit of skimming large blocks of text.
Focus on the WHAT, not the WHY. There is a tendancy in people to want to be too helpful. They try to diagnose the problem instead of very clearly describing what is wrong. at the very least, keep theories in the detail section.
some examples are below:
|
|
Board Index
|
|
#278: Re: Buggy cubes |
by Andrew Brault
on 07/16/2005 20:23, refers to #277
|
|
The cubes pictured were produced by manipulating individual cubes, no subdivision involved...
reply to this message
|
|
#279: Re: Buggy cubes |
by Andrew Brault
on 07/16/2005 21:11, refers to #278
|
|
Using a debugger I pulled out the "edges" array for some of these weird cubes (12 hexadecimal bytes each):
- 101010006054888000888854
- 006080200088005010558284
- 101010100080851087005480
- 100010108054885080000084
- 106010100088005000558284
These appear to be normal in the sense that all nybbles are between 0 and 8 and high nybble >= low nybble. So the rendering problems must be caused not by corrupt edgespans but by the conversion of edgespans into vertex positions.
reply to this message
|
|
#280: Re: CVS Sauer on x86_64 hangs in intermission |
by Aardappel_
on 07/16/2005 22:30, refers to #270
|
|
to solve the 64bit issues we will have to wait until we have a programmer that uses such a system, and thus can just find the bugs.
reply to this message
|
|
#281: Re: Buggy cubes |
by Andrew Brault
on 07/17/2005 03:42, refers to #279
|
|
After reading the code some I think the problems with cube rendering stem from a confusion in the code of what the edgespans really mean. To me, the edgespans define 6 heightfields in the 6 axis directions where each heightfield has a flat square "base" and a jagged "top" which should always be a convex mountain shape (or flat). The ultimate cube shape should be the CSG intersection of these 6 heightfields. However the rendering code treats the edgespans as defining 6 flat planes (even if the planes are not flat) that when intersected always result in a 8 vertex polyhedron.
This seems wrong and inconsistent to me but maybe I have an wrong understanding of the idea behind the edgespans. Any ideas?
reply to this message
|
|
#282: Re: Buggy cubes |
by Andrew Brault
on 07/17/2005 03:52, refers to #282
|
|
I don't think so ... from what I can tell the buggy cubes have perfectly legal structure but the conversion to poly vertices is going wrong, sometimes even producing vertices outside the cube volume.
reply to this message
|
|
#283: the nothing crash |
by shadow.516
on 07/20/2005 00:52
|
|
In the lates CVS, if you remove all the cubes from the map (so that all that is left is the skybox), the game crashes.
reply to this message
|
|
#284: Re: the nothing crash |
by shadow.516
on 07/20/2005 00:56, refers to #283
|
|
in addition, it doesn't matter if there are other materials left on the map - as long as there are no solids, a crash is inevitable.
I came across this bug while trying to make a map entirely out of glass.
reply to this message
|
|
#285: gun vanish |
by da(5)id
on 07/23/2005 07:18
|
|
i've noticed that when i go up stairs the gun flickers in and out of exsistance.
this doesn't happen with the character model in the thirdperson mode. weird huh?
reply to this message
|
|
#286: Re: CVS Sauer bugs on x86_64 -- out of world ents |
by kurtis84
on 07/23/2005 15:07, refers to #285
|
|
just for the record, there are no ents outside of ksauer1. I do have a clue why you're getting that message though. There are several cubes I pulled back 1 or 2 units, then I set ents in that pulled back space...is it not properly calculating those small spaces like that?
I cannot help but wonder Morgaine2, have you done anything to find the source of this 64bit problem, or are you just posting everything you see wrong with it on a 64bit system? AFAIK, nobody working on Sauer has a 64bit system, so I would think these problems aren't going to be fixed unless you, or someone with a 64bit system does it themselves ;)
reply to this message
|
|
#287: Re: CVS Sauer bugs on x86_64 -- out of world ents |
by shadow.516
on 07/24/2005 03:54, refers to #287
|
|
Actually, there are out of map coordinates for 32-bit. But for some reason the code doesn't hang.
Here's what I get with ksauer1:
init: video: mode
init: video: misc
init: gl
Using GL_ARB_vertex_buffer_object extensions
init: world
game mode is ffa/default
init: basetex
init: sound
init: cfg
unknown command: and
init: localconnect
init: mainloop
read map packages\base\aard3.ogz (3893 milliseconds)
game mode is ffa/default
warning: ent outside of world: enttype[11] index 14
warning: ent outside of world: enttype[11] index 15
warning: ent outside of world: enttype[3] index 16
warning: ent outside of world: enttype[3] index 17
warning: ent outside of world: enttype[3] index 18
warning: ent outside of world: enttype[5] index 19
warning: ent outside of world: enttype[8] index 20
warning: ent outside of world: enttype[9] index 22
warning: ent outside of world: enttype[11] index 25
warning: ent outside of world: enttype[4] index 28
warning: ent outside of world: enttype[10] index 34
warning: ent outside of world: enttype[5] index 60
warning: ent outside of world: enttype[4] index 61
warning: ent outside of world: enttype[6] index 64
read map packages\base\ksauer1.ogz (4062 milliseconds)
3Dimentia_1
game mode is ffa/default
reply to this message
|
|
#288: Re: CVS Sauer bugs on x86_64 -- out of world ents |
by kurtis84
on 07/24/2005 19:02, refers to #288
|
|
So, let me get this straight. Is there something wrong with my map thats causing this, or is it in the method the engine is loading the map?
If it's something wrong with my map, I would like to hear someone say exactly what it is about ksauer1 thats causing this...does anyone know yet?
reply to this message
|
|
#289: Re: CVS Sauer bugs on x86_64 -- out of world ents |
by Aardappel_
on 07/25/2005 23:06, refers to #289
|
|
that's because it doesn't solve the problem, only hides it. Other maps have entities outside the world which are legal, such as sunlights.
Some coordinates of some entities are clearly corrupted, they show up as big numbers or NaN even on win32 (so this is not a 64bit portability issue, it just crashes harder on 64bit linux).
I can easily "fix" this map, but I would rather first know how they got corrupted in the first place. You can't really tamper or corrupt a .ogz externally, as it would show up as a zlib crc error. So somehow, some version of sauer must have corrupted this itself.
reply to this message
|
|
#290: hmm |
by Pxtl
on 07/26/2005 14:55
|
|
It does seem that it should at least make a warning about such violations, at least where appropriate (as Aard mentioned, some entities should be outside).
reply to this message
|
|
#291: Re: CVS Sauer bugs on x86_64 -- out of world ents |
by >driAn<.
on 07/26/2005 20:19, refers to #290
|
|
Morgaine2, no it doesn't solve the problem. A bug must be fixed on the root of the problem, else its a cheap hack.
reply to this message
|
|
#292: Re: CVS Sauer bugs on x86_64 -- out of world ents |
by kurtis84
on 07/27/2005 00:13, refers to #292
|
|
ksauer1 was built before we had a working "dropent" command. I did use the dropent on the map after it was implemented, but I think I remember there being some issues with that command.
Could this have caused these troubles?
At any rate, I think if theres any evidence that the newer versions of sauer do not create these "corrupted ents", I would like to fix the map and forget about this....it makes me nervous knowing theres a bug in my map :)
reply to this message
|
|
#293: a new weapon |
by rootnis
on 08/13/2005 23:40
|
|
there is a new weapon in sauer called hidehud 1 and it looks like nuclear explosion ;). But if serious, then take a look at pictures taken few seconds after i execute hidehud 1 in console.
http://img101.imageshack.us/img101/3045/screenshot412824mp.jpg
http://img27.imageshack.us/img27/5602/screenshot421356er.jpg
http://img27.imageshack.us/img27/7016/screenshot431852pu.jpg
unfortunately it works self-destructive because you cant see a thing but game goes on he he. Luckily things can be undone by hidehud 0.
and yes, there is another thing - it doesn`t show hudicons any more. hmm
when: 1.98, ati radeon 7000, winxp
reply to this message
|
|
#294: texture bug (?) |
by CC_machine2
on 08/18/2005 00:21
|
|
ok, so i decided to make a little map in sauer. ive tried using custom textures but it didnt work (properly).
my texture (note i put in a chunk of another tex to help diagnose the problem):
http://www.hitech.clearcrystal.co.uk/mytex.PNG
screenshot of it in sauer (with the original tex that i took a bit from next to it):
http://www.hitech.clearcrystal.co.uk/screenshot_mytex.JPG
i know that my tex is totally CRAPPY but i just tried out a new tex to see if it worked and found this bug or whatever it is.
reply to this message
|
|
#295: .. |
by makkE
on 08/18/2005 00:59
|
|
It´s not a bug. In cube and sauer, textures may appear overbright sometimes.
Adjust their brightness/contrast until they look ok in game. Also depends on lightning.
reply to this message
|
|
#296: Re: .. |
by rootnis
on 08/18/2005 02:59, refers to #296
|
|
lol =D
reply to this message
|
|
#297: Re: .. |
by CC_machine2
on 08/18/2005 11:31, refers to #295
|
|
yes but it shouldn't!
reply to this message
|
|
|
Board Index
|
|