Bug hitscan - Doomworld Forums

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Doom Editing > Bug hitscan

Author

All times are GMT. The time now is 16:37.

Kills
Newbie

Posts: 5
Registered: 01-13

Hi there,

I'm making a megawad but I'm facing a bug that is totally killing me, I don't know how to fix it and is putting in danger the project.

Is at least the 2n time that happens to me in 2 maps consecutively.

The problem is:

Some of the projectiles totally ignore the monsters and end up hitting the walls. Now, this only happens with weapons that use hitscan, like the shotgun, chaingun, etc. But doesn't with plasma, bfg & rocket launcher.

I've been checking arround the webside & internet, I found similar bugs, nevertheless for as long as I know this one is diferent.

This bug only happens in one room <--- (I stopped working on the wad until fix the bug, probably if I keep building, the bug will extend to the new rooms).

This room is rather small, very simple, with 4 or 5 sectors inside the room, the ceiling texture is not sky.

If I build a new room where I start building the map, that room works perfectly without the bug.

I thought it could be by something wrong in the coordinates, maybe? so I moved the hole map to the north (where all sectors work properly)but the room is still buged.

If I blow up the room and I make a sector where it was, the bug persists in the new sector.

And finally, the shots actually hit the monsters when they are like 1 meter from me (almost mele).

Did that happened to someone else? it looks like strange to me that this is not a common bug since its happening to me consecutively.

I'm using gzDoomBuilder and happens the same in Doombuilder 2 (The same bug appeared in maps made by DM2).

The map is still under construction (not even a third done), its not big at all. It has:
Linedefs 10714
Sidedefs 19859
Sectors 2321

When I discovered the bug, I used the test map of doombuilder, and to discart that tiny posibility I try it later from windows using Gzdoom.

Thank you for your interest

02-07-13 04:42 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9139
Registered: 07-07

Are there other sectors in that map that are very far away? If so, what you encounter is the blockmap overflow.

02-07-13 08:23 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Kills
Newbie

Posts: 5
Registered: 01-13

http://imageshack.us/photo/my-images/252/mapbug.png/

All map is conected and there's no sectors very far away. To the left, the farest point from the center of the point 0 is at 24.000 points distance, and to the south (Where the bug is) the farest point is at 18.000 points.

Also this happened to me in maps that doesnt go not even that far.

For what I'm reading at blockmap overflow from doom wiki, that actually happened to me in another map, witch is not the case.

In this case the map is not that big, I don't have the no clipping effect and maybe the most important thing here, is that the bullets doesn't stop in midair, but goes thru the enemies and impact at the wall behind them.

That bug doesn't happened to anyone else? after seen it in different occasions, it's really weird that no one else have seen it.

02-07-13 12:00 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9139
Registered: 07-07

Then it might be this other blockmap bug.

02-07-13 12:22 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Kills
Newbie

Posts: 5
Registered: 01-13

I have read the hole explanation of the bug here:

http://games.moria.org.uk/doom/rese...-through-things

But this bug doesn't seems to be the same, and more important:

http://zdoom.org/wiki/Compatibility_options

If you scroll down, almost at the bottom of the page, you'll se that there is an option witch zdoom can (and it does by default) desactivate the original doom code for hitscan that creates this bug.

I can say pretty sure that this is not the bug I'm stuck with.

Any more suggestions?

02-07-13 12:42 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Forum Regular

Posts: 673
Registered: 04-09

This is a wild guess. Had to do something like this a couple of times.

I suspect there are two sectors involved, and the linedefs separating those sectors are not being handled right, or may be outright missing.
Maybe a degenerate sector was created by putting one linedef on top of another linedef. Another way is to overlap two sectors during a move, so the dividing linedef is on the wrong side of another dividing linedef, the space between them being very confusing to the engine.

The engine has the monsters in a different sector than the shooter and is not checking them because it does not encounter the sector when
tracing the adjacent sectors. Overlapped linedefs and overlapping sectors violate the rules, making coding assumptions invalid.
Then traverses of the internal data structures fail to find everything,
so monsters do not get shot.

Missiles move slower and actually move from sector to sector.

Look at the sector number of every linedef to make sure they are closed, not overlapped, and have no other linedefs within them.

Be careful of shared sectors, as the same sector number will appear in many places, confusing things. Try making all subsectors unique sectors until the bug is discovered.

Look for a linedef on top of another linedef. Most editors cannot find these.
Moving an end vertex does not help as two linedef can share their end vertexes, and they will always move together.
To see the 2nd linedef you must put a vertex in the suspect linedef and then drag that one vertex sideways.
So one method is to put an extra vertex in every linedef and move
it enough to make it bent. You will likely discover a hidden linedef
that you were not aware of.

Another way is to cut each suspect sector into smaller sectors, then delete the original linedefs. This can be done on a copy of the
problem area if the problem is also copied (which implies extra linedef).
This should double the number of sectors, which will make locating the fault easier.
If this does not expose an extra linedef directly, then test with fixed monsters where exactly the shooting goes wrong. The closest
linedef between the shooter and monster is suspect.
Afterwards the new linedefs can be shifted into the original linedef locations, and sectors can be combined.

02-08-13 04:40 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Kills
Newbie

Posts: 5
Registered: 01-13

Thank you for your answer and interest.

I've encountered this kind of problem previously and I can say pretty sure its not that what its causing me problems, instead I think its something bigger, not related with any mistake maded by me, but a bug of doom builder or something like that.

Do you know why I know this?

I kept making my map finding the way to avoid that bug. So, when I deleted the sector and make another one where the last one was used to be, pretty much eliminates that problem that you are saying, and the new sector was still buged in the same way (And that sector was not separated by linedef).

So, before keep building in order to detect where that bug is situated and get the maximum information as posible, I build a simple sector of 4 linedefs outside of the map at diferent distances and positions.

This sectors where buged depending on the location they where builded, so I keep building in the opposite locations and so far I can keep building outside the bug.

I have compiled more information related to this bug:

I kept my original sector where the bug is situated removing all monsters and at the side of the sector where was the monsters & the bug is now a switch, that switch teleports monsters in the opossite direction (in the same sector) and you can surprisingly kill them from the side of the bug, but if they come to close, the bullets start traspassing them without affecting them. There is no linedefs where the bug start affecting and so far I can see has nothing to do with the sector itself (Its a pretty simple sector).

Anyway, I'm still interested in any relevant information, because I'm sure I will have to face again that bug in the future.

02-08-13 17:30 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Forum Regular

Posts: 673
Registered: 04-09

Most mappers sooner or later run into one of these.
They can be very hard to find, so almost everyone goes through thinking that it cannot possibly be something in their map. It is always something in the map.

It is unlikely you will find the problem as long as you have belief that your map is not bugged. It is well known that a writer cannot spellcheck their own work because they will read over obvious misspellings and do not see them. Same with mappers.

You are going to have to distrust everything in your map.
There is no test that will prove that parts of your map are correct.
I have been through that, made that mistake. The part of the map I trusted had a reference that caused an inconsistency. I could not see it until I mangled a copy of the map until I identified a sensitive area. It took several days of debugging and tactics of desperation before I found it.

It is going to be in a part of the map that you trust, because you have more carefully checked over the parts you do not trust.
Mappers never check adequately things that they trust. Their eyes glaze over as they go through the motions.

The tools do not have any code that is X,Y position dependent. Only near the limits you can get calculation roundoff and overflows.
Those limits are tool dependent but +16000 to -16000 should be safe.
Any effect that is X,Y position dependent has to be caused by something on the map that is violating some code assumption (the mapping rules).
If you move the entire map by 2000, the problem area will move with it.

This suggests another way to diagnose. Use a copy of the map and move parts around until the problem area moves. It would help to separate large portions of the map far away from the problem area. Then keep moving portions far away until you hit something sensitive.

It is most likely the nodebuilder that is being confused by something.
The nodebuilder generates the blockmap that speeds up weapon fire checks. It goes through the linedefs trying to determine sector connectivity based on X,Y coordinates. If it is mislead by a linedef sector reference it could get a blockmap that does not agree with your editor visualization of the map.
The game is not played from the editor visualization of the map.

Last edited by wesleyjohnson on 02-12-13 at 23:11

02-12-13 23:00 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote