| Time |
Nick |
Message |
| 00:07 |
|
SFENCE joined #minetest |
| 00:11 |
|
Can0xfBows_ joined #minetest |
| 00:26 |
|
SFENCE joined #minetest |
| 01:04 |
|
SFENCE joined #minetest |
| 01:38 |
|
SFENCE joined #minetest |
| 02:05 |
|
SFENCE joined #minetest |
| 02:25 |
|
SFENCE joined #minetest |
| 02:44 |
|
Mocraft joined #minetest |
| 03:00 |
|
SFENCE joined #minetest |
| 03:22 |
|
SFENCE joined #minetest |
| 03:41 |
|
SFENCE joined #minetest |
| 03:50 |
|
SFENCE joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:05 |
|
gregon joined #minetest |
| 04:07 |
|
SFENCE joined #minetest |
| 04:25 |
|
SFENCE joined #minetest |
| 04:37 |
|
tarsovbak joined #minetest |
| 04:43 |
|
SFENCE joined #minetest |
| 04:43 |
|
gregon joined #minetest |
| 05:24 |
|
SFENCE joined #minetest |
| 05:33 |
|
SFENCE joined #minetest |
| 05:52 |
|
SFENCE joined #minetest |
| 06:24 |
|
SFENCE joined #minetest |
| 06:50 |
|
TomTom_ joined #minetest |
| 06:51 |
|
SFENCE joined #minetest |
| 07:02 |
|
SFENCE joined #minetest |
| 07:06 |
|
jaca122 joined #minetest |
| 07:11 |
|
SliverFlowCipher joined #minetest |
| 07:15 |
|
Talkless joined #minetest |
| 07:18 |
|
Lunatrius` joined #minetest |
| 07:18 |
|
beanbrain joined #minetest |
| 07:31 |
|
Glaedr joined #minetest |
| 07:50 |
|
SliverFlowCipher joined #minetest |
| 08:08 |
|
YuGiOhJCJ joined #minetest |
| 08:09 |
|
mrkubax10 joined #minetest |
| 08:13 |
|
mrkubax10 joined #minetest |
| 08:20 |
|
SliverFlowCipher joined #minetest |
| 08:57 |
|
Hanicef joined #minetest |
| 09:05 |
|
SFENCE joined #minetest |
| 09:31 |
|
SliverFlowCipher joined #minetest |
| 09:42 |
|
gregon joined #minetest |
| 09:45 |
|
tarsovbak joined #minetest |
| 10:05 |
|
tarsovbak joined #minetest |
| 10:06 |
|
gregon joined #minetest |
| 10:06 |
|
SFENCE joined #minetest |
| 11:00 |
|
Meli joined #minetest |
| 11:10 |
|
boingman joined #minetest |
| 11:11 |
|
ireallyhateirc joined #minetest |
| 11:17 |
|
Meli-sama joined #minetest |
| 11:22 |
|
SliverFlowCipher joined #minetest |
| 11:48 |
|
jaca122 joined #minetest |
| 11:49 |
|
SliverFlowCipher joined #minetest |
| 12:12 |
|
tarsovbak joined #minetest |
| 12:13 |
|
gregon joined #minetest |
| 12:23 |
|
SliverFlowCipher joined #minetest |
| 12:28 |
ireallyhateirc |
Are additions to the built-in lua vectors welcome? For example I made my own vector.ceil (that's missing) and vector.random |
| 12:29 |
ireallyhateirc |
these aren't hard to make yourself but I guess it's better to spend your time on actually making games/mods rather than writing basic utilities |
| 12:33 |
|
tarsovbak joined #minetest |
| 12:34 |
|
gregon joined #minetest |
| 12:41 |
MTDiscord |
<luatic> ireallyhateirc: if these abstractions are pretty much universally useful, i'd say they are welcome, yes. vector.ceil is just vector.apply(math.ceil) though, and vector.random has some potential for bikeshedding... |
| 12:45 |
ireallyhateirc |
lua's math provides math.ceil so I guess it's only natural to expect vector.ceil |
| 12:45 |
ireallyhateirc |
no matter how trivial the implementation |
| 12:45 |
ireallyhateirc |
Here's my vector.random: |
| 12:46 |
ireallyhateirc |
function vector.random(...) |
| 12:46 |
ireallyhateirc |
return vector.new(math.random(...), math.random(...), math.random(...)) |
| 12:46 |
ireallyhateirc |
end |
| 12:49 |
MTDiscord |
<luatic> I'd be tempted to just implement function vector.create(f, ...) return vector.new(f(...), f(...), f(...)) end instead |
| 12:49 |
MTDiscord |
<luatic> then vector.random would be just vector.create(math.random) |
| 12:50 |
ireallyhateirc |
yeah, that's more universal than vector.apply |
| 12:50 |
MTDiscord |
<luatic> ireallyhateirc: it's different |
| 12:51 |
MTDiscord |
<luatic> vector.apply takes an existing vector and applies a function to it, this function creates a vector given a function to call with the same arguments for each coordinate |
| 12:51 |
ireallyhateirc |
yeah |
| 12:52 |
|
gregon joined #minetest |
| 12:53 |
|
tarsovbak joined #minetest |
| 12:53 |
ireallyhateirc |
Just wonder if there's a better name than .create which is kind of ambiguous (similar to .new) |
| 12:54 |
ireallyhateirc |
but I guess this shouldn't be a big problem if documented properly |
| 12:54 |
ireallyhateirc |
vector.create_with_function would be more descriptive but also long |
| 12:57 |
MTDiscord |
<luatic> ireallyhateirc: i didn't think too hard about the name, but bear in mind that the context will make it pretty clear that it takes a function - for example if you see vector.create(math.random) |
| 12:59 |
ireallyhateirc |
yeah, it should be fine then |
| 13:03 |
ireallyhateirc |
I'm also thinking about handling functions that return multiple values in vector.apply |
| 13:04 |
|
Thelie joined #minetest |
| 13:04 |
ireallyhateirc |
for example there's the math.modf and I wrote my own vector.modf |
| 13:04 |
ireallyhateirc |
https://codeberg.org/lord_of_the_dumpster/perfect_city/src/commit/fccbfa19df1193b825c5b9db23bafe2b55dcc3e1/mods/pcity_mapgen/utils.lua#L185 |
| 13:05 |
ireallyhateirc |
this sounds a little dangerous though, because some functions can return values that are not numbers |
| 13:05 |
ireallyhateirc |
it could probably also make functions that use vector.apply a little slower |
| 13:13 |
|
Guest95 joined #minetest |
| 13:23 |
|
Meli joined #minetest |
| 13:25 |
|
tarsovbak joined #minetest |
| 13:25 |
|
gregon joined #minetest |
| 13:54 |
|
behalebabo joined #minetest |
| 14:38 |
|
Trifton joined #minetest |
| 14:45 |
|
silverwolf73828 joined #minetest |
| 15:10 |
|
tarsovbak joined #minetest |
| 15:14 |
|
gregon joined #minetest |
| 16:10 |
|
gregon joined #minetest |
| 16:14 |
|
tarsovbak joined #minetest |
| 16:17 |
nekobit |
Hi, are there any useful methods for debugging mods/games? |
| 16:18 |
nekobit |
Restarting the world over and over gets tedious, but i have thought about making a --go while loop which quickly reselects the world |
| 16:22 |
ireallyhateirc |
depending on what you debug/test you may want a fresh world or the old world so I doubt you can make any "one fits all" solution |
| 16:22 |
ireallyhateirc |
though I'd like to be proven wrong because it is indeed tedious |
| 16:26 |
nekobit |
One of the greatest things about dynamic programming languages is that you can do dynamic things with it |
| 16:34 |
|
bdju joined #minetest |
| 16:35 |
|
fluxionary joined #minetest |
| 16:39 |
ireallyhateirc |
fair |
| 16:53 |
|
mrkubax10 joined #minetest |
| 17:19 |
|
SliverFlowCipher joined #minetest |
| 17:33 |
|
bdju joined #minetest |
| 17:34 |
|
SliverFlowCipher joined #minetest |
| 17:41 |
|
Talkless joined #minetest |
| 17:47 |
|
gregon joined #minetest |
| 18:12 |
|
m33 joined #minetest |
| 18:14 |
|
imi joined #minetest |
| 18:15 |
|
Norkle joined #minetest |
| 18:15 |
|
Mocraft joined #minetest |
| 18:16 |
|
sid0 joined #minetest |
| 18:16 |
MTDiscord |
<luatic> nekobit: --world and --go together allows for a pretty fast workflow if your game starts up fast enough: up arrow, enter, test, exit, rinse and repeat |
| 18:16 |
nekobit |
i have it set to a sh while loop |
| 18:17 |
nekobit |
however live reloading would be very convenient |
| 18:17 |
MTDiscord |
<luatic> for specific stuff, you could implement hot reloading, or use existing things like https://content.minetest.net/packages/Just_Visiting/formspec_editor/ |
| 18:25 |
|
SliverFlowCipher joined #minetest |
| 18:28 |
nekobit |
Ta |
| 18:31 |
|
Thelie joined #minetest |
| 18:52 |
MTDiscord |
<wsor4035> you could use inotify to listen for save events, and restart a minetest process |
| 18:56 |
Krock |
read an environment variable within the main menu and auto-join a specific world |
| 18:57 |
Krock |
(overcomplicated solution for what's already implemented differently) |
| 19:34 |
nekobit |
wsor4935: That's true |
| 20:46 |
|
Verticen joined #minetest |
| 20:54 |
|
illwieckz joined #minetest |
| 22:15 |
|
cranez joined #minetest |
| 22:33 |
|
panwolfram joined #minetest |
| 23:05 |
|
Eragon joined #minetest |
| 23:30 |
|
BluebirdGrey51 joined #minetest |
| 23:32 |
BluebirdGrey51 |
Quick question, according to Lua docs I can transfer a VoxelManip into MT's async environment. Can I transfer it OUT? Example: huge tnt boom: on main thread, get voxelmanip, transfer to async. On async, compute all the tnt stuff, map changes, etc. Transfer to main thread. On main thread: apply voxelmanip to real map. Possible? |
| 23:35 |
BluebirdGrey51 |
Other example: large fortress/dungeon generation |
| 23:35 |
ireallyhateirc |
Haven't tried it, but api doc says this: minetest.handle_async(func, callback, ...): |
| 23:35 |
ireallyhateirc |
"When func returns the callback is called (in the normal environment) with all of the return values as arguments." |
| 23:35 |
MTDiscord |
<wsor4035> bluebird: you would probably want to use 5.9 async mapgen api |
| 23:36 |
ireallyhateirc |
not sure if mapgen environment would work for stuff like TNT? |
| 23:36 |
BluebirdGrey51 |
I'm using the 5.9 async mapgen already, but so far only for mapgenning new chunks. No idea how I could "rerun" it for tnt/fortress stuff? |
| 23:37 |
ireallyhateirc |
we will have this in the future: https://github.com/minetest/minetest/pull/14659 |
| 23:38 |
ireallyhateirc |
but again, for ordinary asynch envs I guess you can use the callback from minetest.handle_async |
| 23:39 |
ireallyhateirc |
so I believe the callback just handles stuff returned by the function ran in the asynch env? |
| 23:39 |
MTDiscord |
<wsor4035> you could also delete the area so it regenerates. assuming there is nothing of value there |
| 23:39 |
BluebirdGrey51 |
Yes, about the callback is what I am wondering: would it be able to receive the voxelmanip after the async thread was done with it. |
| 23:40 |
BluebirdGrey51 |
Area deletion is definitely not an option |
| 23:40 |
ireallyhateirc |
if not the voxelmanip object, you can still pass a copy of the (possibly outdated) flat array |
| 23:40 |
MTDiscord |
<wsor4035> minetest.handle_async(func, callback, ...) -> When func returns the callback is called (in the normal environment) with all of the return values as arguments. |
| 23:40 |
MTDiscord |
<wsor4035> read the docs? |
| 23:41 |
ireallyhateirc |
wsor4035, I just quoted this above |
| 23:41 |
BluebirdGrey51 |
Yes, but the docs also talk about serialization for parameters passed IN. If parameters passed out are also serialized, I don't know what this would do to the voxelmanip. I guess I could code up a test ... |
| 23:43 |
ireallyhateirc |
keep in mind that VM data can get outdated quickly |
| 23:43 |
ireallyhateirc |
so you probably need to calculate a diff |
| 23:44 |
ireallyhateirc |
or trust the data as is and hope you won't remove stuff players just did lol |
| 23:45 |
ireallyhateirc |
is your TNT example a real one? What's the average time needed for your VM operation? |
| 23:45 |
BluebirdGrey51 |
the tnt example is just an example, my real usecase is fortress generation (these can get up to 200 nodes in length/width). |
| 23:46 |
BluebirdGrey51 |
The fortresses are only supposed to generate at mapgen time, but for obvious reasons I can't do it on the mapgen thread. |
| 23:46 |
BluebirdGrey51 |
The mapchunks are too small. |
| 23:46 |
BluebirdGrey51 |
Though, even with TNT, a large explosion on my server, in the right location, can lag for up to 5 seconds. |
| 23:46 |
ireallyhateirc |
BluebirdGrey51, this shouldn't be a problem |
| 23:46 |
MTDiscord |
<wsor4035> or just break up your structure across chunks? see other mods for this |
| 23:47 |
ireallyhateirc |
mapgen does 1 mapchunk + mapblock margin |
| 23:47 |
ireallyhateirc |
so if you divide your structure into smaller parts that fit inside, you should be safe |
| 23:48 |
ireallyhateirc |
alternatively you can write some wicked overgeneration code like I did for my road generation in my Perfect City game |
| 23:49 |
BluebirdGrey51 |
If I understand rightly how it works, overgeneration is not possible on the mapgen thread, only on the main thread? |
| 23:49 |
BluebirdGrey51 |
At least IIRC the doc had some kind of warning. .. |
| 23:50 |
BluebirdGrey51 |
(I mean, overgeneration beyond the usual overgenerate margin) |
| 23:51 |
ireallyhateirc |
your fortress thing - is it a schematic or? |
| 23:52 |
BluebirdGrey51 |
it's a collection of schematics, which get combined together to form a fortress. |
| 23:53 |
|
book` joined #minetest |
| 23:53 |
ireallyhateirc |
if you divide the structure into pieces no bigger than a mapchunk and align the structure to the mapchunk grid, they you don't need overgeneration |
| 23:53 |
BluebirdGrey51 |
Generating it is basically 2 steps: 1) design the fortress, and create a huge table with all the layout info. 2) apply all the schematics to the voxelmanip using the data. |
| 23:54 |
BluebirdGrey51 |
Step 1 uses a pseudo random algorithm. |
| 23:54 |
ireallyhateirc |
you can do your own overgeneration if you get adjacent mapchunks and spawn the structure also in the adjacent chunks |
| 23:56 |
ireallyhateirc |
so you need a list of mapchunks that contain your module/prefab (for example a cube) |
| 23:56 |
ireallyhateirc |
then you need the absolute position where the module is placed |
| 23:56 |
ireallyhateirc |
and then you simply place the structure in the chunks |
| 23:58 |
ireallyhateirc |
Do you understand this or do you want me to draw it for you in GIMP? |
| 23:58 |
BluebirdGrey51 |
So, it sounds like my step 1 (the pseudo random algorithm) would need to use a seed number to produce exact results from one mapchunk to the next. |
| 23:58 |
ireallyhateirc |
yes, you need to make it reproducible |
| 23:59 |
BluebirdGrey51 |
Gotcha. |
| 23:59 |
ireallyhateirc |
use a randomseed that doesn't depend on blockseed or whatever the thing is |
| 23:59 |
ireallyhateirc |
I solved a similar problem here: https://codeberg.org/lord_of_the_dumpster/perfect_city/src/branch/master/mods/pcity_mapgen |
| 23:59 |
ireallyhateirc |
though it's a big blob of code that's not yet documented well |