OrbWeaver

@Ansome's question is correct. Nothing in real life ever has a perfectly sharp corner, and one of the pieces of advice often given to newbie modellers trying to make things look realistic and avoid the "obvious CG" look, is to give sharp edges a tiny bevel so they look like something that might be manufactured in real life. The problem you've got in DarkRadiant is (1) dealing with tiny bevels using regular brush geometry is awkward, and (2) brushes aren't smoothed at all (unlike the cube on the right which actually has full smooth shading which you don't notice because of the tiny bevel). So unless you're willing to create imported 3D models with smoothed bevelled edges and place them on the corner of your buildings, adding bevels in brushwork might be more trouble than it's worth. Probably the most important things with brickwork corners is to make sure the bricks line up properly. There's nothing more obviously CG than a plastered-on brickwork texture which just ends in an unrealistic column of cut-off bricks, with mortar joints that are completely unaligned with the brickwork on the adjacent face.

The Blender export scripts have been updated to work with the new Blender 4.1 series. In this Blender version, they removed "Autosmooth" altogether, along with the corresponding parts of the Python API. This meant that the "Use Autosmooth settings" option had to be removed from the LWO exporter, where it was previously the default setting. The new default is "Full", which smooths the whole mesh, giving similar behaviour to ASE models, although "None" is still an option if you want a completely unsmoothed mesh.

That is my recollection too. The i18n system was basically Tels' personal pet project (hence the Perl script which is unmaintained because nobody in the world except Tels and Larry Wall have any interest in writing code in Perl). Because of the various implementation problems and general user-unfriendliness, Greebo didn't approve of merging it into the main mod, so it became a sort of optional extra that individual mappers could use by accessing various resources on Tels' personal server.

This is how i18n typically works in code: Developers write the strings in English (or their native language), but mark all the strings with a function/macro which identifies them for translation. In C++ this might be _("blah") or tr("blah") — something which is short and easy to write. A tool (which may be integrated into the build system), extracts all the strings marked for translation into a big list of translatable strings. This list is then provided to the translators, who do not need to be developers or compile the code themselves. They just create a translation for each listed string and send back a file in the appropriate format (which may or may not be created with the help of translation tools, perhaps with a GUI). At runtime, the code looks up each translatable string, finds the corresponding translated string in the chosen language, and shows the translated version. At no point do developers (who in this case would be mission authors) have to mess around with manually choosing string IDs. All they do is use the appropriate function/macro/syntax to mark particular strings as translatable. String IDs may be used internally but are completely invisible to developers. I suggest that any system that involves instructions like "search the list of known strings for a similar string" or "manually choose a string ID between 20000 and 89999 and then write it as #str_23456" are over-complicated, un-ergonomic and doomed to be largely ignored by mappers.

As of 09e5ec1cae16b8350097fc97839de64cf96c4e88 I have changed the logic to write spawnargs if EITHER the speaker radii are different from the shader default, OR if there were min/max spawnargs to begin with. Spawnargs will no longer be created (or deleted) as a result of a speaker move, but will appear and change if the speaker is resized, which I assume is closer to the expected behaviour.

That's what we originally did, but mappers (or at least one mapper) complained in bug 6062 about the spawnargs disappearing if they were the same as the sound shader. I suppose we could have considered that "not a bug" and kept the original behaviour, but perhaps there are situations where the old behaviour was problematic — there would be no way to distinguish between "this speaker has default radii from the shader" and "this speaker has fixed radii which happen to be the same as the shader but must not change, even if the shader is edited". I don't know how common such a situation is in practice. Correct, but the freezeTransform method is called after the end of any transformation, and does not distinguish between what type of transformation was previously happening. I imagine resizing the speaker to the same size as the shader would also have triggered bug 6062, but speakers are resized less often than they are moved and hitting an exact size with the mouse would be rare, so the issue was only noticed when moving speakers. That's what I'm confused about. I have yet to see any situation in which DR will set a max distance of 0 on a sound shader, other than by explicitly editing the spawnarg to have a "0" value.

This appears to be the function which calculates the texture values for Q3 export: https://gitlab.com/orbweaver/DarkRadiant/-/blob/master/radiantcore/map/format/Quake3Utils.h?ref_type=heads#L56 It's largely based on legacy GtkRadiant code and means absolutely nothing to me.

The commit which introduced unconditional writing of the s_mindistance and s_maxdistance spawnargs was this one: https://github.com/codereader/DarkRadiant/commit/541f2638c810588ada12e9a28360f16df6143d45 and it appears it was intended to fix this bug: https://bugs.thedarkmod.com/view.php?id=6062 The current logic is to set the spawnargs to the same values as in the sound shader, if a shader is set: // Write the s_mindistance/s_maxdistance keyvalues if we have a valid shader if (!_spawnArgs.getKeyValue(KEY_S_SHADER).empty()) { // Note: Write the spawnargs in meters _spawnArgs.setKeyValue(KEY_S_MAXDISTANCE, string::to_string(_radii.getMax(true))); _spawnArgs.setKeyValue(KEY_S_MINDISTANCE, string::to_string(_radii.getMin(true))); } This happens in the freezeTransform method which is called after performing some manipulation of the speaker entity such as moving or resizing it. In this case _radii is the object which contains the modified speaker radii, so this code is persisting the modified radii into the relevant spawnargs. This seems to be working correctly when I manipulate a speaker with a valid sound shader. The only way I can get 0 is by creating a speaker with a sound shader like blackjack_swing which does not have radii defined. In this case the speaker has a default minimum radius of 0.0 and a default maximum radius of 10.0. We could avoid setting a radius at all, but then the speaker just appears as an entity box rather than a sphere/circle, which I assume is the original reason for setting a default value. Right now I have no idea what code path would lead to having both a minimum and a maximum of 0.0. I think we'd need more detailed reproduction steps. This is the current logic for setting the spawnargs on speaker construction (rather than manipulation, which is the previous code): // Initialise the speaker with suitable distance values auto radii = soundShader->getRadii(); entity.setKeyValue("s_mindistance", string::to_string(radii.getMin(true))); entity.setKeyValue("s_maxdistance", radii.getMax(true) > 0 ? string::to_string(radii.getMax(true)) : "10"); So there is a specific check that s_maxdistance is greater than 0 before setting it as a spawnarg. Code similar to this has existed for many years, as far as I can see, and I have to go as far back as 2009 to find something different (originally all speakers just had hardcoded 16/32 radii to make them visible).

I can certainly help to locate and identify the relevant code, but I didn't write it myself and I'm not really a maths guy so the help I can provide with respect to its logic might be limited.

Skins don't require a model path, that's just a convenience feature to allow the skins to be associated with the model(s) in the editor. However I have no idea if an unassociated skin can be used on a func_static. I suppose there's no reason why it couldn't work, but it's not something I've ever tested and I wouldn't be surprised if it fails to do anything (either in the editor or the game).

When you say the value is not correct, do you mean it actually gives wrong results in the Q3 engine, or it just "looks wrong" when examining the text file? If it's the former, then that's arguably a bug (although supporting Q3 isn't top priority for DR). If it's the latter, then that doesn't really mean much at all — raw numbers in a map file don't necessarily correspond directly to values shown in the GUI, especially when transformations are involved (for example the -180 might be a rotation to match the default orientation in a particular engine).

I don't think any declaration names can start with numbers; I doubt this is something specific to skins. This is similar to the rule in most programming languages where you can have a variable called "a1" but not "1a". However you can organise skins into virtual folders using forward slashes, and individual folder elements can start with numbers. The example in the D3 documentation is "skins/models/weapons/3rox".

I can reproduce all of those. For (1), I propose that the Skin Name field should be non-editable, and have a separate button (usually the "pencil" icon) to show a popup entry dialog for editing the name. I doubt renaming skins is all that common, and it certainly doesn't need to happen on every keypress. But if people object to additional popups, the field could be editable but only commit the changes on ENTER or if a "tick" button was clicked. For (3), single-click to edit in a list is rather non-standard (double-click might be more expected). I propose to have two named entry fields below the list for "From" and "To", rather like the key/value fields in the Entity Inspector, with the fields reflecting the currently-selected list item and allowing changes (committed on ENTER or button click). Not specific to the skin editor, but I think we need an application preference for monospace font size. Reading the declarations is really difficult on my 1440p monitor.

I think you need to be more specific. What exactly "does not work"? Does the skin not show up in DR? Does it show up but crash DR? Does it appear but replace the wrong texture, or attach to the wrong model? From the screenshot of the skin file in Notepad it looks like you have a space in the model name, but I'm not sure if that's the cause of the problem or just a cosmetic artifact of the screenshot.