Airlight nodes state

[6r1d]

If you grow anything on Mars, you'll notice "airtight" nodes, which provide a part of light in the caves are removed by the process of building / planting. I am not sure if we should have a tool or ABM to regenerate those, but it's hard to grow stuff in caves because of that. I'm not sure it's how it should be. I can make ultra-glowy cave ceiling and it won't matter. Tools will be better performance-wise and control-wise if anyone wants a dark cave.

Also, a hoe won't work on a dirt with an airtight node above.

[S-S-X]

@6r1d see https://github.com/pandorabox-io/planet_mars/issues/2 I also did think that there was no ABM but then looked at sources and after that verified in game that there indeed is ABM for this, just very slow one..

[6r1d]

there indeed is ABM for this

Well, if that's the case, a tool is more practical. I stood in such place for hours AFKing, no reaction :D

[S-S-X]

Maybe problem was your position as ABM is defined like this:

    nodenames = {"air"},
    neighbors = {"planet_mars:airlight"},
    interval = 20,
    chance = 5000,

so there must be airlight nearby or ABM wont execute. In other words, you have to be near existing airlight to make it spread.

How about LBM solution? Could it make it a bit cheaper to spread airlight faster? Not sure, maybe it would just complicate things...

I think currently only way to make it spread faster is to use jumpdrive to move existing airlight "seeds" into darkness and then just wait there.

Chat command to add few airlights to random locations around mapblock?

It might be good thing that you can prevent airlight to spread in some locations, removing neighbors from ABM could make it spread without existing airlight but not sure if that's good solution... it would cause every air node ~within Mars min_y - max_y~ in world to fire ABM's.

[6r1d]

Chat command to add few airlights to random locations around mapblock?

It will be a pretty nice solution. Tools are good, but it's a system part, which (at least in my opinion) should not influence gameplay too much.

[BuckarooBanzay]

i've addressed (hopefully) all the issues here: https://github.com/pandorabox-io/planet_mars/commit/acc34edf1f95b44173dfe88c8ab69be9c53d9b09

• An additional /mars_lightup command
• Increased chance and interval on the light-restore abm
• Added above-soil-airlight removal

If anyone has an idea how to solve the lighting issues properly i would be very happy it looks like the hacks around that just pile up :yum:

EDIT:

How about LBM solution? Could it make it a bit cheaper to spread airlight faster? Not sure, maybe it would just complicate things...

Well this would fire on every airlight node and induce more lag issues i'm afraid

[6r1d]

Thanks a lot, @BuckarooBanzay!

If anyone has an idea how to solve the lighting issues properly i would be very happy

Yeah, I'd be pretty happy to know a good solution, but which one is good? I think that current graphics engine is the limiting factor and everything else besides patching the it sounds like a hack to me.

I wish MT engine used some modern lighting approach like this one. I think it translates meshes to distance functions, allowing for high-fps light computation.

I feel like I'll only bother engine developers and I'd hear that mobile does not support some API or something, though.

[S-S-X]

How about LBM solution? Could it make it a bit cheaper to spread airlight faster? Not sure, maybe it would just complicate things...

Well this would fire on every airlight node and induce more lag issues i'm afraid

That is true and that's why I thought that it might complicate things, but LBM executes only when mapblock gets loaded and not continuously like ABM's do, therefore LBM execution should actually stop when players are staying in some area and for me it seems that players do very often stay within fairly small area building, farming, running machines, whatever.

That's why I did think that LBM will for sure reduce average lag but it is also true that using LBM's might cause higher lag spikes when a lot of blocks gets loaded.

Exploring would also cause a lot more LBM triggers.

Of course also depends on how often engine decides to unload / reload mapblocks, is there metrics for that?

[S-S-X]

Command works nicely, I think this can be closed. But if there's metrics for mapblock loading it would still be interesting to see that and estimate LBM vs ABM impact.