I see you set "allowduplicates = false" by default in 4.12.0, so all my bundles become broken because they are based on duplicates in gameinfo. I noticed, that I can "-allowduplicates" in BAT file, so my bundles will work again.
Question: is it a way to make "allowduplicates = true" other than in BAT file, for example in CFG or INI? I tried with CFG, but it doesn't work
I admit I'm not a fan of the new launcher, it looks nicer but I liked that the old one had all the information visible all at once without having to go to another tab to adjust settings. I almost always use an external launcher though so the change doesn't bother me.
I will miss the old text startups for Doom however, I liked that the banner was different for each IWAD (and could be modified by PWADs using a GAMEINFO lump), it certainly had more personality than the black screen with the red progress bar at the bottom. If there's a way to keep that I'd love to know. At least the Raven custom startups still work.
Some great features in 4.12 otherwise, as always thank you to the team for all the hard work.
brick wrote: ↑Sat May 04, 2024 5:04 pm
I admit I'm not a fan of the new launcher, it looks nicer but I liked that the old one had all the information visible all at once without having to go to another tab to adjust settings. I almost always use an external launcher though so the change doesn't bother me.
I will miss the old text startups for Doom however, I liked that the banner was different for each IWAD (and could be modified by PWADs using a GAMEINFO lump), it certainly had more personality than the black screen with the red progress bar at the bottom. If there's a way to keep that I'd love to know. At least the Raven custom startups still work.
Some great features in 4.12 otherwise, as always thank you to the team for all the hard work.
It has its benefits and drawbacks.
The good:
Being able to choose language at the launcher itself. Especially with more work being poured into the GZDoom translation table, this is a boon for people that want (or need) GZDoom to have the right language to start from. Especially if they're new to GZDoom, and aren't familiar with the other way to do it.
It looks really nice, not just like a generic Windows form. Whether or not this is actually a benefit is entirely subjective, and does absolutely nothing to make it function better or worse than the g4.11 Launcher, but I do think it looks nice.
The bad:
The radio options lack radio buttons, causing some confusion because they look like ordinary check boxes. Though according to a GZDoom response, this will be made irrelevant in g5.# (whenever that eventually happens).
The new loading screen is, in my opinion, retrograde. It's a plan black screen with no information whatsoever, versus the prior loader which not only looked nice and was extremely customizable by mods to match a theme, but also produced useful output to help rat out and diagnose non-lethal errors upon load for mod makers.
Other minor bug(s).
Like with a lot of big changes like this, the bad comes with the good, and nothing is going to be perfect on its first attempt. Still, outside of the watered down loading screen, I think this is the foundation for a good step forward for a better cross-OS launcher (remember when Windows, Linux, and Mac OSx lacked feature parity?) with more startup options.
Thanks for the post, you made some very good counterpoints. I hadn't thought of the language menu, it's definitely a great addition and will hopefully bring in even more users. On examining it further the options that got moved to the second tab are not ones that should need to be changed regularly, so grouping them together with the language actually makes a lot more sense than I first realized. And of course you're right that the menu does look nicer and more professional, and the cross-OS feature is a big win. I'm reversing my opinion, this is an improvement in every way.
I would still like to see the old loading screen available. It doesn't have to even be the default, just an option that can be toggled on (even if it's just an ini flag I'd be more than happy with that). I think I understand the reasoning behind the new screen, if used in a GZDoom-engine game it looks more professional than the console-style loader, but as you said I like the customization in the old one, not to mention the new one now just makes some of the options that can be set in GAMEINFO useless since it doesn't have a way to display them.
brick wrote: ↑Tue May 07, 2024 5:22 pm
I would still like to see the old loading screen available. It doesn't have to even be the default, just an option that can be toggled on (even if it's just an ini flag I'd be more than happy with that). I think I understand the reasoning behind the new screen, if used in a GZDoom-engine game it looks more professional than the console-style loader, but as you said I like the customization in the old one, not to mention the new one now just makes some of the options that can be set in GAMEINFO useless since it doesn't have a way to display them.
That old screen was removed because it was three different implementations for the major OSs - the new one is one shared implementation for all platforms.
This simple fact alone is why the old ones won't come back - maintaining 3 or 4 launch screens is a lot more work than having a single platform independent version.
Professor Hastig wrote: ↑Mon May 13, 2024 6:10 am
That old screen was removed because it was three different implementations for the major OSs - the new one is one shared implementation for all platforms.
This simple fact alone is why the old ones won't come back - maintaining 3 or 4 launch screens is a lot more work than having a single platform independent version.
So is there any reason the console cannot be re-implemented in terms of the API for the new widget thing, once we have details of how to use it? Or are the hooks into the engine for ZScript simply not available at that time? I'm thinking for easy debugging of mods, rather than to just look cool.
I am not sure I really get the need here exactly. If the startup fails you see the usual fatal error log window where you can read the entire log. If it doesn't fail you can see the startup log by bringing down the console.
If someone wants to volunteer and code the feature then I don't think anyone would reject the PR, but personally I'm not going to code it.
I'm with dpJudas here. The old log window wasn't that great anyway because you couldn't copy text out of it. Reimplementing it wouldn't bring back much of value. If you relly need the startup log for testing, use '-stdout' on the command line. What we might do is adding a CVAR that makes this setting persistent.
Graf Zahl wrote: ↑Mon May 13, 2024 10:18 am
I'm with dpJudas here. The old log window wasn't that great anyway because you couldn't copy text out of it. Reimplementing it wouldn't bring back much of value. If you relly need the startup log for testing, use '-stdout' on the command line. What we might do is adding a CVAR that makes this setting persistent.
OK, I can see that now. Unfortunately, that doesn't work when testing in UDB; it doesn't show you the CLI output window when there's an error messagebox, only the widget screen. I'll have to think about how to work around that.
In the meantime, what does "-stdout" actually do? The engine seems to write the console output to the CLI window (when I start the engine) anyway
Google This Site]
