 |
Nicely spotted, thanks! Should be fixed. |
 |
Maybe fix wasn't merged into 95? I still get the same. My explanation wasn't very clear, so trying again: -create speaker -add property (with browser) speaker->s_maxDistance (note the capital D) -enable speaker volumes It doesn't show. If you add "s_maxdistance" (note lowercase D), now the DR speaker radius shows. At this time, I'm not sure which is correct for TDM (or if it matters), but DR's radius display only likes lowercase, while the property browser only gives uppercase. |
 |
I just checked in a fix to def/misc.def - the editor_vars there were still listed with the uppercase D. That should fix it :) |
|
|
Fixed again. The KeyObserver class was comparing keys case-sensitively. This is changed now, so both s_maxDistance and s_maxdistance should trigger a speaker update. |
|
|
There's some weird problem lingering: =========== Verified case 1: -create speaker -type-to-add, s_maxdistance, 10 Result: it works =========== Verified case 2: -create speaker -type-to-add, s_maxDistance, 10 (capital D) Result: it works =========== Verified case 3: -create speaker -click-to-add, s_maxdistance, then assign a value as normal Result: it works =========== Weird case 4: -create speaker -type-to-add s_maxdistance, 10 -type-to-add s_maxDistance, 10 (case) -delete one of the keypairs Now the speaker radius disappears, even though one of two keypairs proven to work remain. The radius doesn't show again until that keypair is replaced, ignoring the other completely valid one. I guess it became emotionally attached. :) |
|
|
Well, the problem is that the mixed case spawnarg is technically a different one than the all-lowercase spawnarg. The spawnarg observer reacts to both cases, but only creates one value, so if you remove one, the observer believes that this was the same. There's not much I can do here without changing a considerable part of the SpeakerNode's spawnarg handling, but I'll keep this open. |
|
|
Ah interesting, that makes sense. Agreed, this is of very low importance at this stage. |
|
|
Also, I'm inclined to say that if a mapper chooses to add the same spawnarg twice (with different case), it's his bloody own fault. :) |
|
|
Couldn't the editor simple do a toLowercase($spawnarg) before storing them? Do we really have/want spawnargs with uppercase letters in them? |
|
|
Unfortunately yes. The D3 game code is case-sensitive, if I recall correctly, so doing this would almost certainly break things. |
|
|
Setting this back to resolved, as having multiple spawnargs with different case on the same entity is neither recommended nor can I do to prevent it. |
|
|
The last case remains, but accepted as a case of user-beware. |
- Anonymous
