Ultimate Doom Builder

[boris]

I guess that could be added, although it's somewhat redundant because of the "+++" notation (which the fog density input box doesn't support at the momoent, though ).

Stuff like that is very easy to add in UDBScript:

Code: Select all

`#version 4`;
`#name Fog gradient`;
`#description Creates a fog gradient from the first selected sector to the last selected sector.`;

if(!UDB.Map.isUDMF)
    UDB.die('This only works on UDMF maps');

let sectors = UDB.Map.getSelectedSectors();

if(sectors.length < 3)
    UDB.die('You need to select at least 3 sectors');

let startfogdensity = sectors[0].fields.fogdensity ?? 0;
let endfogdensity = sectors[sectors.length-1].fields.fogdensity ?? 0;

let stepsize = (endfogdensity - startfogdensity) / sectors.length;

for(let i=1; i < sectors.length-1; i++)
    sectors[i].fields.fogdensity = startfogdensity + (stepsize*i);

[simc]

The Draw Voodoo Doll Closet script gives an error if the Looping is set true:

ScriptOptions is not defined
at \udbscript\scripts\Examples\Geometry\voodoodollcloset.js:152:2

It's missing the UDB. prefix?


And sorry for asking, but as there is Reorder Things Indices script, would it be possible to create a similar script for linedefs too? But move the renumbered lines to the start (or end) of their own index instead? Certain Doom/Boom linespecials rely on the next sector behind the lowest numbered line as their target reference.

[boris]

The Draw Voodoo Doll Closet script gives an error if the Looping is set true:

ScriptOptions is not defined
at \udbscript\scripts\Examples\Geometry\voodoodollcloset.js:152:2

It's missing the UDB. prefix?

Yes, it was a missing UDB., thanks for pointing that out.

And sorry for asking, but as there is Reorder Things Indices script, would it be possible to create a similar script for linedefs too? But move the renumbered lines to the start (or end) of their own index instead? Certain Doom/Boom linespecials rely on the next sector behind the lowest numbered line as their target reference.

There's no easy way to do it. The thing reordering script uses a trick that won't really work with linedefs. And due to the way UDB handles map elements the order will not be static anyway and might/will change when stuff gets deleted.

[3t0]

Hello,

after some hiatus reporting back.

I am on weird Linux (for the curious Void) running in handmade container (my own tools), with ZFS. OpenGL through nvidia works flawlessly and editor seems pretty stable (I have yet to hit some bugs, like the ones mentioned in this post - knocking on wood).

I haven't had too much time for mapping before, but anyway, at least I rebuilt occasionally. Some weeks ago I started experimenting with UDB more again.

What is pissing me off to no end, is missing some of "good old" interface design. I tried to retrain myself really hard and got somewhat proficient with stuff, but I am really missing the right-click context-menu, like one from 3DS MAX or other "old" software. I know cool stuff is being lobotomized for kids these days, but please have mercy on this [censored word] elder.

Would it possible to have something like that old school toggleable context menu, or there is no way?

I would gladly welcome popup menu with most sensible options (wtr mode selector), even famous max quad, over weird properties dialog popping up currently, any time.

Dialog is not that big quality of life improvement, plus I am using tiling window manager (yeah, I AM THAT KIND OF A WEIRDO) and .net runtime seems to be confused whether dialog should be "dialog/toolbox" style or "window style". Anyway that is partly my problem, so I hacked around of that, but it still kinda takes you out the flow, when it breaks focus (both literally and programmatically).

If this is too alien request for the direction software is sailing to, please disregard.

[nova++]

I won't opine on the interface parts of the post, but I am curious for more details about the procedure of getting UDB running on Void since that's what I'm on too, and couldn't manage to get it to build when I tried a few weeks ago. In general, I've always had a hell of a time getting UDB to cooperate in the slightest on linux and have usually ended up just giving up and booting into windows when I want to do any serious mapping...

[3t0]

... but I am curious for more details about the procedure of getting UDB running on Void since that's what I'm on too, and couldn't manage to get it to build when I tried a few weeks ago.

Well here is my original getting to run post. I admit it is some week since I tried full CLR binary rebuild, but at least I recently re-pulled-in whole userland due to recent nvidia betises (again) which broke OpenGL rendering path, and UDB still works(!).

The notes/ubd-install-minimal-working-package-set.execline dump in that post is what you are after and it should be easily adaptable to your needs ... but read following part first.

Firstly honest disclosure, even among Linux users I am extremist, that old grumpy guy who always turns debate to old times being better, ridiculing new and stupid, chameleonic BSD user in fact, and my this old stone heart of mine is not swayed by "teh new coolest soy infested shit tech" that we (in the Linux world) are drowning more and more into each day ... until no living soul will remain - it truly fucking is full on invasion from hell. So if you are willing to know more, I am of course open to sharing, but it might not be to your liking.

Thus my direct advice to you would probably be skewed too much in my favor (I run lot of my own tools) and thus perhaps even useless (?) and/or you might be lacking in experience with support infrastructure around this - no ad hominem is intended - it's just how it usually is (talking from experience).

But overall "very vague guidelines" would be like this:
- first isolate
- repetitively try until it builds
- run

Mono is quite a big hunk of bytecode blobs, integration and other crap (several gigabytes), and if you use machine for your daily driving like me, you don't want all that crap to infest your "host" install and break it. more over as you main environment drifts the way youw ant it to be this might not be to UDB liking. So first isolate your UDB stuff.

If you know chroot, you should immediately get where am I aiming with this. Modern kids call it "containers" now, on FreeBSD we call it jails. Since 99% of linux containerisation crap sucks (and is being designed and implemented by 10-yo retards) I have my own crap for dealing with that stuff, but rudimentary chroot should be enough to isolate something like UDB.

I am using ZFS underneath so I can snapshot the UDB "chroot" "jail" anytime and return it to working order without messing with tars too much (and other sillyness - it is 2022 after all).

So install your chroot with the packages listed in my dump, maybe some went missing or changed names, it is a year old instructions after all, but I believe you are intelligent enough to sort that out by yourself. Once you have base installed, create your user under which you plan to build and use UDB under and then I strongly suggest you to snapshot the whole jail (zfs snapshot or tar it without /proc and other magic dirs) so you can revert any time to working order.

Then clone the UDB github project (maybe snap it gain - depends on your situation and space availability (if useing tars)) - and try to build it. They (UDB) used to have pretty good instructions for building so you can just follow them - I remember they worked for me very well after couple of tries. Remember this net stuff uses its own thing for building, there is no make if I remember correctly.

Once you succeed in building, you can try to run the UDB, by means of chroot again. Forward your current x socket into the jail, enter it with chroot, switch to your UDB user and try to run it. As it uses OpenGL, you will naturally, need to have proper devices forwarded into jail's /dev (depends on your setup and machine - probably out of scope of this intro) - with that done the thing should run.

Because you used jail approach, you can now mess with it backup it, restore and revert to it any time you want, and your main "host" should be unaffected. That's all.

If anything what I am writing above is unclear to you, maybe you should back off and study concepts mentioned more before attempting. Maybe it seems like too much hassle, so pick your own method but then you are on your own.

In general, I've always had a hell of a time getting UDB to cooperate in the slightest on linux and have usually ended up just giving up and booting into windows when I want to do any serious mapping...

I am windows free 20+ years now, so that would be feat really hard for me to do, windows gives me creeps (no really I get physically sick every time I deal with windows). But I trully understand and feel you.

For quake we have Trenchbroom, which is simply phenomenal. Not so much for doom.

There are dozens of editors and most of them are pretty good for old-school mapping (and believe me I tried them all), but they all suck especially wtr modern engine features. At a time I hoped SLADE3 will "get there", especially since I saw eevee patches, but it is 7 years now (fuck time files) and shit is still not done - UDB works so I refuse to wait anymore.

[nova++]

I did manage to get it building this time (I am not entirely sure what I did differently this time, but still), but I am quickly remembering all the trouble I had the last time I had it working too... sluggish and unresponsive, likes to completely trap my inputs especially in 3D mode as it spends 20-30 seconds trying to load the UI, lots of crashes or at the very least semi-recoverable errors, as well as a total inability to build nodes out of the box since the included builders are windows only, so I guess I'll have to find/build a linux one too (or install wine and try to alter the commands in the config)

Maybe I should just run a windows VM or something...

[Rachael]

Romero did that, afair. He uses Mac and just ran GZDB using Parallels. But I think that was before it became UDB.

I never could get it running, myself, I am sure with enough effort I could.

Much as I am really not too fond of 3t0's condescending references to intellect, he does have a good point about chroots: You can build any debian-based chroot very easily on pretty much any distro using the "debootstrap" utility (you'll have to download and/or build that on your own if you're currently using a non-Debian based distro), which you could use to build a Linux Mint chroot. And it's fairly easy to mount that to a virtual drive (i.e. loopback) device so that you can do backups on its working state if you please, but that is optional - a folder will suffice. The reason why I suggest Mint is because that is the distro upon which UDB was developed, so you will probably have an easier time there. Bonus: You can install wine into the chroot without it affecting your main system.

Anyway, all the external utilities that UDB uses have Linux replacements. You should not even need to install wine at all. You will have to do some mount --rbind's to get the chroot running correctly, I at minimum bind /sys, /proc, and /dev when mounting my dual-booted Linux install as a chroot inside WSL2.

[3t0]

I did manage to get it building this time (I am not entirely sure what I did differently this time, but still), but I am quickly remembering all the trouble I had the last time I had it working too... sluggish and unresponsive, likes to completely trap my inputs especially in 3D mode as it spends 20-30 seconds trying to load the UI, lots of crashes or at the very least semi-recoverable errors,

This seems more like graphics subsystem or configuration errors/issues. Two major questions are:
- what graphics core/stack are you on: xorg or wayland?
- what graphics card are you on? nvidia, ati or intel?

On my xorg + nvidia setup I am getting consistent FPS, no hiccups whatsoever. But I fear the day legacy drivers will stop being pushed down.

Also my "gui" session is pretty barebones and handmade too, but I imagine if you are using some modern pre-made crap like shitty gnome, it might wreak havoc on your graphics stack (especially under XOrg I guess).

<EDIT>
Thinking about more, it might be just a stability issue. Sadly there seem to be no tagging system in place with UDB, but have you tried moving a bit back in commit history for a change? Some commits might be borky or not build at all. It would be cool if UDB team added at least stable tags. That way we source builders could rewind quickly to stable releases, at least.
</EDIT>

... as well as a total inability to build nodes out of the box since the included builders are windows only, so I guess I'll have to find/build a linux one too (or install wine and try to alter the commands in the config)...

Yeah I got that too.

At a time I got standalone repo of zdoom GL node builder working, I think, I don't care anymore.

I came to conclusion node building is overrated. Make no mistake, if you want to have your wad cross-engine compatible, maybe it's worth the time spent, but that is not what I am interested in. You can go completely node-less with modern engines. IMHO it's relic of the past, worthwhile maybe for few people who play on ancient builds?

Both gzdoom and k8vavoom have builtin node builders, and this is not quake, so building is pretty damn fast even for huge levels. In my experiments, it is completely safe to disable it in UDB, and go completely node-less, but what works for me, might not work for you.

But by doing things my way, you are also stress testing engine builtin node-builder each level load, which is IMHO more productive use of your CPU time.

... Maybe I should just run a windows VM or something...

If you have desktop, go for it. Few of my colleagues are "still relevant games" gamers (ie they play new/modern games from Steam on virtualized Windows). And they are like real "Gamers" obsessing over FPS and unimportant shit. I don't see point.

Although I have Steam (and 99% of shitty windows games works 99% of times through Proton no problem), at heart I am GOG person and 99% of time I play Linux native games only (in general, if a game doesn't have Linux port, it's not worth my time anyway).

I can even tolerate tragic 20 FPS GZDoom pushes on this machine in Elementalism. Yeah. That kind of fuck I am.

[spolier]I am especially amused by teams that have MacOS port but don't have Linux port. It's like: "Come on idiots, you made 99% of job porting your shitty game to Job's deranged unix, yet you are unable to pull through the final one percent of the last mile to make it work on Linux? You won't be getting any pennies from me".[/spolier]

What I personally saw working best was dedicating second GPU to windows VM through PCI passthrough. This made even shittiest things run in VM go butter smooth (you should CPU/NUMA pin the VM, if you can, too, for maximum performance) no issues whatsoever. One of guys on my team is small fish counter strike player, and such setup worked perfectly for him (framerate wanking and everything). Plus you get advantage from Linux advanced storage solutions and filesystems for your VM.

My brother runs Doom Eternal in Proton on some kind of ryzen with 4 yo amd card, and with most normal people, nobody minds the 10 - 20 fps framedrop at 150 fps, trust me.

But if you really want to (use windows for example ) and you can, you should certainly pursue this option, it is really great experience system configuration wise.

For me it's more important to run this on Linux and report back issues so UDB on Linux gets better. So far I have no issues.

[3t0]

Eh, I had my wordy second reply written, only to lose it with expiring session , I have been punished now...

Romero did that, afair. He uses Mac and just ran GZDB using Parallels. But I think that was before it became UDB.

Good to know, thanks, forgot that tidbit.

Much as I am really not too fond of 3t0's condescending references to intellect,...

Please excuse me Rachael, nova++ and other readers, for my probably rude reply!

It was not my intention to offend you in any way, it was just reflexive reaction. I don't have very good soft skills, and given the direction world is taking these days (up to 11 in tragicomically ridiculous, so please buckle up), I am getting a bit tired of it. Not to give up, god forbid, it's just that condescending sarcasm is my normal reaction to anything these days. So sorry if I hurt you in some way, it was really not intended.

You are of course right Rachael, I don't know you guys, I have no clue about your skillset, so please don't let it bother you.

It's just that I am working for smallish cloud operator, i.e. we run containers for clients (the other side), and also lead few admins of my own, and human resource material is getting more and more lacking each year. Ridiculously lacking, I would add. Then I am called-in to analyze client's container problems, and seeing the image, investigating the issue, I ponder if billions years of universal evolution were really intended to produce entropy soup I am watching with my very eyes.

So not really an apology, but please take it as an explanation, at least.

...he does have a good point about chroots: You can build any debian-based chroot very easily on pretty much any distro using the "debootstrap" utility (you'll have to download and/or build that on your own if you're currently using a non-Debian based distro)...

That. If you combine it with zfs, or btrfs (not really a fan, but it should be more or less equivalent), you get the data isolated at filesystem level too (without need to spelunk with loop devices and whatnot) and you get filesystem snapshots for free, so you can always return to @this-udb-verison-wroks-best-for-me snapshot.

On btrfs, I strongly suggest you to investigate snapper, as it can meta-annotate otherwise prety barebones btrfs snapshots, and it can also restore them into target location (btrfs doesn't know to do rollbacks natively).

debootstrap is a way, if you can stomach last centry theories of package management (not really a fan), as apparently UDB was ported on debian-like os, but as Void guy, I think you are more interested in rolling (more future proof).

Although all major (but stale) package management tools: apt, yum/dnf - can manage chroots, its quite a far cry when compared to something with more modern design like pacman, xbps or pkg.

Given Void is by default built in containers itself, they have some pretty good tools for thin mutable containers, and xbps is also very container friendly:

Code: Select all

: cat /jails/udbjail/xbps-install 
#!/usr/bin/execlineb -s0

env XBPS_ARCH=x86_64

xbps-install 
  -R https://alpha.de.repo.voidlinux.org/current
  -r /jails/udbjail/chroot 
  ${@}

I have similar wrappers for other major xbps tools, I bet you get the gist. For chroot + unsharing from main host namespaces, check out xbps-uchroot(1) or xbps-uunshare(1) which is very very minimal (compared to docker). If you don't mind namespace isolation chroot(1) will be sufficient.

Keep in mind in such setup xbps does not even reside within chroot(! - it's your "host's" xbps doing all the work). Whether to isolate other namespaces is your call, security wise.

Anyway, all the external utilities that UDB uses have Linux replacements. You should not even need to install wine at all. You will have to do some mount --rbind's to get the chroot running correctly, I at minimum bind /sys, /proc, and /dev when mounting my dual-booted Linux install as a chroot inside WSL2.

Both acc and gl compatible node-builder have external repos on gzdoom's github (I think) so there is everything you should need.

Regarding mounts you don't need to mount/have /sys, as you are not running udev in container, and UDB has no business to query hardware.

/proc is needed to due to Mono's .net CLR runtime self refrerential magics and binary loading, whether to isolate the PID namespace is your call.

/dev needs to be rudimentary only, but you need to pass in gfx related stuff (depends on device, nvidia/amd/intel, you have) for OpenGL to work reliably.

[boris]

John Romero used DB2 to create Sigil: https://twitter.com/romero/status/688177700742139904

[Ultimate Freedoomer]

Possible ability to open maps from PK3 files added in future?

[Kappes Buur]

Possible ability to open maps from PK3 files added in future?

Never say never.

However, this had been requested in the past, the answers was always a resounding no.

[doomzie]

Some feedback for the great people who are developing this editor. Thank you so much for your ongoing effort.

I was happy to find this editor was "supported" natively on Linux, so I gave it a go.

Here's my test results with: Core i9/Nvidia 1080Ti/Debian 11.

Ultimate doom builder R3274 Linux

$ uname -a
Linux lbox 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux

$ wine --version
wine-5.0.3 (Debian 5.0.3-3)

$ mono --version
Mono JIT compiler version 6.12.0.122 (tarball Mon Feb 22 17:42:49 UTC 2021)

Compilation was done by cloning the github repo and adding the special mono-complete repo for Debian.
Was a bit tricky due to complications with existing mono packages on my system.
It resulted in a mono runtime conflict and broken packages for mono.
I managed my way out of it though.


When running the application natively on Linux, I have the following immediate problems:

1. There seems to be an upper toolbar next to the menu items (next to 'Help') which does not display icons/information correctly and is not clickable/usable. Only after checking the Windows version through Wine I was aware of the functions that are present in that toolbar. The toolbar displays icons/options properly for the 'Draw Lines Mode' and others. However for the 'Vertices, Linedef, Sector, Things mode' it displays an empty toolbar most of the time, for some options the comboboxes are displayed, but not the icons/buttons. This toolbar is probably required if you want to make maps properly? I've seen for example the 'Make Door' option is in that toolbar, but I can get around it by assigning a key. I'm not sure how problematic this is. I don't really know what I'm missing here.

There are gaps in the menu Options 'Edit' and 'Mode' when you click on them. It's like some options are not listed in the menu list or there is just an empty gap. I don't know if a function is missing or not (it seems they are missing). Perhaps I should also mention that I installed the gtk2-engines and murrine theme packages as it was complaining about that in the terminal. It however did not seem to change anything as far as I can tell.

There are missing icons in the left toolbar below 'Visual mode' (after crosschecking with a native windows version in a VM):
a. Pick Sector/Light Color : hot key K
b. Apply Directional Shading : hot key Ctrl+L
c. Randomize : Ctrl+J
Someone who launches UDB natively for the first time (on Linux) is unaware of what is missing in the toolbar/menu or how to access them through hot keys.
After checking I realize that these correspond at least with the missing 'Modes' menu options.
I confirm that (via the hot keys) these functions work correctly running UDB Linux natively, so it's purely a toolbar related issue.

Minor misalignment of the right toolbar, the text of the labels is slightly cut off.

2. Node builder error every time I save; "Unable to build the nodes: The nodebuilder failed to build the expected data structures". I don't know if there's an option somewhere to make it point to zdbsp installed on your system? How does UDB Linux access zdbsp? I've tried different options in the Game Configuration menu, but I always get the error. The zdbsp (1.19) source however compiles without any hassle on my system. Placing it in /usr/local/bin also makes no difference (just a test). UDB seems unaware. I don't know the implications of that, can I still do the required node building for my custom wad using my local zdbsp? It's weird that this does not work via UDB Linux, as zdbsp is natively supported on Linux. Is this an issue that is being looked at for the Linux version or what exactly is the issue here? I can't find any instructions on this for Linux. Am I doing something wrong?

3. Visual Mode: I've been testing for two weeks now on my first ever doom map and the usual behaviour is that it launches the visual mode quickly and I can practically immediately move the mouse around, but in 80% ? of the cases I cannot move around (SDEF keys). Waiting long, clicking, key input has no effect. Nothing happens anymore, except spinning around and loading textures. The textures in the bottom pane load quickly and UDB shows a green icon after the texture is loaded. I can continue to pan around and the textures load correctly. However, I just can't seem to move around (SDEF) and the worst part is that I can't exit the visual mode anymore as it seems to completely ignore key input. Now if this was consistent I would say it's just not supported (yet), however I've been testing a lot and it does fully work sometimes, which is baffling to me. Sometimes I go into Visual mode and I can move around immediately. If I do it again, I'm stuck. There's no indication whatsoever of why this happens. Mind you this needs to be Ctrl-C killed in the terminal that launched UDB.

Even when it works and I can traverse the map, it must be noted that there is a structural problem that is consistent in Visual Mode. As soon as you right click a texture in visual mode, the pop-up comes up, but I'm unable to select a texture. The mouse input remains locked in the visual mode, moving around its axis. At this point you're stuck and need to kill the application. This always happens so I make sure not to use this.

In the current state I basically have to avoid checking my editing with the Visual Mode as much as possible.


I figured I'd move on to testing UDB via Wine on Linux and see how well it's supported there:

Ultimate doom builder R3949 x64 Windows (on Linux via Wine)

At first glance, the builder/editor itself seems to run fine in a win64 wine bottle with command 'mono Builder.exe' or 'wine Builder.exe'.

A minor issue is that you can't launch/test the wad via the interface as it requires the windows binary of gzdoom. Setting it to a custom folder with a windows binary does not help as it requires a win64 prefix, which I can't provide through UDB (can't link to script with win64 wine prefix). This is obviously a minor issue, I can easily test it via a script that launches my custom made wad. If anyone knows how to deal with this, please let me know?

As far as I can tell, the visual mode seems to work fine, but I haven't tested visual sloping/arching yet. Is everything in Visual Mode supported via Wine?

I'm still investigating/testing to see if the application is really fully functional under Wine as I'm not familiar with UDB, especially its advanced functions (like visual slope/arch). For example, am I supposed to see a 3D floor icon on the left, because running UDB through Wine I'm not seeing it (but in the native Linux it's there). The 3D floor plugin seems active in the preferences menu, but I only hear a beep trying to use it (via hotkey). I've used it multiple times already in UDB Linux native, so I think it should just be there.

Also, are the release numbers different for win/linux version?


Last resort, running UDB in a VM:

Windows 10 VM on VirtualBox 6.1 (with 3D acceleration support on and plenty resources):

No support for OpenGL, however there's Mesa 3D for windows, which supposedly works as a work-around for software that requires 3D rendering.
However, upon testing, entering the Visual Mode did work, but was unusable as the slightest mouse move results in wild uncontrollable spinning around. Basically worse than above options. I don't know if there's a solution for this.

You can't test or run 'Doom' either in your VM, the game launches after placing Mesa 3D (opengl32.dll) in the gzdoom directory, but crashes to desktop after selecting the skill level. Unfortunately there's no Mesa 3D for OpenGL 3.3.

In conclusion, any update on the current state of UDB Linux or how to properly run UDB on Linux (via Wine for example) would be highly appreciated.

[boris]

As the build instructions say you are on your own when running on Linux.

1. There seems to be an upper toolbar next to the menu items (next to 'Help') which does not display icons/information correctly and is not clickable/usable. Only after checking the Windows version through Wine I was aware of the functions that are present in that toolbar. The toolbar displays icons/options properly for the 'Draw Lines Mode' and others. However for the 'Vertices, Linedef, Sector, Things mode' it displays an empty toolbar most of the time, for some options the comboboxes are displayed, but not the icons/buttons. This toolbar is probably required if you want to make maps properly? I've seen for example the 'Make Door' option is in that toolbar, but I can get around it by assigning a key. I'm not sure how problematic this is. I don't really know what I'm missing here.

It's just some additional stuff, most of it can be accessed through the menus or through hotkeys. Nothing of it is required to make maps.

2. Node builder error every time I save; "Unable to build the nodes: The nodebuilder failed to build the expected data structures". I don't know if there's an option somewhere to make it point to zdbsp installed on your system? How does UDB Linux access zdbsp? I've tried different options in the Game Configuration menu, but I always get the error. The zdbsp (1.19) source however compiles without any hassle on my system. Placing it in /usr/local/bin also makes no difference (just a test). UDB seems unaware. I don't know the implications of that, can I still do the required node building for my custom wad using my local zdbsp? It's weird that this does not work via UDB Linux, as zdbsp is natively supported on Linux. Is this an issue that is being looked at for the Linux version or what exactly is the issue here? I can't find any instructions on this for Linux. Am I doing something wrong?

You probably have to make a custom nodebuilder config (in the "Compilers/Nodebuilders" directory in the UDB directory). But for GZDoom you can simply set UDB to not build the nodes, since GZDoom will do it anyway.

Also, are the release numbers different for win/linux version?

The release number is actually set in the Windows build script. That doesn't happen on Linux, so it'll forever be at 3274.