scripting and world generation

[harsh frost]

are there any plans to enable scripting integration within world generation?
for example scripts that can modify structure placement or contents based on world events.

[blazing kite]

We need worldgen custom components xD

[rigid sundial]

@modest void you'll love this.

[nimble bramble]

custom components on features files xD

[zinc spear]

the performance wozld definitely fail here, molang is the way or static definition components

[harsh frost]

even if it was handled in world Initialize?

[zinc spear]

what do you mean by that?

like block events?

[harsh frost]

like custom components

[zinc spear]

well custom components still have JS callbacks and like i said JS is slow

so i still dont think thats the way

[harsh frost]

i am not saying it should be the way. just as an option
we do have a lot of molang stuff that script can do, so it would be nice to have the option to play around with world gen using script

[undone lynx]

Mmmm not really. If they had a load of contexts they used it could still be multi threaded and could also be semi performant with a better engine

[zinc spear]

but thats not happening so it wwould be slow if they just add apis for conditions or something

also keep in mind that API calls are slower then actually JS context calls

[undone lynx]

This is true

I was more referring to fully custom impls

Like WGE or ur thing

[zinc spear]

ohh

👍

[undone lynx]

Tho please mojang optimize molang lmao

[hexed cosmos]

We're looking to explore some ways to maybe integrate scripting with world gen, but as you all note, it's a bit hard because it wouldn't be performant to, say, have scripting "take over" significant parts of chunk generation. Three-deep for loops of a set of blocks can get slow quickly 🙂

But maybe there are places where we can call out to script to "make a decision" about something. Not aware of a place where script will be in the short term roadmap for worldgen though.

[hexed cosmos]

One of the first demos I tried to build with scripting a couple of years ago was a dungeon generator in script, but it was hard to make it work because most of the logic was about how do you timeslice all of the block placement (and also deal with chunk load semantics) across ticks to get the thing built.

Since then there is a bit more support in scripting for things like generator functions to take advantage of spare cycles in a tick - and maybe if you limit its usage to highly performant devices (a beefy dedicated server) or you really optimize - it could be pretty workable and awesome. I know some people in the community have built some cool things along those lines.

[terse cipher]

I've chatted about it elsewhere, but a fun prototype for us to do would be to use the webworker model to spin off JavaScript to actually run on other threads for stuff like world generation.

A neat idea would be to provide a different API surface (a different module you can import) with specific world-gen related APIs.

All just fun ideas at this point, but maybe one day!

[warped belfry]

I think even just hooks like chunkBuilt could be interesting. But would even something at that scale still be too slow?

[wooden umbra]

the current issue with generation in general using the Script API is that it is post-generation, meaning it does not generate unless you are within simulation distance. Luckily Molang can be used for custom terrain, but its also still not very performant.

[terse cipher]

Chunk lifetime events (loaded, unloaded, startTicking, stopTicking, etc.) might be really interesting as well. Those could exist in the main thread once chunks are done actually being generated

[cosmic quarry]

Chunk loading can be fixed using the tick_world entity component

[wooden umbra]

which is unbearably laggy

[terse cipher]

Yeah, ideally if we wanted to do scripting + world gen. we'd hook scripting deeper/earlier into the chunk generation process.

[acoustic vessel]

Not a good idea. You shouldn't be ticking chunks just to generate them

[cosmic quarry]

My dungeon with a radius of +-6 chunks on scripts is generated at 19+ tps

[wooden umbra]

try going larger

[cosmic quarry]

So I don't think it's a big burden.

[acoustic vessel]

Structures are very different from sculpting and decorating the world

[cosmic quarry]

Maybe later

[wooden umbra]

my dungeon generator would be far laggier in scripts than it currently is with functions

[wooden umbra]

structures are still decorating the world lol

[acoustic vessel]

I mean with tons of feature decorations like trees, grass, ores, etc..

[cosmic quarry]

Well, I don't know. My generator is quite similar and it is generated in about 20 seconds and not 3 minutes)

[acoustic vessel]

And there's still the terrain itself

[cosmic quarry]

You have to be able to do it

[wooden umbra]

mine only takes a little while because it is much larger than yours

and it does not take 3 minutes

[cosmic quarry]

The last version I saw was generated so much

[wooden umbra]

now the unreleased one could take a little while because it has to be able to load individual modules that are 31x31x31 or larger

i purposely slowed that one down, but once i finally finish it itll load a lot faster

[cosmic quarry]

It will be interesting to do it faster))

[cosmic quarry]

Didn't understand

[dusky kiln]

Sounds like an incredible idea! Something important that a lot of us would like is certain APIs to load and unload specific chunks/subchunks! Thats not only useful for stuff like @zinc spear's WorldGen or WGE, but also for a lot of other projects how you hopefully already noticed 😊

[terse cipher]

More precise control than ticking areas I suppose?

[cosmic quarry]

I think it would be nice to have an event that is called when a certain structure is loaded

[dusky kiln]

Pretty much! Also becuase the amount of ticking areas is limited... thanks :3

[cosmic quarry]

And ticking area cannot be set through scripts

[wooden umbra]

current version takes 11 seconds for a medium dungeon

[acoustic vessel]

We should have an API for that

[olive gate]

🙏 If scriptAPI can't do it, I know my boy runCommand comes in clutch.

[cosmic quarry]

I think if I use structures instead of block by block, it won't be difficult to make my generator faster

By the way, good idea..

[wooden umbra]

thats not block-by-block

lol

[acoustic vessel]

Wait, you're making structures block by block???

[wooden umbra]

the unfinished one uses it tho, but only to reduce lag as much as possible

[cosmic quarry]

Yes. I meant that I have it block by block. That's why it's slowed down a lot

[wooden umbra]

id keep it and set up a way so that only one module can load at a time, this will almost remove lag if done properly

[limpid rose]

For dungeon creation on the fly, I found using a block generator to be too slow and switched to making chunk-sized room structures and I'm placing and updating them at sim distance whenever the player changes chunks

[cosmic quarry]

After a while we will find out which is faster

[wooden umbra]

faster isnt the issue

performance is

[cosmic quarry]

However, the lower the TPS, the longer the dungeon takes to generate.

[wooden umbra]

its better to have stable tps than tps that spikes

using block-by-block also makes sure fps doesnt slow to a crawl

[cosmic quarry]

This is exactly what I'm talking about

[acoustic vessel]

Have you considered using system.runJob()?

[wooden umbra]

scripts will slow down the generator a lot

itll also lag more

[acoustic vessel]

I must be confused. You're not using scripting?

[wooden umbra]

its one reason i chose to use functions

[wooden umbra]

how many times have i said that i dont use scripts?

[acoustic vessel]

I don't know

I can't even remember you saying that

With the title of the post and the conversation I assumed we were talking about structure generation via scripting

[cosmic quarry]

Yes, we think what will be faster for generation?

[dusky kiln]

WGE be faster

[wooden umbra]

what in the world are you talking about

[dusky kiln]

a JS based world generation engine.... #1301288314124632144 message

there have also been other implementations by people such as ConMaster

[wooden umbra]

you do realize how laggy that actually is...

it's post-gen

[orchid quail]

That is fast, last time I did one it took 3 minutes and stole all my laptop's ram

[wooden umbra]

at least using molang for terrain isnt laggy

[dusky kiln]

Its not as laggy

in general it actually is not laggy at all

[wooden umbra]

is it RAM-heavy?

if so its just as bad

[dusky kiln]

no

[wooden umbra]

Molang-based terrain is done in generation

what ur using is post-generation

[dusky kiln]

yep, but thats not bad

[wooden umbra]

which will ALWAYS be laggier than generation passes

[dusky kiln]

jup... but it still works well on lower end devices, so I see no problem :3

[cosmic quarry]

This does not change the fact that scripted generators can be optimized, do not lag and provide more opportunities for customization

[wooden umbra]

how does the CPU handle it? what is the TPS?

[wooden umbra]

they can only be fully optimized if they can be taken out of post-generation

[dusky kiln]

about 5 MPT less

which is not a big difference

[cosmic quarry]

What is MPT?

[wooden umbra]

MPT = Mod-Plug Tracker

lmao

[dusky kiln]

actually no, we can optimize scripting api based solutions more since they can have multiple passes which span over multiple ticks...

[wooden umbra]

actually yes

no matter what you do

[dusky kiln]

please go use google, it means Milliseconds Per Tick.. and if you do the math the default MPT are around 50ms

[wooden umbra]

unless it can be done within generation

there will always be a performance increase

there's no getting around that

[dusky kiln]

sure, but if the end users doesnt notice a difference it is fine.. isnt it?

[wooden umbra]

please realize it was a joke

[wooden umbra]

fine for users

not fine for creators

more of a hassle to do than it needs to be

[dusky kiln]

why?

[wooden umbra]

it's better to wait for the q.noise query to have its seed unlocked or wait for the ability to directly modify Minecraft's terrain generator

[dusky kiln]

a solution via scripts is way easier and way more extendable :)

[cosmic quarry]

Isn't it the creators' job to make well-optimized content?

[wooden umbra]

a solution via true data-driven support is better regardless

[dusky kiln]

no absolutely not, just use WGE/other custom world gens as a polyfill rn

[dusky kiln]

sure, but if it doesnt exist we're better off with this :)

[wooden umbra]

im still gonna say the molang route is better

its literally just math

[dusky kiln]

and so is the js route :)

[cosmic quarry]

Therefore it gives less options

[dusky kiln]

but we can optimize it more

and have more than just math lol

[wooden umbra]

incorrect

thats literally all procedural terrain is

math

[dusky kiln]

eh, kinda and kinda not

yes it is mostly math

[wooden umbra]

perlin noise is also math

[dusky kiln]

but a lot is also other conditions, for example using libraries for a lot of features

[wooden umbra]

sure libraries are helpful

but again

postgen is a nightmare

i will never go back on that

sure, my dungeon generator is postgen

doesnt mean i like postgen

[dusky kiln]

wonder how much I can optimize that dungeon generatior via the scripting api

one tick dungeons generation go brrr

[cosmic quarry]

We are all content creators after all, and I don't think we should argue about which is better. Because “better” is a rather complex concept. I believe that the main thing for generation is optimization and comfort for the player. And not speed, although this is also important

[cosmic quarry]

Yes yes. I will do this in the future

[wooden umbra]

not stopping you

but good luck

youll likely run into a lot of issues

especially with infinite module size

[cosmic quarry]

Difficulties in writing scripts are the norm

[dusky kiln]

?

[wooden umbra]

its the issue im tackling with my unreleased generator version

the fact that larger modules cause significantly more lag