Frost_Salamander

Is it possible to see the 'bounding box' in Dark Radiant? This is the first I've heard of such a thing. I guess then this is something that is sort of out of our control, and perhaps nothing to really worry too much about?

So I created a small test map and I can't reproduce it now either! But I've definitely had this problem, gone and moved the model, and that has fixed it. But I don't think it's as simple as I thought. Here are 2 screenshots from my current WIP mission where something is happening. In both cases, the model is outside of the current visleaf. I need to look closer tomorrow, but in the 2nd screenshot the model wall (to the right of the window) doesn't even appear to be touching the sealing at all, so I have no idea why it is showing up here. If I was wrong about what I said about the effects of models poking into sealing geometry then I apologize for spreading misinformation. If that's the case then I am even more puzzled about what is causing this. It's not an 'internal leak' either, as I am very familiar with those now (location entities wouldn't work and you'd see everything in the next visleaf, not just a single model).

What I meant by this is the following scenario: Say you use module walls on the inside of a house which is separated from the outside by a portalled window. If all the modules are touching the sealing geometry then they will be 'visible' in the outside visleaf if using 'r_showtris 2', even if the portal is closed. I had this in my first map and had to go back and fix a lot of them, along with loads of other models that were also sticking into the seals. It's not a big issue if you have a model or two, but whole rooms of module walls will cause all your indoor models to be 'visible' to the engine/renderer from other visleafs. I don't know if I'm using the correct terminology here, or if I even fully understand what I'm talking about, but I don't think this is a good thing for that to happen regardless

Hi thanks for the replies/comments. I guess my main issue with thick walls is when you go to join rooms using a doorframe or window frame model. Say you are using the 'door_frame_wood_96x48' model. It's 24 units thick, so if you have an 8 unit thick seal, plus 2 8 unit thick walls then the doorframe will be the same thickness as the walls and will look weird. If you use thinner walls (or make your own frames) I guess the issue goes away. It's even worse with the module walls because if you use them for both inside and outside and you have an 8 unit thick seal, things like window and door frames will absolutely NOT be wide enough unless you move them into the sealing geometry, which is a big no-no. It's still doable, but you have to use thinner seals (and mess around with smaller grid sizes) which conflicts with popular advice, and that's kind of where I got confused a little bit. I haven't quite figured out what works best for myself - maybe by the 3rd or 4th map I will have it down .

@Obsttorte(and anyone else) may I ask, when you use this approach what grid sizes (thickness) do you use for the detailing walls? Do you use 8 for the sealing brushes, and then something thinner for the walls? I'm kind of trying this approach for my second map, but the problem I keep having is if you use 8 + 8 the sealing + wall is too thick (especially if using the modules, which I love but am starting to find them too restrictive so using them less now). If you use a smaller one for walls, you end up with weird grid sizes all over the place. What do people find works best?

Doesn't this happen if the first thing you create in the map isn't worldspawn? I've done this a couple of times (being a n00b myself). I can't remember the reason why I kept doing it, but it might have been the idea that one of the first things you need to create is the ambient_world light (which is obviously an entity). I can't remember if one of the tutorials suggests this or not. Also, there is no troubleshooting entry for that exact error in the dmap section on the Wiki, which would be helpful to have.

Yes this could be it as there is one repeating structure that has angles in it. Okay, I'll assume it's the nature of the map and there is no issue. Thanks!

I've started a new map with not a whole lot in it yet besides some basic architecture, etc. I'm finding that if I add an AI to the map and run dmap, it gets to the point where it says 'merge leaf nodes' and takes about 15-20 seconds to do that part. If I remove the AI the whole thing takes about 2 seconds flat. I didn't see this in my previous map, and it's making think there is something fundamentally wrong with this one. Anyone know what the issue could be?

Do you mean if you started a game, took a quick save, changed the map, and then tried to load the quick save? If so, that's not what happened here. I didn't make any changes since i started the game. I won't worry too much about it, but but if keeps happening I might come back for help

I have an FM under development/beta testing and while playing through it I've ended up with both quick saves causing TDM to crash when they are loaded. I'm a bit worried it's a problem with my map, or is it? This is on TDM 2.09. I'm creating a memory dump file regardless. I will do an other playthrough later, but can anyone advise what I should do or try next? Thanks

I'm trying to set up something with a func_pendulum. Totally guessing, and so far I've got: created a long, narrow invisible brush and converted to func_pendulum bound it to a model moved the origin so it swings from the top All that works, but is it correct, and how do I change the frequency and distance? All I could find on the the Wiki is this: "Pendulums always swing north / south on unrotated models. Add an angles field to the model to allow rotation in other directions. Pendulum frequency is a physical constant based on the length of the beam and gravity." So: Do I just make it longer to slow it down? I only want to it swing a very small distance - is it possible to change that? the 'angles' field - is that just a spawnarg on the model I've bound, or the func_portal?

Yeah I did see that behavior as well actually, but you're right it is a hack. Does anyone know if that's the only option, or what property of an entity makes doors stop on them? There must be something about the AI entity that does this...

What's the best way to have something block a door from opening? Most things I try, the door just passes through them (model furniture), or gets pushed (moveable entities). If I make the entity nonPushable, again the door just passes through it. Ideally I would like to use one of the rock entities, as I would like to be able to move it out of the way afterwards. Or if I did want to use a model, is there something I could do to it to make it behave this way?

it's in fms/<mymap>/models/darkmod/decorative/toys However I've since been informed it might be a different issue that we're trying next, so will report back

OK almost there. I imported the model into DR and it looks perfectly fine. But it doesn't show up in-game. I've tried checking for warnings, restarting TDM, deleting map files and re-running dmap, etc..

oh right - so there is information in the model file itself about where to find the materials? OK will check about that...

It's a .lwo model that @Kerry000 provided, along with diffusemap and bumpmap texture files. They are .dds though (I converted them to .tga as well so I have both - do I need both)?

I have a model and textures, and I've created a materials file for it. I don't get though how to associate the materials file with the model so it all shows up properly in DR. I've looked at the dewdrop model as an example, but I can't figure it out. What am I missing? Do I need a skin?

that appears to have done the trick. Thank you Only issue is that both of them appear identical (the 2nd one is supposed to be coloured, while the first is just an engraving). Might be just too similar a colour to the sign, or is there anything else in the materials def we need to look at?

textures/darkmod/decals/signs/hare1 { qer_editorimage textures/darkmod/decals/signs/hare_sign_001_512 diffusemap textures/darkmod/decals/signs/hare_sign_001_512 bumpmap _flat specularmap _black nonsolid noimpact discrete sort decal noShadows }

also as a side note, you can cover the switch with monsterclip and it still works. I guess MC just affects where the AI can move, and not what it can interact with?

Yep just tried in my real map with it flush to the wall model and that worked

I think I have a way forward. If you make the monsterclip very thin, you can drag it almost all the way over to light switch and the AI will use it. If it's not close enough to the switch, they get confused. It's thick in the test map because I wanted to simulate how it would look if it was covering other models I had in my 'real' map. You can't have another monsterclipped model like a table too close, as the AI then won't go near it. So I would need to re-arrange a couple of things but no big deal you can move the switch one unit out from the wall and it's not really that noticeable that it's not flush. It's obvious if it's casting a shadow, but setting noshadows=1 on it and you can't tell.

Test map here: https://drive.google.com/file/d/1zi_elHG2t7mTA6k5LI4g8gERYUNjkENr/view?usp=sharing There are 2 rooms, one with modules and one with brushwork. Observations: that switch can't be flush against the wall, I think because the origin then won't be visible to the AI as @Dragofer mentioned. You can see this in both rooms. in the room with the models, the monsterclip interferes with the pathing. If you reduce the MC to the point where it can operate the switch, the AI will faff around for a while before it gets to the switch. So I can sort of get it to work in with the modules, but not in a state where I would include it in a map unless I can figure out how to overcome those issues.

no, won't go anywhere near it think I just need to spend a while playing with it to get to the root of the problem. It's not just one switch, but all of them in the area I'm working on. I need a general strategy that takes into account the modules, the monsterclip and the switch placement that will work everywhere... I'm guessing the AI path nodes don't really have anything to do with it? Is it expected they will stray off course to deal with the light? Not really an issue as the switches are right by doors they walk through, but just thought I'd ask.