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

1 hour ago, TJG1289 said:

Edit: I just tried it on a backup of the map and figured it out. Deleting all the unused textures/flats/patches doesn't effect the IWAD. I should have figured that right from the start

Deleting unused textures/patches actually DOES affect the IWAD maps, unless you are playing using a sourceport such as GZDoom/ZDoom that supports loading TEXTUREx and PNAMES lumps cumulatively.

1 hour ago, Worst said:

 

Deleting unused textures/patches actually DOES affect the IWAD maps, unless you are playing using a sourceport such as GZDoom/ZDoom that supports loading TEXTUREx and PNAMES lumps cumulatively.

Ok, so I should just use the Remove Unused Patches tool then?

20 minutes ago, TJG1289 said:

Ok, so I should just use the Remove Unused Patches tool then?

That should be okay, assuming your TEXTURE1/2 lumps and PNAMES lumps are imported from the IWAD. Since I think it only removes patches that aren't used in the TEXTURE1/2 lumps.

Slade3 question: 

Is there a way to run the current map without having to start from the first map? I am working on map02 and whenver i try to run the current map it will start with my map01. I'm not sure if there is something I am completely missing, but part of me just wants to build off a dummy wad and then copy/paste everything over when I am all set with what I'm working on 

2 hours ago, aloysiusfreeman said:

Is there a way to run the current map without having to start from the first map? I am working on map02 and whenver i try to run the current map it will start with my map01. I'm not sure if there is something I am completely missing, but part of me just wants to build off a dummy wad and then copy/paste everything over when I am all set with what I'm working on 

Add the warp argument to whatever your run configuration is:

Ahhhh, thank you!

Hi everyone! Its a small question, there are objects like Evil Eye, that have full brightness, how to disable it in decorate lump in MBF? 

In DEHACKED you mean?

The full bright flag is encoded in the frame code. I think it's called sprite "sub" number in DEHACKED? So A is 0, B is 1, etc. but if you add 32767 then it's full bright. So you look for the sprite sub number of the evil eye and you remove 32767 from it to get it no longer full bright.

2 minutes ago, Gez said:

In DEHACKED you mean?

 

The full bright flag is encoded in the frame code. I think it's called sprite "sub" number in DEHACKED? So A is 0, B is 1, etc. but if you add 32767 then it's full bright. So you look for the sprite sub number of the evil eye and you remove 32767 from it to get it no longer full bright.

Thanks a lot!

There are two strings that can show up whenever to try to open a door which needs a key you don't have.

"You need a XYZ key to activate this object"

and

"You need a XYZ key to open this door"

My very specific question is, what is considered a door and what is considered an object according to Doom, and how is it handled in other complevels (Boom, mbf...)?

I ask this because I want to use it to add details to a few Boom shenanigans (i.e. Machine of sorts that uses Voodoo dolls needs a key and should show that it's an object, and not a door)

35 minutes ago, thiccyosh said:

My very specific question is, what is considered a door and what is considered an object according to Doom, and how is it handled in other complevels (Boom, mbf...)

"... activate this object" shows up if you use "S* Door (<key color>) Open Stay (fast)" actions - 99, 133-137.

Generalized boom S* Locked Door specials will show door message.

4 minutes ago, Doomy__Doom said:

"... activate this object" shows up if you use "S* Door (<key color>) Open Stay (fast)" actions - 99, 133-137.

Generalized boom S* Locked Door specials will show door message.

Thank you!

Hey. I'm in the process of making my first map and want to include a low fence/railing in one of the map's rooms.

First I thought to just offset the texture (which works in UBD) but then I noticed that the entire texture is visible through the floor in dsda-doom.

Is there a way to make lower half of the texture invisible in vanilla/limit-removing and if so, how?

3 hours ago, DoomPlayer00 said:

Is there a way to make lower half of the texture invisible in vanilla/limit-removing and if so, how?

 

Create two different sectors on either side of the line. Give the sectors two different brightness. For example, 160 and 161.

This problem apparently exists if the sectors on the front and rear of the linedef are identical. So you just need to create a small difference, like a difference in height or a difference in texture. In your use case, you can't use a different height or texture, so just change the brightness by +1 instead. A brightness of +1 is completely unnoticeable to the player, but it's enough to get the renderer to stop creating the texture bleed through.

12 minutes ago, RDETalus said:

 

Create two different sectors on either side of the line. Give the sectors two different brightness. For example, 160 and 161.

This problem apparently exists if the sectors on the front and rear of the linedef are identical. So you just need to create a small difference, like a difference in height or a difference in texture. In your use case, you can't use a different height or texture, so just change the brightness by +1 instead.

That did the trick!

Thanks for the help :)

Oh wow, I mostly play and map in GZDoom, and had NO IDEA this was an issue. That's great to know!

4 hours ago, ShallowB said:

Oh wow, I mostly play and map in GZDoom, and had NO IDEA this was an issue. That's great to know!

It's not a problem if your maps are only going to run on GZDoom. But if you intend for people to play with ports like Woof, PrBoom, DSDA-Doom, you definitely want to check your maps for this issue otherwise those players are going to see some messed up textures.

Question regarding vanilla Dehacked....

I wanted to try and put black glove sprites (by Grimm) in a wad, cause they look neat and its a nice little extra touch. However, I found that to get them working properly I had to duplicate a couple of sprites for the SSG from the IWAD, to prevent what I think were issues around frames/states - firing the SSG would break the game with an "R_ProjectSprite: invalid sprite frame" error - this is all very much guesswork though. 

I can get a set of custom zombie sprites working with the same methods (which is what makes me think I'm trying to do something potentially not doable), but these are more trouble somehow. With the duplicate sprites added it works in Chocolate with -file mywad.wad -as mywad.wad -deh mydeh.deh command line parameters, but with the caveat of duplicated IWAD entries, which I don't want. I can avoid all of this by just loading the black gloves wad alongside my wad with -merge, which will do the job, and the file allows redistribution (so could be packaged with the wad potentially), but is it possible to add these into my wad directly without causing a conflict with the existing states? This is a "would be nice", sure, but its gotten me curious. 

Also to get it working in DOS I presume I'd have to get to grips with DEUSF, but that's a bridge I can cross later. I've seen a couple of threads with similar questions before but none dealing with the player hand sprites, which makes me wonder if there's something specific with them that makes replacing them in vanilla Dehacked more problematic, as like I said adding a set of custom sprites for the Former Human gave me no trouble.

@Somniac just use merge. I'm not really sure what's up with -as because in the chocolate doom documentation it says "adds sprites to the IWAD" but in NWT it says "adds sprites to the PWAD." Could be a typo? Anyway you should be able to put everything in your pwad and then -merge it instead of -file.

For actual DOS, you either have to create modified IWADs using DeuSF or similar, or rename all the sprites and change the STRINGS table accordingly.

There are two HOM I can't fix in one of my maps. You need CheeseTex (my texture pack for a community project I'm running) to see all textures. It's still not finished and kinda buggy.

Happy birthday (Public).7z

cheesetex V1.2.wad.7z

@jo2ukegappy

I just tested and I don't see the HOM on my end. I used GZDoom though. Not sure what you're targeting.

Andarchitect

The DANDY Company

1 minute ago, The DANDY Company said:

@jo2ukegappy

I just tested and I don't see the HOM on my end. I used GZDoom though. Not sure what you're targeting.

 

Andarchitect

The DANDY Company

I forgot to say what port it happened in. Sorry. It works fine in GZDoom, but doesn't in any of the Boom based ports. DSDA, PrBoom+ and Woof all give me these two HoM. I'm losing my mind over this.

Sometimes when I use UDB, and try to drag a vertice, it simply will not allow me to.

Exiting and reloading UDB fixes this. I haven't been able to find a way to reliably replicate this. Knowing me, it's probably some setting I turned on by accident w/ a hotkey...

Anyone else ever have this happen? You're dragging vertices like normal, and then all of a sudden, you simply can't.

1 hour ago, jo2ukegappy said:

There are two HOM I can't fix in one of my maps.

From a quick look at the screenshots, those don't look like HOMs, they look like slime trails.

3 minutes ago, Gez said:

From a quick look at the screenshots, those don't look like HOMs, they look like slime trails.

Oh, that's exactly it. Makes sense. Any guides on how to troubleshoot and fix these? From what I understand they result from the nodebuilder rounding results when a vertex is outside of the original grid? So they are more likely to happen in angled linedefs, is that correct?

1 hour ago, jo2ukegappy said:

Oh, that's exactly it. Makes sense. Any guides on how to troubleshoot and fix these?

The only way to really fix them is to try moving around some vertexes near the slime trail by a few units, or adding new ones into the wall, etc., until you can get it to go away.

The first shot might also be a nodebuilder error (can't really tell), you can usually fix those the same way but also using a different node builder can sometimes fix the problem.

1 hour ago, jo2ukegappy said:

So they are more likely to happen in angled linedefs, is that correct?

Yep.

5 hours ago, plums said:

The only way to really fix them is to try moving around some vertexes near the slime trail by a few units, or adding new ones into the wall, etc., until you can get it to go away.

 

The first shot might also be a nodebuilder error (can't really tell), you can usually fix those the same way but also using a different node builder can sometimes fix the problem.

 

Yep.

I got it fixed, thank you very much! I'll implement it on the bugs section of my editing thread later. 

For my tutorial thread, I'm writing about port compatibility and good mapping practices. What are some examples of engine specific quirks and how to avoid them? For example, I know that in Zdoom based ports, lifts can be untagged, and they will be assigned to the back of the linedef that activates it, but this doesn't work in Boom based ports. They also use a skybox when you don't assign a texture to outer walls, but other ports need the ceiling to be lowered to the floor level. What other behaviors like these are there? Here is what I wrote so far:
 

Quote

"There are many source ports in use, but the most used is probably GZDoom,which is derived from ZDoom. GZDoom has many properties that other source ports don’t, so it’s important to pay attention to these aspects and to test your maps in different source ports, if that’s your goal. Below there is a list of ZDoom based behaviors that do not happen in other source ports.

 

Untagged Lifts
As mentioned before, In Zdoom based ports, if you make a lift and don’t the sector or the linedefs, they will assume that the lift is on the backside of the linedef and act accordingly. This practice of not tagging lifts is disencouraged, since it can lead to problems with lifts not working in other ports like PrBoom+, DSDA or Woof. 

 

Skybox from missing texture
In ZDoom based ports, if you don’t use a wall texture on the walls, and also use FSky_1 on the ceilings adjacent to it, the ports will use the skybox textures in game to fill those gaps. In the original game and Boom based ports, you have to make an “outer layer” and lower it to the level you want to make a skybox using the Sky hack. If you don’t, you’ll get a Hall of Mirrors instead.

5 hours ago, jo2ukegappy said:

For my tutorial thread, I'm writing about port compatibility and good mapping practices. What are some examples of engine specific quirks and how to avoid them? For example, I know that in Zdoom based ports, lifts can be untagged, and they will be assigned to the back of the linedef that activates it, but this doesn't work in Boom based ports. They also use a skybox when you don't assign a texture to outer walls, but other ports need the ceiling to be lowered to the floor level. What other behaviors like these are there? Here is what I wrote so far:
 

 

The skybox from missing texture in ZDoom is wrong. It only "works" if you have hardware rendering on, and even then it is very glitchy especially if there is something to be rendered behind the "sky" wall.

5 minutes ago, jaeden said:

 

The skybox from missing texture in ZDoom is wrong. It only "works" if you have hardware rendering on, and even then it is very glitchy especially if there is something to be rendered behind the "sky" wall.

Thanks, I just tested it and it was true, in software mode it turned black. I'll update it. Why does it work like that? Do ZDoom based ports have any special definitions that allow for that?