ZDoom

Jaska wrote:I was away from mapping since 8.10, so I changed nothing.. Updated the editor and when opening a map get these error messages:

Also on error log:
"mscorlib: Saman avaimen sisältävä kohde on jo lisätty."
some kind of translation:
"An item providing the same key has already been added."

Ooops, it's basically the same as the other crash, just for decalgroups this time, and not just for decals

Here's an interesting thing that I just stumbled across.

If I have the following in a scripts lump: it compiles without error. However, Script 18 does not appear in the drop-down list of available scripts when I edit the line properties and if I add it manually to the line, the error checker tells me "Lindef references unknown ACS script number "18"".

If, I remove the "//" on the line before "Script 18 (void)" the script still compiles and this time UDB can find it, adds it to the drop down list and doesn't flag up an error. The funny thing is, I worked on this map yesterday and also earlier today and I F4 checked it several times. I don't think that I changed anything about this script but this error started flagging up after I updated today. I didn't notice anything ACS specific in the update notes (though I could have missed it). The script was already allocated to a line in the map (has been for several days now) and the map had been given a clean bill of health by the error checker prior to today's update.

Now, I know that the "//" doesn't need to be there and, honestly, it's probably just there by mistake but something about it is making UDB not be able to find the script and therefore flag it as an error if it is placed on a line. I'm pretty sure this didn't cause a problem beforehand. So, it's an easy fix from my side but I'm flagging it here in case it indicates a bigger problem somewhere.

It's a tiny oversight in the parser. The issue is that there's a line feed right after the comment slashes - that throws the parser off, so it ready until the next line feed, so it thinks the "script 18 (void)" belongs to the comment. Fixed.

Thank you.

And now more of a question than anything - is UDB meant to scale sprites by reading scale values from their DECORATE? The reason I ask is that I have several items that use big sprites that are scaled down in game and they are often very big (presumably unscaled) in the 3D editor.

By way of an example:
2D editor:


In game:


3D Editor


Sprite

It's 48x78 - so not that big.
(the pickup floatbobs, so it is offset quite high X:24 Y:118)

DECORATE and it is loaded into UDB via a custom game config entry:
Things config Is it something that I have done wrong or is sprite scaling like this not supported?

Try setting the scale in the config, this should work:

Unfortunately that didn't work. UDB tells me that there is an error on the line with the spritescale entry: "Invalid value in assignment. Missing a previous terminator symbol?"

I just copied it exactly as per your post.

Interesting, the config parser actually requires floating point numbers to have the "f" affix to be recognized at all. So you'll have to use "spritescale = 0.3f;".

Works perfectly. Once again, Thank you.

Is there any way to change/improve the auto-filling of the sound sequence list in the sector properties? I need to load gzdoom.pk3 in my project for the actors but I don't really need most of the sound sequences defined therein. In fact, I have several of my own sound sequences and, unfortunately, many of them have similar names to some of the gzdoom defaults (Silent versus Silence, for example). What's more, there seem to be a lot of defaults in the list so I'm guessing that all of the sequences from gzdoom.pk3 get loaded, and not just the ones from the current game.

I tried renaming mine to group them all together on the list but I found that the sequence names are stored in the UDMF textmap, not the sequence numbers, so this messed up all my maps and I had to revert.



I'll know in future to name my sound sequences with something more identifiable, and with the same characters at the start for sorting, but I was wondering if there was anything that I could do to make the situation better with my current resources? At the moment, I keep having to open up my SNDSEQ lump to double-check the names of the sequences that I want to use so that I can pick them from the list.

No, there's no designated way to exclude them. What should work is making a copy of gzdoom.pk3 for development purpose and simply delete sndseq.txt from it.

I thought that might be the way to go. OK, thank you. I'll do that.

I just had a problem which I think shouldn't have happened.

I have a bunch of slightly complicated doors in a map in as much as they involve moving two lifts/platforms and one door every time that they open. As a result, each one is run by a script and, because the map is an older one and I didn't know about using line arguments to be variables in a script when I made it, each door has its own script.

Anyway, when the player approaches these doors, what he can see is the lower side of one of the lifts facing him. I realised that, now that I am working in UDMF, the texture would look better scaled to fit the available space. Fortunately, all such lines, and only these lines use the same texture. Easy I thought, just search for the texture and while all the lines are selected, edit their sidedefs (using the "edit selection" button in the search) to give them the required scale.

However, I hit a problem. Even if I don't go into the properties tag, doing the above sets all of the scripts on all of the doors (all 44 of them) to 0. By that I mean that the special (special 80, script execute) was still present on the line, but the script argument (i.e. which script to run) was set to 0. I don't know if any other line args were affected. Like I said, the script setup is such that every door has its own script, so only the script number arg is non-zero anyway.

This is clearly counter to how most things work in UDB where when editing a multiple selection where some of the options are set differently across the selection the values in the relevant fields get preserved unless they are explicitly changed.

I take it this issue isn't meant to happen?

Fortunately, I managed to catch the error quickly (more by luck as anything: I accidentally pressed F9 after editing, so the map started and I just happened to press one of the doors - which gave me an "unknown script 0" error). I then had to ctrl-z to undo my changes and then edit every single line separately to change the scale on the doors. Doing this did not zero the script number.

Hmm, for some reason for scripts it sets the first parameter to "0" when multiple different ones are selected, instead of leaving it blank. You can circumvent that by manually removing the "0" so that the field is blank, it'll then use the original value for each line. Might be related to https://github.com/jewalky/UltimateDoom ... issues/380

I love Ultimate DOOM builder; it's an amazing tool. I recently had one problem with it you may not be aware of. My current map wasn't close to origin (0, 0), so to appease my OCD I moved my rather large work to center. I did this by selecting all the sectors and dragging. A couple things I noticed:

A minor issue:

1. Some of the Things that were dragged within the sectors wound up off by maybe 16 pixels or so.

A bigger one:

2. All my multi-polygon sectors (sectors that have two or more unconnected polygons) split into a sector for each polygon.

Number 1 is easy to fix in my map. I caught the second too late to undo. I use a lot of dummy polygons for lowering floors or what have you. It broke my map quite a bit.

Thought you might like to know! Maybe I have a setting set wrong, but if so it'd be the default setting, and changing the default so that this doesn't happen would be wise I feel.

For number 2, if I understand your description correctly, I think these buttons on the tool bar are what you are looking for: