Brendon Chung

I'm trying to write a DarkRadiant python script with the purpose of orienting/angling a model between 2 arbitrary points (i.e. for a clothesline, or hanging pennant flags, etc). The goal is: The user selects 2 entities (target_null's). The user runs the script. A window will pop up, and ideally display the rotation matrix between these 2 entities. I can get the XYZ of these entities, and I can get the euler angle between them. The problem is: props want a rotation matrix, not euler angles -- I can't quite figure out how to get the rotation matrix, or how to convert the euler angle into a matrix. I'm not sure if I'm approaching this correctly -- has anyone had experience with this, or can point me in a direction?

On the func_emitter, when I assign a .prt particle to it, it seems like the entity position visually looks offset in the editor. I attached an image of what I'm seeing. When the emitter has no particle assigned, the emitter can be moved / snapped to grid normally. When the emitter has a particle .prt assigned to it, the emitter is visually offset from its origin by a few units. Because of the offset, it makes it a little difficult to place an emitter at a specific position. Is there perhaps a way to disable this offset, or am I perhaps misunderstanding how this works?

Great stuff! Incredible work, congrats all on the release.

Makes sense! Thanks.

I was wondering if there was a way to make models display differently in DarkRadiant. For example: a model that has specific material settings that make it appear dark/black in the editor (i.e. the material has something like: RGB parm5, or a fire burn effect stage, etc). The model looks fine in-game; but looks strange in the editor due to its various material settings. I was wondering if there was some sort of keyvalue like "editor_displayskin" that would make the model use a specific skin override when displayed in the DarkRadiant editor -- this keyvalue would point toward a 'sanitized' version of the material that makes it appear more correct in the editor.

Got it, thanks for taking a look! I'll make a suggestion in the bugtracker.

Oh! I didn't realize assets.lst could hide .def files. I have assets.lst working for materials, but I can't seem to get it working for .def files: Should assets.lst go into the base\ folder or the base\def folder? I couldn't get it working with either. To clarify, is the documentation in https://www.darkradiant.net/userguide outdated? "Asset paths listed on the left-hand side are interpreted relative to the directory containing assets.lst (which must be models or materials)."

I was wondering if there was a way to prevent an entity type from appearing in the Create Entity list. For example: I'd like to not show the damage_* definitions, as they're not placed in maps and sometimes muddle my search results. Is there some sort of .def keyvalue like: "editor_hidden" "1" (the assets.lst feature to hide deprecated materials/models is very similar to what I'm looking for)

Fantastic stuff!!! Thanks to you all

Got it! Thank you. Our mistake, we were accidentally setting our source control to ignore this file.

Does anyone know where, or what file, that the ctrl+shift+G Selection Groups are saved in? We just noticed that our Selection Groups are not being propagated into our source control -- so if someone creates a Selection Group, a different person is not getting that Selection Group when they get latest data via source control. Wondering if it's maybe a local file, or perhaps not a file, or if we maybe accidentally set our source control to ignore this information.

Thanks! Yup, ctrl+mmb is currently the way I do this. I wasn't sure if some sort of keybind existed for centering the 3D camera.

Is there a hotkey for focusing the 3D camera on the currently-selected entity? Right now you can bring up the Entity List (J), and then click the entity in the list to focus the camera. I was wondering if there was a hotkey to focus the camera on the currently-selected entity, without having to bring up the Entity List. Thanks!

Sure thing -- I created a new item in the bugtracker and submitted it.

Resolved! It turns out that on the machine that didn't work, "Open Map From Project..." was being used to open the map. This was somehow affecting the .lin and autosave functionality. At any rate, using "Open..." resolves the issue.