R Soul

A TDM version of NewDark's DML system would keep FMs intact yet allow people to fix compatibility problems.

NewDark gets around this with DML files - plain text files that tell the engine to find a specific object (or all instances of a specific type) and add/remove/set properties*. No files are altered, so the mission itself remains intact. It also has the benefit of allowing people to clearly see what's been changed, and to bugfix the bugfixes. *There are other things that can also be changed too, such as various mission parameters and even loading scripts.

Filigree material, various colour combinations: http://www.mediafire.com/file/aexe8ajetped1zp/filigree_1.zip/file Note that the white and gold one has a choice two choices of background colour, white and pale blue.

Could dmap support material substitution? E.g. if any material's name ends with _editor_alpha, that text could be removed (in memory, not the map file) before building the mission.

The decal is actually well within the edges of the rest of the object. The problem seems to be related to the decal shader, possibly the "polygon offset" which is prevents z fighting. Here's a version where I shrank the decal (by chopping bits off) and I think it's as small as it can be. There is an improvement but from some angles the problem is still visible from quite a short distance. stall_test.txt (change extension to .zip) An alternative is to provide versions of the models (there's also a double version and a cheap version) that have no decals. If their effect is too nice to do away with, the LOD system could be used to only show the decal model at close range.

The material can be locked by giving it a custom property called NoChange with a value of 1. I'll look in to the example you gave and see if it's a code bug or if it's an error that can't be avoided. I'll edit this post with my findings, unless there's another reply to this thread in the meantime. edit: On my PC the correct texture is assigned. Does your 'extracted textures' folder have the same structure as the pk4 files. E.g. some_path/stone/brick, some_path/wood/panels etc?

I've updated this addon. Now, when a texture is shared by multiple materials, it lists each of them as values of a set of custom properties. You can then paste the correct value to your Blender material name, and set the NoChange custom property to keep the chosen material. It does this for collision textures too. You'll end up with 36 custom properties to choose from. Same link as before, but reposting anyway: Go to the GitHub page: https://github.com/RSoul82/Blender-TDM-Material-Manager Reinstalling it is very easy. Just download the above, in Blender go to User Preferences > Addons >Install from file. Select the zip file and it'll overwrite the previous version.

I've added some versions of the pillar model. interior_set01_pillar02 tweaked version of interior_set01_pillar01, which has some odd vertex placement, but I didn't want to override it in case UV mapping changes had an adverse affect on existing instances of it. interior_set01_pillar02_m8 - 8 inches smaller in X and Y directions. interior_set01_pillar02_m16 - 16 inches smaller Placment: Line up their outer edges with the edges of the original 'half pillars' (or where they would be if you used them). E.g: interior_set01_pillar02_m16: interior_set01_pillar02: Downloads: interior_set01 extra models.txt I've removed the 'obtuse corner' models because they caused more problems than they solved. I also extracted the skins file and added these models to the the other ones that the skins already apply to: skins.txt There will always be a seam if the pillar's texture distortion is to match the adjoining walls, and I think the latter is more important. Some compromise is also needed to allow for the wide variety of skins.

Attachment: ---- (Removed the inner posts from the 'mid hole' model, slight tweaks to obtuse corner texture mapping)

I've removed the inner vertical posts of the 'hole mid' model. The model is designed to work with the fireplace model in your other screenshot. With that in place the overlapping posts cannot be seen (which is why I didn't notice them). Texture mapping, obtuse corner: I did make a few changes to the m8 model to reduce texture distortion, but I think the original models' UV mapping depends on the wallpaper texture being fairly uniform/repetitive. I don't think it's possible to get a texture to seamlessly flow around all of those faces, but it can be masked by only using textures that are highly repetitive. That may be why the default skins for these models only use such textures. The current obtuse corners are meant to slot in between two two half pillars that are on the ends of the 'default' wall model. If you use the models I made so that there are no half pillars at the corners, a new obtuse corner could be made which is entirely made of wood (so its texture mapping no longer has to fit in with the other models). e.g. no half pillars at the corner: models/darkmod/architecture/modules/interior_set01_pillar01.lwo with a custom skin to replace the wallpaper with wood: In game: Imagine the above pillar being much more narrow (so it's the same size as two half pillars with the obtuse corner in between). It's just occurred to me that using the full pillar I could do something like that (there would be a seam on at lease one of the inside corners, which may be obscured by shadow and thus hard to see). See next post for updated models attachment...

New version (replaces previous versions): see post 12 Three "obtuse pillars" are included. The original has been modified to correct some erroneous vertices that weren't quite lining up with some parts of the original pillars. There are two smaller variants. "m4" (m for minus) is 4 units smaller in X and Y directions. "m8" is 8 units smaller (relative to the original), which looks the same as your diagram. I tweaked the texture mapping to stop it looking too squashed.

I've added the 'mid hole' models. The attached file is the full set: Now go to post 8. This completely replaces the previous file. default mid hole has both pillars (to match the existing naming convention. There's a no pillar version and left and right pillar versions. I'll have a look at the obtuse corner pillar. I think I know what you mean: Thee copies of the small 'half' pillar forming a 270 degree shape.

I haven't played many TDM missions so all I've seen of mages is them using short range spells to attack me. Based on that: Lighthand, or lighthanded. Coinspark (assuming every use of magic involves the spark effect we see their attacks). The act of performing magic for profit could be called coinspelling.

I have a set of 11 models. see post 6 for attachment. (rename extension to zip) Naming scheme interior_set01_default_no_pillar: No pillars on either side. interior_set01_default_l_pillar: Pillar on the left only interior_set01_default_r_pillar: Pillar on the right only Hole(s) for the fireplace: Your second screenshot shows the fireplace siting on the intersection of two wall pieces. For that scenario you need a left and right model: interior_set01_default_no_pillar_r_hole: no pillar, hole cut out on the right (goes on the left of the fireplace) interior_set01_default_l_pillar_r_hole: same as above with a pillar on the left interior_set01_default_no_pillar_l_hole: no pillar, hole cut out on the left (goes on the right of the fireplace) interior_set01_default_r_pillar_l_hole: same as above with a pillar on the right This one has the fireplace hole directly in the middle: interior_set01_default_mid_hole interior_set01_corner_no_pillar: corner piece, no pillars These two have one pillar each. Left/right is interpreted as the player standing in the room facing the corner like a very naughty boy: interior_set01_corner_l_pillar interior_set01_corner_r_pillar

I'm no expert, but at what point in your process does it crash? What's in your darkradiant.log file? (in %appdata%/DarkRadiant) Look for references to "particles". Have you added TDM and DR to your antivirus exceptions lists in case they're blocking or deleting something they don't like? I think this should be in its own thread so that it can get more peoples' attention.

Try setting the full paths of the materials. e.g. models/darkmod/props/textures/painting02_L models/darkmod/props/textures/painting01_L

I'll have a go. It's been a while so I'll first have to reaquaint myself with some processes.

Here's a very good addon: https://github.com/ndee85/Multi-Object-UV-Editing Meshes can be kept separate but their UV maps can be edited together, which makes it easier to have multiple models sharing the same material without any overlapping (good for baking ambient occlusion and normal maps).

Hello. I've decided to have a look at the DR code, which starts with trying to compile it. I found this page and began going through the instructions. I used TortoiseGit to clone DR. Is this any different to going to GitHub and downloading the project as a zip file, or is a Git client just for keeping things synchronized? The link to TortoiseGit takes us to a different program: Only a Google search takes us to the correct program. I extracted the w32deps/ and w64deps/ folders into DarkRadiant so my folder structure matched the screenshot. When I tried to compile (Debug/Release or Win32/64 makes no difference) I got well over 100 errors about missing files: I did some searching and found a solution to the above: https://stackoverflow.com/questions/38290169/cannot-find-corecrt-h-universalcrt-includepath-is-wrong (reinstall VS (it may do an update) then you'll see the modify button mentioned by parsely72) I then got it to compile, albeit with many warnings: Those warnings disappeared after the first compilation, so I guess all relevant files were created. Hopefully my story will help someone else. Does the wiki page need updating?

The physical shape has hardly changed. Here's a screenshot of the old model intersecting the new one: The only physical change I made was to the vertices highlighted in orange: I moved them down a little bit to make them line up with the brickwork. However, I do agree that some changes entail making the resource a new thing rather than a replacement. In this case though, the new model is an .lwo not an .ase, so it won't overwrite the original, albeit on a technicality. I know how we can tell users an object is deprecated, or provide any other info: have a separate text file (or set of text files) with some simple formatting (like the code blocks in skin or material files) which includes the model path and a comment. When a model is selected, DR can read the file and display any info it finds. DR can have its own one buried in the .pk4 files, and users could include their own to explain their own models if necessary.

Here's a tweaked version: Download: http://www.mediafire.com/file/ad6m0p5i34575sd/tdm_fireplace_wooden_uv.7z/file I increased lowered the bottom of the horizontal wood part so that it lined up with the bricks. I also replaced the original brick material. This had been baked into a new texture, so the only way to properly fix the UV mapping was to apply the material on which it was based.

It's the corner decorations. I massively overdid the subdivisions: There are 12 of these in total. 8 on the 4 button panel, and 4 on the single button panel. If I remove them the file size goes down to 54MB. The 400MB file compresses down to 37MB, but the file could cause performance problems for some computers. I just tried using a 'decimate' modifer for a few iterations and removed many tris without having a major impact on the appearance. The total The total is now 1.7 million. That gets the file down to 127MB, and 14MB when compressed, so I'm now uploading it: http://www.mediafire.com/file/c7hrfkdre0s7c2a/ElevPanel.7z/file (Blender only)

Model fixed: http://www.mediafire.com/file/hldhxs4hsdi8o1x/ElevButtonPanel.7z The rectangular part is 17 inches high. Source texture (twice the resolution of the model texture): http://www.mediafire.com/file/ykugce0gbb72kgs/tdm_ElevPanel_source_texture.7z I'd like to upload the blender file which generates the AO/Normal maps, but it's now 400MB.

I renamed the material at the last minute - I'd been inconsistent between the material, model and texture names, sometimes using "ElevPlate" and sometimes "ElevPanel", and forgot to update the references in the models. I'll tweak the models tomorrow to give the rectangular part an exact size (without moving the buttons) and with a corrected material reference. You can temporarily rename the material to ElevPlate so you can bask in its shiny glow.

Release version: Download: http://www.mediafire.com/file/pnxcz0v3iwbcpkp/ElevButtonPanel.7z Prefabs included. I've included a copy of the custom sound from the button in the first post.