friendlier exploratoration: additional fields, or override __tostring / __serialize, on userdata

[slippycheeze]

When I'm poking around in-game trying things out, or whatever, I frequently dump the results of some API operation to the game console using `game.print` and `serpent.line`.

Right now I then follow that with a loop over the values extracting `.name` because the representation of any API object is

Code: Select all

{__self = "userdata: 0x...."}

It would be possible to augment this to be a tiny bit friendlier, in several possible ways. This would make it a little easier to interactively investigate the API through in-game stuff. Not exactly earth-shattering,

set an extra field or two on construction with static values

Code: Select all

{__self="userdata: 0x...", _instance="LuaEntity", _type="accumulator", _name="fred"}

...or something similar. Nothing dynamic or even all that interesting, but just knowing that this is a LuaEntity, is useful, and getting the "most common fields" would often save me time and trouble extracting those couple fields when, eg, doing a get_entities in an area or whatever.

write a __tostring method, and stick it in the metatable

Implemented in lua or C++, a method stuck in the metatable to control how both the lua `tostring` function, and serpent, emit it when they try and print the object.

optionally, but probably wisely, also implement __serialize

if `__tostring` is present on a table, serpent will serialize it by calling that. if this isn't a valid output for reading, I don't know that good things will come of it. so, if serpent is used for more that debugging, the `__serialize` metamethod can return an arbitrary object to substitute for the original, and is preferred over `__tostring`, allowing you to do ... whatever you want, really, there.

[Rseding91]

This isn't going to happen. Pushing those every time a LuaObject is created would add a massive amount of overhead that would be completely wasted in 99%+ of the cases.

[Optera]

Eduran has implemented an object explorer in our library: https://github.com/Yousei9/Opteras-Libr ... ctions#log
Unwrapped types and parsing depth can be configured as well.

To use all you have to do is add a dependency to the library, then you can use the following to log fields of objects.

Code: Select all

local logger = require("__OpteraLib__.script.logger")
logger.log(entity)

[slippycheeze]

Eduran has implemented an object explorer in our library: https://github.com/Yousei9/Opteras-Libr ... ctions#log
Unwrapped types and parsing depth can be configured as well.

Thanks. That seems like a decent solution, which I can wire in to the toolchain I'm using. The print method, rather than the log method, would be the best match to my particular problem -- but since it does the same transformation, that'll do what I need and make it easier to investigate this stuff. I can just substitute it into place in the logic. ...or use your CLI commands to do the same, which is probably going to cover 99 percent of the needs I have anyway.

[Optera]

I can just substitute it into place in the logic.

Not sure i understand that. Do you mean to copy some logic from the library into your project? It's almost always preferable for everyone to link a library instead of copying the code from it into a project.
Our advantage, we have to maintain code in a single one location.
Your advantage, receiving bugfixes and updates tested across many projects.

[slippycheeze]

I can just substitute it into place in the logic.

Not sure i understand that. Do you mean to copy some logic from the library into your project?

Oh! No, I mean use that when I type `/c game.print(serpent.line(game.entity_prototypes.banana.energy_cost))` style things, which is where i want this. In actual fully written out code I very rarely need that support, in large part because I have enough time and space to write all those helpers.

What I wanted this for was the in-game experimental stuff where I poke around at details to figure out, eg, what the in-game fluid box settings for a steam engine are, because apparently I got them wrong reading the code, or whatever.

I understand your confusion now. I wanted this stuff to help for interactive work -- a REPL in-game -- rather than inside a more fleshed out mod.