| Time |
Nick |
Message |
| 00:00 |
MTDiscord |
<Jonathon> yes |
| 00:00 |
MTDiscord |
<ZweiKamel> That's a mod, isn't it? dynamic_liquid I believe |
| 00:01 |
fluxionary |
will look that up, but what i'm thinking is a change in what the engine does |
| 00:01 |
fluxionary |
though i suppose some of the ideas i've had could be fudged w/ a mod |
| 00:03 |
MTDiscord |
<ZweiKamel> That is an interesting idea, but we've been doing it like this since Minetest started |
| 00:03 |
fluxionary |
that's an interesting mechanic, but in particular i'm looking for something that doesn't suffer from the O(n^2) blow up from uncontrolled flow in huge caverns |
| 00:03 |
MTDiscord |
<ZweiKamel> oh yeah, that's a change I'd welcome |
| 00:03 |
MTDiscord |
<ZweiKamel> lol |
| 00:04 |
fluxionary |
ZweiKamel: yeah, i don't fully like it, but i want to see what if anyone said about this in the past before i start throwing around ideas or working on a possible solution |
| 00:04 |
fluxionary |
... what, if anything, anyone said ... |
| 00:05 |
fluxionary |
you've at least got me a big forum page to read for now |
| 00:05 |
|
erle joined #minetest |
| 00:06 |
MTDiscord |
<ZweiKamel> I haven't seen much of anything like that, sorry |
| 00:06 |
MTDiscord |
<ZweiKamel> I just searched it up in the Discord server |
| 00:06 |
MTDiscord |
<ZweiKamel> I found this though |
| 00:06 |
MTDiscord |
<ZweiKamel> https://cdn.discordapp.com/attachments/749727888659447960/976274614772703252/unknown.png |
| 00:06 |
MTDiscord |
<ZweiKamel> Thanks Warr1024 |
| 00:08 |
fluxionary |
lol |
| 00:08 |
fluxionary |
wait someone was talking about fluid cobwebs? O_O |
| 00:09 |
MTDiscord |
<ZweiKamel> yeah, that's how cobwebs work |
| 00:09 |
MTDiscord |
<ZweiKamel> they have viscosity, so they work by hacking the fluid mechanics |
| 00:09 |
MTDiscord |
<ZweiKamel> a goofy solution lol |
| 00:10 |
MTDiscord |
<Jonathon> i think some of wuzzys prs should help make the liquid hack less needed |
| 00:10 |
fluxionary |
i suppose that is a fluid mechanic. just not the same sort of mechanic i mentioned earlier. got it. |
| 00:10 |
fluxionary |
Jonathon: if you can get me links to those PRs i'd be curious to read them (even if they're rejected) |
| 00:10 |
fluxionary |
it's hard to find anything just searching "fluid" |
| 00:11 |
MTDiscord |
<Jonathon> there for not using fluid hacks for other things, you want just fluid things, right? |
| 00:12 |
MTDiscord |
<Jonathon> and search liquid, you get much better results |
| 00:12 |
fluxionary |
i want any talk about changing the "liquid flowing" mechanics in particular |
| 00:23 |
rubenwardy |
fluxionary: finite liquid was a feature of the engine a while back, was then removed though |
| 00:23 |
rubenwardy |
due to poor performance, glitches, and bad code |
| 00:23 |
rubenwardy |
that led to freeminer's creation |
| 00:24 |
fluxionary |
what's freeminer? |
| 00:25 |
MTDiscord |
<Jonathon> yet another minetest fork |
| 00:25 |
fluxionary |
i do see a reference to finite liquid somewhere, but no description of how it works: https://github.com/minetest/minetest/issues/1262 |
| 00:25 |
proller |
try any fm: server... |
| 00:29 |
|
Sven_vB joined #minetest |
| 00:42 |
proller |
rubenwardy, btw poor performance was/still in engine, not in liquids |
| 00:43 |
rubenwardy |
liquids are in the engine |
| 00:45 |
proller |
then why still whole engine not removed? |
| 01:04 |
|
proller joined #minetest |
| 01:28 |
|
erle joined #minetest |
| 01:31 |
|
specing_ joined #minetest |
| 01:31 |
fluxionary |
LOL |
| 01:44 |
|
Verticen joined #minetest |
| 01:45 |
Pexin |
"debugging is the process of removing bugs from a program, programming is the process of adding bugs to a program" |
| 01:46 |
MTDiscord |
<Warr1024> Incorrect. Programming is the process of adding new bugs, while debugging is the process of swapping old bugs out for new ones. |
| 01:47 |
Pexin |
:O |
| 01:48 |
MTDiscord |
<Warr1024> Programming increases the bug count, debugging decreases the average age :-) |
| 01:53 |
MTDiscord |
<Ronoaldo> Hi! Does anyone knows how to setup a lab with this mod? It is old, and it seems like sfan did it but I'm not sure how to setup the world/server to use it https://content.minetest.net/packages/sfan5/teaching/ |
| 01:53 |
MTDiscord |
<Ronoaldo> I tested with a server and no items show up on the sfinv craftguide, so I don't know how to create the questions after I have the teacher priv. |
| 02:28 |
|
queria^clone joined #minetest |
| 02:33 |
|
queria^clone joined #minetest |
| 02:48 |
Evergreen |
Is there a way to change where the ~/.minetest configuration directory is located? (for context I'm going on a bit of a home directory cleaning spree) |
| 02:49 |
Evergreen |
I suppose I could just RUN_IN_PLACE, but it would be nice to know if it's possible |
| 02:55 |
MTDiscord |
<Bastrabun> Isn't there a parameter like --configuration ? |
| 03:02 |
|
Sven_vB joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:04 |
MTDiscord |
<MisterE> yes, run <minetest_executable> --help |
| 04:05 |
MTDiscord |
<MisterE> there is a config file specifier option |
| 04:22 |
|
behalebabo joined #minetest |
| 04:41 |
|
lemonzest joined #minetest |
| 05:50 |
|
calcul0n joined #minetest |
| 05:58 |
|
riff_IRC joined #minetest |
| 05:59 |
|
Rafi592 joined #minetest |
| 06:00 |
|
Megaf_ joined #minetest |
| 06:25 |
sfan5 |
Ronoaldo: you can't craft them, use creative or giveme for that |
| 06:31 |
|
bdju joined #minetest |
| 06:45 |
|
wallabra joined #minetest |
| 08:12 |
|
harry-wood joined #minetest |
| 09:31 |
|
Fixer joined #minetest |
| 09:33 |
|
queria joined #minetest |
| 09:35 |
|
harry-wood joined #minetest |
| 09:38 |
|
appguru joined #minetest |
| 09:46 |
|
orwell96 joined #minetest |
| 09:59 |
|
orwell96 joined #minetest |
| 10:12 |
|
jni joined #minetest |
| 10:33 |
MinetestBot |
[git] paradust7 -> minetest/minetest: Use std::map instead of core::map (#12301) 273bfee https://github.com/minetest/minetest/commit/273bfee9a193d0dd2e9f9b400add980c0b5202a7 (2022-05-18T10:31:49Z) |
| 10:46 |
|
definitelya joined #minetest |
| 11:17 |
|
alguien joined #minetest |
| 11:40 |
alguien |
How do I get a list of force-loaded blocks? |
| 11:47 |
calcul0n |
alguien, not sure you can, core forceloading stuff is overriden by builtin lua code and made private |
| 11:47 |
calcul0n |
you can get still read persistent ones from force_loaded.txt but i guess it's not a good idea |
| 11:48 |
calcul0n |
see builtin/game/forceloading.lua in mt sources |
| 11:49 |
alguien |
calcul0n, thanks, force_loaded.txt will do |
| 11:50 |
alguien |
i don't need programmatic access this time |
| 11:53 |
definitelya |
Looks like it's compiling errors bonanza when making Minetest now. |
| 11:53 |
definitelya |
I hope it's fine ahah. |
| 11:56 |
sfan5 |
hm? |
| 11:57 |
definitelya |
Minetest throws a lot of warnings for me. I'll try making a clean build to see if it's just me. |
| 11:59 |
sfan5 |
don't forget to pull the newest source of irrlichtmt too when you update |
| 12:00 |
definitelya |
Yes, I did. |
| 12:02 |
definitelya |
hmmm why does Arch have cmake only up to version 3.23.1-1? |
| 12:02 |
definitelya |
That might be it. |
| 12:08 |
alguien |
calcul0n, umm wait, what's the format of force_loaded.txt? I get some big number as a key, and a 1 as a value |
| 12:09 |
MTDiscord |
<Warr1024> that's probably the block ID |
| 12:09 |
MTDiscord |
<Warr1024> there's a formula you can use to convert it to block coordinates |
| 12:09 |
MTDiscord |
<Warr1024> and then you multiply those by 16 to get the xmin, ymin and zmin of the node positions that block corresponds to |
| 12:10 |
definitelya |
The "dependencies" section in the README must be wrong then, because that is the last version. |
| 12:10 |
definitelya |
I'm confused. |
| 12:13 |
alguien |
calcul0n, or i guess that's why you gave me the reference to source, will look into |
| 12:13 |
sfan5 |
definitelya: what is the error you get |
| 12:14 |
definitelya |
Yes I'll post the error after building. |
| 12:19 |
alguien |
calcul0n, ok i got the permanent force-loaded areas. How about this though: Is there a way to see all blocks that are currently loaded (and then I can filter out the ones with players)? |
| 12:19 |
definitelya |
Mostly warnings, my mistake. |
| 12:30 |
definitelya |
https://0bin.net/paste/OUkLXKrT#OubhKg5khZLCdrhMsBvwVSoVg9biry9rRMH74YrROpL |
| 12:34 |
definitelya |
AFK |
| 12:35 |
calcul0n |
alguien, no idea, i doubt it's possible, at least without ugly hacks |
| 12:35 |
alguien |
calcul0n, ok thanks |
| 12:37 |
|
debiankaios joined #minetest |
| 12:46 |
|
erle joined #minetest |
| 12:51 |
sfan5 |
definitelya: that's cmake's verbose / debug output, not visible by default |
| 12:58 |
definitelya |
I see, thanks. Is it CMakeOutput.log? |
| 13:06 |
definitelya |
nvm |
| 13:06 |
definitelya |
Hang on, I'll do this right, sorry... |
| 13:12 |
sfan5 |
if you're looking at the log file you don't have to worry about the contents |
| 13:12 |
sfan5 |
relevant errors will pop up on the terminal during building |
| 13:14 |
definitelya |
OK, I'll post just that then. |
| 13:17 |
definitelya |
https://0bin.net/paste/WcXAw5DB#sGnxjUGEhUWStXxeEHdhE+FI0N-wx8qtInKx7TeQoSN |
| 13:21 |
definitelya |
I think I just caught many warnings. |
| 13:27 |
|
erstazi joined #minetest |
| 13:31 |
|
specing_ joined #minetest |
| 13:33 |
|
mannerism joined #minetest |
| 13:43 |
|
proller joined #minetest |
| 14:01 |
|
mrgreymatter joined #minetest |
| 14:07 |
|
Wuzzy joined #minetest |
| 14:08 |
Wuzzy |
Is there a way to find out in Lua whether the world is brand-new (i.e. it is the first time the server runs this world)? |
| 14:09 |
Wuzzy |
I want to write a compability layer for a new biome system after a major game update, and I want to avoid discontinutities in old worlds |
| 14:09 |
rubenwardy |
minetest.get_gametime() < 10 |
| 14:10 |
rubenwardy |
or lower |
| 14:10 |
rubenwardy |
< 0.5 will probably work if on first step |
| 14:37 |
Wuzzy |
interesting idea |
| 14:38 |
Wuzzy |
sounds hacky but ok :D |
| 14:39 |
MTDiscord |
<Warr1024> you could also store a flag in mod_storage, so you could tell "is this world new to this mod." Depends on whether you want to do your "one time" thing only for totally new worlds, or for worlds that just enabled the functionality or upgraded to it or something. |
| 14:40 |
Wuzzy |
hmmm |
| 14:41 |
Wuzzy |
that doesnt seem to work for upgrading. because with this approach (mod storage) i still cant distinguish between old world and new world |
| 14:41 |
erle |
the mod storage solution is hacky and i explicitly suggest to not do it |
| 14:41 |
MTDiscord |
<Warr1024> You MIGHT have to guard against the possibility someone created the world, thought "oh crap I forgot to enable that mod", quits within the first 10 seconds, then restarts it, so in either event you'd want some kind of state-tracking thing. |
| 14:41 |
MTDiscord |
<Warr1024> erle, "hacky" is a foregone conclusion here, it's just a question of which kinds of duct tape to use and how to get them working together properly. |
| 14:41 |
Wuzzy |
its not about external mods. its about a game |
| 14:42 |
erle |
the “correct” solution is, of course, biome blending in the outermost shell of newly generated nodes. |
| 14:42 |
MTDiscord |
<Warr1024> It sounds like what you want to do is keep the old biomes for old worlds for continuity's sake, and introduce the new biomes only in new worlds... |
| 14:43 |
erle |
if i had to implement that, i'd probably start with a method that tries to infer a biome of an existing mapblock |
| 14:43 |
MTDiscord |
<Warr1024> Frankly that's a tough one. |
| 14:43 |
erle |
which is still hacky, but doable |
| 14:43 |
MTDiscord |
<luatic> rubenwardy: < 0.5 is equivalent to < 1 because gametime is an int |
| 14:43 |
erle |
as you only need to evaluate the border |
| 14:43 |
erle |
if the border is air, no problems |
| 14:43 |
Wuzzy |
erle, thats not an option, the new biomes are radically different |
| 14:43 |
MTDiscord |
<Warr1024> Sort of makes me want to add a "record the version of the game the world is running only once if it's never been recorded before" kind of system so that I can make sure I don't run into a similar problem in the future. |
| 14:44 |
erle |
Warr1024 kay27 did that and he used mod storage and it was not good. broke both world downloads and i think something (crashing the server?) lead to holes in his world. |
| 14:44 |
erle |
kay wanted to sidestep the “mapgen runs lua stuff twice” thing by recording metadata about mapblocks |
| 14:44 |
rubenwardy |
mod storage like this only works with upgraded worlds, not new worlds |
| 14:45 |
rubenwardy |
bc just using mod storage won't let you tell a new world and an upgrade world apart |
| 14:45 |
erle |
yeah, but anyways, there are several circumstances in which the solution is racy, he posted the screenshots himself |
| 14:45 |
Wuzzy |
rubenwardy, minetest.get_gametime() returns nil when game just started :( |
| 14:45 |
MTDiscord |
<Warr1024> wait, wat? I'm pretty sure mod storage works with ALL worlds |
| 14:45 |
rubenwardy |
Wuzzy: game needs to have finished starting |
| 14:45 |
Wuzzy |
hmmm |
| 14:46 |
erle |
Wuzzy minetest.after(0, …) should get you to the first frame i think |
| 14:46 |
Wuzzy |
not even minetest.register_on_mods_loaded() works :O |
| 14:46 |
MTDiscord |
<Warr1024> after(0) is sort of what I assumed they'd be using |
| 14:46 |
erle |
did you try teh minetest.after hack? |
| 14:46 |
Wuzzy |
strange, minetest.after works but not minetest.register_on_mods_loaded O_O |
| 14:46 |
MTDiscord |
<Warr1024> there's a possibility you may be able to infer it from some other signal, like if there are player attributes you can check on the first player join or something |
| 14:46 |
MTDiscord |
<Warr1024> gametime might work, but having to pick some arbitary < X value sucks |
| 14:47 |
erle |
Wuzzy that is because minetest.after() only executes once the world is ready. it might not be ready when mods are ready. |
| 14:47 |
rubenwardy |
Wuzzy: register_on_mods_loaded is whilst the world is still loading |
| 14:47 |
rubenwardy |
minetest.after(0) runs on the first tick after the world has loaded |
| 14:47 |
MTDiscord |
<Warr1024> If there's something else that you would have already stored in mod_storage then you could make an inference from that. |
| 14:47 |
erle |
you can easily verify that by trying to find nodes or emerging stuff in register.on_mods_loaded() it should at best do nothing or return nothing |
| 14:47 |
erle |
at worst crash ig |
| 14:47 |
MTDiscord |
<Warr1024> I'm fairly sure that mod_storage is readable at load time because if it wasn't, then my "load saved state from mod storage at load time" stuff would all have been broken already... |
| 14:48 |
rubenwardy |
Warr1024: minetest.get_gametime() == 0 isn't that arbitrary |
| 14:48 |
MTDiscord |
<Warr1024> can you guarantee that a tick will run at exactly 0? |
| 14:48 |
erle |
Warr1024 mod storage is not robust for this solution, i think a) because it is racy b) because map downloads exist |
| 14:48 |
MTDiscord |
<Warr1024> is the first tick always at t=0, or is it after some dtime has already passed? |
| 14:48 |
rubenwardy |
Warr1024: gametime is an integer |
| 14:48 |
erle |
also because mod storage might be lost on upgrade if you do not convert, or was that handled automatically? |
| 14:49 |
erle |
(mod storage backend switch) |
| 14:49 |
MTDiscord |
<Warr1024> erle: again, it sounds like you're considering a solution that only involves one component, which is probably unrealistic here. Either way, after you've made the decision on old vs new biomes, you'll need to store this information somewhere. |
| 14:49 |
rubenwardy |
mod storage isn't converted automatically |
| 14:49 |
rubenwardy |
and when you do convert it, no data is lost |
| 14:49 |
MTDiscord |
<Warr1024> IIRC you always have to --migrate stuff if you switch backends; it's true of map, players, auth, etc. |
| 14:49 |
erle |
okay, i want to answer! |
| 14:50 |
rubenwardy |
the client converts client mod storage automatically, but that also migrates old day |
| 14:50 |
erle |
i have a solution, but you all won't like it |
| 14:50 |
rubenwardy |
-y+ta |
| 14:50 |
erle |
the solution is to place a single node signifying that you are using new biomes somewhere in the outermost part of the maps that are invisible. |
| 14:50 |
erle |
these mapblocks still exist, can be queried etc. pp. |
| 14:50 |
rubenwardy |
that's one of the worst solutions you could use |
| 14:50 |
erle |
it's the only one that is robust |
| 14:51 |
rubenwardy |
it's not |
| 14:51 |
erle |
why not |
| 14:51 |
rubenwardy |
what if the node is built over? What if that area of the map isn't loaded? |
| 14:51 |
MTDiscord |
<Warr1024> there's no robust solution that isn't vulnerable to SOME kind of tampering, even inadvertently |
| 14:51 |
erle |
if it is in the outermost mapblock, it is *really* hard to build over |
| 14:51 |
MTDiscord |
<Warr1024> you'll just have to design something that works well for a reasonably-behaved admin/user, and tolerate some failure scenarios. |
| 14:51 |
rubenwardy |
mod storage is by far a better way to store info here |
| 14:52 |
erle |
welp, i just realized that invisible mapblocks are never saved locally haha |
| 14:52 |
MTDiscord |
<Warr1024> if emerging some arbitrary mapblocks somewhere and storing metadata in there were a good solution I'd have probably already done it as a hack to store large-scale spatial metadata like mapblock-level meta :-D |
| 14:53 |
erle |
well, “somewhere” needs to be outside of usual bounds |
| 14:53 |
erle |
like in mineclone2 void or so |
| 14:53 |
erle |
anyways, any stateful solution can be corrupted i guess |
| 14:54 |
erle |
i have a possibly worst solution! |
| 14:54 |
Wuzzy |
thanks for your help so far, but it seems all solutions so far are really hacky, and i rather not rely on any hacks. i dont want to do the same mistake i didd with MCL2 |
| 14:54 |
erle |
what was themistake? |
| 14:54 |
MTDiscord |
<luatic> relying on hacks I guess :P |
| 14:54 |
Wuzzy |
MCL2 is kinda hacky |
| 14:54 |
erle |
mapgen in mcl2 is pretty hacky and clears out some stuff people build sometimes :( |
| 14:54 |
MTDiscord |
<luatic> Wuzzy: I fixed /time ~-00:05 BTW |
| 14:54 |
rubenwardy |
I don't think that using get_gametime is that hacky. "Seconds since world was created" is a good way to determine if the world was just created |
| 14:54 |
erle |
it's extremely hacky haha |
| 14:54 |
Wuzzy |
thank you |
| 14:54 |
MTDiscord |
<Warr1024> Basically, at load time, queue an after(0) and check get_gametime() in it. If it's below a reasonable threshold, like <10 (unless the first tick is guaranteed == 0) then it's a new world, else it's an old world. Whichever it is, store that somewhere so you don't end up switching crap around later. If mod storage won't work (like you need access to it too early) then I guess you might have to use an old fashioned file-in-world-dir or |
| 14:54 |
MTDiscord |
something ... but check and make sure mod_storage won't work first. |
| 14:55 |
MTDiscord |
<Warr1024> erle: your scale for "mildly" vs "extremely" hacky is tuned very wrongly for MT modding. |
| 14:56 |
erle |
Warr1024 i caused a lua stack overflow by building a giant nether portal, that is one inspiration for “extremely hacky”. the other is the various dupe bugs. |
| 14:56 |
erle |
a good hack is not bad though |
| 14:56 |
erle |
like liquid spiderwebs, i love that |
| 14:56 |
Wuzzy |
liquid spiderwebs are no longer required |
| 14:57 |
MTDiscord |
<luatic> there exist hacks to make the Lua stack infinite from within Lua using coroutines :) |
| 14:57 |
Wuzzy |
you can use move_resistance now |
| 14:57 |
erle |
Wuzzy and it is correctly sent to old clients? |
| 14:57 |
Wuzzy |
there is fallback code, yes |
| 14:57 |
erle |
well, i don't want any user to fall to their death if a spiderweb could have helped them |
| 14:58 |
erle |
anyways, what if you make the new mapgen generate new nodes and then check for the presence of these nodes? |
| 14:58 |
erle |
like, if air is so good, why not have air2 hehehehehehehe |
| 14:58 |
MTDiscord |
<Warr1024> To me whether something works or not is largely orthogonal to whether it's hacky or not. I've seen some very robust terrible hacks, and I've seen things done with the "proper" approach but still incorrectly. |
| 14:58 |
erle |
(i am half-joking) |
| 14:58 |
MTDiscord |
<luatic> We need Minetest 6.0 |
| 14:59 |
MTDiscord |
<luatic> It's time for all those breaking changes to happen |
| 14:59 |
MTDiscord |
<Warr1024> People calling for MT 6.0 don't seem to remember how painful it was to make the 0.4->5.0 transition :-) |
| 14:59 |
MTDiscord |
<luatic> Oh I remember it |
| 14:59 |
MTDiscord |
<luatic> Magic-CTF still hasn't been ported :-) |
| 14:59 |
Wuzzy |
I have created move_resistance because the spiderweb hack annoyed me :D |
| 14:59 |
MTDiscord |
<luatic> (or completed, for that matter) |
| 15:00 |
Wuzzy |
a lot of liquid features are decoupled now |
| 15:00 |
MTDiscord |
<Warr1024> I'm not against making a 6.0, but I'm just anticipating actually making it happen being pretty difficult. |
| 15:00 |
MTDiscord |
<luatic> But #12340 pretty much requires a breaking change. |
| 15:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/12340 -- Physics: Acceleration is severely broken |
| 15:00 |
MTDiscord |
<luatic> The non-breaking fix would be to add another object property or the like, which would make acceleration off on older clients. |
| 15:00 |
MTDiscord |
<luatic> Although TBF it is already off on older clients :-) |
| 15:00 |
MTDiscord |
<Warr1024> luatic: getting some momentum behind a push for 6.0 probably would involve someone creating a 6.0 label or milestone or something, and having a lot of juicy features pile up on it. |
| 15:01 |
rubenwardy |
https://github.com/minetest/minetest/blob/master/doc/breakages.md |
| 15:02 |
sfan5 |
I have never seen a more incomplete list |
| 15:02 |
MTDiscord |
<Warr1024> I have a fairly strict compat policy in NC, and my method for dealing with this stuff is largely adding compat hacks, and then scheduling removal of the hacks for some future release. I have a special list I keep for to-be-removed hacks. |
| 15:02 |
MTDiscord |
<luatic> sfan5: lol indeed |
| 15:02 |
MTDiscord |
<luatic> Warr1024: The problem in this case is that a hack is simply not possible as I have proven in the issue |
| 15:03 |
MTDiscord |
<Warr1024> A label or roadmap list thingy or something would be better for breaking changes than having to hand-curate an md file somewhere... |
| 15:03 |
MTDiscord |
<luatic> The error is partially determined by dtime (both on client & server), and as client dtime is an unknown variable to servers, it can't be used to correct the calculations. |
| 15:03 |
sfan5 |
the hack would be possible if we had CSM with custom physics prediction |
| 15:03 |
MTDiscord |
<luatic> sfan5: yes |
| 15:04 |
rubenwardy |
Yeah, I'm not a fan of the .md file |
| 15:04 |
rubenwardy |
it's annoying to edit |
| 15:04 |
MTDiscord |
<Warr1024> luatic: the hack would be a "enable_unfucked_physics" setting (server-wide) or a minetest.set_physics({integrals = "correct"}) API or something that takes effect world-wide. Old stuff can keep using the old stuff, new stuff sets the option and deals with the consequences ... and then you can remove the options and make the new way required in 6.0+ |
| 15:05 |
MTDiscord |
<Warr1024> It would need to be sent to the client as well for prediction, obv |
| 15:05 |
MTDiscord |
<luatic> Which is why I believe an object property is ideal if compat is intended. |
| 15:05 |
MTDiscord |
<Warr1024> it's an ugly hack, but you either do that and get it maybe in 5.6 or 5.7, or you don't and it's forced to 6.0+ only. |
| 15:05 |
MTDiscord |
<Warr1024> per-object would be fine too, if it's easy enough to do |
| 15:05 |
MTDiscord |
<Warr1024> but if it has to be all-or-nothing world-at-a-time, I think we could live with that too. |
| 15:06 |
sfan5 |
per-object is easy but I'm not convinced we want that |
| 15:06 |
sfan5 |
per-world is better |
| 15:06 |
Wuzzy |
ehh I guess my solution is to just a major release and announce compat-break :P |
| 15:06 |
sfan5 |
of course you need mods to agree on it, but fundamentally this is better |
| 15:06 |
Wuzzy |
better than relying on hacks |
| 15:06 |
MTDiscord |
<Warr1024> I mean if you make it per-object, that just means that I have to do some more work to enable it for each object ... but I personally wouldn't mind doing that work :-) |
| 15:06 |
rubenwardy |
this gravity/acc thing should be per-world, yeah |
| 15:06 |
MTDiscord |
Command sent from Discord by luatic: |
| 15:06 |
MTDiscord |
!? |
| 15:06 |
MTDiscord |
<luatic> global setting, per-world or per-object? |
| 15:06 |
MTDiscord |
<luatic> I lean towards the last one |
| 15:07 |
sfan5 |
global and per-world are essentially the same |
| 15:07 |
MTDiscord |
<luatic> because it allows mods to continue working properly without upgrading |
| 15:07 |
Wuzzy |
it would be nice if there is a function like mintest.is_this_a_new_world() :D |
| 15:07 |
MTDiscord |
<Warr1024> I can tell you that I'll probably enable it in my game for every world automatically, unless I need to provide an option to specifically opt out for players (but the old physics is "broken" enough for my game that an opt-out has little value), unless there turn out to be serious problems with it, which I don't expect. |
| 15:08 |
rubenwardy |
function minetest.is_new_world() return core.get_gametime() < 1 end |
| 15:08 |
rubenwardy |
jokes |
| 15:08 |
MTDiscord |
<Warr1024> The only way to do per-world settings is some kind of minetest.set_some_kind_of_option() API that's not persisted in settings and mods need to call at load time right now. Persisted per-world settings would be nice, but from what I can tell, not on the near horizon. |
| 15:10 |
MTDiscord |
<Warr1024> ruben: the thing about get_gametime() that concerns me is that it's possible for games to do a whole bunch of stuff on the first tick such that slow enough machines may take a couple seconds to fully initialize a world ... and if the first tick is not guaranteed to be at exactly t=0 before rounding, you can't be sure that a get_gametime() == 0 will ever happen. |
| 15:10 |
sfan5 |
we have per-world settings just nobody has told the modders |
| 15:10 |
MTDiscord |
<luatic> IIRC gametime is only incremented by server steps |
| 15:10 |
MTDiscord |
<luatic> so everything that runs before the first server step should be fine |
| 15:11 |
MTDiscord |
<luatic> sfan5: hence modders like me have implemented the entire setting hierarchy themselves :-) |
| 15:11 |
MTDiscord |
<Warr1024> get_gametime() basically as far as I can tell returns the equivalent of the rounded sum of all globalstep dtimes that the world has seen thus far. I actually have a separate hack to get the UN-rounded gametime by tracking it based on dtimes, though I initialize it from get_gametime() at startup, so there's always a bit of rounding error across restarts. |
| 15:12 |
MTDiscord |
<Warr1024> luatic: yeah, that's my question: does an after(0) run after the first internal server step, or before it? |
| 15:13 |
MTDiscord |
<luatic> FWIW: If called at loadtime, get_gametime returns nothing |
| 15:16 |
MTDiscord |
<luatic> Also gametime is in fact incremented before any globalsteps are called |
| 15:16 |
MTDiscord |
<luatic> Now I'm left to figure out whether the first globalstep is guaranteed to have dtime = 0 |
| 15:16 |
MTDiscord |
<Warr1024> ick |
| 15:16 |
MTDiscord |
<Warr1024> seems like it shouldn't; if it does, I'd be surprised. |
| 15:17 |
MTDiscord |
<Warr1024> so basically it sounds like get_gametime() == 0 is not robust. |
| 15:17 |
MTDiscord |
<luatic> It might be, there's interesting code to be found here, lol: if((dtime < 0.001) && !initial_step) return; |
| 15:17 |
MTDiscord |
<Warr1024> ? |
| 15:21 |
MTDiscord |
<luatic> According to some testing (minetest.register_globalstep(error)) dtime appears to be 0 the first step |
| 15:22 |
MTDiscord |
<luatic> get_gametime() == 0 is not robust for another reason though: What if Minetest is killed before a second in dtime has passed, or if Minetest fails to write the updated gametime? |
| 15:23 |
erle |
<luatic> It's time for all those breaking changes to happen |
| 15:23 |
erle |
luatic NO |
| 15:24 |
MTDiscord |
<luatic> erle YES |
| 15:24 |
MTDiscord |
<luatic> I can't deal with those broken physics! |
| 15:24 |
MTDiscord |
<luatic> They literally ruin all my hopes for accurate ballistics in Minetest! |
| 15:26 |
erle |
“and then you can remove the options and make the new way required in 6.0+” that is precisely the most asshole way to do it, if you a) introdce an option to keep the old behaviour b) then remove it |
| 15:26 |
MTDiscord |
<luatic> Whoa, I'm positively surprised |
| 15:26 |
MTDiscord |
<luatic> Some of the code is even correct: m_position += dtime * m_velocity + 0.5 * dtime * dtime * m_acceleration; |
| 15:26 |
MTDiscord |
<luatic> That's rubenwardy's precious SUVAT |
| 15:27 |
erle |
<sfan5> we have per-world settings just nobody has told the modders |
| 15:27 |
erle |
someone should tell Wuzzy i guess? ;) |
| 15:27 |
MTDiscord |
<luatic> So Minetest is even inconsistent about it's poor approximations :/ |
| 15:27 |
erle |
for the biome thing |
| 15:27 |
MTDiscord |
<luatic> its* |
| 15:28 |
MTDiscord |
<GoodClover> What's the actual reason for keeping the broken physics? Do any mods rely on it in some way? |
| 15:28 |
MTDiscord |
<luatic> olive: Gravity relies on it |
| 15:28 |
rubenwardy |
changing physics tends to break maps |
| 15:28 |
rubenwardy |
as parkour and puzzles rely on jump distance |
| 15:28 |
MTDiscord |
<GoodClover> ah yeah parkour is a good one |
| 15:29 |
erle |
i think there are two things: first, you have prediction being wrong between server and client, then you have the incorrect formula being used overall |
| 15:30 |
erle |
the prediction being wrong is a thing that should be fixed anyway, but the wrong formula thing needs to be kept if you want people to still, uh, get catapulted by accurate player-launchers and so on |
| 15:30 |
erle |
the problem is, of course, that stuff like jumping relies on the client |
| 15:31 |
erle |
you can, right now, even stand in mid-air if the client is desynced enough to believe there is something there |
| 15:31 |
MTDiscord |
<Warr1024> luatic, I have actually at some points considered just doing the corrected physics calcs myself in my own entity code and just pushing corrected pos and vel updates to the entity. Could be janky-looking at larger step sizes, but I care whether things work consistently first before I worry about beauty... |
| 15:31 |
MTDiscord |
<luatic> Technically I may argue that a correct formula would be identical to the wrong formula for infinitely small stepsizes :) |
| 15:31 |
MTDiscord |
<luatic> So this is no breakage, see (/s) |
| 15:32 |
Wuzzy |
how do per-world settings work? |
| 15:32 |
MTDiscord |
<luatic> This is hilarious! |
| 15:33 |
MTDiscord |
<luatic> @Warr1024 turns out the issue only applies to physical entities |
| 15:33 |
erle |
i have an even better excuse: the phyics equations were never documented, so OBVIOUSLY they can and HAVE to be changed each release |
| 15:33 |
MTDiscord |
<luatic> yay |
| 15:33 |
MTDiscord |
<luatic> 5.6 fixed physics lesgo! |
| 15:33 |
erle |
explain |
| 15:33 |
MTDiscord |
<Warr1024> wait, what's a non-physical entity? is that just a non-colliding one? |
| 15:33 |
MTDiscord |
<luatic> nonphysical entities use the correct formula |
| 15:33 |
MTDiscord |
<luatic> Warr1024: yes |
| 15:33 |
MTDiscord |
<Warr1024> so wait, turning on collisions turns OFF correct math? |
| 15:34 |
MTDiscord |
<luatic> Yes. |
| 15:34 |
erle |
why |
| 15:34 |
erle |
how did this happen |
| 15:34 |
MTDiscord |
<Warr1024> haha, that's beautiful |
| 15:34 |
MTDiscord |
<luatic> blame time |
| 15:34 |
MTDiscord |
<Warr1024> probably it was just implemented twice |
| 15:34 |
MTDiscord |
<luatic> I just feel we'll end up incorrectly blaming whoever last reworked the physics though :/ |
| 15:34 |
MTDiscord |
<luatic> Warr1024: yes, that's exactly the cas |
| 15:34 |
MTDiscord |
<luatic> e |
| 15:34 |
erle |
everyone is guilty hehehehe |
| 15:34 |
MTDiscord |
<luatic> and in collision.cpp it's implemented incorrectly as v3f newpos_f = *pos_f + *speed_f * dtime; |
| 15:35 |
erle |
the question is “how” not “who” |
| 15:35 |
MTDiscord |
<Warr1024> ironically it was probably implemented incorrectly once (due to the math being wrong) and then incorrectly again (due to the fact that a second implementation of the exact same thing is already wrong on another level) |
| 15:35 |
MTDiscord |
<luatic> Ah yes, very wise words // If there is no speed, there are no collisions |
| 15:35 |
MTDiscord |
<luatic> except these words are utterly wrong |
| 15:35 |
MTDiscord |
<luatic> because set_pos completely breaks that assumption |
| 15:36 |
erle |
what happens if an immovable object hits an immovable object |
| 15:36 |
MTDiscord |
<luatic> meaning the collision code will refuse to resolve such collisions |
| 15:36 |
erle |
i hope it does |
| 15:36 |
erle |
because otherwise you get bonkers situations in games |
| 15:36 |
MTDiscord |
<Warr1024> yeah, that's the issue, people using "collision" to mean "strike" in one sense, but "intersect with" in another sense. |
| 15:36 |
erle |
where you get in a wall and keep colliding with it |
| 15:36 |
erle |
and get flung out into space |
| 15:36 |
MTDiscord |
<luatic> mhm |
| 15:37 |
MTDiscord |
<luatic> well, I suppose mods can work around that tho |
| 15:37 |
erle |
at one point jordan implemented a spring-based collision model for mineclone2 mobs |
| 15:37 |
MTDiscord |
<Warr1024> collision is expected to mean "two things come into contact" in some cases, and "two things ARE in contact" in other cases. |
| 15:37 |
MTDiscord |
<luatic> haha this is hilarious |
| 15:37 |
MTDiscord |
<Warr1024> we need both |
| 15:37 |
erle |
i abused that spring-based model to create a mob launcher |
| 15:37 |
MTDiscord |
<luatic> because it checks the speed after applying the acceleration |
| 15:37 |
erle |
that flung cows around the map |
| 15:37 |
MTDiscord |
<luatic> (which is the wrong speed) |
| 15:37 |
erle |
(you drop the cows all into a small hole which has an opening at the side) |
| 15:37 |
MTDiscord |
<Warr1024> probably renaming "collision" to "contact" and then having like an is_new flag or something would help |
| 15:38 |
MTDiscord |
<luatic> luckily it checks against exact zero, which probably doesn't happen with floats due to precision issues |
| 15:38 |
MTDiscord |
<luatic> (i.e., an object which decelerates to a speed of zero would be consider not moving in the very step where it has decelerated to 0) |
| 15:39 |
definitelya |
erle: The most fun mechanic I found out these days has been shooting the rpg from rangedweapons to metal doors; they RICOCHET! |
| 15:39 |
MTDiscord |
<luatic> (but float precision issues probably save the day there) |
| 15:40 |
erle |
definitelya arrows in mineclon* games also ricochet at the right (not 90° obv) angles |
| 15:40 |
definitelya |
You can make an explosive fun course for the rocket too. |
| 15:40 |
MTDiscord |
<Warr1024> luatic, personally, I've run into trajectory inconsistency enough times that I actually prefer the option of keeping fixed timestep sizes and just tolerating heuristic math, rather than rely on correct calculus to fix the emergent behavior of the system. I'm pretty sure box2d doesn't do the math that wrong, but I couldn't get my love2d platformer to have a consistent jump height independent of fps until I moved the physics stuff into its |
| 15:40 |
MTDiscord |
own update cycle running at a fixed 120Hz. |
| 15:40 |
definitelya |
Awesome! |
| 15:41 |
erle |
but … heuristic math with fixed-size steps produces reconciliation problems if the steps do not match up? |
| 15:42 |
MTDiscord |
<Warr1024> steps do not match up with what? |
| 15:42 |
MTDiscord |
<luatic> client & server steps don't match |
| 15:42 |
MTDiscord |
<Warr1024> why wouldn't they? |
| 15:42 |
MTDiscord |
<Warr1024> you'd send the client the state at some step boundary |
| 15:42 |
MTDiscord |
<Warr1024> then it would run the same size steps from there |
| 15:42 |
MTDiscord |
<Warr1024> each step boundary would occur at the same points in time |
| 15:43 |
MTDiscord |
<Warr1024> then you'd just have the same normal network latency issues |
| 15:44 |
MTDiscord |
<Warr1024> I mean I think we have to operate under the assumption that the client-side prediction stuff is supposed to match up with the server-side logic, or else what the client is doing cannot really be called "prediction" |
| 15:44 |
erle |
right now, client “prediction” just continues stuff in a straight line at constant speed |
| 15:45 |
erle |
it's super stupid |
| 15:45 |
MTDiscord |
<Warr1024> it could be made less stupid if accel were included |
| 15:45 |
erle |
no, that's still stupid |
| 15:45 |
MTDiscord |
<luatic> I get the feeling Fleckenstein made a mistake in his PR as he just sets the speed to the average speed |
| 15:45 |
MTDiscord |
<Warr1024> we'll have to tolerate some non-zero amount of stupid either way, because not every object behaves in a perfectly ballistic way and only colliding with the scenery and other ents that already exist |
| 15:45 |
erle |
it would allow laggy things to accelerate more |
| 15:45 |
MTDiscord |
<luatic> But this may only be applied when calculating the position |
| 15:46 |
MTDiscord |
<luatic> Now I shall take a look at particles |
| 15:46 |
erle |
luatic particles are billboards with their own scenes, there, saved you a few minutes of your life |
| 15:46 |
MTDiscord |
<Warr1024> Fixing the client-side prediction issues in a non-stupid way is pretty straightforward, actually ... it just requires you to break causality. |
| 15:47 |
erle |
luatic or something like that :P |
| 15:47 |
MTDiscord |
<luatic> erle: I know already :P |
| 15:47 |
erle |
so what about particles |
| 15:47 |
MTDiscord |
<Warr1024> I've heard a lot about why particle render performance sucks, but what is it that makes entity rendering perf suck? |
| 15:47 |
MTDiscord |
<luatic> same thing basically AFAIK |
| 15:47 |
erle |
is it drawcalls |
| 15:47 |
MTDiscord |
<luatic> they too use one drawcall per entitiy |
| 15:47 |
MTDiscord |
<luatic> entity* |
| 15:47 |
MTDiscord |
<luatic> rather than doing a bulk drawcall for all entities of the same kind |
| 15:48 |
MTDiscord |
<Warr1024> how fixable is that? |
| 15:48 |
MTDiscord |
<luatic> ¯_(ツ)_/¯ |
| 15:48 |
sfan5 |
there is no entity culling |
| 15:48 |
MTDiscord |
<Warr1024> what does "same kind" mean here? same drawtype? Same model? Same textures? |
| 15:48 |
MTDiscord |
<luatic> I'd approach fixing it in raw OGL, but with the Irrlicht fluff I CBA |
| 15:48 |
sfan5 |
is IMO the more relevant limitation |
| 15:48 |
MTDiscord |
<luatic> Same model pretty much |
| 15:48 |
MTDiscord |
<Warr1024> I'd very much like to see entity rendering improved; it's probably the single biggest rendering-speed-related headache that my players face routinely. |
| 15:48 |
erle |
“batch drawcalls for stuff of the same type” is something that is a recurring topic in irrlicht forums, they might have an answer (or several) |
| 15:49 |
MTDiscord |
<Warr1024> about 99% of the entities involved, in my case, are static and immobile, and could even be baked into the mapblock meshes, if such a thing were possible. |
| 15:49 |
erle |
for particles in particular, batching it by texture is how i would do it (if i knew how) |
| 15:50 |
erle |
in mineclonia, we made chests non-animatable after a griefer placed a lot of chest entities around spawn |
| 15:50 |
MTDiscord |
<luatic> Ah shit, particles are handled pretty much the same way as entities |
| 15:51 |
MTDiscord |
<luatic> LOL |
| 15:51 |
MTDiscord |
<luatic> Minetest quantum physics :o |
| 15:51 |
MTDiscord |
<luatic> If you set collision removal = true, you get particles with broken physics despite them being removed on the first collision |
| 15:51 |
erle |
amazing |
| 15:52 |
MTDiscord |
<luatic> NVM, particle physics are broken either way |
| 15:52 |
erle |
luatic here is a list to look for more bullshit in the engine https://github.com/minetest/minetest/issues/10647#issuecomment-731739227 |
| 16:07 |
erle |
hey Wuzzy i have been making medieval-styled treasure maps, do you have a mod to include them to? |
| 16:07 |
erle |
Wuzzy i vaguely remember that you had some treasure chest thing, but maybe i remember it wrong |
| 16:09 |
erle |
maybe i should just make the maps point to railcorridors |
| 16:11 |
|
___nick___ joined #minetest |
| 16:17 |
Wuzzy |
what do you mean? |
| 16:17 |
Wuzzy |
do you need treasure chests?# |
| 16:18 |
rubenwardy |
Treasurer? |
| 16:18 |
rubenwardy |
I used that in CTF |
| 16:18 |
Wuzzy |
I did that treasurer mod ages ago but it didnt gain traction due to complexity, i guess |
| 16:19 |
|
sometalgoo joined #minetest |
| 16:48 |
|
Verticen joined #minetest |
| 16:49 |
|
orwell96 joined #minetest |
| 16:58 |
|
MinionKIRC joined #minetest |
| 16:58 |
MinionKIRC |
Uhmm guys |
| 16:59 |
MinionKIRC |
is it known that client side mods folder randomly can disapear? |
| 16:59 |
MinionKIRC |
Becuase I lost my clientsidemods folder |
| 17:00 |
MinionKIRC |
The only thing i have done yesterday, when it still worked, was getting sscsm working... Btw yesterday it still existsed |
| 17:00 |
MinionKIRC |
but today it is gone |
| 17:00 |
MinionKIRC |
I will try to get my dad to find and restore the folder, but this is really strange |
| 17:00 |
|
gera left #minetest |
| 17:03 |
MinionKIRC |
I gtg now |
| 17:13 |
|
erstazi joined #minetest |
| 17:13 |
|
___nick___ joined #minetest |
| 17:14 |
|
Talkless joined #minetest |
| 17:16 |
|
___nick___ joined #minetest |
| 17:19 |
erle |
what if SSCSM has not been working because as soon as it gets done, some higher being intervenes |
| 17:19 |
erle |
and deletes it |
| 17:20 |
erle |
hehe |
| 17:20 |
|
Taoki joined #minetest |
| 17:20 |
|
est31 joined #minetest |
| 17:21 |
erle |
Wuzzy rubenwardy so far, fleckenstein has only used the maps thing for a somewhat realistic rendering (see mineclone2 mcl_maps), i want a medieval-style pirate's chest map. so i see two ways for that to go. first, players make them and right clicking a chest sets the coordinates. second, they are generated and point to treasure far away. |
| 17:22 |
erle |
Wuzzy rubenwardy you can see such a map rendering in the lower right here, but i need to work on the trees https://mister-muffin.de/p/rXJe.png |
| 17:24 |
|
alguien joined #minetest |
| 17:46 |
|
___nick___ joined #minetest |
| 18:02 |
|
orwell96 joined #minetest |
| 18:14 |
erle |
still not satisfied with the tree rendering https://mister-muffin.de/p/tDnl.png |
| 18:40 |
|
Thelie joined #minetest |
| 18:55 |
|
sobkas joined #minetest |
| 18:57 |
|
Warr1024 joined #minetest |
| 19:14 |
erle |
sfan5 luatic btw since the question came up what i can do with paletted images that i can not do with RGBA images: have the same color for dark lines in the colormap for the medieval-style map, but still have it distinguishable if i want a colored version of the map. |
| 19:18 |
Pexin |
erle: I doubt minetest can update the image if they palette is dynamically modified, but have you seen some of the things sega genesis games did with it? |
| 19:18 |
erle |
Pexin, i use this thing to draw trees where no other trees are https://mister-muffin.de/p/p7Lt.png |
| 19:19 |
MTDiscord |
<Warr1024> erle: hiding invisible metadata behind duplicate palette entries ... that's a pretty cool trick, actually. |
| 19:19 |
erle |
trees can overlap coastline, but not other trees. but they have the same color as the other trees. |
| 19:19 |
erle |
and the coastline |
| 19:21 |
erle |
Warr1024 Wuzzy luk3yx luatic what except water/land and trees would you want on a map. i mean a big X for a treasure of course. and skull and bones for bone blocks or so hehe |
| 19:22 |
Pexin |
I imagine identifying a steep peak as a "mountain" would be a nightmare to codify |
| 19:23 |
Pexin |
and such irl maps generally have some visual cue for like swamps don't they? |
| 19:23 |
Pexin |
at this resolution though, any such attempt would be a mess |
| 19:24 |
MTDiscord |
<Warr1024> you could do contour lines by identifying thresholds between areas taller than and areas shorter than certain breakpoints. |
| 19:24 |
erle |
i accidentally went quadratic when i had the stupid idea to compare each tree to each other tree to prevent overlaps |
| 19:24 |
erle |
so now i only test at drawing time hehe |
| 19:24 |
MTDiscord |
<Warr1024> basically find every x/z pos where y > threshold, and then color pixels if they are, AND are adjacent to another pos <= threshold. Could do the latter as a second pass. |
| 19:25 |
Pexin |
yeah topo maps would be awful at this res |
| 19:25 |
MTDiscord |
<Warr1024> you could also really just draw a little mountain peak icon or something at the highest y point on the map |
| 19:25 |
erle |
i can do heightmaps |
| 19:25 |
erle |
in fact i did heightmaps as the very first thing |
| 19:25 |
MTDiscord |
<Warr1024> artificial structures of course might make things ... interesting? |
| 19:25 |
erle |
it does not look hand-drawn enough |
| 19:25 |
Pexin |
maybe if the iso regions are gradient shaded |
| 19:26 |
MTDiscord |
<Warr1024> you can make it look hand drawn |
| 19:26 |
MTDiscord |
<Warr1024> I'm thinking of those iso-whatever contour lines |
| 19:26 |
erle |
i can shade ice or so |
| 19:26 |
MTDiscord |
<Warr1024> and you can also make them "approximate" to give more of a hand-drawn impression |
| 19:26 |
erle |
no |
| 19:26 |
erle |
i hate dishonest design |
| 19:26 |
erle |
i will not blur or jitter anything |
| 19:26 |
erle |
a friend suggested i add sea monsters to the ocean |
| 19:26 |
erle |
but i will not do it |
| 19:26 |
erle |
everything must have a purpose |
| 19:26 |
MTDiscord |
<Warr1024> no, I'm thinking more like just dividing your map up into larger cells and do the topo stuff based on cells |
| 19:27 |
MTDiscord |
<Warr1024> it's not "dishonest," it's just that you don't necessarily need to represent every little bump on a map. |
| 19:27 |
MTDiscord |
<Warr1024> If you try to keep every detail you'll just end up with a mess |
| 19:31 |
Pexin |
erle: re your previous comment, I would favor option 2: "they are generated and point to treasure far away" |
| 19:32 |
erle |
btw, code is here https://git.minetest.land/erlehmann/maps |
| 19:32 |
erle |
needs tga_encoder mod |
| 19:33 |
erle |
just in case you want to play around with it |
| 19:33 |
erle |
and yes i know the X sometimes does not update |
| 19:34 |
Pexin |
what does it look like in a deepcave |
| 19:41 |
erle |
Pexin, this is a bunch of maps i generated https://mister-muffin.de/p/zwRf.png |
| 19:45 |
Pexin |
that looks a lot like a 15-tile-slider puzzle thing and now I'm feeling very OCD. |
| 19:57 |
|
appguru joined #minetest |
| 20:05 |
|
rymiel joined #minetest |
| 20:05 |
Wuzzy |
erle, height lines for the landmass, maybe? |
| 20:06 |
Wuzzy |
but water/land is alreay a good start |
| 20:06 |
Wuzzy |
it really depend on the type of game, really |
| 20:07 |
erle |
Wuzzy i obviously want to make a general maps API, but for treasure maps … those rarely include height contour lines |
| 20:07 |
erle |
and also not biomes |
| 20:07 |
erle |
there is so much i can graph that i do not want to graph |
| 20:09 |
erle |
btw, there are some trees in water and the answer is always: overhangs |
| 20:12 |
erle |
i wish HuguesRoss could chime in, after all, only fleck, and HuguesRoss and me made maps as far as i know |
| 20:18 |
|
orwell96 joined #minetest |
| 20:19 |
erle |
trees are no longer drawn in water (i.e. if they are on an overhang) https://mister-muffin.de/p/xVAD.png |
| 20:28 |
|
proller joined #minetest |
| 20:51 |
|
Thelie joined #minetest |
| 20:53 |
|
simon816 joined #minetest |
| 21:26 |
|
Thomas-S joined #minetest |
| 21:54 |
|
Sven_vB joined #minetest |
| 22:00 |
|
Sven_vB joined #minetest |
| 22:17 |
|
riff-IRC joined #minetest |
| 22:36 |
|
panwolfram joined #minetest |
| 23:13 |
|
Alias joined #minetest |
| 23:14 |
|
Lesha_Vel joined #minetest |
| 23:15 |
|
Lesha_Vel joined #minetest |
| 23:28 |
|
Sven_vB_ joined #minetest |
| 23:41 |
|
AliasAlreadyTake joined #minetest |
| 23:49 |
|
sometalgoo joined #minetest |
