2013-02-02 DarkRadiant 1.7.3 released
This release contains a fix for a subtle but serious data corruption bug which caused non-worldspawn brush geometry to become corrupted after multiple save operations.
http://darkradiant.sourceforge.net/Thanks for the update.
Cool stuff. Although it would be nice to fix animation playback for md5 models and func_door issues (
https://github.com/orbweaver/DarkRadian ... state=open )
Btw, is bugtracker kaput?
Bugtracker is not kaput but the parties involved in fixing issues are very limited.
If you post a thread in the forums about your issue it might get more visibility.
That said, looking at the md5 preview report, I don't see replication steps.
Did you try preview with Doom 3 base assets?
It could be that something in Blender (etc) md5 formats is not quite compatible?
If you attach a test map with an example md5 it would help evaluate.
Beyond that I think that Dark Radiant may generally have problem producing much beyond brushes, patches,
particles, and trigger entities for non Dark Mod maps. The advised workflow would be to build your geometry in
Dark Radiant then add Doom 3 entities in Doom Edit for non Dark Mod maps AFAIK. I haven't heard much
one way or another?
I suppose that (thus far) Doom 3 modders haven't been outspoken about this that much since they
are happy to have a better brush\patch editor than Doom Edit from a UI stance. But it might be good
to gather more Doom 3 oriented folks to the project and further delineate the Doom 3 project mode.
Greebo has previously stated that he is not interested in merging Dark Radiant into the native Radiant
in Doom Edit but I think it would be a cool project.
Rant:
It seems that other folks are more interested in starting from scratch and creating their own editing tools.
(At least that was how the ioDoom3 IRC was...)
More power to 'em but seeing those same said authors' projects' go idle seems to indicate how big of a task "starting from scratch" is.
If at least one of the tool makers just joined to help Dark Radiant it would make a world of difference to an already great tool.
But I guess that's it... When you are trying to make a name for yourself, you don't wanna just slightly improve something that's good.
You wanna prove that you can make something radically new and bold.
Thus we have a bunch 'o fork projects all re-inventing the wheel rather than collaborating for the common good.
("I'm not gonna fix your smelly old code! I'm gonna write mine from scratch to run my way... the good way..." etc. )
I am still interested in what some of the leading coders (left?) will show in terms of tools.
Jmarshall appears to have built quite a set already...
Tr3b, IIRC, was planning on selling his tools?
At worst it'll just mean there are more diverse options for mappers. Though most will probably
gravitate to the ones with the most features rather than the "best" coded ones (stable, clean,
fast, etc.) Though Dark Radiant itself is a behemoth and might fall into that "most features" category
so "stones in glass houses" I suppose... (I think it's at least more light weight and clean than Doom Edit...
)
End rant...
There shouldn't be any issue regardless where MD5 comes from. Blender's exporter works extremely well and produces exactly the same MD5 files. Otherwise models wouldn't work in Doom 3.
I tried loading vanilla Doom 3 models and the model viewer shows them fine. I have no idea how else would I play animation besides going into Entity > MD5 Animation viewer > selecting model def and then animation. Nothing is being rendered in the window. It doesn't work with vanilla Doom 3. Am I doing something wrong?
I find DarkRadiant is pleasant to work with. DoomRadiant is horrible. Who came up with that z-window? o.O Plus, DarkRadiant is cross platform, and there is no way to have that happen with DoomRadiant without complete rewrite.
Well, needless to say, there are a lot of folks like that in the FOSS community - rewrite is the thing (which doesn't make sense). Look at dhewm3 fork. Yeah, they made it cross platform, but because they don't like Windows they f$^ked it up so badly that we are still untangling ungodly SDL mess to get tools working again. Don't get me wrong, dhewm3 is the cleanest leanest fork of Doom 3 out there, but such approach has ruined it.
Anyhow, not like MD5 animation support stops us from mapping, but it would be nice to have it working. And the func_door issue is really outrageous one, but since you mention math was rewritten in DarkRadiant, maybe in 1.7.3 it will work fine (haven't tried it yet).
I'm using Netradiant for brushwork / patchwork in my current Doom 3 map, and Darkradiant for editing lights, sounds, particle effects etc. I prefer those to the built-in editor because my entire workflow is in Linux (also for my main project).
Thanks for the update; what I'd really need a fix for is the problem where I cannot drag-resize brushes (and lights even) in DarkRadiant.
I might have to finish my map under Windows with the built in editor. It looks like Doom 3 mapping is, for the foreseeable future, requiring Windows.
Or run Doom 3 under WINE, that works too
gb_remake wrote:
Thanks for the update; what I'd really need a fix for is the problem where I cannot drag-resize brushes (and lights even) in DarkRadiant.
That's not a bug, it's a feature!
View - entity list
Then select the brush that's an entity (ie a func_static, door, whatever). That entity is autoselected in the entity list.
Click the "+" next to it and you'll see the work "Brush" appear below it. Click on this and then you can change the brush properties.
It makes sense from a technical point of view (you can't resize model entities after all) but from a practical POV I find it annoying.
Since I'm on Windows I just use doomedit, but I use GTK 1.5 for my Quake 2 stuff, so I'd most likely use GTK 1.5 for D3 stuff if I needed to.
It works for me. Just make sure you grab edge outside of the volume.
Or use the scale only function. That's easier at times.