entryway Posted September 29, 2004 Who knows how to compile level and by which program with which parameters to avoid visual bug, which can be seen in software mode of prboom? (Rendering is good in glboom). Screen-shots demonstrating this bug are available here: http://geocities.com/e6y/files/doom/my/soft01.gif http://geocities.com/e6y/files/doom/my/soft02.gif Level: http://geocities.com/e6y/files/doom/my/e6y.zip (map02) I am using the DoomBuilder with ZenNode1.2.1 compiler. My bridge seems like HellRevealed2's one on 19-th level, but there all correct as in prboom as well in glboom. But in case of re-compiling of 19th level by any of accessible for me compilers and then saving, visual bug appears in it too. 0 Share this post Link to post
Mordeth Posted September 29, 2004 Although I haven't examined your level, it looks like only one side of the support linedefs refers back to the dummy bridge sector instead of both sides. 0 Share this post Link to post
Graf Zahl Posted September 29, 2004 Make sure that the self-referencing sectors representing the invisible blocks used to walk over the bridge are closed and there are no overlapping lines involved. You just have isolated linedefs and with such a setup it is pure luck if a node builder manages to create usable nodes. If those blocks are closed there is no ambiguity to which sector the inside will belong to and the bridge will work. Make also sure the entire bridge is surrounded by lines belonging to the outside sector(s) (currently it is) so that the bridge blocks don't extend into areas they are not supposed to. 0 Share this post Link to post
netnomad312 Posted September 29, 2004 GL ports will often screw these things up (I know). If your level has 3D bridges I suggest you don't use a GL port at all (except for very few exceptions). 0 Share this post Link to post
entryway Posted September 29, 2004 4 4 ooooooooooooooooooooooooooooo o 3 3 3 o o o o 1 1(3) 1(3) 1 o .---.---.---.---.---.---.---. o | 1 | | | | 1 | o o | | 2|2 | | | o 4 o | | 2|2 | | | o 4 o | 1 | | | | 1 | o .---.---.---.---.---.---.---. o 1 1(3) 1(3) 1 o o o o 3 3 3 o ooooooooooooooooooooooooooooo 4 4 "--" both sides refer to sector 1 "|" both sides refer to sector 2 (tag 52) o - sector 3 The visual mistake described above is present http://geocities.com/e6y/files/doom/my/e6y_old.zip But if the front side of "--"line refer to sector 3 - all works perfectly. But in all wads both sides of a handrail refer to the one sector http://geocities.com/e6y/files/doom/my/e6y.zip I would like to see concrete descriptions of my mistake in e6y_old.zip\map02 0 Share this post Link to post
The Ultimate DooMer Posted September 29, 2004 Overlapping lines are used, as there are meant to be no vertices connecting the self-referencing linedefs to the crossbeam linedefs. btw, Zennode doesn't like 3D bridges much (it makes the self-referencing linedefs much thinner in terms of being able to stand on them), you're probably better off with DeepBSP. 0 Share this post Link to post
kristus Posted September 29, 2004 IMO I suggest you use Boom specials. you get the same effect and it works in GL ports aswell. 0 Share this post Link to post
entryway Posted September 29, 2004 kristus said:IMO I suggest you use Boom specials. you get the same effect and it works in GL ports aswell. It was always working in GL ports for me. What is "Boom specials"? 0 Share this post Link to post
Graf Zahl Posted September 29, 2004 entryway said:It was always working in GL ports for me. What is "Boom specials"? Boom has one linedef special that transfers the floor height from one sector to another. It can be used to create invisible blocks without any self-referencing sector hacks. But this means the level requires a Boom-compatible source port to run, which with the sole exception of JDoom applies to all modern ports. As for your bridge, you should do it like this (I made the space between the lines larger to fit in the numbers: | | |4 4| | 4 | |--------------------------------------| | | 4 | | | 1 4|4 2 4|4 3 | | --------- | --------- | --- | | | 1 | | | 2 | | | | | |4 1|1 1|1|2|2 2|2| | |3 4| | | 1 | | | 2 | | | | | | --------- | --------- | --- | | 1 4|4 2 |4 3 | | | 4 | | |--------------------------------------| | ^ 4 ^ | |4 | | 4| | |-These are the crossbeams (1-3 are the parts of the bridge and 4 is the outer sector. The crossbeams of the bridge are part of the outer sector in this setup.) Notice that the blocks which make the bridge are closed shapes with self-referencing sectors (i.e. same sector on both sides) but everything else is the outer sector. This configuration should work with every node builder out there. The problems appear if there are overlapping linedefs from different sectors or as in your case isolated linedefs from a different sector inside another sector. These isolated linedefs don't create a closed shape which is required to reliably determine in which sector a certain point lies. With your setup, depending on the way the node builder works, any point on the bridge may incontrollably end up in either the lower sector or the invisible block. 0 Share this post Link to post
entryway Posted September 29, 2004 Graf Zahl said: Thanks a lot! That all what I needed. 0 Share this post Link to post
deathbringer Posted September 30, 2004 Boom has one linedef special that transfers the floor height from one sector to another. It can be used to create invisible blocks without any self-referencing sector hacks. It does? and i had just gotten fed up with trying to make the sector referenceing work too! 0 Share this post Link to post
Graf Zahl Posted September 30, 2004 deathbringer said:It does? and i had just gotten fed up with trying to make the sector referenceing work too! Check out Boomref.txt and look for type 242. Alternatively you can look here: http://www.zdoom.org/wiki/index.php?title=Transfer_Heights The lower part fully applies to Boom also. 0 Share this post Link to post