DarkRadiant 3.0.0 released

[greebo]

DarkRadiant 3.0.0 is ready for download.

It took a while, but DarkRadiant 3.0.0 is finally available. Most of the time has been spent on improving DarkRadiant's renderer, which now features shadow mapping support of up to 6 lights. It's still not matching the engine's output (especially in terms of performance), but it should be faster and much more helpful than it was before.

The effort that has been put into the renderer rewrite plus the bigger changes in the previous few releases make the jump to the next major version feel more than justified. Besides of that, a lot of non-renderer issues have been resolved in this release too, next to some fine usability improvements.

For more things that have changed or fixed, see the list below.

  Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.0.0 and of course linked from the website https://www.darkradiant.net

Thanks go out to all who helped testing this release! And I'll gladly repeat myself, by thanking all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going.

Please report any bugs or feature requests here in these forums, following these guidelines:

• Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask.
• If you run into a crash, please record a crashdump: Crashdump Instructions
• Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker.

Changes since 2.14.0

• Feature: Realtime shadow mode
• Feature: Allow way to hide some entities in Create Entity list
• Feature: MD5 Animation Viewer: show current frame & total frames
• Feature: MD5 Animation Viewer: jump to frame
• Feature: DarkRadiant warns about missing .darkradiant file on load
• Feature: Ability to center 3D camera on selected entity
• Feature: Cut functionality to complement copy and paste
• Feature: Save user settings by application version
• Fixed: Free Rotation not working anymore, can only rotate along 3 axes
• Fixed: DR crash with combination of mouse buttons pressed
• Fixed: Git Sync Exception: too many redirects or authentication replays
• Fixed: Missing brushes when opening alphalabs1 from vanilla Doom 3 PK4s
• Fixed: Selected Skin not showing in ModelSelector
• Fixed: Reload Defs takes longer every time
• Fixed: ForceShadows materials are not casting shadows
• Fixed: Objective GUI doesn't display properly in some places
• Fixed: Crash on loading certain maps
• Fixed: Vertex colours do not show on models in lighting mode
• Fixed: Entity inspector shows inherited spawnargs of previous selection
• Fixed: DR overwrite order for defs is different from TDM's
• Fixed: X/Y and Camera View bindings don't save properly
• Fixed: Material Preview rendering
• Fixed: "Replace Selection with exported Model" sets classname to "func_static".
• Fixed: Map -> Edit Package Info (darkmod.txt)... crashes DarkRadiant
• Fixed: Rotating a func_static result to random stretch textures
• Fixed: DR crashes when syncing with remote Git repository
• Fixed: Switching visibility of Github repo from public to private causes crash
• Fixed: Dockable window layout doesn't save new floating XY views
• Fixed: "Choose skin..." button on custom model spawnargs shows skins for main model spawnarg
• Fixed: Entity inspector considers inherited colors black
• Fixed: ReloadDefs moves def_attached light crystals to entity origin
• Fixed: Option to filter skins out of search results in the Choose Model dialogue
• Fixed: .lin files can't be opened if different case than .map name
• Fixed: Model chooser radio box selection issue
• Fixed: Changing multiple lights between omni/projected resets colours to black
• Improvement: Allow absolute paths for snapshots
• Improvement: Light diamonds and Speaker radii are transparent
• Improvement: Unify Declaration Parsers
• Improvement: Add "Create Particle" to right-click orthoview drop-down menu
• Improvement: Revisit Interaction Shader to get closer to the TDM looks
• Improvement: Entity inspector should recognise spawnargs beginning with "sprS_" as def spawnargs
• Improvement: UI for worldspawn-to-entity conversion
• Improvement: classname field should always be read-only, to force use of the "Choose entity class" button
• Coding: Update solution and build dependencies to Visual Studio 2022

The list of changes can be found on the our bugtracker changelog.

Have fun mapping!

[nbohr1more]

Congrats!

[Brendon Chung]

Great stuff! Incredible work, congrats all on the release.

[Xolvix]

Does this mean I have to start learning how to map?

[Nort]

2 minutes ago, Xolvix said:

Does this mean I have to start learning how to map?

Rather than just post status updates saying "This is a status update."? Not really. Eating cookies is contributing too.

[Xolvix]

2 hours ago, Nort said:

Rather than just post status updates saying "This is a status update."? Not really. Eating cookies is contributing too.

And yet my status updates still make more sense than yours.

ANYWAY... congrats on the release! I notice there's no Linux release, is that because Linux users will traditionally compile it from source?

[Nort]

5 minutes ago, Xolvix said:

And yet my status updates still make more sense than yours.

ANYWAY... congrats on the release! I notice there's no Linux release, is that because Linux users will traditionally compile it from source?

Thankfully, making sense is not part of my job description, because I'm not good at it.

So they mentioned that 3.0.0 took a while to get out, so now I'm wondering how long it is before version 3.0.1 comes out, because I'm wondering if I should hold off on trying to make my patch pack work with the current release, until after 3.0.1 comes out, or if I'd have to wait for months for that, and should actually get started right away.

[Frost_Salamander]

14 minutes ago, Xolvix said:

I notice there's no Linux release, is that because Linux users will traditionally compile it from source?

From the release notes:

Linux: There's a debian package available (with some delay), otherwise you'll have to compile it yourself.

Edited June 16, 2022 by Frost_Salamander

[Frost_Salamander]

1 hour ago, Nort said:

Thankfully, making sense is not part of my job description, because I'm not good at it.

So they mentioned that 3.0.0 took a while to get out, so now I'm wondering how long it is before version 3.0.1 comes out, because I'm wondering if I should hold off on trying to make my patch pack work with the current release, until after 3.0.1 comes out, or if I'd have to wait for months for that, and should actually get started right away.

You can get an idea of the release cadence here: https://github.com/codereader/DarkRadiant/releases

3.0.0 was a major release with a lot of new features, so it probably took longer than usual.

If there is a 3.0.1, it will be a patch release anyways which by definition will be backwards-compatible with 3.0.0, so no harm getting started on whatever it is you are talking about.  I'm speculating a little bit as I don't have a roadmap for DR, but that's normally how software development and releases work.

[datiswous]

1 hour ago, Nort said:

because I'm wondering if I should hold off on trying to make my patch pack work with the current release, until after 3.0.1 comes out, or if I'd have to wait for months for that, and should actually get started right away.

I wonder why it shouldn't work by default. As far as I understand these are fixes to assets in TDM and DR just reads those.

Edited June 16, 2022 by datiswous

[Nort]

10 minutes ago, datiswous said:

I wonder why it shouldn't work by default. As far as I understand these are fixes to assets in TDM and DR just reads those.

So none of the TDM pk4 files have been altered? That sounds good, but I still have to verify this myself, so that I'm not recommending a patch that would somehow break things in this new version.

[JackFarmer]

 

Many Thanks!

Ich melde mich demnächst bei Dir Mal wieder über Discord.

 

 

[OrbWeaver]

23 hours ago, Xolvix said:

ANYWAY... congrats on the release! I notice there's no Linux release, is that because Linux users will traditionally compile it from source?

We've never released Linux packages on the main DR website, but you can download the latest version for Ubuntu from my PPA.

https://launchpad.net/~orbweaver/+archive/ubuntu/darkradiant

For other Linux distros or incompatible versions of Ubuntu you will either need to compile from source or wait for your distro's respective packaging team to release it (if they are prepared to do so).

[greebo]

I added a link to your PPA to the website. It usually takes some time for the debian package to appear.

[OrbWeaver]

Thanks, that will probably reduce some user confusion. For some reason I can't get the native Debian package to show up in my Ubuntu package managers (which it definitely used to), but I don't know if that's something I'm doing wrong or if Ubuntu have decided not to include it for some reason.

[IZaRTaX]

Thank you very much for the release what a great job you've done

[datiswous]

Now testing 3.0 . When I am in free camera mode (right mouse button in Camera view), I can't zoom in and out with mouse wheel scroll, keyboard arrows do still work. Is that normal? This was possible previously.

Also when I select a face instead of a whole block, I used to see a blue dot in the middle. Now that is gone.

Or are these just settings?

Edited June 21, 2022 by datiswous

[Nort]

Mouse Wheel zoom works fine on my end.

I think the blue dot is gone for me too. I only vaguely recall it being there. Maybe the "Select Faces" mode is new, and meant to replace that, because then you get dots for all the faces of a brush.

[kingsal]

I am little late to the party but congrats @greebo , thanks for the dedication and keeping DR rockin!

[peter_spy]

If I see correctly, fog lights are still treated as omni lights, and they mess up the lighting preview. The workaround in previous versions was to put such light on a separate layer and make it invisible. It doesn't seem to work on my end anymore with 3.0.0

[greebo]

I didn't work on fog or blend lights at all, so yes, it's still an open topic. The corresponding issues are still open on the tracker (I see one of them was opened by you):

https://bugs.thedarkmod.com/view.php?id=4706
https://bugs.thedarkmod.com/view.php?id=2350

Maybe during the next round of renderer changes.

[coldtobi]

Hi greebo,

thanks for the new release. I finally had time to look into packaging it for Debian (sorry for the delay) and I have a issue with the tarball: The tarball includes ".gitattributes" which has the line

* text=auto

As the Debian packaging happens inside a git repo as well, this causes the file

darkradiant/install/scripts/commands/count_loot.py

to change line endings, which then makes the Debian toolchain to believe that there are changes where they should not be:

dpkg-source: info: local changes detected, the modified files are:
 darkradiant/install/scripts/commands/count_loot.py
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/darkradiant_3.0.0-1.diff.385Qey

This complicates the work on the packaging a lot, as git is becoming in the way and no way to convince git to restore to the format as in the tarball, except to extract the file from the tarball again.

I can work around this issue locally, so no need to do a release for that, but for future releases I'd appreciate if that could be fixed for future releases, for example by

• NOT shipping the .gitattributes file in the tarball,
• making sure that the tarball has the bit-for-bit identical files (by normalizing before releasing (https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings#refreshing-a-repository-after-changing-line-endings)
• or making sure that line endings are OK at the time of push/commit  (maybe using some git hooks) -- disclaimer: did not research if that is possible/feasible…

Thanks for considering!

--

tobi

[greebo]

Hey tobi,

with tarball, are you referring to the sourcecode.tar.gz in the Github releases page? If so, this file is automatically created when I click "publish" on a new release in Github, I cannot influence its contents.

I'm not even sure I placed .gitattributes myself in the repo - I believe my local Git client is already configured to commit Unix line-endings only, but will check out CRLF-style locally. So I could live with removing the .gitattributes file from the repo, I don't need it personally. I can also offer to fix the count_loot.py file or any other file you report to me as faulty.

8 hours ago, coldtobi said:

or making sure that line endings are OK at the time of push/commit  (maybe using some git hooks) -- disclaimer: did not research if that is possible/feasible

I would have guessed that the .gitattributes file should do exactly that, but maybe it's only working in the check-out direction, not when committing files.

@OrbWeaverWhat's your take on that, do you prefer that .gitattributes file staying under version control?

[OrbWeaver]

I don't think the preferred solution would be to remove .gitattributes from source control — even if its contents aren't strictly required now (which I haven't investigated), a permanent requirement to never have a .gitattributes would be somewhat restrictive since we might need its functionality at some point.

The problem is that the file is appearing in the tarball, which is unnecessary and undesirable. The first thing to do would be to set the export-ignore attribute on .gitattributes itself, which should cause it to be excluded from any git archive command. I have no idea whether this will affect the automatic tarball published by GitHub, but if it doesn't, presumably it would be feasible for either us (upstream) or coldtobi to create a tarball explicitly using the git archive command from the repository.

[coldtobi]

8 hours ago, OrbWeaver said:

I don't think the preferred solution would be to remove .gitattributes from source control — even if its contents aren't strictly required now (which I haven't investigated), a permanent requirement to never have a .gitattributes would be somewhat restrictive since we might need its functionality at some point.

The problem is that the file is appearing in the tarball, which is unnecessary and undesirable. The first thing to do would be to set the export-ignore attribute on .gitattributes itself, which should cause it to be excluded from any git archive command. I have no idea whether this will affect the automatic tarball published by GitHub, but if it doesn't, presumably it would be feasible for either us (upstream) or coldtobi to create a tarball explicitly using the git archive command from the repository.

I agree,  you should be free to use .gitattributes and it should not be the problem;  If a generated tarball has the same content everything will be fine… Best thing would be if those .git files where not part of the tarball… No idea as well if github would be doing the right thing if utilizing export-ignore.

One thing that might work is to re-normalize the git repo before doing a release:  (requires * text=auto in .gitattributes)

$ git add --renormalize .
$ git status        # Show files that will be normalized
$ git commit -m "Introduce end-of-line normalization"

(Stolen from https://git-scm.com/docs/gitattributes)

Another approach could be to make the release tarballs manually, (and possibly also GPG sign them afterwards to ensure that supply chain attacks can not happen -- Debian would appreciate a GPG signature, but I digress)

I'd like to avoid creating "upstream" tarballs, as it is recommendation within Debian to use the upstream tarball unmodified when ever possible; (even if there is no GPG signature to break…)

(Said that, I found a quite simple workaround to fix the problem locally for me, so I could also live with the status quo. Version 3.0.0 is almost ready to be uploaded to Debia )

Cheers,

tobi

Edited August 17, 2022 by coldtobi