Search the Community

For the last 1-2 weeks the forums have been really slow and unresponsive for me, when I type a post half the time it just sits there etc.. is anyone else having the same issues..?

One feature often requested by DarkRadiant users is a graphical material editor, that would allow easy management of Doom 3 materials and textures. I have always resisted suggestions to add such functionality into DarkRadiant itself due to its primary nature as a consumer of Doom 3 resources, rather than a producer, but I think there could be a strong case for a standalone application for this purpose. Here are some of my thoughts regarding the potential scope and design of such an application: Code from DarkRadiant could be re-used, particularly in the areas of parsing and managing the hierarchy of materials, textures and skins. Separating such code into a library would be one option, although simple copying might be easier given the fairly static nature of this code. Initial functionality might be to display the tree of materials and allow their properties to be inspected via a GUI rather than as text, for example using checkboxes for global keywords, a subtree of material stages (with stage GUIs) and so on. Previews of the textures could be shown in a suitable widget. A distinction would need to be made between materials in editable files, and materials inside PK4s which are not easily editable. For editing an in-PK4 material, the options would be to either save an edited copy of the material outside of the PK4, or integrate functionality to update the file within the PK4 itself using ZIP tools. More advanced (but potentially extremely useful) functionality could involve allowing external tools to integrate with the material editor, perhaps by invoking it with command-line options, or some form of inter-process communication. This would allow the further development of plugins for 3D applications such as Blender to allow Doom 3 materials to be directly accessed and applied to objects inside a 3D scene without the tedious process of editing and re-writing texture paths. Taking (4) further might involve adding similar support for inspecting the model tree and allowing models to be edited with a chosen 3D application (likewise for skins). In this case the "material editor" would become a more general Doom 3 resource editor. If starting a new application from scratch I would probably go for the Qt framework as a toolkit; I use this extensively at work and have concluded that it is in fact a lot more powerful than GTK as well as being a native C++ library rather than requiring C++-to-C bridge techniques. Qt's inbuilt support for sockets, IPC and the like could come in useful for point (4) above. None of this functionality is in any way Dark Mod-specific, so the tool would be useful to the wider Doom 3 editing community as well as TDM mappers. Just throwing some ideas out there, in case anyone has any comments or better suggestions.

Does anybody else have this problem? In the (European) evenings the forum is unbearable slow. The server is delivering about 8Kbyte/s, sometimes less and usually stops midwhere during loading the page. Sometimes you can't even get the index page, sometimes you can log in, but then only get half of the overview etc. In the mornings everything is snappy.

I've upgraded IPB to the latest stable version, and since this was a major upgrade (from 2.3.6) I also had to re-do the forum style. Most of the new stuff is in place, but I bet that the logo will be changed. One of the many new features in version 3 is rating of posts and also a "report spammer" ability which will make it easier to single out spam bots and ban then at sight. Hopefully this will stop some of the spam threads we've seen recently. Make sure to empty your browser cache if you're experiencing any problems. And please report any errors etc in this thread. Cheers, ~m2

I've been working with materials, and I've run into a bunch of materials with quoted descriptions, as quoted surface types which are not needed as far as I can tell - thus far I've just been converting them, i.e "flesh" -> flesh eg: models/md5/chars/thief/tunic //shadowcasting { qer_editorimage models/md5/chars/thief/thief_d_ed "flesh" noselfshadow diffusemap models/md5/chars/thief/thief_d specularmap models/md5/chars/thief/thief_s "description" "herpa derp" -> description "herpa derp" eg: fogs/real_fog { noShadows blendLight "description" "A blend light instead of a foglight. Works best when covering the entire map and bound to the player, but can also look better (no artefacts) than real foglights. Does not fog any postprocess surface, like water or sky. These need to be colored sep. to match the fog color, either by using custom materials on them, or by putting a patch over them with textures/darkmod/fogs/real_fog_layer_moving on it." { blend add map textures/fog/realfog zeroclamp // make sure it doesn't bleed over the edges } } Is there not perhaps a reason they were used? I know that TDM specific surface types need to be quoted. I see that DR shows both "description" and description - however I think it's easier to just use the intended, unquoted form. On the up side : If I can get my solver to better respect tables, I should also be able to clean all of our materials and simplify a bunch of redundant/inefficient stuff, a few more human touches (like removing terrible id style literals, "-.3" :argh:). At a later date we can most likely use it to remove workarounds from ambient/tdm specific stuff once tech4 is out, with a bit more control than the id internal stuff.

So... What was up with the forums all day yesterday..?

I used textures/darkmod/stone/flat/smooth/ceramic_tile_tan03 in the trainer as a loud surface but it was not as effective as metal. Checked the shader and it is 'stone' material. So, are we certain that all our tile materials are actually correct? As a mapper I would expect ceramic tiles to be tile material. Of course you can have a tile of anything but I think we're talking ceramic or marble tiles? Is marble supposed to be tile material?

[update] Spoke to Marcus @AMD UK on the phone and as it turns out a number of complaints have been made against "Spyre". My AMD forum account has been unbarred and my Ip address unblocked!!! Bought a new gfx card for xmas, been having issues with mainly the driver So I though a good place to look for support and polity vent etc - or so I thought My second post got flamed by some smart arse fanboy and then promptly locked, to which I reported the posted asking why it had been locked.. and then my account on there got deleted and my Ip blocked (untill the isp dhcp refreshed etc) so I cant login even with a different account name. I have emailed AMD directly about this as I did nothing wrong according the t&c's and I got no warning Pm or email from the forum mods. Now I've been over at the nVidia forums a long while back when I had the 8800GTX when I was equally frustrated when posting about the driver issue with thief etc, but at no point did a thread get locked or worse my account deleted. I don't have loyalty to AMD or nVidia but depending on the answer I get from AMD next week this card maybe going back and AMD will be added to the list of manufactures I will never buy anything from again. So whats the moral of this story, well take your pick.. [update] found cached copies of 1 of my posts Cached AMD frum link Cached AMD forum link2

when i do a search, it give me some results, I click on a result and exspect to get taken to the post it specifies - but no..... I get taken to the first post of the bloody thread it is in..ggrrr

As we know, there was an issue with detecting material type for statics using texture/common/collision materials. Arrows break on this type of material which makes it useless for using on f.e. wooden models. (like trees, which need collision meshes to prevent floating in leaves effect). Dram has reported this several weeks ago. I've solved this problem in very simple way - I added surface declaration for collision material. Instead of using texture/common/collision I used my tdm_collision_wood, which looks like this: tdm_collision_wood { wood qer_editorimage textures/common/collision.tga noshadows collision } This way arrows stick into this material, as they should. I've created new material file - collision.mtr, where we can put material declarations for all other surface types, like tdm_collision_straw, tdm_collision_foliage etc...

why are they so slow this evening..??

The forums have been upgraded, please see this thread: http://forums.thedarkmod.com/topic/9845-forums-upgraded-to-ipb-3-0-3