Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
rdwpa

*** The "ask a miscellaneous editing question" thread ***

Recommended Posts

I have an issue with sectors in GZDoom Builder, you se when I try to make a sector inside a sector, it ends up treating the newly created sector as a seperate sector, in other words the sector lines are not light grey like they are supposed to, the lines are white, and  when I go into 3D mode, the ceiling and floor for the sector are all messed up, (not the textures, it just that the floors and ceiling at at the same height as the sector I created the new sector in,) 

 

Here are some screenshots showing what I mean, the messed up sector is the rectangle the triangle is the way it is supposed to be, I think I accidentally activated a keyboard shortcut that changed a setting or mode while mapping the level out that caused this to happen,

 

keep in mind I am using the latest version of GZDoom Builder (BugFix Version) so the settings will be a bit different if you're using a older version or a altogether different editor.

 

Also note: the 3D view picture that appears to have to triangles on the floors may be a bit confusing to some, the triangle on the right is the actual triangle sector, the one on the left is actually the messed up rectangle sector.

MAP01 at 2018.12.05 13-06-41.229 [R3041].jpg

MAP01 at 2018.12.05 13-07-41.400 [R3041].jpg

MAP01 at 2018.12.05 13-20-01.944 [R3041].jpg

Share this post


Link to post

You'll need to tell the sidedefs what sectors they should be referencing directly in the linedef editor, which means you'll need to flag the lines double-sided, unflag them impassible, and make each sidedef reference the proper sector (for example, the front sidedef references sector 933 and the back references 932). That's the only way I know that works around this.

Share this post


Link to post

AJOgames, only idea I have is when you draw the sector to change from clockwise to anticlockwise (or visa versa) so that the front side of the linedefs are on the outside of the shape when it's drawn. Maybe the editor is making an assumption about the back side of the linedefs which is making them impassible.

 

10 minutes ago, Aquila Chrysaetos said:

You'll need to tell the sidedefs what sectors they should be referencing directly in the linedef editor, which means you'll need to flag the lines double-sided, unflag them impassible, and make each sidedef reference the proper sector (for example, the front sidedef references sector 933 and the back references 932). That's the only way I know that works around this.

And this will certainly fix the problem, but it would be nice to avoid it in the first place. This also happens to me sometimes with Doom Builder 2. I just undo and try it again reversing the clockwise/anticlockwise order I drew it. Or if it was a difficult shape to draw and I don't want to do it again, fix it like Aquila Chrysaetos describes. Whatever works the quickest.

Edited by alowe

Share this post


Link to post
8 minutes ago, AJOgames said:

I have an issue with sectors in GZDoom Builder, you se when I try to make a sector inside a sector, it ends up treating the newly created sector as a seperate sector

 

Do you mean every time you try to draw a sector inside another sector it does this?  Or just within this one specific sector?

 

If it's every sector it sounds like an issue with a setting in GZDB.  If it's just that sector it sounds like that sector is bugged and you might want to just redraw it.

Share this post


Link to post
5 minutes ago, Bauul said:

If it's every sector it sounds like an issue with a setting in GZDB.  If it's just that sector it sounds like that sector is bugged and you might want to just redraw it.

 

That reminds me that sometimes "making" the sector surrounding it and the sector you just drew sometimes fixes the problem. I'm not sure if GZDB has a make mode, but that's how I sometimes fix this issue in DB2.

Share this post


Link to post

GZDB does have a make mode, I just never knew how to use it, I always used Linedef mode to draw my sectors.

Share this post


Link to post
3 minutes ago, AJOgames said:

GZDB does have a make mode, I just never knew how to use it, I always used Linedef mode to draw my sectors.

 

I don't use make mode to draw sectors. I use it to get the editor to "refresh" a sector that's already been drawn. This often fixes mismatches between the sector indexes on linedefs with a single click :o)

Share this post


Link to post

Sometimes GZDB does this to me and I have no idea why, because my geometry should be perfectly valid. I think the editor just has a stupid moment. If I try to re-draw it again slightly differently and then move vertices to fix it, it works fine.

Share this post


Link to post

Still have the problem, changing the direction the sector linedefs faces does nothing, the "Make Sector" mode does nothing to it, and and Alowe, the whole "draw the sector clockwise/counter-clockwise" thing unfortunately doesn't work for me, every time I try to draw a square sector, regardless of which way I draw, the sector snaps to having the linedefs face towards the inside, 

 

Also that whole "reference" thing Aquila mentioned I don't understand, or rather I don't know how to do, (I do know how to change the flags, just not the "referring to sector" I don't know how that's done. I'm still fairly new with GZDB)

 

The only good thing I can say so far is that at least it is only affecting the big sector that I'm attempting to put the square sector in. I did try partially rebuilding it, but it didn't fix the issue

theres also another issue I had, when i simply draw a line in a sector that has no textures/floors/ceilings, and hit enter, the sector automatically generates floors and ceilings, and it does this at the most inconvenient moments.

Share this post


Link to post
10 minutes ago, AJOgames said:

Also that whole "reference" thing Aquila mentioned I don't understand, or rather I don't know how to do, (I do know how to change the flags, just not the "referring to sector" I don't know how that's done. I'm still fairly new with GZDB)

 

That I didn't understand until recently either. Okay, each sector is given a number. Each linedef, when you look at its properties, has something called a "Sector Index". Sector index means what sector the linedef is pointing into.  Normally, two-sided linedefs have a front side and a back side. Front, in this case, is the direction the little notch is pointing. So if you have a sector X with all its linedefs pointing outward into sector Y, the Front Sidedef's Sector Index would be Y, and the Back Sidedef's Sector Index would be X because the back side is "pointing into" sector X.

 

Check the linedefs of your bad sector and see if the editor thinks they are single-sided or not, and then check to see that the sector indexes match what they should be.

 

 

9 minutes ago, AJOgames said:

theres also another issue I had, when i simply draw a line in a sector that has no textures/floors/ceilings, and hit enter, the sector automatically generates floors and ceilings, and it does this at the most inconvenient moments.

 

Err, pardon? Are you drawing single lines and then hitting enter? That's not a proper way to create a sector. A sector needs to be a closed box of at least three lines. Anything else will not be a legal sector. That could be a problem.

 

Always close your sectors, and never overlap lines without connecting them with vertices.

Share this post


Link to post

Thank you Stabbey for telling me that, and I did get the problem fixed for the most part, but the thing is...

 

that wasn't the problem, or at least, I got rid of some "invisible" sector... (at least I think it was,)

 

for some reason, whenever I turned gravity off in 3D mode, I would walk around the big sector for a bit, but somewhere around the messed up sector I kept suddenly going up,  going up a higher level, even though the floor height was the same in that area...

 

So it was like I was standing up on a higher floor level, without there being a higher floor level,

 

So I decided to try to do some experiementing, I deleted the rectangle sector, put a line directly through the big sector (down the middle, with thus caused the big sector to become two connected sectors,) and then deleted that line, and somehow...

 

That fixed the issue, that's why I believe that there was some sort of invisible floor or sector that, when I apparently deleted the first rectangle sector, (which I did a bit before you joined the conversation,) the editor might've only partially deleted the sector, keeping the hit detection there, but the rest was otherwise deleted.

 

I don't know if this glitch was a side-effect of the recent update I got for GZDoom Builder Bugfix, but either way, it was a rather odd glitch,

I don't know, I was all a bit confusing, but hopefully i got the issue fixed, I thank every one of you who came to help me out! :)

Share this post


Link to post
9 hours ago, AJOgames said:

So I decided to try to do some experiementing, I deleted the rectangle sector, put a line directly through the big sector (down the middle, with thus caused the big sector to become two connected sectors,) and then deleted that line, and somehow...

 

That fixed the issue, that's why I believe that there was some sort of invisible floor or sector that, when I apparently deleted the first rectangle sector, (which I did a bit before you joined the conversation,) the editor might've only partially deleted the sector, keeping the hit detection there, but the rest was otherwise deleted.

 

For the record that's not the best way to merge two sectors into one. You want to use the Merge Sectors function (Shift + J). Also whenever I do that, I also make sure to set both sectors to the same settings (textures, floor and ceiling height) so that the merged sector will have the settings I want.

 

It sounds to me like you might want to skim over the basic tutorial section first:

 

You don't need to actually DO the tutorials, but you might want to read the lessons.

Share this post


Link to post
19 hours ago, AJOgames said:

regardless of which way I draw, the sector snaps to having the linedefs face towards the inside,

Hmm, maybe this is a feature of GZDB as I don't get that behaviour in DB2.

 

Quote

that wasn't the problem, or at least, I got rid of some "invisible" sector... (at least I think it was,)

That's one of the most difficult glitches to fix, because it can only be deduced and not seen (unless you know how to interpret it in a hex editor).

 

Another way I fix these is redrawing the linedefs over the top of the existing linedefs of the surrounding sector. That sometimes fixes mismatches where make sector fails. If vertices get disconnected they can be restitched by moving them away and then back to their original position.

 

I think a lot of these problems are caused by copying and pasting sectors. The editor has to figure out what the sector indexes should be for each linedef and sometimes it makes a mistake, for example if you paste a sector into an area that overlaps more than one sector. It might be obvious to you what should go where because you know the overall context of the area you're building, but that's hard for a programmer to deduce ahead of time and sometimes they're forced to make assumptions.

 

So, I have about 5 or 6 methods to fix this problem. Even then sometimes it doesn't work and the only solution is to delete and do it again. That's why I save often.

Share this post


Link to post
On 12/5/2018 at 3:57 PM, AJOgames said:

..... every time I try to draw a square sector, regardless of which way I draw, the sector snaps to having the linedefs face towards the inside, .....

 

 

Which way linedefs are facing depends on how the linedefs are drawn

 

1. drawing an initial sector in void space has the handles pointing inwards

 

2. drawing a new sector clockwise inside an existing sector has the handles pointing inwards

 

3. drawing a new sector counterclockwise inside an existing sector has the handles pointing outwards

 

4. drawing a new sector clockwise inside an existing sector has the handles pointing inwards,

but highlighting the linedefs and pressing F flips the linedefs

 

 

Edited by Kappes Buur

Share this post


Link to post
10 hours ago, Kappes Buur said:

4. drawing a new sector clockwise inside an existing sector has the handles pointing inwards,

but highlighting the linedefs and pressing F flips the linedefs

Thanks for breaking that down. I was tempted to figure it out but was too lazy, haha.

 

Although flipping the linedefs will change the direction they're facing, if the editor has decided that they're impassable (even though the sector was drawn inside another sector), then you'd need the make the sector you drew (and perhaps also remake the sector it's inside), then take a note of the inside and outside sector indexes and manually enter those indexes into the appropriate linedef front and back references.

 

Now I think about it, if the editor thinks any part of the sector you're drawing intersects sector 0 (zero) then it can make all the linedefs impassable and one sided, because it's assuming you're drawing in an unedited area (open space). That's why you also need to remake the surrounding sector and fix the issue with that before drawing new sectors inside it. Then those sectors will be double sided and passable no matter if they're drawn clockwise or anticlockwise.

 

What I suspect happens is:

1) there's a glitchy sector with an unshown sector intersecting it.

2) You paste or draw a new sector inside this glitchy sector.

3) The editor sees that part of your new sector intersects sector 0 (zero) or some other sector that is unshown.

4) It therefore assumes that your new sector is in open space, and therefore the outside of that sector is considered impassable.

5) Therefore the lindefs are set as one sided and the index of the outside sector is allocated to one direction of the linedefs only.

6) Resulting in exactly what is shown in AOJgames' screengrabs.

 

The solution is to:

1) If the sector you just drew that has unintentional impassable lindefs is simple and easy to redraw, just delete it.

2) Whether or not you delete it the problem is in the sector you're drawing in. So remake that sector (not redraw, just do a make sector on it).

3) If that doesn't fix the problem then try retracing the sector you're trying to draw into to get the editor to reinterpret and remove the unshown sector removing the glitch.

4) If that doesn't work then check the vertices on the lindefs of the sector you're drawing into. Make sure when you pull them away they're still stitched to the lindefs. If not then restitch them by moving them away, releasing, and then moving them back again to trigger the editor to stitch them.

5) If that doesn't work then go around each linedef of the sector you're drawing into and flip it once and back again to make sure there isn't another linedef hidden within it. If there is then delete one of the duplicate linedefs. This might mean you have to do a make sector on adjoining sectors if the editor turns them into sector 0.

6) Even if all that doesn't work, just redraw your sector inside as before, or if you didn't delete it leave it as it is. Then do a make sector operation inside that one (whether you redrew it or not).

7) Note down the sector index of the surrounding sector. Note down the sector index of the sector you just drew.

8) Select all the linedefs of the sector you're drawing, and making sure they all have the same orientation relative to the sector you just drew, manually enter in the appropriate sector indexes for each linedef direction.

9) If that still doesn't fix it there's a more serious problem. At this point I tend to undo my actions back to the last point where the glitch didn't exist and failing that load a previous save that doesn't have the glitch and finally, failing all that deleting or redrawing in place all the sectors affected by the glitch until the glitch is removed.

 

Once you get used to fixing this stuff you somehow learn to avoid making the actions that cause these glitches and they happen less often. That's why it's a bit hard for me to remember what causes them, because it's been a while since I've seen one.

 

Note: Just manually fixing the issue for the sector you've drawn won't necessarily resolve the glitch that caused the problem. It won't remove duplicated lindefs. It won't restitch floating vertices. And it won't necessarily resolve any mismatched linedef sector index references. That's why I think it's worth totally blitzing the problem so that it's completely fixed, rather than just fudging it and leaving a mod that is unstable.

Share this post


Link to post

Do two sectors that are joined but not continuous (ie. the same sector but not connected in space) count as multiple visplanes or just one?

Share this post


Link to post
On samedi 8 décembre 2018 at 9:47 PM, whirledtsar said:

Do two sectors that are joined but not continuous (ie. the same sector but not connected in space) count as multiple visplanes or just one?

That depends on whether there is another visible plane in between them. And also, they can be separate sectors or joined, it doesn't change anything.

 

Visible planes (visplanes) are merged if they have the same property (flat texture, brightness level, height) and there isn't another visplane separating them visually. Note that walls are not visplanes. So for example if you have two low ceilings separated by a high ceiling, and you can see the low ceilings but the high one is out of sight, the the two low ceilings can potentially be merged even if you see some upper wall texture between them. You can even have some strange situation like this:

    ┌───┐
    │ A │
┌───┼───┼───┐
│ B │ C │ B │
└───┼───┼───┘
    │ A │
    └─x─┘

x is the position of the player, looking north. A and B are both split sectors with low ceilings that are visible by the player. C is a sector with a high ceiling, not visible by the player. In this situation, both visplanes of the A sector will be merged together since there's no other visplane between them; and both visplanes of the B sector will likewise be joined for the same reason. Even though "logically" these merges result in an "overlap" in the space of sector C.

 

Oh, and I only talked about ceilings to make this simpler, but the floors have their own visplanes too. Here if the floor A, B, and C are all visible, then the floor visplanes of A and B don't get merged with their split because there's another visplane (C) blocking both their merges.

Share this post


Link to post
1 hour ago, Gez said:

Visible planes (visplanes) are merged if they have the same property (flat texture, brightness level, height) and there isn't another visplane separating them visually. Note that walls are not visplanes. So for example if you have two low ceilings separated by a high ceiling, and you can see the low ceilings but the high one is out of sight, the the two low ceilings can potentially be merged even if you see some upper wall texture between them.

 

Does this same logic apply when the ceiling (or floor) texture is the F_SKY1? It's technically an invisible flat that allows you to see to the sky illustration behind it.

 

However, let's say you had different sectors with the sky ceiling set to different heights (for whatever reason). Using your example above, let's say sector A is at 96, B is at 128, and C is at 160. In principle, you could see all the ceilings if they were not invisible, but since they're the sky, they are. Ignoring the floors and considering only visplanes from the ceilings, would that mean there would be 5 visplanes? Or just 1 visplane, since the flats are invisible?

 

Share this post


Link to post

As far as the renderer is concerned, there's no sky "behind" anything. But to answer your question: for skies, the height and brightness properties are simply ignored when checking whether the visplanes can be merged.

Share this post


Link to post

Hi all,

 

Can anybody think of a reason why lump filtering is no longer working apparently?

 

I have a FILTER directory in my main wad file for DOOM2 assets (doom.doom2.commercial) and instead of using the DECORATE file here, the engine is using the main DECORATE file.

 

I am using the latest version of GZDoom. 

 

Has lump filtering been discontinued or something?

 

Any help would be greatly appreciated!

Share this post


Link to post
2 hours ago, Poormetheus said:

I have a FILTER directory in my main wad file for DOOM2 assets (doom.doom2.commercial) and instead of using the DECORATE file here, the engine is using the main DECORATE file.

DECORATE files are cumulative, so the main one will be loaded regardless of whether any other DECORATE file is also found in the filtered folders. There's no "instead of" here, both will be loaded.

 

You can have a dozen different DECORATE.something files in the root directory and they will all be loaded.

Share this post


Link to post
1 hour ago, Gez said:

DECORATE files are cumulative, so the main one will be loaded regardless of whether any other DECORATE file is also found in the filtered folders. There's no "instead of" here, both will be loaded.

 

You can have a dozen different DECORATE.something files in the root directory and they will all be loaded.

 

Thank you, Gez.

 

I was fully sure it didn't use to work this way (c. Dec 2016) but I guess I am wrong. 

Share this post


Link to post

In my main DECORATE file I have this; it randomizes Zombiemen and Shotgunguys with scientists, and if it is Inferno episode, replaces them with 'Zombie Fodder':

 

Actor Zombiereplacer replaces Zombieman {
   States {
  Spawn:
  TNT1 A 0
  TNT1 A 0 A_JumpIf(CallACS("Checkepisode", 0, 0, 0, 0)==3, "Spawn2")
  TNT1 A 0 A_Jump(110,"Spawn3")
  TNT1 A 0 A_SpawnItemEx("ScientistSpawn",0,0,0,0,0,0,0,SXF_TRANSFERAMBUSHFLAG|SXF_TRANSFERSPECIAL)
  stop
Spawn2:
  TNT1 A 0
  TNT1 A 0 A_SpawnItemEx("ZombieFodder",0,0,0,0,0,0,0,SXF_TRANSFERAMBUSHFLAG|SXF_TRANSFERSPECIAL)
  stop
 Spawn3:
  TNT1 A 0
  TNT1 A 0 A_SpawnItemEx("Zombieman1",0,0,0,0,0,0,0,SXF_TRANSFERAMBUSHFLAG|SXF_TRANSFERSPECIAL)
  stop
  }
}

 

 

 

I placed a DECORATE in my FILTER directory saying this, and my CPU NEARLY MELTED ITSELF:

 

Actor Soldiers replaces ScientistSpawn {
   States {
  Spawn:
  TNT1 A 0
  TNT1 A 0 A_SpawnItemEx("SoldierSpawn",0,0,0,0,0,0,0,SXF_TRANSFERAMBUSHFLAG|SXF_TRANSFERSPECIAL)
  }
 }

 

 

Any advice on how I can get those pesky scientists out of my DOOM2 game and replace them with a thing called 'soldierspawn'?

Share this post


Link to post

I feel a bit stupid asking this, but how do I build down stairs? The thing is, I have a pre-existing staircase, which I want to remove (!) after a button is pressed or item is collected. My problem now is, that the "26 Stairs Build Down"-special causes the steps to submerge into the ground, which I actually don't want. :/

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×