Ultimate Doom Builder

[boris]

This happens because UDB always rounds the offsets up - according to the comments in the code GZDoom apparently used to do that. While trying to fix it I ran into some unexpected behavior in GZDoom with upper/lower textures (where, in the case of a scale of 1.333333, it looks like an additional 1/3 of a pixel is drawn), so I'll have to check with the UZDoom devs to see if that's the intended behavior or not.

[Enjay]

Thanks for looking into it. Much appreciated.

[boris]

This is now fixed in UDB, but as reported here there will still be differences between what UDB shows and what [UG]ZDoom shows (at least in hardware renderer mode). But it now works correctly in other ports that support texture scaling.

[Enjay]

Thanks for pursuing it, and the UDB-side fix.

I've been following that issue on GitHub and raised one that may, or may not, be related myself ( 224 ) In fact, I think your issue was posted while I was typing mine.

[Enjay]

Does anyone have (or is anyone willing to make) an Ultimate Doom Builder script that can find sidedefs that have been scaled in-map (i.e. they have a scale factor other than 1 on the upper, middle, or lower sidedef (font or back))?

I've tried but I just don't know the syntax well enough and I have failed failed miserably.

The reason is that I have a few in progress maps where I have used some per-sidedef scaling in the map. To solve some problems, I want to use the ForceWorldPanning flag in the MAPINFO for these maps. However, if I just set this flag, then it will change how some of the textures appear in the map with respect to their offsets. Simply going through the map looking for errors manually would almost certainly mean that I miss some. So a script to find all scaled sides to allow me to specifically go and look at them would help.

Alternatively, a feature request: could SideDef Scale be added to the F3 search capability?

[boris]

You can find them when using the "Sidedef UDMF Field" search type and then using the field names. i.e. scalex_top, scaley_top, scalex_mid, scaley_mid, scalex_bottom, or scaley_bottom. To find them all you can use scale*.

But of course you can also use UDBScript, for example something like this, which will only print one line per sidedef:

Code: Select all

/// <reference path="../udbscript.d.ts" />

`#version 5`;
`#name Find Scaled Sidedefs`;
`#description Finds all sidedefs that have a scale set.`;

function checkSidedef(sd)
{
	if(sd === null)
		return;

	const info = [];

	['scalex_top', 'scaley_top', 'scalex_mid', 'scaley_mid', 'scalex_bottom', 'scaley_bottom']
	.filter(prop => sd.fields[prop] !== undefined)
	.forEach(prop => info.push(`${prop} = ${sd.fields[prop]}`));

	if(info.length === 0)
		return;

	UDB.log(`Sidedef ${sd.index} (on linedef ${sd.line.index}): ` + info.join(', '));
}

const lines = UDB.Map.getLinedefs();

if(lines.length == 0)
	UDB.die('The map has no linedefs');

const sidedefs = [];

lines.forEach(ld => {
	checkSidedef(ld.front);
	checkSidedef(ld.back);
});

[Enjay]

Thank you kindly.

I didn't even think about using the Sidedef UDMF Field. Or, rather, I did look to see if there was something already in the search options, but I didn't realise that I could use that one to search for scaling.

That being said, the script works perfectly and gives a nice clear readout of the lines that have scaled sidedef elements, and which elements have been scaled (and their scale values). So, it's definitely going to be very useful.

Again, thank you.

[Enjay]

Is the Sound Sequence Index field for the sector sound sequence override thing (ednum 1411) supposed auto-populate from a loaded SNDSEQ? If so, mine isn't:



Although it doesn't list any indices, if I type in a valid index (as defined in my SNDSEQ), it works in game.
(Perhaps worth pointing out that not all entries in the SNDSEQ lump have indices.)

If I edit a sector's sound sequence field, all the sequences are listed (along with the default ones). So, UDB must be reading the lump.



So, are the indices for the thing supposed to autopopulate, or am I just meant to know the numbers (because I can never remember them, and have to open up the SNDSEQ to find them every time)?

Why am I not using the sector field? I do, sometimes, but having a 1411 thing in the sector means it is easier to spot a sector where the sound has been changed from the default, versus the no-visual-clues sector field way of doing it.

[boris]

The drop down menus are fed by the different sources. The one in the sector edit form is from the SNDSEQ that got parsed, the one for the action arguments is just a static enum defined in the config. Currently there's no way to assign the loaded SNDSEQ to an action argument.

[boris]

How does that thing work, anyway? As the argument is an int, is is just the index of the order of definitions in the SNDSEQ lump? They don't seem to have an id, do they? So does that mean if you add/remove items in the SNDSEQ at the beginning or the middle a sector will suddenly make another sound when using thing type 1411?

[Enjay]

A lot (maybe all) of the default ones don't have an index (xZDoom "knows" how and where to use the defaults), but if you are defining one yourself, you can give it an index (indeed, you need to to make it useable for some applications). You can specify a DOOR or PLATFORM index. I usually give any sequence I have defined both which means I can use them for either a door (ceiling) or a platform (floor). So, for example, this definition:

[Edit: There's also the Environment Index type which I have never used. I think it's used by Heretic for its environmental ambient sounds.]

Code: Select all

:WDOOR1
	DOOR		5
	PLATFORM	5
	attenuation STATIC
	playuntildone	WDOOR
	stopsound	WSTOP
end

has index 5 (for both ceilings and floors). That means you can place it in a map as thing number 1405, or use thing 1411 and set the first arg to 5 and it will work too.

In a similar way to how the first 64 ambient sounds get auto-allocated an ednum, the first 10 sequences get one too (from 1400 to 09). After that, you need to use thing 1411 and put the index in the thing's argument. I don't know if there is a limit, but I currently have around 40 defined (explaining why I can never remember them), and they all work fine. I don't know why ednum 1410 is skipped.

I have no idea what happens if you give a definition two different indices for DOOR and PLATFORM. Maybe it takes up two index slots?

You can also use the index number when you are defining polyobjects. e.g. the Sound Number arg on line type 1 (PolyObject Start Line) takes an index from the SOUNDSEQ definition. So, if it was possible to auto-populate that argument too it would be very useful because I always have to look that up in my SOUNDSEQ too.