Itches, Glitches & Anything Else...

[Springheel]

These settings aren't inherited

 

So if a sound shader has the "looping" keyword, you still have to set "looping" to "1" when you make the speaker?

[Komag]

I would prefer some default settings there, would make using them easier for me (but if there are good reasons not to do that then so be it)

[greebo]

So if a sound shader has the "looping" keyword, you still have to set "looping" to "1" when you make the speaker?

No, but you can "override" the looping setting by the spawnarg, i.e. make a non-looping shader looping by enabling the spawnarg.

[Flanders]

Great, the sound editor works for TDM as well I noticed. Great for testing sounds.

 

If you're interested create a shortcut:

"C:\games\Doom 3\Doom3.exe" +set fs_game darkmod +set r_fullscreen 0 +set com_allowConsole 1 +editsounds

 

There's a Doom3World tutorial here:

http://files.filefront.com/D3W+Vid+Tutoria...;/fileinfo.html

[Fidcal]

Months ago I was struggling with that old DR naming error. I had scores of errors so finished up manually renaming them to things like func_static 33B then later errors and another named 33B2 and so on. Anyways, now I suspect errors can arise if the model name is left as eg, func_static_1 and another has the same.

 

I just created a small no draw brush and made it func_static then found it had a huge collision area I couldn't get near it - anyway it shouldn't be solid. In game g_showCollisionModels showed a huge rooftop structure in the middle of the bathroom that I recognized from outside in the street! I see that was renamed but its model name was still func_static_1. So dmap is confused I guess. Hell, this may mean a big manual search through for all such names.

 

I'm also wondering why this new brush I just made into a static is called func_static_1. Yes, it's the only one but I'm surprised with the size of this map that name hasn't been used. Oh well, I've not worked on this map since about July so maybe I deleted the old one for some reason.

 

So I guess I'm asking does it matter what brush func_static model names are so long as each one is different or must it be identical to its entity name?

[greebo]

Months ago I was struggling with that old DR naming error. I had scores of errors so finished up manually renaming them to things like func_static 33B then later errors and another named 33B2 and so on. Anyways, now I suspect errors can arise if the model name is left as eg, func_static_1 and another has the same.

 

I just created a small no draw brush and made it func_static then found it had a huge collision area I couldn't get near it - anyway it shouldn't be solid. In game g_showCollisionModels showed a huge rooftop structure in the middle of the bathroom that I recognized from outside in the street! I see that was renamed but its model name was still func_static_1. So dmap is confused I guess. Hell, this may mean a big manual search through for all such names.

 

I'm also wondering why this new brush I just made into a static is called func_static_1. Yes, it's the only one but I'm surprised with the size of this map that name hasn't been used. Oh well, I've not worked on this map since about July so maybe I deleted the old one for some reason.

 

So I guess I'm asking does it matter what brush func_static model names are so long as each one is different or must it be identical to its entity name?

I'm not quite sure about what you want to know. As for the last sentence, I can give some general answers:

 

- Each entity must have a unique name (no entities with the same name in one map)

- func_statics can either be an actual static model or one with child primitives (brushes/patches)

- func_statics as static models need to have a "model" spawnarg different to their "name"

- func_statics with child primitives must have their "model" spawnarg identical to their "name".

 

DarkRadiant does respect the last requirement by automatically renaming the "model" spawnarg together with the "name" spawnarg when the latter is changed in the Entity Inspector.

[Fidcal]

The last case applies to me. I manually changed a lot of entity names but not the model names. I think now I need to go through in a text editor and check every single entity with a child primitive has a model name identical to its entity name.

[greebo]

How did you rename these func_statics? DarkRadiant automatically takes care of the "model" spawnarg if you rename the "name" value.

[Fidcal]

I must have used a plain text editor. I was inundated with errors so probably it seemed a good idea at the time for some reason.

[Fidcal]

Thinking back, I think the reason was I worked through the entity list initially changing names, then when I ran doom it came up with more multiple names I'd missed - though it only tells you one. Each time I had to close it and re-open DR. I got so tired of it that in the end I think I kept doom open with a plain text editor open. Enter 'map' and when it came up with a same name I changed it in the text editor, save, Enter 'map' repeat endless times until the errors stopped.

 

Maybe a text editor is the quickest way now or maybe entity list, select every item one by one, click and enter on the name in entity inspector so it renames the model.

[Fidcal]

Theothesnopp, using SL resources, reports that 'extra materials' eg, rtable1 he has used in his map have 'spontaneously' changed to _default. I just can't think what might cause this. I'm using some extra materials in my own map and they are stable after many saves. Any ideas?

http://forums.thedarkmod.com/index.php?showt...st&p=171401

[greebo]

Frankly: no ideas. DarkRadiant does not trim any textures based on their name, so there must be something else going on. Unless some reliable reproduction steps are found, I can't do anything.

[Fidcal]

That was my feeling too - he must surely be doing something that he's not mentioned, like deleting a folder or something! Even then I would think it would remain as rtable in DR but just show as shader not found. But he's not particularly crystal clear in what he posts but I get the impression this is not a one-off but 'keeps happening.' I'll suggest he set one surface, make regular snapshots, and keep note of everything he does until it disappears.

[Fidcal]

Worked through the entity list and found a couple of brush entities, including the roof, where the model is not the same name as the entity name. Entity Inspector won't let me change this; it won't let me edit any spawnargs on these. No problem, this is unlikely ever to happen again. Changed the names in a plain text editor. Dmapped. Still get the roof cm in the bathroom. Checked the roof in DR and it's origin is OK. I can probably delete this and extract it from an old save and re-import it as a prefab but can't think why it had dmapped like this. Don't like the inexplicable in a map that will include months of work.

 

Footnote: I might just go back to an earlier save. This error only began (I hope) when I created a nodraw entity brush in the bathroom which got named func_static_1 so I might not lose much.

[SneaksieDave]

Something I'm sure we've spoken of in the past, and it might even have been tracked or partially addressed, but I haven't found a dupe.

 

-create two entities of any type

-give them a nonsense keypair of anything, e.g., "value" "a"

 

Any time you select either entity, the row "value" "a" will be selected (until you click something else) and as such the properties boxes will be filled in with those values.

 

-select one of them and change the pair to "value" "b"

-clear selection; the properties boxes remain populated (this is desired)

-select the other entity, with the intention of hitting Enter to update its value to "b" as well

 

This doesn't work in DR, because the 'active' row is auto-selected in the second selection, which changes the properties boxes back to the original value, "value" "a". This does work in DoomEdit; no row is selected, and so the properties boxes retain the last valid values. The updated properties are easily applied with a press of Enter.

 

The simple fix suggestion is that no row be selected upon selection of an entity; this should take care of the problem (evidence is seen in fields which are not shared between entities -- in this case no row is selected in successive selections).

 

It should be noted also that applying fields via multi-selection is now in place in DR, but this is a separate need. I'll track this if it sounds reasonable.

[greebo]

Sounds like something that should go to the tracker, but maybe other mappers want to comment about their preference in this matter.

[SneaksieDave]

Yes, please chime in with opinions. I tried to think of cases when auto-selecting of a row is important, but couldn't come up with anything beyond the UI controls (e.g., _color button) being presented without a specific click.

[Komag]

It sounds like there is a problem and there is a solution. If there is any reason not to do the solution I can't really think of it.

 

Maybe someone has 15 different chairs each with a different set value, and they want to quickly check what the value was on each chair, so they WOULD want it to auto-highlight that row and show up each one's current settings as they successively select each chair. But really? I think it FAR more likely to want to do something like the fix would allow, to update the same setting on one entity after another. So I vote for the fix - no auto-row-selection.

[SneaksieDave]

Any other mapper's opinions on this issue?

[Fidcal]

Just tried this and agree, ideally, if it can be fixed on trial so we can see over a month or so if it aggravates something else.

 

Here's another related minor irritation:

 

Select one of the entities again.

The spawnarg 'value' happens to be 'half-highlighted'

You're not interested, at this point you are just adding a new spawnarg

Type hello in the box

Hit tab to go to the value box below

Enter 99

Oh dear! When you hit tab the spawnarg changes back to value so you've just changed value to 99 and not entered a new spawnarg as you thought.

 

So presumably that too would be fixed if no spawnarg was selected by default.

[SneaksieDave]

I guess I'll put the issue up as there is little feedback and no resistance to it.

 

@Fidcal: regarding the issue you just mentioned. Hm, is there any minor step missing, or perhaps something specific about the highlight state? I know at one time there was an issue where tabbing between fields did revert the first to what it was, but it was tracked and fixed (supposedly?). I'm not seeing this behavior right now. Or, could it be the slightly ambiguous role of Tab? I've changed (long ago) my GroupCycleForward to be shift-Tab instead of Tab, so that Tab would behave nicely on the entity dialog.

[SneaksieDave]

I've made a little movie showing the different aspects of this discussion.

 

http://72.8.59.188/TheDarkMod/temp/drents.wmv

 

Ignore the horizontal stretch on the video; it happened as a result of the conversion.

 

First it shows what I was describing. "value" fields exist on the two entities. Then, you try to change them one at a time, but when you switch to the second, the new value is reset, presumably because of the auto-select of the matching row (this is the subject of the tracked issue, and is contrary to DoomEdit behavior, where no auto-select happens).

 

Next it shows behavior revolving around what Fidcal is describing (I think). The field is "half selected", and then when you go to enter a completely new value, after you hit Enter to add it (it is shown to have been successfully added), it reverts to the previously selected row. This is annoying as well, but I would imagine it would be addressed along with the fix for the above issue. However what I do not see (anymore, since the original fix) is the first field reverting back after Tab. Try unbinding GroupCycleForward from Tab and see if it behaves differently.

[Fidcal]

I'm surprised this is on a shortcut key because TAB is the standard Windows method to scroll the focus through a group of window input controls and I used it without thinking. Interestingly this glitch doesn't always do it.

 

Create a func_static

Click on any spawnarg line, eg the entity name func_static_1

Click in the input box at the bottom

Enter 'test'

Hit TAB

The word 'test' disappears and is replaced by 'name'

 

If you don't notice it then type geronimo then you've renamed the entity as well as failing to add the spawnarg.

 

But I also just tried it with a path corner then tried to add a 'target' spawnarg. When I hit TAB it didn't remove the 'target' spawnarg name.

 

So when you say unbind TAB you mean bind something else to it. Let's try that......

[Fidcal]

Didn't really find a satisfactory key. Tried Enter (Return) but this didn't progress to the next field at all. Tried F4 and this had the glitch and put the entity name into the field AND it didn't move to the next field. It may be that shortcut isn't doing what we think and Tab or any combo with Ctrl or Alt just naturally goes to the next field anyway. ...

 

...yes it does. I just changed the shortcut to F4 again and still Tab goes to the next field anyway. It's a Windows thing. Ah! but it doesn't have the glitch.

 

So this is what you meant when you said unbind? Just use Tab in the normal way without it being bound. That fixes my problem. I'm off!

[SneaksieDave]

Yes, I bind GroupCycleForward to shift-Tab, and Tab is completely unbound (so it acts normally).

 

I wonder if the default should be changed.