Well, the starting question would be... what would this add compared to Frankelnster's depository. If there isn't an apparent benefit, what's the point?

Frankelnster's method (the not raw one) seems efficient enough to find each and every issue in the game (albeit to be completely ignored by Overkill instead). If this is not the case for most people, what would you add that make it more palpatable for non-coder users to understand what's going on?

I'm aware that whatever I could do would probably be of not much use/interest to coders or anyone who has gotten used to the current repository. My goal is not to replace or improve upon that (if that could be done), but rather provide a simple/dummy-proof way of "seeing" how things work within an interactive application. Say you want to know how/what triggers a specific action in a heist, you can simply find the action in a list and then it will show you all elements that point to/from it and their trigger conditions.

It's purely an attempt at making it visually appealing and interactive. And of course make it so people that can't read (pseudo)code would feel compelled to get involved and play with it.

Sounds good, though I'm not quite sure how you would set that up considering if you want to segment "specific actions" there would be a lot of options per heist.
Although I suppose a tool to, for example, quickly overview all the different sniper setups for all different heists could be very useful (*cough* also to Overkill who'll just ignore it *cough*).

Would you just give options like "snipers", "diff", "spawns", "mission objective 1/2/3/4/5", "random spawns of 1/2/3/4/5" etc?

(I mean, it sounds great, but I just personally don't see how you would preset it user friendly. But knowing you and your site, you probably thinking something that I couldn't possibly have thought off).

But I guess you answered 3) posively, for me anyway. Can't really help with 1 or 2, sorry.

Yes, the idea is to be able to see things by what they actually mean in the heist. Of course, an initial look would be required by someone with enough knowledge to crack it, as the element names many times say nothing about what they refer to. Setting a custom name, say "Sniper Rooftop Cafeteria", to an element would make it possible for anyone looking into sniper spawns to find that element later without going through the trouble of figuring that out themselves.

The same goes for finding groups of similar elements, both by meaning (say a sniper spawn as opposed to a safe spawn) and by element type (if it's a chance roll, a trigger, a toggle, etc).

I don't use Lua for the mission files so my approach is more fundamental, but I don't know if there is not a better function already implemented.

The root of a mission is world.world. It should say world_data.continents_file = "x", which refers to "x.continents". Anyway, I think it is always continents.continents.

continents.continents then has the names of the individual folders in that mission. E.g. if one entry is mt_temp, then there usually is a file "mt_temp/mt_temp.mission" and "mt_temp/mt_temp.continent". There is no guarantee that continents.continents points at valid files only, so you must check for existence. At this point I also filter out editor_only stuff.

The scripts mostly stand on their own, but can interact with each other using ElementExecuteInOtherMission, which behaves the same as a simple MissionScriptElement but its on_executed elements are from another script. The id of each element is unique across scripts of a mission anyway, so this is purely for encapsulation; I personally keep a list of all mission elements mashed together for bookkeeping.

I had tried plain HTML for the mission scripts. It was very ugly and very useless. I'm afraid I haven't looked further into this.

The reason I use LUA to do it is mainly because I'm not experienced enough reading binary(?) data from the game files directly so it's easier for me to just use the functions the game uses to read this data. Thank you for the mission data directory structure pointers. I'll try to revisit my script and make the necessary changes.

I can think of of mappers and modders doing map edits who would find some sort of visualization of several elements of the structure of scripts handy. I'll link them in and see what they might be able to contribute to the conversation.