Display posts from previous

Sort by

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.

When you're trying to fill an infinite multiverse, if you're not willing to consider the entire creative output of humanity as a starting point, you're wasting your time.
User: JoshParnell is accountable for this user's actions.

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.

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.

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.

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.

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)

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.

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.

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.

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

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

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.