Return to “Scripting & Modding”

Post

In-game LUA inspector

#1
I was wondering, I'm sure it would be easily implemented, but what do you guys think about having an in-game inspector that would allow a player to click on any aspect of the UI, or any asset in the game and see the code which is making it work. This would be an amazing tool for modders imho.
Image
Challenging your assumptions is good for your health, good for your business, and good for your future. Stay skeptical but never undervalue the importance of a new and unfamiliar perspective.
Imagination Fertilizer
Beauty may not save the world, but it's the only thing that can
Post

Re: In-game LUA inspector

#2
It's also one of those seemingly trivial ideas that is WAY beyond trivial to code.
Once drawn basically nothing has a reference to WHAT drew it, so you would have to alter the draw code to store the reference to the object that drew it. Per frame.
Then you start getting HUGE dips in performance from every pixel on screen knowing what caused it to be drawn.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: In-game LUA inspector

#4
Sort of, yes. I disagree with Silver, though - it wouldn't be difficult to code at all, nor would it take up much processor time. All you need is for each object to have an extra array, into which you get the names of all called lua scripts. Just run the lua calls through a function that adds the name to that array and you're done.

As to which specific lines of lua code you're calling... that's a bit less feasible. That would take the same performance drops and coding time Silver mentioned.
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: In-game LUA inspector

#5
Talvieno wrote:
Tue Jul 25, 2017 10:37 am
Sort of, yes. I disagree with Silver, though - it wouldn't be difficult to code at all, nor would it take up much processor time. All you need is for each object to have an extra array, into which you get the names of all called lua scripts. Just run the lua calls through a function that adds the name to that array and you're done.

As to which specific lines of lua code you're calling... that's a bit less feasible. That would take the same performance drops and coding time Silver mentioned.
Then you have to reference which UI element, including every line drawn, was drawn by which script.
Thats a large array.
Post

Re: In-game LUA inspector

#7
Talvieno wrote:
Tue Jul 25, 2017 1:47 pm
Well, I imagine most UI elements would have a single "main" LUA script they're linked to, with some overlap. It wouldn't be much different from the inspector window in chrome or firefox.
Tal, have you ever worked with building a GUI outside of HTML?
Serious question here.

Majority of the time you write pixels and forget about them, because remembering them is expensive and they don't matter between frames.
A stateful inspector that remembered everything's links to everything else... that would be on the order of the FPLT to solve without recreating the FPLT in the Inspector.

You are *MUCH* better off doing a step based debugger option.
Game halts, and shows each step of rendering with a side window of the current chunk of code its working through, you tick through the code and things change on screen, data changes in a different pane (data inspection is easy, I could show you Goat's Dat dump as an example. :V )

But mapping those changes BACK to the code that made them?
Very much a non-trivial implementation.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: In-game LUA inspector

#9
Talvieno wrote:
Tue Jul 25, 2017 3:11 pm
Well, I never said back to the code. :D Just to which lua file data were accessed for a particular object type.
Object types would be more do-able, but not usually GUI elements.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: In-game LUA inspector

#11
Talvieno wrote:
Tue Jul 25, 2017 3:18 pm
Yeah, to be honest I wasn't thinking about GUI elements when I said it initially, just object types like ships, stations, weapons, planets, nebula backgrounds, etc. (hence why I didn't mention GUI initially)
Heh, yeah the non-UI elements are much simpler, but still its a *HELL* of a lot of data to store.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: In-game LUA inspector

#13
Talvieno wrote:
Tue Jul 25, 2017 3:38 pm
Yes it is, unless you classify objects by type and then store which object types use which lua files. I imagine they would already be classified by type. You aren't likely to see an object that's part sky, part ship, part planet, for instance. :D
You still can have a ton of overlapping mod responsibilities.

take UI mods/additions.
A dozend mods adding two dozend different features to the UI.

Or ship design mods which add stylized components which can be multiple on a ship from different sources.
(radar dishes&co, fancy thrusters mod etc)

Mods which add functionality to objects and you dont know what caused what particular effect.

And so on.
Theres a lot of things that overlap with naïve inspection shemes
Post

Re: In-game LUA inspector

#14
Silverware wrote:
Tue Jul 25, 2017 3:36 pm
Heh, yeah the non-UI elements are much simpler, but still its a *HELL* of a lot of data to store.
I strongly disagree - the UI is by far the easiest to know what is drawing it.
Why? Because UI elements already have a built-in function to know whether the mouse cursor is hovering over them or clicking them. Because that's how buttons work.
So literally all you have to do is add

Code: Select all

if (debug){
print(<name of this code file + line>);
}
to your onClick() or onHover() function.
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
Post

Re: In-game LUA inspector

#15
I'm leaning towards what dino is saying. The fact that you already have code that handles the mouse clicks and stuff means that you have code that knows where things are being drawn. I'm pretty sure from what Josh said that the UI is going to be completely written in LUA, so I'm sure that there'll be some sort of mini API that Josh makes in order to render components on the UI. In the best case scenario, hopefully all UI calls boil down to a single function which does some very generic UI attachment stuff which can then be replaced by a debug version which attaches an onHover event to the UI element which it's drawing that shows the stacktrace until that point.
A life well lived only happens once.
Seems deep until you think about it.

Online Now

Users browsing this forum: No registered users and 4 guests

cron