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

Yes, I would recommend ZDL to properly manage your load order. for the files, look through the sprites and sounds for the ones you want manually.

Godfather38 said:

Yes, I would recommend ZDL to properly manage your load order. for the files, look through the sprites and sounds for the ones you want manually.

Ahh, so there IS a load order. I'm used to that being the case with games like Skyrim, in which mods loaded last in a last override mods that are loaded earlier, but I assumed that Doom had a simpler structure that wouldn't necessitate something like that. Thanks, I'm glad that I asked.

And that's a good recommendation. I'll scour through the files to see if I can find the sprites that make up the Playstation Doom logo.

Forget about the reverbs -- they're not a property of the sounds, they're baked into the maps. If you play the PSX TC maps, you'll get reverbs, even with the normal PC Doom sounds; and if you play a non-PSX TC map, even with the PSX TC sounds, you won't get reverbs.

I understand that it's different for everybody, but what's the best order to build a map? I plan on first making the basic geography and mapping, adding enemies to playtest it, then going and properly texturing everything, and then going and tweaking lighting/geography to make rooms seem a bit more unique (i.e. slightly angled rooms as opposed to square rooms, slight indents in some of the floors, that sort of thing).

What do you guys usually do?

Seems I am an odd one, but I map rooms in their entirety, including detail, monsters and secrets. While doing this I have the time to think about how the next couple of rooms should be built and what the layout should look like when I am finished. This time spent while making the detail of a room lets me construct some very unique ideas and interesting layouts which are by-products of the detail itself.

Before I start I obviously think about what the main objective with the map is, for example "In this map I want to make a very interconnected tech base in which the player has to find all three keycards to gain access to the final room".

I find when I pre-make my layout, the map itself suffers from looking generic, while the layout doesn't particularly play better than if I started without planning the layout.

This question has been asked many a time on DW, the only thing you can take away from the thread is that there is no 'standard' or 'proper' way to map. Do what you do because that's what helps to define your own style. :)

Cool, thanks! A more technical question; how can I make a lift in its "lower" position as a starting position? I.e when you run onto the linedef it raises the sector as opposed to lowering it; I'm using the tutorial over on http://doomwiki.org/wiki/Making_a_lift. Can anyone suggest a way to make an opposite sort of lift?

EDIT: Hey, I'm a dingus! For others with the same question, using Action 128 on your linedef will do it!

You can use one of the "Floor Raise to Next Higher Floor" actions, but the floor won't automatically lower again, you'll need to use another "Floor Lower to Lowest Floor" action to lower it. There isn't any "opposite sort of lift" action among vanilla Doom's predefined actions. Well, there is a "Floor Start Moving Up and Down", but it's pretty slow and its effect is perpetual until you trigger "Floor Stop Moving".

Thanks; yet another question. I'm making a teleporter, and the ground texture is unaligned by about half. How can I align the texture manually; I can't really edit the alignment like I can for walls and linedefs.

In Doom format, you indeed can't offset flats, so you need to offset the teleporter itself (or make an offset flat graphic and put it to your wad as a new flat). Only if you were mapping in UDMF format (which implies mapping specifically for ZDoom), you could offset flats.

untilitdies said:

I understand that it's different for everybody, but what's the best order to build a map? I plan on first making the basic geography and mapping, adding enemies to playtest it, then going and properly texturing everything, and then going and tweaking lighting/geography to make rooms seem a bit more unique (i.e. slightly angled rooms as opposed to square rooms, slight indents in some of the floors, that sort of thing).

What do you guys usually do?

Try different things. Find out what works for you.

With the process you have in mind I'd strongly recommend choosing the textures and drawing some facsimiles of proper room shapes for what you call "the basic geography and mapping", sort of like you're making an actual map but with very low detail. Going from monotextured squares ("layout" in its purest form) to anything half-decent visually is a nightmare. And since areas in general are highly dependent for their identity on which textures you use, you are probably going to end up with something quite generic-feeling, as dragonfly suggests, if you ignore texturing or shaping or both.

But yeah, you really have to try different things. Every time I thought a certain process was the holy grail, I eventually discovered downsides or ended up learning things that made an entirely new process more effective. What more, different processes can be better for different types of maps or even different types of areas.

scifista42 said:

In Doom format, you indeed can't offset flats, so you need to offset the teleporter itself (or make an offset flat graphic and put it to your wad as a new flat). Only if you were mapping in UDMF format (which implies mapping specifically for ZDoom), you could offset flats.

Or, still using ZDoom you could use the Hexen format and use two ACS commands:

Sector_SetFloorPanning

Sector_SetCeilingPanning

...but there's no point using the Hexen format over the UDMF format.

Dragonfly said:

Or, still using ZDoom you could use the Hexen format and use two ACS commands:

If you're perverse enough to try, you can use Boom displacement scrollers.

Gez said:

perverse

Interesting, yet correct choice of word.

I didn't know about this method and after reading about it I'm not in a hurry to try it out either.

I'm getting this "Parent type 'ShotgunGuy1' not found in KeyDropShotgunGuy" -error when trying to run my map.

Actor KeyDropShotgunGuy : ShotgunGuy1 260
//$Category Keys
{
	dropitem OneUseCard
}

"ShotgunGuy1" is defined in an another wad which I'm loading up at the same time.
Do I need to define "ShotgunGuy1" somewhere else?

illuknisaa said:

"ShotgunGuy1" is defined in an another wad which I'm loading up at the same time.

Your error message indicates that this statement can't be true. Make sure you actually load the other wad, and that ShotgunGuy1 is actually properly defined in it (when you run the other wad alone, you should be able to summon ShotgunGuy1).

Also the "//$Category Keys" should probably be within the brackets, I'm not sure if it works outside of them.

scifista42 said:

Also the "//$Category Keys" should probably be within the brackets, I'm not sure if it works outside of them.

As far as ZDoom is concerned, it should work; however it might confuse the parsers in Doom Builder and/or Slade.

scifista42 said:

Your error message indicates that this statement can't be true. Make sure you actually load the other wad, and that ShotgunGuy1 is actually properly defined in it (when you run the other wad alone, you should be able to summon ShotgunGuy1).

Also the "//$Category Keys" should probably be within the brackets, I'm not sure if it works outside of them.

I can summon "shotgunguy1" just fine.

They it must be that you're not actually loading the wad with ShotgunGuy1 together with the wad with KeyDropShotgunGuy. What exact way are you launching them?

Shotgunguy1 is defined in PB.pk3. Canyon.wad is the wad I'm working on. Dummy. wad is just a replacement for pb.pk3 because pb.pk3 is only loaded when testing.
Lauching via builder or zdloader.

Check the startup log (it's where the error message appears) if it contains a line (should be near its beginning) with the following text:

Adding C:/Users/Mikko/Desktop/Doom/PB.pk3, <some non-zero number> lumps

If it doesn't, it indicates that the given file path might not exist, or that there might be a problem with the custom contents you put in the "Parameters" box (there is "-file", then "+map", then "-file" again, and I'm not sure if that works).

But whether it does or doesn't, try to change the parameters so that PB.pk3 will be loaded before canyon.wad.

Also check if the startup log contains any additional complaints, for example about conflicting actor numbers. Particularly, the actor number of ShotgunGuy1 and the actor number of KeyDropShotgunGuy should be not only distinct from each other, but distinct from numbers of all other actors in the wads/pk3s you're loading.

I got it fixed.
It was apparently something to do with the load order. I also needed to move the "dropkeyshotgunguy" decorate definition into it's own resource and make it load after pb.pk3

illuknisaa said:

"dropkeyshotgunguy"

I know it's late, but it could have been easier to trigger an ACS function to spawn a keycard on the shotgunner when they die.

For reference:

Set up a shotgunner to have a thing tag (in this example, 1), and to trigger a script on death - Action 80 (again, 1 in this example). [image reference] [wad example]

Now kill the shotgunner for a red key.

Script 1 (void) {
	Thing_SpawnFacing(1, T_REDKEYCARD, 1, 0);
}

Dragonfly said:

I know it's late, but it could have been easier to trigger an ACS function to spawn a keycard on the shotgunner when they die.

For reference:

Set up a shotgunner to have a thing tag (in this example, 1), and to trigger a script on death - Action 80 (again, 1 in this example). [image reference] [wad example]

Now kill the shotgunner for a red key.

Script 1 (void) {
	Thing_SpawnFacing(1, T_REDKEYCARD, 1, 0);
}

Actually I did this first but pb.pk3 changes how monsters die. They get like replaced with a new actor and when the script tries to execute it won't find the original thing to actually place the key on top of.

I also find this "dropkeyshotgunguy" easier to use. I don't have to set up multiple scripts for multiple actors and it is easier to spawn via a script.

Gez said:

Forget about the reverbs -- they're not a property of the sounds, they're baked into the maps. If you play the PSX TC maps, you'll get reverbs, even with the normal PC Doom sounds; and if you play a non-PSX TC map, even with the PSX TC sounds, you won't get reverbs.

Aw, that sucks. I don't suppose it's easy to add reverb to my own maps, is it?

Thanks for the response, I suppose that leaves only one or two things for me to have to figure out.

miketheratguy said:

I don't suppose it's easy to add reverb to my own maps, is it?

It is relatively easy if you are using G/ZDoom.
Download and play EAX.WAD.
Then open and read http://zdoom.org/wiki/REVERBS .
Then load EAX.wad into GZDoom Builder while at the same time having open reverbs.txt from g/zdoom.pk3.

That should show you the way.

I enthuse you add reverbs to your maps. Something about maps that use reverbs effectively (but not excessively) make me smile a lot more than they should.

Is it possible to edit vertices' absolute height via acs?

Vertices don't have height, so no.

In ZDoom UDMF, vertices can have floor and ceiling heights, this is one of the ways in which you can define slopes. However, ZDoom slopes aren't dynamic -- you can't change them at run-time -- so even if it was possible to change vertex height with ACS, it would not have any effect.

Gez said:

In ZDoom UDMF, vertices can have floor and ceiling heights, this is one of the ways in which you can define slopes.

First multiple sector tags belonging to a single sector, then vertice heights to define slopes, UDMF keeps surprising me. :)

Slope">

Slope said:

it only applies to triangular sectors, and if only some of the vertices have a height given, the others will use the "native" height of the sector.

This sounds like an unclean implementation, though. What about a new sector property ("svertex" or something) which would define the vertex (with a zfloor/zceiling set) that the sector is supposed to slope towards? Sectors with this property set would slope, and other sectors would not, regardless of their number of vertices.