Bug Reports

by eihrul on 09/03/2008 01:41, 1175 messages, last message: 12/31/2023 08:39, 929594 views, last view: 05/19/2024 23:21

Please post your bug reports in here.

With your bug report, please submit the following information:

1) OS: Your operating system, i.e. Linux, Windows, or otherwise and what version you are using.

2) 3D card: The 3D card you are using. If you do not know, this is printed on the "Renderer:" line in the console when Sauerbraten starts up.

3) The edition of Sauerbraten you are using, i.e. Assassin edition, CVS as of a particular date, or otherwise.

4) Error information: If you are on Windows, a pop-up message showing filenames and line numbers should show up when Sauerbraten crashes; if possible, post a screenshot or a copy/paste of this. If on Linux, post a log of the startup info from the console, including relevant errors or any info you might have discovered. If on MacOS X, please post the crash log if applicable.

5) A description of the problem and how to reproduce it. Please give as much detail as possible on how someone can recreate the problem, in as certain terms as you can. If someone else can't reproduce the problem, it is unlikely he can fix it or tell you what is wrong.

   Board Index   

#1107: Re: ..

by eihrul on 09/29/2014 20:54, refers to #1106

Numbers prefixed with 0 are octal, not a bug, and must have digits in the range of 0-7 or else it stops parsing.

reply to this message

#1108: Re: ..

by Papriko on 09/29/2014 21:13, refers to #1107

Alright, thanks for the tip. Not really an error or bug, but is there also a function which forces numeric output to be octal/hex?

reply to this message

#1109: shader issues

by suicizer03 on 10/17/2014 00:08

1) Windows.
2) I'm rendering on a GeForce 8800 GT/PCIe/SSE2 with driver updated to 3.3.0
3) Collect Edition.
4) No error log.
5) The shaders and their respective settings are messed up when taking different resolutions.
For example, using the decalworld shader works perfectly for high resolutions (on my computer at least), but they stop being rendered on resolutions like 1024x768, 1280x800, 1280x720, 600x480, 1280x768 and anything lower than that.
It seems to matter also what size of decals you've used; one which is only 256x256 (calling up "cube.png" on a 128x128 texture for example) has not such problems, but 512x256 has (calling up "logo.png" on a 256x128 textures for example).
Anti-aliasing seems to have no effect, neither forcing to another rendering mode.
If you try to take your previous resolution after the one which doesn't work; the new resolution isn't showing off correctly also (like going from 640x480 to 1280x960). You have to start up Sauerbraten entirely.
Rendering fullscreen or windowed doesn't matter at all.
The pulseworld shader isn't working in GLSL rendering mode; no matter what resolution (neither fullscreen or windowed).

So is this a bug in the code or due the driver? Will it be fixed? Can I fix it on my own version? Please some answer.

reply to this message

#1110: Re: shader issues

by suicizer03 on 10/17/2014 00:10, refers to #1109

But a decal of 512x256 has issues being rendered with those resolutions or lower (calling up "logo.png" on a 256x128 textures for example).

reply to this message

#1111: Re: shader issues

by suicizer03 on 10/20/2014 00:06, refers to #1110

For those who want to experience it, put the next line within a map-cfg and select the textures;

setshader "decalworld"
texture 0 "jf1/jfwall.jpg"
texture d "../data/logo.png"

texture 0 "jf1/jfyellow.jpg"
texture d "../data/cube.png"

setshader "pulseworld"
setshaderparam "pulsecolor" 1 1 1
setshaderparam "pulsespeed" 0.5
texture 0 "jf1/jfflr.jpg"
texture 1 "jf1/jfrust.jpg"

reply to this message

#1112: Re: shader issues

by Pyccna on 11/01/2014 00:37, refers to #1111

The root cause might be because you're changing resolutions. What do you need to do that for anyway?

P.S, nice to know how decalworld works now!

reply to this message

#1113: Re: shader issues

by suicizer03 on 11/01/2014 01:04, refers to #1112

It also occurs when not changing the resolution; so loading right after start up.

reply to this message

#1114: Re: shader issues

by Pyccna on 11/01/2014 03:12, refers to #1113

You lost me now.
Most likely this is a driver issue.

reply to this message

#1115: Re: shader issues

by suicizer03 on 11/02/2014 17:10, refers to #1114

Doesn't seems so as I've tried it on my laptop with the very same results.

I'm rendering on a GeForce 610M/PCIe/SSE2 with a driver version of 4.3.0 on my laptop, using Windows 7 Home Premium also.

So is it an issue in the code or so??

reply to this message

#1116: Crashes with Mac OS X 10.10 Yosemite

by el_tars on 12/05/2014 03:43

1) Mac OS X 10.10 Yosemite

2) Intel Iris HD

3) Collect Edition

4) Sauerbraten crashes immediately upon launch. The default Mac error "Sauerbraten quit unexpectedly" appears.

reply to this message

#1117: ..

by Papriko on 12/13/2014 22:50

1. Ubuntu 12.04, 64-bit

2. NVidia GeForce GT 640

3. Collect

4. You apparently no longer collide with SP ents (boxes, barrels, platforms, elevators)

5. Try playing platform_demo or box_demo. Alternatively, try to play a SP map like lost and die because you suddenly phase through the platform into doom.

reply to this message

#1118: Re: ..

by Papriko on 12/13/2014 22:52, refers to #1117

Additional information: apparently those ents no longer collide with each other either.

reply to this message

#1119: Re: ..

by Papriko on 12/13/2014 22:59, refers to #1117

OOPSIE! Sorry, forget this! I messed up something in the source code! My fault XD

reply to this message

#1120: clipping is broken please fix

by nyamms on 12/28/2014 21:57

1) OS: Windows 7 Ultimate 64bit, most likely makes no difference

2) 3D card: GTX 260 or 770, makes no difference

3) Sauerbraten Collect Edition

4) map demonstration of various clipping bugs: https://dl.dropboxusercontent.com/u/27093909/nyammsclipadventures.ogz

5) It's easier to see for yourself on the map than it is to explain it in words.

Short version: The clip material and even clipping with only normal cubes behaves weird in various cases, mostly on diagonal surfaces. It causes players to bump over surfaces that should be flat, or even get stuck on them.

Clip in some cases also causes the player to slow down when they hit their head against it, unlike a ceiling made of normal geometry.

reply to this message

#1121: Last used crosshair doesn't work.

by Drarrhat on 12/28/2014 22:14

I have two crosshairs, red.tga and green.tga. If I select one of the crossairs and restart, that crosshair becomes blurry. The other one stays sharp. Does anyone know why this happens?
By the way, I'm loading the crosshairs with the "crosshairs = [...]" function from autoconfig.cfg. If I try to use "loadcrosshair" I get the error "could not load texture".

reply to this message

#1122: Re: Last used crosshair doesn't work.

by Antiklimax on 12/31/2014 13:16, refers to #1121

Hi! Use .png and not .tga. Put your crosshair into users data directory where Sauerbraten hold your cfg and custom maps etc. at me : c:UsersmynameDocumentsMy GamesSauerbratenpackagesbase.
Write this into your autoexec.cfg: loadcrosshair "packages/base/yourcrosshairname.png"
exec in game autoexec.cfg
Have fun!

reply to this message

#1123: Re: clipping is broken please fix

by suicizer03 on 12/31/2014 14:56, refers to #1120

Slopes has been always a quite tricky thing.
The bug on the first slope seems to be caused due being at the height of the default world. If you make it even just a little bit higher (with the flat geometry next to it); you won't have the same result. That's why my advice is always to start your map about 8 or 16 default cubes higher; so you won't have such troubles.
I know that's not solving the case; but it is a work around (why fixing a minor issue while it doesn't have to be seen as an issue?).

The second case with clipping material below the slope is just quite obvious; you can't expect a cylinder hover over the slope and missing the clipping material; that would probably mess up the collision box. Why would you put clipping material there in the first place? It's never recommended to have paperthin walls in a map as you're just asking for bugs while it doesn't make it more realistic when someone gets hit by splash damage (as you get the full splash damage while you probably couldn't even see the rocket or made exploding at the other side of the wall).

Slopes are always a pretty nasty thing in maps. Rather use stairs instead.

For the getting stuck in walls (3th case); that's a more common thing and it could and perhaps should be fixed (although I'm not the one to decide).

There doesn't seems to be a bug for the 5th case (where you got to jump frequently). It's obvious you bump back to the floor faster again when the space to jump is smaller. Then again; all those cases shouldn't occur commonly in a gameplay oriented map as they decrease the flow. Perhaps as a certain cut off to a strategic area, but that's it.

Some certain unwritten rule when designing a gameplay oriented map;
- Use clipping and noclipping material with sense.

Hitting your head towards clip when jumping and certain other cases lacks that piece of sense.

reply to this message

#1124: Re: Last used crosshair doesn't work.

by Drarrhat on 12/31/2014 20:45, refers to #1122

FYI I wasn't sure if this was a bug or not, so I reposted a related question in the general thread. I don't know if an admin wants to delete one of them?

Anyway, I narrowed down the problem. Here's a summary: If loadcrosshair is in the config.cfg or if bilinear filtering is enabled, it blurs. (The crosshair is black and white with transparent pixels.) I can put loadcrosshair in the autoconfig.cfg but it has no effect on whether it blurs or not.

reply to this message

#1125: Re: clipping is broken please fix

by nyamms on 01/02/2015 13:03, refers to #1123

There are countless examples where clip doesn't work the way it should. As I mentioned, the map I provided included only very simple and abstract examples. That doesn't mean that clipping is any less broken when it comes to proper mapping. For example, why can I get stuck on this corner that is perfectly clipped? https://i.imgur.com/hp2ASgs.png


>>The bug on the first slope seems to be caused due being at the height of the default world. If you make it even just a little bit higher (with the flat geometry next to it); you won't have the same result. That's why my advice is always to start your map about 8 or 16 default cubes higher; so you won't have such troubles.


That's hardly the only place this issue pops up, and that's why I provided another another example right next to it that isn't on default height.

If you'd tried shifting the whole thing up one or two gridpower 5 cubes, you'd know that the problem still persists. I assume it has something to do with the way slopes intersect larger cubes.

Even if it did work, I don't think there being a way to circumvent a bug is a reason not to fix it. It's not a minor issue. The collision box interfering with geometry that should be out of the way is a problem that pops up in many places and is the main source of all clipping-related troubles a mapper runs into.


>>The second case with clipping material below the slope is just quite obvious; you can't expect a cylinder hover over the slope and missing the clipping material; that would probably mess up the collision box.


The slope is a flat surface, the clip is underneath it, of course I can expect it not to interfere. A collision box should not hit geometry behind a slope that isn't even in reach. I know what you're trying to say and why it does work this way, but it's counter-intuitive, and a better solution for collision detection would involve something that prevents this sort of problem.

Note the example next to it that uses geometry cubes instead of clip: That one isn't bumpy either. As far as the collision box is concerned, clip and geometry should merge just as well as two geometry cubes. There is no reason it should be this way, it's a bug.


>>Why would you put clipping material there in the first place?


I placed an example right next to it that uses skyclip to make bumpy stairs smooth. Again, the map contains very basic examples. The fact that clip behaves in very weird ways when it connects to geometry is a problem that pops up again and again.

Example: https://i.imgur.com/ORMJjDt.png
You will get stuck on the clipped edge, while the skyclip one works fine. That makes no sense, and is an annoying solution not only because it is a workaround, but it also restricts the use of opaque skytexture and makes grenades bounce off of it.

The point is, you don't need paperthin walls for this to be a problem.


>>There doesn't seems to be a bug for the 5th case (where you got to jump frequently). It's obvious you bump back to the floor faster again when the space to jump is smaller. Then again; all those cases shouldn't occur commonly in a gameplay oriented map as they decrease the flow. Perhaps as a certain cut off to a strategic area, but that's it.


Try it again. The point is that the height 5 clip ceiling somehow kills your forward momentum while the same ceiling made of geometry doesn't. And then somehow, a clip ceiling at height of a gridpower 4 cube only does this occasionally, perhaps at certain points.

A straight wall or ceiling made of clip or geometry shouldn't affect your movement in different ways. I know players other than me who observed the same thing.

I'm also not advocating the use of low ceilings, this is a noteworthy bug regardless. What is and isn't good mapping once again has nothing to do with it.

reply to this message

#1126: Re: clipping is broken please fix

by suicizer03 on 01/02/2015 22:17, refers to #1125

Your screenshot of memento seems somewhat weird as I'm not having such trouble at all. So I don't know how you managed it but perhaps you should reinstall your Sauerbraten version.

http://i.imgur.com/BT9Gp07.png

It should definitely be appreciated that you've added such effort in experimenting with the clip and eventually even put abstract cases in a map. This might also affect any other game on Cube Engine 2 (like Tesseract or Red Eclipse); more investigation is necessary for that.
If you really want to reach the developer (Eihrul, Baby-Rabbit, etc); I would advice to speak to them via IRC (#sauerbraten @ irc.quakenet.org) or send them an email. They aren't always looking throughout the forum.

Perhaps the clipping material could share the same code as normal geometry does? Although that probably means a complete rewrite of the physics on the engine.

reply to this message

   Board Index