grayman

May I take a shot at it? I'd produce a local copy of the gui and manipulate that, so as not to bother other mappers.

No way to shut down the WARNING spam?

WS4: The Warrens has rain. However, you should play WS1, WS2, and WS3 before WS4. It's a story that starts in 1 and will end in 7.

Getting a warning that the number of values provided for Ambient Occlusion doesn't match the number of text descriptions provided in the gui: choiceDef AmbientOcclusion { rect SETTINGS_X_OFFSET, 171, 80, MM_LINE_H choices "#str_07221" // Off;Low;Medium;High(;Very High) values "0;1;2;3" cvar "r_ssao" updateGroup render CHOICE_DEF onAction { resetTime "AnimGammaDown" 0; } } In all.lang we see "#str_07221" "Off;Low;Medium;High;Very High". The parser finds 5 values in the "choices" keyword, but only finds 4 values in the "values" keyword (thus the warning). The code that processes r_ssao doesn't include anything to handle the value "4", so a "4" will default to "default", which is the same as the value "3" (High). Could this please be corrected to make it explicitly 4 or 5 choices, whichever the intent is? Less spam = goodness. Thanks

Problems with newspaper readable gui: Getting these warnings: I tried tracking down the root cause, but got lost in the weeds of gui instruction/definition inclusion. Everything looked okay to me.

When two location areas overlap (missing separator between them), we get the warning: WARNING: location entity 'AAA' overlaps 'BBB' in area 53. How do I find out where area 53 is? Solving these has been pretty trivial in the past, w/o knowing where the area is, but a current WIP has multiple touch points and I'm tired of trying to figure out where the overlap is.

Nicely done. I have lamps in 2 WIPs that could certainly use this effect. Thanks!

Thanks, @SeriousToni! Glad you're enjoying the series. The 3 remaining missions are under construction. I hope to release them this calendar year.

Np. We appreciate your continued attention to DR.

Verified that HOM is gone from the void. Thanks. Pls make sure this gets merged to the 2.08 branch.

Verified that the fix works. Three maps repaired, easy-peasy. Thanks!

I’ll check this in the morning

Thanks! I have 3 maps that need repair, and it looks like I just need to delete the unwanted Layers and Group blocks. Fingers crossed. I will do that after the bug is fixed.

Perhaps, but to be clear, I don’t run multiple DR instances

"SelectionGroups" appears to be suffering the same fate as "Layers".

I might be able to see something, but the key thing I'm looking for is why the AI aren't queuing up properly to use the elevator. And that means seeing what's happening from the moment they realize they need the elevator to get somewhere.

The trunk behaves the same way, so nothing was changed since the problem was first reported.

Suggested here.

I'm not providing example maps because you won't be able to examine *.darkradiant as the maps are edited according to the steps below. After step 6, bring up a text editor and look at what DR has done with *.darkradiant. It looks like, at step 7, orville.darkradiant retains the layers defined in archie.map (good), but when you rename them in steps 8 and 10, and save the map, a new Layers section gets added to orville.darkradiant, rather than having the current Layers definition replace the previous Layers section inherited from archie.map (bad). I.e. it ends up looking like this: Layers { Layer 0 { Default } Layer 1 { Archie } Layer 2 { Walter } } Layers { Layer 0 { Default } Layer 1 { Orville } Layer 2 { Robert } } Layers { Layer 0 { Default } } 1. Create a new map. 2. Add an AI named Archie. 3. Add an AI named Walter. 4. Create layers "Archie" and "Walter". 5. Move Archie and Walter to their respective layers. 6. Save the map as archie.map. 7. Save the map as orville.map. 8. Change the "Archie" layer to "Orville". 9. Rename Archie to Orville and move him to the "Orville" layer. 10. Change the "Walter" layer to "Robert". 11. Rename Walter to Robert and move him to the "Robert" layer. 12. Save orville.map. 13. Open the previous map archie.map. 14. Look at the layers. They're Archie and Walter, as they should be. 15. Open the previous map orville.map. 16. Look at the layers. They're Archie and Walter, but they should be Orville and Robert. orville.darkradiant looks like the lines in the highlighted section above. It looks like there's some integrity problem with saving/recalling layers. I can't say when this first showed up, but I never saw this prior to this round of beta versions. I also had a situation where, when I was switching maps, the layers changed to those of a map unrelated to what I was working on. Since this appears to have been going on for a while, and I've been editing several different WIPs over the past week or so, I now have to unravel my layer settings. If I'm right about previous Layer definitions not being replaced, this might be as simple as removing everything prior to the latest definition. If somehow they've become tangled, it's going to be like unraveling a plate of spaghetti. So I'm stopping work until this is understood (and fixed). If this is a bug (and I'm not just seeing things), it will have affected any mappers using layers, for as far back as when the bug was introduced.

I might have found a major issue with Layers, so if you're getting close to a final version, please pause until I figure out what's going on. In short, I'm seeing layers belonging to different maps showing up along with the layers of the map I'm working on. Trying to create an example.

Do you have a savegame from a point just prior to the problem occurring? If so, I'll take a look. If not, perhaps you can create one. Thanks.

Using Beta 4. I thought this HOM problem was fixed. View is from the eastern void in "Accountant 1".

Greetings from another North Carolinian.

Looks good in-game. I have a maid who's walking around dusting things, and it works perfectly. Thanks!

That looks great as is! An AI will carry this around. I don't intend for it to be frobable by the player.