Is the OverlayMap a user tool or a developer tool?

[koosemose]

The titles for the different overlays imply that it is meant to be a user tool (since some are marked as Debug), but how useful is it really as a general player tool? While it could be used by players, most of the information that would be useful is available elsewhere or could be made available, and for a player facing tool it is subpar, mostly as a matter of performance, there are obvious dips when it has to rebuild the overlay, and in addition the refresh rate feels much to slow to be something player facing.

If it is a developer tool we should make it clear that it is (even if it as simple as making the dropdown togglable off in a debug setting or something), so that future developers don't use it as a way to convey important information to players. If it is a player tool, we need to drastically improve it's performance, at least make it so that rebuilding the overlap map doesn't take so long causing a severe performance hit, and if possible improve the refresh rate somewhat.

[BraedonWooding]

Personally I love those kind of tools in games (i.e. Civ 6 lenses or even rimworld has similar things for power and certain things), and honestly it's all done in LUA currently so moving it to C# will be a huge performance boost and in reality shouldn't be as slow as it is, we could even move all the processing to separate threads and just then use a buffer system?

[koosemose]

I could easily be wrong (particularly as I haven't profiled or anything), but from when I was messing around with overlays a while ago, it seemed like a lot of the slowdown was in the creation of the actual overlay texture (which it really shouldn't be that slow... I think).

If it's something we want to keep as a player facing tool, we should for a way to do it that allows Lua to be used and not slow things down so bad (if Lua is at fault in the first place), to attempt to keep Lua as a viable way to implement overlays, before just moving everything to C#.

[koosemose]

So, after digging around and profiling, it seems to me that the Lua isn't primarily at fault, but rather how it's being called. With a default world, it gets called 10000 every time the texture has to be built, it's making basically the same mistake that was being made in TimeManager, in that calling something that's slow only occasionally doesn't make it any better, it just means you get spikes of bad performance. And from what I can tell, it's not that Lua itself is slow, but that calling Lua is slow. So either it needs the same sort of treatment that TimeManager got, so that rather than occasionally updating it all, it updates a portion of it at a time. However, even though I think that would improve things, it would also tie up a lot of performance in updating things.

If I'm correct in thinking that the slow part is the actual calling of Lua rather than Lua actually running exceptionally slowly, then things could be drastically improved by altering how the overlay map gets its values, and rather than having a separate call for each instead have the Lua process the entire thing at once, so there's only one Lua call. I'll check and see if that improves things any... assuming I can sort things out.

Alternatively, Moonsharp can do Coroutines which may in an iterator type fashion, which may be a better way to do it, though I'm not sure, and I'm also not sure how we could mirror the setup in the C# mod code.

As another alternative, we could take inspiration from Rimworld, and rather than having an overlay over the entire thing for player facing "lens", we could do something along the lines of what Rimworld does for beauty, and directly show values in an area around the mouse cursor, reducing the calls from 10,000 to maybe 100 for a 10x10 area around the cursor

Update: Well, doing it entirely in Lua may not be feasible... as it's taking several minutes to do it, but there's a chance I'm mucking things up horribly, since I also have to hard code the tile coordinates because it's coming up null for some reason...

Update 2: Nope, the slowness is definitely in the Lua... the derp was just me slightly misusing lua for loops forgetting lua for loops are set up to work with Lua's 1 indexed arrays....

[koosemose]

Alternative way to handle it would possibly be to do a bit of threading, but that requires also separating the logic of getting the values from building the textures, and building the texture in not a thread only after the getting of values thread has completed and possibly marking it as dirty so it knows to rebuild the texture.

But to be honest, personally I have trouble getting the motivation to do that as it feels like drudge work on a tool that doesn't feel anywhere near useful for actual gameplay in anything approaching it's current form, and only good for getting a broad picture of thing for development, it still requires mousing over things to get the slightest idea of what things mean for gameplay.

Barring someone taking the time to improve both the performance and the meaningfulness of the display (so that colors means something more than "this tile is different somehow than this other tile that is another color), I'm going to consider and treat this as a development only tool. Which really just means that any implemented feature that needs a display is expected to have some form of display other than just the overlay and when we eventually go to some kind of true release (assuming it hasn't been improved of course), I will look for this to be hidden behind a debug option.