Jump to content


Photo

DarkRadiant 2.5.0 available


  • Please log in to reply
55 replies to this topic

#1 greebo

greebo

    Heroic Coder

  • Root
  • 16052 posts

Posted 24 December 2017 - 12:01 AM

DarkRadiant 2.5.0 is ready for download. This is a feature release introducing a new Game Setup dialog, which can adapt itself to the selected game type. More specifically, The Dark Mod mappers are now supported by a custom setup dialog with options to create their mission folder setup right from within DarkRadiant, plus a few safety checks to notify them about a possibly wrong folder configuration. Moreover, new dialogs for editing the TDM mission description files (readme.txt and darkmod.txt) have been added featuring a live preview of the edited texts. It's recommended to prefer this version over any previous release.

Windows and Mac Downloads are available on github: https://github.com/codereader/DarkRadiant/releases/tag/2.5.0
 
New TDM Game Setup Dialog with easier FM editing selection:

Attached File  dr_game_setup.png   94.88KB   0 downloads

(more about this feature here: http://forums.thedar...ests/?p=416393)

 

GUI for editing darkmod.txt and readme.txt:

 

Attached File  dr_darkmod_txt_editor.png   353.67KB   0 downloads

Attached File  dr_readme_txt_editor.jpg   75.98KB   0 downloads

 

Thanks go out to all who helped testing this release!

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

  • New Game Setup Dialog
  • One can now group/ungroup objects while in Select Group Parts mode
  • Add GUI for authoring the darkmod.txt/readme.txt files
  • Script input window is no longer receiving duplicate backspace events
  • Added Rank to TDM AI tab.
  • Replaced boost.format with fmtlib
  • Replaced remaining boost libraries with standard C++11 libraries

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

Nice holidays and have fun mapping!



#2 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8694 posts

Posted 24 December 2017 - 12:05 AM

Congrats!


  • HMart likes this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

(Yeah, shameless promotion... but traffic is traffic folks...)

#3 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12492 posts

Posted 24 December 2017 - 01:04 AM

Got it, thanks!



#4 teh_saccade

teh_saccade

    Advanced Member

  • Member
  • PipPipPip
  • 630 posts

Posted 24 December 2017 - 03:42 AM

can't ~#git clone the link.

Fatal: <link>/info/refs not valid: is this a git repository?

(I'm lazy...)

 

// oh - I just read windows and mac only - sorry. Idk why I glossed over that...


Edited by teh_saccade, 24 December 2017 - 03:43 AM.


#5 greebo

greebo

    Heroic Coder

  • Root
  • 16052 posts

Posted 24 December 2017 - 05:56 AM

The above is not a Git Clone URL, most people want to directly download the binaries - for Windows, that is.

 

The git clone URL is https://github.com/c...DarkRadiant.git

Linux folks should follow the compilation instructions on the wiki or (if you're on Debian or Ubuntu) wait for a new package to be made available by the Debian Games Group.



#6 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19857 posts

Posted 24 December 2017 - 06:15 AM

@Greebo, do you want us submit bug reports here or on Github..?



#7 greebo

greebo

    Heroic Coder

  • Root
  • 16052 posts

Posted 24 December 2017 - 08:07 AM

As usual, post here about them if you're unsure or want to get feedback. Issue reports go to the bugtracker.



#8 ERH+

ERH+

    Advanced Member

  • Member
  • PipPipPip
  • 689 posts

Posted 24 December 2017 - 12:16 PM

Why all grids have XX.000000 in bottom-right "current grid size"?


S2wtMNl.gif


#9 greebo

greebo

    Heroic Coder

  • Root
  • 16052 posts

Posted 25 December 2017 - 12:43 PM

You mean the post-comma stuff? Didn't notice it, it's probably a mistake from the formatting changes when migrating to fmtlib.



#10 ERH+

ERH+

    Advanced Member

  • Member
  • PipPipPip
  • 689 posts

Posted 25 December 2017 - 01:01 PM

BTW when I'm using "scripts/convert to ASE" (under previous build) the given new model have "origin" formed like "-1488.0 -12224.0 -5386.0" (even if model had no brush wedges that normally cause .9999 errors). I'm using "snap selection to grid" to get rid of it - but is it a rounding error and model is actually misaligned, or is it literally .00 ?


Edited by ERH+, 25 December 2017 - 01:01 PM.

S2wtMNl.gif


#11 greebo

greebo

    Heroic Coder

  • Root
  • 16052 posts

Posted 25 December 2017 - 01:19 PM

The "Convert to ASE" script is just converting in the origin vector to a string using Python's format() method:

 

originKey = '{0} {1} {2}'.format(found_func_static_origin.x(), found_func_static_origin.y(), found_func_static_origin.z())
func_static.getEntity().setKeyValue("origin", originKey)

 

There's no explicit format specification passed to the formatter, so I guess the post-comma-zero is just some default.

 

If the "origin" keyvalue is ending with ".0" that's what is written to the map file as well. And a .0 number value will be parsed accordingly by the TDM map file loader, so I don't think there's any danger of getting precision, rounding or misalignment errors.



#12 the_deep

the_deep

    Member

  • Member
  • PipPip
  • 103 posts

Posted 25 December 2017 - 01:35 PM

Works like a charm as far as I can tell. Great work!



#13 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1270 posts

Posted 18 January 2018 - 02:59 PM

This is not a version-related problem, more like DR works from the beginning, but I think it's worth mentioning. It's very weird an unusual that you can select brushes and meshes based on their faces in 2D views.

 

And, you can't select them or move them, if their faces are turned backwards in relation to any given 2D view, which happens with planes and models without faces on the back, like wall panels. Every other game editor and modeling software I know selects geometry based on its wireframe in 2D views.

 

I filed an issue in the bugtracker just in case: http://bugs.thedarkm...iew.php?id=4735


Edited by Judith, 18 January 2018 - 03:01 PM.


#14 LDAsh

LDAsh

    Member

  • Member
  • PipPip
  • 81 posts

Posted 20 January 2018 - 04:03 PM

Is it no longer possible to disable "uniform texture thumbnail size" in the Texture Browser?  It was always on by default but there was a button above to disable it, now the button is gone?

 

Also, I seem to be having some trouble with the texel scale of textures applied to brush faces when the previous(original) texture was a different size/proportion.  Instead of being "natural" to the default texture scale set in the preferences, it inherits the scale from what was applied before it.  If there's a button/option to control that, I can't seem to find that either.


Edited by LDAsh, 20 January 2018 - 04:16 PM.


#15 LDAsh

LDAsh

    Member

  • Member
  • PipPip
  • 81 posts

Posted 24 January 2018 - 10:28 PM

DR221vDR250_texelscale.gif

Here's a pic to demonstrate what I mean.  The icon with the 2X2 red squares is missing, and the way textures are scaled when applied on the brush faces are not using the default texel scale as they should.  Maybe people don't think the texture browser issue is huge (although I personally think it's critical) but the texel scales are.

I'm thinking maybe this is not a wide-spread issue because I'd assume someone else would have already mentioned this...  (Anybody???)

I've tried uninstalling, deleting the DarkRadiant folder in "Application Data" and looking through the registry, but I can't seem to fix this


  • Anderson likes this

#16 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1480 posts

Posted 25 January 2018 - 01:46 AM

What is your setting for the "Default Texture Scale" in the Surface Inspector? Maybe you changed this at some point (because you needed a smaller scale on a small object), did not change it after that and now DR still uses this setting? Regarding the missing button: I didn't even notice that it was gone...


  • Anderson likes this

#17 LDAsh

LDAsh

    Member

  • Member
  • PipPip
  • 81 posts

Posted 25 January 2018 - 02:32 AM

Thanks Destined, for the reply.  So the button is missing for you?

 

As for the setting, in both Preferences (Primitives) and Surface Inspector, the scale is set to 0.125 which is the default for my projects.  The default of 0.5 has the same effect, just 4X bigger.



#18 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1480 posts

Posted 25 January 2018 - 04:16 AM

Yes, the button is missing. I don't know if it was removed on purpose or not. But as I said: I haven ot really missed it, as I never used it.

 

I think I don't really get the problem regarding the scaling. If you set the default to 0.5 and this increases the size of the texture by 4 it does exactly what it is supposed to do, isn't it? If you want to have the texture in its original size a  factor of 1 should do that. Or you can use the fit button (with 1 times 1), so you have one instance of the texture stretched over one face. As I said, I am not sure, what size you are looking for for your texture.



#19 LDAsh

LDAsh

    Member

  • Member
  • PipPip
  • 81 posts

Posted 25 January 2018 - 04:35 AM

I think it's pretty important to be able to see size and dimensions of a texture in the texture browser.  Making everything a uniform size means you'd need to apply it to a surface before you could know how big it is.  As I said, perhaps this isn't something most mappers miss, but for people who care about consistency of texel scales everywhere, it's important, not to mention it's the way all Radiants always worked before.  Uniform scale in the browser is a DarkRadiant "feature", which was an option, but is now mandatory.  I never used it, I never even minded that it was enabled by default, but I really miss it not being there now.

As for the scaling issue of new textures applied, it has a lot more to do with proportions as well.  The proportions can be seen even if the resolution can't, but they are not applied.  So in the GIF I posted, the original surface is a caulk texture which is 64X64, which tiles 16X16 onto the faces, and when applying the new texture which is 1024X256, which should tile 1X4 (as it does on the left side of the GIF, a previous version of Radiant and infact all other Radiants) and not 16X16 which is happening on the right side.  16X16 of 64X64 at 0.125 = 1X4 of 1024X256, which is how it should be, I believe.  It means every time I apply a new texture, I need to go into the Surface Inspector and click "Natural" to make sure it's correct.

I'm just trying to figure out - is this just me or is this happening to everyone?

 



#20 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1270 posts

Posted 25 January 2018 - 07:00 AM

Typically I want the preview to be small, so I can see and apply as many textures as possible from that browser, without scrolling. Pixel density issue is less relevant when you use models for almost everything, as you have to care about that when you create them (and that's what checker override materials are for).

 

Also, to properly examine the pixel density in-editor, we'd need a dedicated rendering mode for perspective view (with material override). Something like Unreal's "Lighting with texel density" mode:

obraz.png


Edited by Judith, 25 January 2018 - 07:17 AM.


#21 LDAsh

LDAsh

    Member

  • Member
  • PipPip
  • 81 posts

Posted 25 January 2018 - 09:21 AM

There also was a % setting which you could lower to see more textures in the browser, which is gone too, naturally.

All I'm saying is - these things should still be an option, no matter what the defaults are, unless they are causing severe technical issues (which I'll just assume) it really confuses me why it changed. Seems counter-productive, you'll end up with inexperienced mappers using 2048* textures on tiny brushes.

So Radiant becomes like Blender - multiple versions for varying levels of functionality. At least the custom keyboard shortcuts are still there, for now, so I can "Naturalise" the texel scales with one key, since I need to do it every time now.

Edited by LDAsh, 25 January 2018 - 09:23 AM.


#22 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1270 posts

Posted 25 January 2018 - 09:48 AM

I think last time I saw an option to have different sizes of thumbnails in texture browser was back in UT3 editor, maybe? UDK and Unreal4 ditched it, there's only a % (zoom) slider and thumbnail size dropdown menu. Maybe some or most people (myself included) didn't use it, as frankly it makes the browser content look messy and less readable? Bear in mind that UE has a "content browser", so there's everything in it, not only textures or materials.



#23 LDAsh

LDAsh

    Member

  • Member
  • PipPip
  • 81 posts

Posted 25 January 2018 - 02:13 PM

I'm very sorry. I was just attempting to concern myself with silly things like texture memory and performance. I will learn to add extra keyboard shortcuts into my workflow while I'm lucky enough to enjoy it before it's needlessly removed. Compromise, workaround and STFU, that's my motto. ;)

#24 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1270 posts

Posted 25 January 2018 - 03:57 PM

You are looking for problems where there are none (or at least few). Texture memory problems are nothing in comparison to drawcall limit, which you will hit very soon, if you plan to use a lot of brushes and different textures/materials.



#25 greebo

greebo

    Heroic Coder

  • Root
  • 16052 posts

Posted 25 January 2018 - 11:19 PM

I can look into the missing button. I don't recall removing it specifically, so maybe it's just a mistake, but I have to check. Does anybody know the last version it had been present?

 

As for the texture scale, can you post what steps you're doing to apply the texture to the brush? I remember working on that area a few months (or even a year) ago, likely that's when it happened. I can look into it, maybe it's a behaviour I can restore, but I can't make any promises.

 

To clarify, I don't remove features or break stuff just to annoy users for fun. In the end I'm working on DR to make it more usable for you folks, so I try to follow the given feedback - if it's possible code- and design-wise. Things like broken features happen naturally when I'm trying to improve and simplify the huge codebase, it's rather rare that I sacrifice a feature on purpose.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users