ZDoom

Alright, makes sense then. Thanks for your input! So the general outcome is — this probably won't be done anytime soon
Since I barely have time even for more critical things these days.

Just out of curiosity,
is there a statistic of many times the editor was downloaded?

Nope. Maybe Rachael has it

In the less than 2 days of its existence 60 people have join the Discord, which surprised me a bit. So there's definitely interest.

Enjay wrote:

Kappes Buur wrote:From what I take away from reading various responses on Doomworld and some from ZDoom forum, those mapping for DOOM/2 or BOOM are mostly using Doombuilder2 or, if they are at least I bit interested, DoombuilderX.

That's my impression too. Most of them aren't even that interested in a newer editor; they already have one that they know, like and which does what they want. They didn't adopt GZDB and the majority probably won't adopt UDB even if they could run it.

There's that - but there's also the undisputable fact that these systems are a tiny minority these days - it's just when you got 1000 satisfied customers and 5 running on an "old potato" you get 5 complaints but zero feedback from the other side, making this group to appear larger than it really is when in reality the continued support for them is not economical.

It's the same thing I said countless times when talking about GZDoom - what does it bring to give these maybe 2% of the user share a better experience when you have to trade in advancements the other 98% do not receive in return. I've seen this miscalculation far too often in the Open Source scene where software doesn't get modernized because it'd mean sacrificing that tiny group of stubborn holdouts. The end result is always a product that underserves.

But by catering to them all that gets done is making them to cling to that toaster for even longer - at some point they have to be told to either move on or else...

That said, I even question the need of a 32 bit build - this pretty much treads the same ground of out of date hardware. But unlike GL 2 support this one is normally not causing extra work, but it has gone down in significance far enough by now that if it ever becomes a blocker it'll be gone.

ZZYZX wrote:Nope. Maybe Rachael has it

If you want download statistics, upload a release package on Github, they track these numbers. Doing so would definitely be better than relying on devbuilds, a proper release appears a lot more professional.

Graf Zahl wrote:There's that - but there's also the undisputable fact that these systems are a tiny minority these days - it's just when you got 1000 satisfied customers and 5 running on an "old potato" you get 5 complaints but zero feedback from the other side, making this group to appear larger than it really is when in reality the continued support for them is not economical...

I fully agree with everything that you said in that post.

It's also why I referred to the people who complain (in these kinds of circumstances) as the "squeaky wheels getting the grease" of the community. i.e. they make their voices heard so they tend to get a response (whether they take advantage of the result or not) but the silent, happy, majority may lose out because of catering/pandering to the noisy ones.

Graf Zahl wrote:

ZZYZX wrote:Nope. Maybe Rachael has it

If you want download statistics, upload a release package on Github, they track these numbers. Doing so would definitely be better than relying on devbuilds, a proper release appears a lot more professional.

The auto-update will need to be changed to work with this. And I agree that we need a different process for auto-updates and CI (so that we don't automatically read from master branch)
Also, thanks, didn't know about the download stats there.

What I don't like is the idea of going away from revisions to versions (releases). I threw out everything talking of versions on purpose and would gladly throw out the remaining "3.0", if not for undefined consequences with the build process (it may not parse version without leading numbers and break, too lazy to check and fix). Just "R3286" is perfectly enough.
Moreover, even big software seems to move away from the old versioning model — using year+month or year+some numbers as opposed to major/minor versions.

Either way, on releases, if done properly — we need to implement CI and multiple "channels" for updates — dev/unstable (Git builds) and stable (more or less well-tested releases).

Graf Zahl wrote:That said, I even question the need of a 32 bit build - this pretty much treads the same ground of out of date hardware. But unlike GL 2 support this one is normally not causing extra work, but it has gone down in significance far enough by now that if it ever becomes a blocker it'll be gone.

In case of UDB, 32-bit build is related to WINE support. 64-bit WINE is quite broken and buggy from my experience, especially 64-bit Mono (I still remember wild array index out of bounds in 64-bit version but not 32).
In this particular case it manifests as 64-bit version lagging up to unusable state.

For info, I have now put in quite a bit of time with UDB, played around with some very big maps and projects, made a small map from scratch and generally done most of what I would expect to want to do with a Doom map editor.

I have not had any real problems with UDB in any way since the initial post-release flurry of fixes. It has performed well, done what it is supposed to, saved without corruption, been able to undo/redo reliably and I don't think I've had a crash since the initial fixes either.



The only enhancements that I would really like to see are things that have been discussed before (and are both related):
1) The thing 2D texture to have the centre-point marked on it to aid accurate placing of things. I use this edited one myself:

Spoiler:

---

2) The ability to easily have the ThingTexture2D overlay shown on all things, not just the ones that have an obvious direction by default. (perhaps this option already exists somewhere?) With stim packs, med kits and many other items, their orientation doesn't matter - right up to the point you load a model pack or something and then suddenly all the med pack in the map are facing the wrong way.

I have found placing items onto to small shelves/pillars/alcoves with any degree of accuracy quite difficult and have had to resort to placing items that use the ThingTexture2D graphic first and then replacing them with the item that I actually want to have in that position later.

I second Enjay’s suggestions.

Here's a question - would it be too much to add support for UMAPINFO parsing? It's not super important or anything, literally all I can think of getting out of it is F_SKY1 rendering the correct sky textures as it would for a map definition in ZMAPINFO, but even for that much it'd be nice.

I'm not sure if this can be considered a bug or not, or if this is even worth bothering with ...

When resizing the editor (r3289) in Nodes Viewer Mode, the map does not scale
but is either squeezed or stretched depending on the direction of resizing.

Issue #348

I see that this has been moved to closed.
Thank you boris.

I am running into a strange problem. "Autoalign" in visual mode doesn't work with the attached texture in the attacked map, but it works with other textures, so I guess it's not a problem of the geometry or sectors.

Link: https://www.dropbox.com/s/phxnsmnfqpjinvp/sm03.zip?dl=0

Thanks for providing a mystery worth of a small detective
We looked at the map and somehow found your screenshotted piece in a 19900x9000 level, and even identified the issue (the texture's right border is aligned with the line end, which somehow breaks autoalign)
Will fix!

Though on a slightly more serious note specifying the line number (4468) would help more