Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Kid Airbag

"Invisible Barrier" Bug

Recommended Posts

On some of my levels, in certain rooms, there are "invisible barriers" that I can't go through, just randomly there even though there is nothing there in the automap, nor is there anything there in WadAuthor.

I was told that this is the result of faulty node-building, and that I needed to get a better node-builder than the one that is built in to WA. So I downloaded BSP, and used that on the wad with the errors. However, I went back to play it, and the bug was still there.

Does anyone have any idea as to what I'm supposed to do to fix that?

Share this post


Link to post

Might as well probably a better idea to post a link to your wad, so people could figure out what the real problem is in game :)

Share this post


Link to post

There might be some error in line-sector assignments. I'd have guessed that node-building went bad, but as 999Cop said, you need to post the wad or email it. I'll look at it if you want, send to llblakely@earthlink.net.

Share this post


Link to post

You have probably already checked this but from time to time I still get this.

What it usually is is a line that should be 2 sided somehow marked impassable or a sector with out texture that is to low to go under.

I know you are far beyond this a mapmaker but I find most of my problems these days are simple once I find them. In other words, the hard is done easily, and the easy screws me up sometimes.

Share this post


Link to post

Actually, could it be Long Wall error?

Just a suggestion, although it only sounds remotely like it.

Share this post


Link to post

This happened to me once on a particularly large map. I think it's definitely a nodes problem.

Share this post


Link to post

I know it's definitely not a case of a linedef accidentally being marked impassable or one-sided, cause the barrier is totally non-existant. Usually it's in the middle of a room, and it doesn't show up on the map at all, or in the editor.

This is a WIP, so it hasn't been uploaded yet, but I guess I'll e-mail it around to those of you who graciously offered to help.

Share this post


Link to post

If you don't get it worked out in a couple of days, I would be happy to look and see if I might be able to help. Email is just under the message, if you can zip it to less than one meg for the fools at hotmail and the fools who use hotmail ;)

Share this post


Link to post

it's a nodes problem. I got it with bsp 2.3 once in a pretty small map. Only happened that one time though and switching nodebuilder to WARM fixed it.

Share this post


Link to post
Erik said:

it's a nodes problem. I got it with bsp 2.3 once

Most likely BSP 2.1 though. There was a math error that got fixed in 2.3 Go read the docs and see:) Could be this person is using 2.1 also or maybe it got reintroduced in a newer version? He never mentioned the version.

Share this post


Link to post

Arch, the repaired file has been emailed to you. For the curious, it was a stubborn node-building problem which did not yield to the efforts of several node builders. The problem structure was a chair made of four (IIRC) sectors. Putting a "guard" sector around the chair did nothing. What fixed it was simply moving the chair vertices slightly and rebuilding. All fixed.

Share this post


Link to post

Hmm, I figured it was something stupid like that, cause running BSP a second time seemed to get rid of just about every single other error that I had previously noticed.

Thanks, Biffy.

Share this post


Link to post

Is it an actual barrier, or is it an 'invisible block' that you can walk on with no clipping mode?

If it's a block, then it's because the linedef is pointing the wrong way. The general rule is that the front sidedef should point to the sector with the lower floor and/or ceiling. I suggest flipping the linedef round and that usually fixes it. (There are a few cases where it's the other way round, but that's very rare)

Share this post


Link to post
Archvile64 said:

Hmm, I figured it was something stupid like that, cause running BSP a second time seemed to get rid of just about every single other error that I had previously noticed./B]

I'd like to see the original level - solution doesn't sound right:) deep@sbsoftware.com

If the lines are shorter than 4 units maybe. There's an option in DeePBSP to consider shorter lines. However, I have a zillion "chairs" and little 2x2 stubs in Xtheateriii with no probs.

You mean running the same BSP program 2x on the same level? Should make no difference at all, unless the editor is messing up the vertices inserted by the nodebuilder (or visa versa).

Share this post


Link to post

U Doomer, I tried that linedef flip and it did not correct this rare problem. In fact, the backsides of the lines are facing the sector with the lower floor, but that is commonplace and the only thing I've seen affected by it is the occasional wall which will "swallow" rockets or not display bullet puffs. But, it's a good ground rule to remember as you stated it.

In this case, there is an unusual vertex alignment (I'm guessing) which affects the node build. Go figure....

Share this post


Link to post

Nope, the solution is "right". There are no short lines. I've run this wad through DeePsea node building with no change, the problem was still there. It's a simulated red chair made of four sectors and at one corner of the chair you can see a red line extending into the floor. Flipping lines does not fix it. WARM, DeePsea and WA node builds do not fix it. Moving the vertices slightly does fix it.

Now, why this happens is something maybe one of you can explain.

deep - I will email you this wad now, as I received it from Arch64. His email should explain where to find the error..it's quite close to the player start, a bit northeast.

Something I'd like to know is how I managed to cause a problem with DeePsea. During fix attempts, I opened this wad (it's a doom1 wad) and saved as a new name with rebuild nodes selected. After that, zdoom would crash with a single r_init texture error I think it was. Upon examination, I found that an extra entry, f_end, had been inserted in the wad, right after the ff_end. There was a ff_start entry, no f_start entry. When I deleted this extra f_end entry, zdoom was again happy. How did I make DeePsea insert this f_end entry?

Share this post


Link to post

Thanks for the file Biffy - always fun to look at new levels. Nice job Archvile. Looks like you put a lot of work into that so far.

Biffy said:

There are no short lines.

Well, actually there is a short line as seen by a node builder:) The chair is angled (a relevant detail left out) and the angled line whose vertexes you moved is angled slightly differently from the rest of the chair. The delta Y between those points has to resolve to an integral unit and in this case they end up too close (2 units) and then when it decides what side it's on gets confused in the conversion from FP back to integers:)

That's probably exactly the same problem in some polyobjects having bleeding - the renderer can't decide. Use grid size = 1 to see what I mean.

Which reminds me, making angled anything is very expensive in terms of nodes. Do this only if one can actually tell a difference (the chair was fine it had a purpose). The outside squares may be better (and cause less probs, esp if you get into polys) if they became normal verticals and horizontals.

There's also an overlapped line in the level - LD 1672 and 1699 overlap. This is common WA error - a cause of potential grief:)

zdoom would crash with a single r_init texture error

Mistake in ZDOOM. Having an FF_END followed by F_END is perfectly legitimate. I added that (long ago) since DOOM required an F_END to recognize added flats (FF_START is wintext/port invention). Run the level in BOOM or Legacy or PRBOOM and see. Another bug for Randy:)

If this is for ZDOOM(?), how about hi-res textures for the pop machines? They'd look awesome even close up.

Share this post


Link to post

"There's also an overlapped line in the level - LD 1672 and 1699 overlap. This is common WA error - a cause of potential grief:)"

I fixed that in the zz4fix file I sent, I think. WA flagged a problem there, but it was for coincident nodes and upon inspection I saw the overlapping lines. WA will let you overlap lines without warning.


"The delta Y between those points has to resolve to an integral unit and in this case they end up too close (2 units) and then when it decides what side it's on gets confused in the conversion from FP back to integers:)"

You lost me there. Since the minimum grid is one, how can the delta be anything other than an integer? Did Archvile manage to place a vertex in an "invalid" location? And, why is two units too close for anything? I've spaced things at one unit OK.

Share this post


Link to post

"Mistake in ZDOOM. Having an FF_END followed by F_END is perfectly legitimate. I added that (long ago) since DOOM required an F_END to recognize added flats (FF_START is wintext/port invention). Run the level in BOOM or Legacy or PRBOOM and see. Another bug for Randy:)"

Holy crapola, Batman! Are you saying this just cropped up? Does Randy know? Naw, this must be known for some time, eh?

Share this post


Link to post

Biffy said:
WA will let you overlap lines without warning.

Exactly - that's what I meant. No warning.

You lost me there. Since the minimum grid is one, how can the delta be anything other than an integer?

The point along a SLOPED line for intersections (which is how this is calculated) are initially a floating point coordinates - not integers. Then what happens is that these points are added as NEW vertices by a nodes builder - which of course means they get converted back to integers in the process. Then it has to be decided which side of the line you are on as the build progresses. Because of the unavoidable rounding artifact, in special cases this causes "invisible" barriers - since the rendered only does what it's told. And of course also causes the poly issues, vertical lines and all those other anomalies in some cases.

Look at BSP 2.1 vs BSP 2.3 code to see the problem in another way. This is one of many reasons why QUAKE went to floating point coordinates.

The FF_END thing - I don't know when that happened - all I can tell you is that ZDOOM has a mistake. Maybe this is only on DOOM levels or maybe if there is nothing following. XTHEATERIII has FF_END/F_END except it has more lumps following. My guess is that this is an unknown error and just cropped up, since levels usually have something following.

Share this post


Link to post

So, what's the lesson here for wad authors? Can they anticipate the ocurrance of this problem, or should they just build away and if this anomaly is seen, attempt corrections which include slight vertex movement?

Share this post


Link to post
Biffy said:

In this case, there is an unusual vertex alignment (I'm guessing) which affects the node build. Go figure....

This could possibly be due to the fact that I built the chair on the grid, and then used WadAuthor's "rotate sector(s)" tool to rotate the chair 35 degrees or whatever.

Share this post


Link to post

Good thing it doesn't happen very often:)

The basic rule is NOT to make angled lines unless you really need them. Many many many levels (is that enough<g>) don't pay attention to straight lines. I see them drift by 1-4+ units totally by accident, not because of any design intent. And that of course is why I added the shift+A command (for align) - used the grid coordinates as the delta allowed.

Share this post


Link to post
Archvile64 said:

This could possibly be due to the fact that I built the chair on the grid, and then used WadAuthor's "rotate sector(s)" tool to rotate the chair 35 degrees or whatever.


Hey, that might be it??? After doing such, maybe you can drag the vertices to the nearest snap. With WA, minimum grid is 2, hold shift to allow dragging every one unit.

Share this post


Link to post
deep said:

There's also an overlapped line in the level - LD 1672 and 1699 overlap. This is common WA error - a cause of potential grief:)

Erm, where exactly are those two lines? I assume from the numbers that their in the little brown courtyard with the pond, visible from the windows outside the staircase, but I can't pinpoint the exact lines...

If this is for ZDOOM(?), how about hi-res textures for the pop machines? They'd look awesome even close up.

Well, it's not ZDoom specific, it just needs any source port since it uses the line type 244, which vanilla Doom doesn't recognize, and E1M3 totally destroys vanilla Doom's shitty visplane limits. So any source port should do fine.

Share this post


Link to post
Archvile64 said:

This could possibly be due to the fact that I built the chair on the grid, and then used WadAuthor's "rotate sector(s)" tool to rotate the chair 35 degrees or whatever.

Could be your grid. More interestingly, rotation commands show PRECISELY the problem with floating point vs integer coordinates. The rotate is done in pure floating point. Then the final results have to be mapped back to integral (integer) DOOM units. Even without snapping to grid, it's impossible to get smooth lines if they are too close together (as in the chair).

Share this post


Link to post
deep said:

Good thing it doesn't happen very often:)

The basic rule is NOT to make angled lines unless you really need them. Many many many levels (is that enough<g>) don't pay attention to straight lines. I see them drift by 1-4+ units totally by accident, not because of any design intent. And that of course is why I added the shift+A command (for align) - used the grid coordinates as the delta allowed.

I am very, very careful about straight lines, unless I want them to not be straight. That's the first time I've ever had something I rotated to not be snapped correctly. So yeah, it doesn't happen very often, fortunately =)

Anyway, thanks for all the help you guys have given me.

Share this post


Link to post
deep said:

...The delta Y between those points has to resolve to an integral unit and in this case they end up too close (2 units) and then when it decides what side it's on gets confused in the conversion from FP back to integers:)

That's probably exactly the same problem in some polyobjects having bleeding - the renderer can't decide. Use grid size = 1 to see what I mean.

Which reminds me, making angled anything is very expensive in terms of nodes. Do this only if one can actually tell a difference (the chair was fine it had a purpose). The outside squares may be better (and cause less probs, esp if you get into polys) if they became normal verticals and horizontals.


Okay, here's questions more out of just "would this work well or not in an engine rewrite" that deal with this:

(1) Would having vertex positions in the WAD be 24-bit integers (20.4 in terms of feet), but in the engine being 32-bit (25.7) cause more or less rounding errors? (Would the reverse help more with rounding errors and FP/integer conversions?)

(2) What would be the simplest way to combine polyobjects, slopes, and EDGE's extrafloors without making changes to the data structures? (Would it be more of a hassle than it's worth?)

(3) Should the node system be made more complicated and allow non-AABB (axis-aligned bounding boxes, for those not In The Know, heh), making angled areas less expensive in terms of nodes, but making node building more computationally expensive (and possibly rendering as well)?

Thanks.

Share this post


Link to post
Archvile64 said:

Erm, where exactly are those two lines? I assume from the numbers that their in the little brown courtyard with the pond, visible from the windows outside the staircase, but I can't pinpoint the exact lines...


Use WA and run the error checker on E1M4. Scroll down the list of errors, near the bottom you will see that duplicate vertices are identified. Hilight that message. Click the "view" button, zoom in if needed. Now, drag the offending vertex and you will see the overlapping lines revealed. I'm pretty sure that's all fixed in the zz4fix.zip I sent you, so look in your zz4.wad for it.

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
×