Jump to content
The Dark Mod Forums

DarkRadiant 3.0.0 released


Recommended Posts

  • greebo pinned this topic
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?

A word of warning, Agent Denton. This was a simulated experience; real LAMs will not be so forgiving.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Frost_Salamander
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by datiswous
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by datiswous
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...

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.

  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...

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

Thanks for considering!

--

tobi

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by coldtobi
Link to comment
Share on other sites

  • greebo unpinned this topic

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recent Status Updates

    • peter_spy

      Perhaps an unpopular opinion: TDM team might benefit from someone with actual QA experience; someone with naturally and professionally developed curiosity, who is interested in how and why things work, how they break At least to me it's kind of mind-boggling how untested some rather important features are (first the absence alert feature for items, now the rope +body carry behavior).
      · 4 replies
    • nbohr1more

      The Dark Mod is hosting an Ask Me Anything thread on the PC Gaming reddit forum:  https://www.reddit.com/r/pcgaming/comments/10nfcwj/hello_we_are_the_international_development_team/
      Feel free to join the discussion there
      · 2 replies
    • stgatilov

      Bumped into an interesting piece of wisdom called Hyrum's Law:
      With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
      · 5 replies
    • The Black Arrow

      I love playing The Dark Mod when it's cold in my place. Bonus points when it's a bit (or even very) dark and it's raining, too.
      · 2 replies
    • The Black Arrow

      I've been having stutters in Vulkan, apparently it's Nvidia Drivers' fault, so I reverted to 512 according to this: https://www.nvidia.com/en-us/geforce/forums/geforce-graphics-cards/5/505679/regular-microstutter-in-vulkan-applications-after-/?topicPage=40

      And no, that did NOT fix it. What's going on? My GPU is an RTX 2070, by the way.
      · 4 replies
×
×
  • Create New...