| Time |
Nick |
Message |
| 00:05 |
VanessaE |
greetz, RBA |
| 00:06 |
|
Robby_ joined #minetest-dev |
| 00:06 |
|
rmilan_ joined #minetest-dev |
| 00:06 |
|
hontss joined #minetest-dev |
| 00:06 |
|
sfan5_ joined #minetest-dev |
| 00:49 |
|
ImQ009 joined #minetest-dev |
| 01:02 |
|
book` joined #minetest-dev |
| 01:07 |
|
book` joined #minetest-dev |
| 01:21 |
|
book` joined #minetest-dev |
| 02:38 |
|
sol_invictus joined #minetest-dev |
| 03:13 |
|
Sokomine_ joined #minetest-dev |
| 03:18 |
|
Sokomine joined #minetest-dev |
| 03:43 |
|
Hunterz joined #minetest-dev |
| 04:04 |
|
Miner_48er joined #minetest-dev |
| 04:15 |
|
cg72 joined #minetest-dev |
| 04:18 |
cg72 |
ok if im checking a node to see whats under it and the chunk under its not loaded what will the check return???? |
| 04:21 |
VanessaE |
"ignore" |
| 04:21 |
VanessaE |
that is, the node name will be "ignore" if you do e.g. minetest.get_node() on an unloaded block |
| 04:24 |
cg72 |
ok cuz my treedecay is ok till they get taller lol |
| 05:16 |
|
RealBadAngel joined #minetest-dev |
| 05:17 |
|
cg72 left #minetest-dev |
| 05:31 |
|
Eater4 joined #minetest-dev |
| 05:39 |
|
Hunterz joined #minetest-dev |
| 05:53 |
|
^v joined #minetest-dev |
| 05:56 |
|
darkrose joined #minetest-dev |
| 06:22 |
|
Eater4 joined #minetest-dev |
| 06:59 |
|
CraigyDavi` joined #minetest-dev |
| 07:14 |
|
nore joined #minetest-dev |
| 07:28 |
|
iqualfragile joined #minetest-dev |
| 08:12 |
|
Anchakor_ joined #minetest-dev |
| 09:04 |
|
Amaz joined #minetest-dev |
| 09:23 |
|
SmugLeaf joined #minetest-dev |
| 09:37 |
|
Calinou joined #minetest-dev |
| 10:13 |
|
Weedy joined #minetest-dev |
| 10:13 |
|
Weedy joined #minetest-dev |
| 10:39 |
|
Megaf joined #minetest-dev |
| 11:11 |
|
PilzAdam joined #minetest-dev |
| 11:13 |
|
proller joined #minetest-dev |
| 12:33 |
|
nore joined #minetest-dev |
| 12:34 |
|
ImQ009 joined #minetest-dev |
| 13:20 |
|
hintss joined #minetest-dev |
| 13:21 |
|
Evergreen_ joined #minetest-dev |
| 13:23 |
|
EvergreenTree joined #minetest-dev |
| 14:13 |
|
Eater4 joined #minetest-dev |
| 14:38 |
|
VanessaE joined #minetest-dev |
| 14:40 |
|
rubenwardy joined #minetest-dev |
| 14:45 |
|
PenguinDad joined #minetest-dev |
| 14:48 |
|
proller joined #minetest-dev |
| 14:49 |
|
iqualfragile joined #minetest-dev |
| 15:07 |
celeron55 |
some recent optimization stuff in MCPE, if someone is interested: https://tomcc.github.io/2014/08/31/visibility-1.html https://tomcc.github.io/2014/08/31/visibility-2.html |
| 15:08 |
* sfan5 |
saw that blog post but didn't read it yet |
| 15:08 |
VanessaE |
THOSE are minecraft's caves? |
| 15:21 |
VanessaE |
hm, breadth-first search eh |
| 15:21 |
VanessaE |
didn't I suggest something like this a while back? :) |
| 15:21 |
sfan5 |
sounds interesting |
| 15:21 |
|
hmmmm joined #minetest-dev |
| 15:21 |
sfan5 |
but I dunno about 3D graphics stuff |
| 15:22 |
VanessaE |
specifically to address the stuttering problem with the view range tuner, that is |
| 15:22 |
sfan5 |
don't we have a wireframe mode in mt? |
| 15:22 |
VanessaE |
start at the player, start rendering stuff close by, keep adding stuff that's further out until you run out of time at the current fps |
| 15:22 |
sfan5 |
hmm |
| 15:22 |
sfan5 |
no |
| 15:22 |
VanessaE |
sfan5: I think so but how to turn it on, no idea. |
| 15:23 |
sfan5 |
I made minetest use wireframes |
| 15:23 |
sfan5 |
but as always I stored the code in /tmp |
| 15:23 |
sfan5 |
because it was.. well.. temporary |
| 15:23 |
VanessaE |
couldn't hurt to add that code back into mainline, might be useful for testing in the future. |
| 15:24 |
VanessaE |
(if you can recreate it I mean) |
| 15:24 |
sfan5 |
I probably can |
| 15:24 |
sfan5 |
>setMaterialFlag(video::EMF_WIREFRAME,t |
| 15:24 |
sfan5 |
there it is |
| 15:25 |
VanessaE |
attach it to F9 or some such |
| 15:25 |
|
twoelk joined #minetest-dev |
| 15:28 |
kahrl |
I don't think we should add an X-ray to the standard client |
| 15:28 |
twoelk |
could that wireframe view be tweaked to also study cave-gereating in air or maybe disblay chunk borders to detect border issues? |
| 15:29 |
twoelk |
maybe add to minimal? |
| 15:29 |
VanessaE |
kahrl: wireframe just showing what the user normally sees? |
| 15:29 |
VanessaE |
(+ caves, e.g. similar to that screenshot) |
| 15:30 |
VanessaE |
it's not like the user's gonna be able to see where all the mese is. |
| 15:31 |
kahrl |
VanessaE: yeah it's not useful for finding ores in stone, but as you can see on the screenshot in that article you can see abandoned mineshafts and big lava-level caves |
| 15:31 |
kahrl |
which are often very profitable |
| 15:31 |
VanessaE |
hm. good point |
| 15:31 |
VanessaE |
I guess that's what all the orange is? |
| 15:31 |
kahrl |
yep |
| 15:31 |
VanessaE |
didn't think about that - I've never played Minecraft. |
| 15:32 |
sfan5 |
gur.com/q1ZUsLs.png |
| 15:32 |
sfan5 |
fail |
| 15:32 |
sfan5 |
http://i.imgur.com/q1ZUsLs.png |
| 15:32 |
VanessaE |
\o/ |
| 15:32 |
sfan5 |
upon entering the ground all the caves get rendered |
| 15:32 |
VanessaE |
that was easy |
| 15:32 |
sfan5 |
that could be improved |
| 15:34 |
twoelk |
only node sides as viewed with noclip in that pic? |
| 15:35 |
VanessaE |
shows how much gets drawn that shouldn't be huh. |
| 15:35 |
VanessaE |
sfan5: what's that little bit of something just above and left of the target? |
| 15:35 |
VanessaE |
(four very short lines) |
| 15:36 |
sfan5 |
VanessaE: ¯\_(ツ)_/¯ |
| 15:36 |
sfan5 |
probably desert grass that has changed it's rotation because wave shaders |
| 15:37 |
VanessaE |
ah |
| 15:38 |
|
SmugLeaf joined #minetest-dev |
| 15:38 |
|
SmugLeaf joined #minetest-dev |
| 16:07 |
|
Hunterz joined #minetest-dev |
| 16:08 |
|
zat joined #minetest-dev |
| 16:34 |
|
khonkhortisan joined #minetest-dev |
| 16:44 |
|
Calinou joined #minetest-dev |
| 16:47 |
|
Krock joined #minetest-dev |
| 16:48 |
hmmmm |
hrmmm |
| 16:48 |
hmmmm |
i wonder if there will ever be a situation where we'll use VoxelManipulators on the client side |
| 16:49 |
VanessaE |
finding surfaces for mobs to spawn on maybe? |
| 16:49 |
hmmmm |
i don't want mobs to ever spawn on the client |
| 16:49 |
VanessaE |
that and realtime sound effects are the only two things I can think of that client-side modding would really be appropriate for at this point |
| 16:50 |
VanessaE |
well to *walk* on then. |
| 16:50 |
VanessaE |
otherwise, no |
| 16:50 |
VanessaE |
I don't see a reason for it |
| 16:50 |
hmmmm |
hmmm |
| 16:50 |
hmmmm |
no we don't need that |
| 16:50 |
hmmmm |
we have lua pathfinding |
| 16:51 |
VanessaE |
right |
| 16:51 |
VanessaE |
so yeah, I would just not bother considering that possibility for now. there's no logical reason to use an lvm on the client |
| 16:51 |
hmmmm |
good |
| 16:52 |
VanessaE |
I could see an argument for distributed computing using clients - that's how MC is able to handle so many at once, I'm told - but that's WAY out of scope here. |
| 17:08 |
|
Krock2 joined #minetest-dev |
| 17:10 |
VanessaE |
kahrl: *poke* |
| 17:11 |
|
Miner_48er joined #minetest-dev |
| 17:13 |
|
SoniEx2 joined #minetest-dev |
| 17:18 |
hmmmm |
I feel as if removeNode* functions are just a gigantic duplication of effort |
| 17:18 |
hmmmm |
you could easily trim those to remove a couple hundred LoC easily |
| 17:31 |
|
SoniEx2 joined #minetest-dev |
| 17:36 |
|
SmugLeaf joined #minetest-dev |
| 17:43 |
kahrl |
VanessaE: peek? |
| 17:44 |
ShadowNinja |
sfan5: The wireframe view definitely seems usefull. Maybe bind it to a key and surround it with #ifndef NDEBUG? |
| 17:46 |
VanessaE |
kahrl: just reminding you about that no-extrude patch. it still works. Would be nice to see it merged as an option in the settings menu. |
| 17:46 |
Krock |
Bug: Direct3d8 isn't showing up in the settings tab - do I need to create an issue or does someone have free time to fix it? |
| 17:47 |
sfan5 |
ShadowNinja: maybe |
| 17:49 |
ShadowNinja |
Krock: Is your build compiled with Direct3D8 support? |
| 17:49 |
kahrl |
VanessaE: I'd prefer to fix the extrusion routine, but I don't really have good ideas for that, so I guess the setting is fine |
| 17:50 |
Krock |
ShadowNinja, yup. I replaced Irrlicht.dll with my new build |
| 17:50 |
Krock |
ShadowNinja, and minetest works with it |
| 17:51 |
ShadowNinja |
Krock: driver=direct3d8 works, but it isn't in the settings menu? |
| 17:51 |
sfan5 |
ShadowNinja: why would you want to use d3d8? |
| 17:51 |
ShadowNinja |
sfan5: Ask Krock. |
| 17:52 |
Krock |
ShadowNinja, exactly. I possibly found the bug. In the title, it says "Direct3D 8.1" |
| 17:52 |
Krock |
but the driver is set with direct3d8 |
| 17:52 |
ShadowNinja |
Krock: Odd, you should ask sapier about that. |
| 17:53 |
Krock |
ShadowNinja, or I'll look into the codes first. I'll tall him about this if I can't find it |
| 17:53 |
sfan5 |
Krock: are you complaining about the ".1"? |
| 17:53 |
Krock |
sfan5, I don't know if that's the reason for not having it in the settings menu |
| 17:53 |
ShadowNinja |
Krock: If you're using a different build of Irlicht than you compiled with that might be the issue though. |
| 17:53 |
sfan5 |
Krock: thats not the reason |
| 17:54 |
Krock |
ShadowNinja, I compiled the non-direct3d8 and the one with on the same PC |
| 17:57 |
hmmmm |
has this thing ever been seen with splizzard's mod? http://pastebin.com/f0ZFd00p |
| 17:57 |
hmmmm |
or did I make it do that :< |
| 17:57 |
VanessaE |
not sure, hmmmm. |
| 17:59 |
ShadowNinja |
Krock: Doesn't matter. Use the same library for building and using and see if it works. |
| 17:59 |
Krock |
ShadowNinja, I found the bug . |
| 17:59 |
Krock |
https://github.com/minetest/minetest/blob/master/src/script/lua_api/l_mainmenu.cpp#L1008 |
| 17:59 |
Krock |
possibly. |
| 18:00 |
Krock |
lua requests core.get_video_drivers() and doesn't get direct3d8 |
| 18:00 |
hmmmm |
vanessae, shouldn't Pine Needles be added to the leaves group? they aren't decaying |
| 18:00 |
hmmmm |
nevermind about that |
| 18:00 |
VanessaE |
heh |
| 18:01 |
VanessaE |
moretrees manages leaf decay on its own, yeah |
| 18:01 |
|
rubenwardy joined #minetest-dev |
| 18:02 |
kahrl |
Krock: perhaps you've compiled minetest with the non-direct3d8 Irrlicht's headers |
| 18:02 |
Krock |
kahrl, I can play with direct3d8... |
| 18:02 |
ShadowNinja |
^ |
| 18:02 |
Krock |
oh wait |
| 18:03 |
Krock |
but yes, nvm, it doesn't matter because I can play it... |
| 18:03 |
kahrl |
Krock: yeah, but isDriverSupported is in the header, not the DLL |
| 18:03 |
ShadowNinja |
Krock: Minetest might not think it supports D3D8 because of the headers it was compiled with, but the function calls still work bacause the DLL that it uses actually does have support for it. |
| 18:04 |
Krock |
kahrl, ShadowNinja: but well, there is still a way to detect if the driver is supported or not, without looking at headers |
| 18:04 |
Krock |
because it throws an error when I use my older Irrlicht build |
| 18:06 |
ShadowNinja |
Krock: But that's not the right way to do it. That's trying it and seeing if it breaks instead of just checking if it will work beforehand. |
| 18:07 |
kahrl |
if fact, doing that would be stupid because some drivers might crash minetest when they are created (see sapier and video_driver = software) |
| 18:07 |
kahrl |
in fact* |
| 18:09 |
* Krock |
points at https://github.com/minetest/minetest/blob/master/src/main.cpp#L1385 |
| 18:09 |
* Krock |
unpoints cuz he noticed how he failed |
| 18:14 |
|
NakedFury joined #minetest-dev |
| 18:22 |
|
Krock2 joined #minetest-dev |
| 18:24 |
hmmmm |
wtf |
| 18:24 |
hmmmm |
land of the cut-off trees |
| 18:24 |
hmmmm |
did somebody do something lately concerning mapgen because the last time I worked on anything this did not break |
| 18:29 |
hmmmm |
jesus christ the regressions |
| 18:31 |
Sokomine |
hmmm: do you have a screenshot at hand? |
| 18:31 |
hmmmm |
no. I can see it perfectly fine |
| 18:32 |
hmmmm |
happened sometime in between e9e9e42573a50dbf94370996d65b03dca1d5c284 and e14c4cdd4c3c9b554dc9cb91f8f29078ad337ded |
| 18:33 |
Sokomine |
hmmmm: posting a screenshot might help to find out if the phenomenon was observed by others before |
| 18:33 |
hmmmm |
perhaps. i don't really need to find that out though |
| 18:35 |
hmmmm |
you know what, I bet this was my own stupid doing |
| 18:36 |
iqualfragile |
hmmmm: lava flows into ungenerated mapblocks |
| 18:41 |
hmmmm |
whoops, sorry guys, i broke the trees |
| 18:42 |
hmmmm |
well derp |
| 18:42 |
* VanessaE |
mumbles incoherently |
| 18:42 |
hmmmm |
>tfw you accidentally griefed hundreds of peoples' servers |
| 18:44 |
VanessaE |
hmmmm: shit happens. |
| 18:45 |
hmmmm |
well i think it might be possible, pending the response from this one guy who made an issue like 3 weeks ago. |
| 18:45 |
VanessaE |
is this perhaps the cause of the ordeal we've been arguing about for the past few days? |
| 18:45 |
hmmmm |
no |
| 18:45 |
VanessaE |
ok |
| 18:45 |
hmmmm |
i have that fixed |
| 18:45 |
VanessaE |
can't blame me for hoping ;) |
| 18:45 |
hmmmm |
https://github.com/kwolekr/minetest/commit/f46695d02b17466281b4d957c12f1a55633029d2 |
| 18:49 |
hmmmm |
https://github.com/minetest/minetest/commit/a2e1b0fc7fa9a470f645e130115ce14a89aa2e02 this is a stupid commit |
| 18:49 |
hmmmm |
there are about 500000 different cases where a generated block would still need to be saved |
| 18:49 |
hmmmm |
(from the mapgen) |
| 18:50 |
VanessaE |
oh no... |
| 18:50 |
VanessaE |
that's not what I think it is...is it? |
| 18:50 |
hmmmm |
I don't know what you think it is |
| 18:50 |
VanessaE |
the glitch some folks had with the mapgen overwriting existing/user-built structures |
| 18:51 |
|
Amaz joined #minetest-dev |
| 18:51 |
hmmmm |
i'm not really sure how it'd play into that |
| 18:51 |
VanessaE |
well just looking at the patch alone it looks like it |
| 18:51 |
hmmmm |
the only time blocks wouldn't be saved back if they've been generated is on mapgen time |
| 18:51 |
hmmmm |
you didn't look closely enough |
| 18:51 |
VanessaE |
you've got the whole code, I've just seen the patch so far |
| 18:51 |
VanessaE |
anyway, no matter |
| 18:57 |
VanessaE |
I'm just glad stuff is getting fixed. |
| 19:18 |
hmmmm |
when I first saw the third person view i got excited |
| 19:18 |
hmmmm |
then i realized it's crap.. the walking animation doesn't work properly |
| 19:19 |
hmmmm |
it's very desynchronized from the player's actual movement |
| 19:19 |
hmmmm |
and then you're not able to see what item/node is being wielded |
| 19:19 |
VanessaE |
there's a mod for the latter, |
| 19:19 |
VanessaE |
but how do you mean desynched? it looks fine to me |
| 19:20 |
hmmmm |
when i start walking the animation for walking does not start |
| 19:21 |
VanessaE |
strange.. it works here |
| 19:21 |
hmmmm |
looks like sam is hovering over the land |
| 19:21 |
hmmmm |
and then he'll start erratically walking after i had already stopped |
| 19:21 |
VanessaE |
and this is in singleplayer? |
| 19:22 |
hmmmm |
i do all of my testing in singleplayer. |
| 19:22 |
VanessaE |
strange. even the tiniest steps are instantly reflected in the player animation here. |
| 19:22 |
VanessaE |
is your minetest_game up-to-date? |
| 19:22 |
VanessaE |
I know it's a derp question but can't hurt to ask |
| 19:22 |
hmmmm |
it isn't |
| 19:23 |
hmmmm |
it's quite old. i don't update the game very often |
| 19:23 |
* VanessaE |
checks dreambuilder also |
| 19:23 |
VanessaE |
my mt_game is pretty close to HEAD, dreambuilder is much older as far as the player control code is concerned. |
| 19:24 |
VanessaE |
however both behave as they should |
| 19:24 |
hmmmm |
i'll check it out i guess.. |
| 19:24 |
hmmmm |
well |
| 19:24 |
VanessaE |
and db has the split-limb model, too, so that's not it |
| 19:24 |
hmmmm |
i don't play minetest so it doesn't concern me much |
| 19:24 |
hmmmm |
i'm just pointing out that it doesn't work well |
| 19:24 |
PilzAdam |
hmmmm, you need to update minetest_game in order for the animations to work properly |
| 19:25 |
PilzAdam |
a new function was added so it can tell the client which animation to play |
| 19:25 |
hmmmm |
ahhh ok |
| 19:25 |
hmmmm |
thanks |
| 19:32 |
VanessaE |
ah yes, I forgot about that function. |
| 19:40 |
|
paramat joined #minetest-dev |
| 19:44 |
paramat |
hmmmm, that error you saw in snow mod http://pastebin.com/f0ZFd00p i got that too, lots of bugs in that mod, my fixed and faster version is stored in here https://github.com/paramat/wieldhandsam2 but uses non-mapgen object vm |
| 19:45 |
VanessaE |
"paramat/wieldhandsam2" ? |
| 19:45 |
VanessaE |
strange name for a snow mod :P |
| 19:46 |
VanessaE |
oh, multiple mods there , derp |
| 19:46 |
paramat |
:) |
| 19:49 |
VanessaE |
hmmmm: getting back to the wield object for a moment.. there HAS been some call for a proper in-client solution to showing the wielded tool/object for a while now. there's a mod by stu that does this but it's buggy under some circumstances (last time I used it, it left indestructible item entities all over the place). |
| 19:55 |
paramat |
the code in snow mod was a perfectionist's OCD nightmare 8/ |
| 19:55 |
VanessaE |
haha |
| 19:57 |
paramat |
back in 2h o/ |
| 19:57 |
|
paramat left #minetest-dev |
| 20:00 |
|
alexxs joined #minetest-dev |
| 20:16 |
|
cg72 joined #minetest-dev |
| 20:45 |
hmmmm |
paramat: I fixed that thing |
| 20:46 |
hmmmm |
https://github.com/minetest/minetest/commit/9e4e7072da8f565eef37da7558053a436b9cbba3 |
| 20:46 |
hmmmm |
try using a mapgen object vm again |
| 21:10 |
iqualfragile |
in the player files is the position x,y,z? |
| 21:10 |
iqualfragile |
position = (3078,135,1101.83) |
| 21:10 |
iqualfragile |
height x, y? |
| 21:10 |
VanessaE |
it is. |
| 21:10 |
VanessaE |
in tenths. |
| 21:10 |
VanessaE |
x,y,z that is. |
| 21:10 |
VanessaE |
so that position is 307.8, 13.5, 110.183 |
| 21:11 |
iqualfragile |
why the fuck in tenths? |
| 21:11 |
VanessaE |
beats me |
| 21:11 |
hmmmm |
why not the fuck in tenths? |
| 21:11 |
hmmmm |
what would you use? |
| 21:11 |
iqualfragile |
because it will be a horrible nightmare to process in bash -.- |
| 21:11 |
VanessaE |
hmmmm: I think he means why is it multiplied by 10. |
| 21:12 |
hmmmm |
that's an awfully specific use case. i'm sorry celeron didn't predict your future plight when he designed that 5 years ago or whenever |
| 21:12 |
iqualfragile |
why not in ninths? |
| 21:12 |
iqualfragile |
sounds better to me |
| 21:13 |
iqualfragile |
i like the number |
| 21:13 |
VanessaE |
which DOES beg the question, why IS it multiplied by 10? wouldn't integers have been perfectly good for this? |
| 21:13 |
hmmmm |
the reason why it's multiplied by 10 is so that it COULD be stored as an integer |
| 21:13 |
celeron55 |
it's the glorious BullShit constant |
| 21:13 |
VanessaE |
that's what I figured. |
| 21:13 |
celeron55 |
the best thing ever |
| 21:13 |
celeron55 |
(to be explained to anyone) |
| 21:14 |
hmmmm |
VanessaE, the position needs to be stored in tenths simply because the player moves in increments of 1/10th |
| 21:14 |
celeron55 |
there's no reason whatsoever for it to be applied to that saved value but it just happened to be and that's how it is then |
| 21:14 |
hmmmm |
if the player really moved node by node, don't you think that would ruin the fluidity of motion..? |
| 21:14 |
VanessaE |
seems fair. |
| 21:15 |
VanessaE |
hmmmm: sure...if that file were constantly being re-read after every player movement. |
| 21:15 |
hmmmm |
I think it would be annoying to start off in a slightly different spot on every player join |
| 21:15 |
celeron55 |
moving in tenths of nodes wouldn't exactly be "fluid" motion 8D |
| 21:15 |
hmmmm |
well, yeah, but being able to round to 1/10th makes it a lot more fluid than otherwise |
| 21:15 |
|
twoelk|2 joined #minetest-dev |
| 21:15 |
hmmmm |
makes things much less perceptible i should say |
| 21:16 |
hmmmm |
differences |
| 21:16 |
VanessaE |
I doubt a player would notice if they're off by half a node when they re-join, were it storing a rounded integer position. |
| 21:16 |
celeron55 |
there's no other reason for BS than it forcing conversion between integer and floating-point positions to be explicit |
| 21:16 |
VanessaE |
doesn't matter anyway, it's just an academic curiosity |
| 21:16 |
celeron55 |
_no_other_reason_ |
| 21:16 |
hmmmm |
huh? |
| 21:16 |
celeron55 |
when it happens to be in saved values, it's just laziness |
| 21:17 |
iqualfragile |
so why isn't it stored in ints then? |
| 21:17 |
hmmmm |
I thought the point of BS was to convert to irrlicht coordinates |
| 21:17 |
hmmmm |
because a block was visually 10 whatevers |
| 21:17 |
celeron55 |
and just the fact that nobody would have guessed that anything other than minetest would have cared about what minetest saves |
| 21:17 |
hmmmm |
so it really is bullshit |
| 21:18 |
celeron55 |
well it does that too, that has no meaning whatsoever; everything would work equally with BS=1, except for the reason i just said |
| 21:19 |
iqualfragile |
ok, so im gona post the command i will use in the end for extracting the position and you will be forced to look at it |
| 21:20 |
celeron55 |
i posted some bash stuff on my solo game development channel today |
| 21:20 |
celeron55 |
$ grep '>' -Isn 201*/*8dromeda* | grep -v 'celeron55.*>' | cut -d/ -f1,2 | cut -d: -f1,3 | cut -c1-7,17,32-33 | xargs -n1 date -d | cut -d' ' -f1 | sort | uniq -c | sort -n |
| 21:20 |
celeron55 |
i'm mentally prepared for your version of bash shit 8D |
| 21:21 |
* celeron55 |
is the true evil |
| 21:21 |
iqualfragile |
you could just sort -u |
| 21:21 |
celeron55 |
maybe; i couldn't have cared less |
| 21:22 |
hmmmm |
you could just write a Python script in 1/10th the time it takes to figure out the necessary command switches |
| 21:22 |
iqualfragile |
hmmmm: nah, thats just basic stuff |
| 21:22 |
celeron55 |
...or just don't figure out the necessary ones and use three times the ones you remember |
| 21:22 |
iqualfragile |
you usually know these ones by heart |
| 21:22 |
hmmmm |
right, it all comes down to familiarity |
| 21:22 |
hmmmm |
whatever you know best is going to be the fastest |
| 21:23 |
hmmmm |
...i used to write C utilities to do text processing occasionally |
| 21:24 |
iqualfragile |
echo $(($(cat worlds/newworld/players/Iqualfragile | grep -F position | cut -d, -f2 | cut -d. -f1) /10)),$(($(cat worlds/newworld/players/Iqualfragile | grep -F position | cut -d, -f3 | cut -d. -f1) / 10)) |
| 21:24 |
celeron55 |
absolutely lovely |
| 21:25 |
iqualfragile |
not even all that ugly |
| 21:25 |
iqualfragile |
imagined it would be worse |
| 21:25 |
iqualfragile |
but it does open the file twice, which is ugly |
| 21:26 |
celeron55 |
hmmmm: using C's scanf and printf is actually probably a relatively fast way of making these |
| 21:26 |
iqualfragile |
sed all the way |
| 21:34 |
hmmmm |
https://github.com/kwolekr/minetest/commit/f3eefeb7948b8b8d1a98f2f89baa39abc807f72d |
| 21:34 |
hmmmm |
tell me if anybody would find this useful or not |
| 21:34 |
hmmmm |
basically you can set a specific MapNode table at a specific position in a voxelmanip, for special cases, rather than having to set everything in bulk and then set with set_node after |
| 21:35 |
hmmmm |
so if you have one goofy node in the middle of the map that you'd like to set, you can do vm:set_node_at(pos, {name="koolmod123:thingie", param1=whatever, param2=whatever})) |
| 21:43 |
|
proller joined #minetest-dev |
| 21:53 |
VanessaE |
might be useful |
| 21:53 |
VanessaE |
sokomine had an idea or two for her villages mod that I think needed something similar to this actually |
| 22:09 |
hmmmm |
i thought sokomine was a guy |
| 22:12 |
|
SoniEx2 joined #minetest-dev |
| 22:14 |
Sokomine |
no, i'm female |
| 22:15 |
Sokomine |
i'm sure those new functions will come in handy in many situations - especially as they allow to set a few nodes without bothering too much about vm |
| 22:16 |
Sokomine |
for the villages, the only working solution i found was to write to the entire vm - including shell. that seems to work fine so far - no more caves inside houses, and no more mudflow problems |
| 22:17 |
Sokomine |
it seems to be cruical to be able to generate such a mapchunk procedurally from the coordinates/seed entirely (minus perhaps some decorative plants) |
| 22:20 |
Sokomine |
after the vm is written via vm:write_to_map(data), there are a few calls using set_node - for chests which are to be filled (though that could be done - apart from the metadata - with vm as well), and some ground grass node type changes for those buildings that are schematics |
| 22:20 |
hmmmm |
oh yeah - these new functions clearly aren't going to work for metadata |
| 22:21 |
hmmmm |
metadata are far beyond the scope of what luavoxelmanipulator is intended to do and requires an unreasonable amount of effort to handle |
| 22:21 |
hmmmm |
s/are/is/ |
| 22:21 |
Sokomine |
that's ok. those chests are an exception and can be handled that way |
| 22:23 |
Sokomine |
what would be great, though, would be an option to insert a schematic into a voxelmanip. would seem cleaner than reading a worldedit file, doing some string comparison/deserialization, rotation etc. there |
| 22:24 |
hmmmm |
the best would be if schematics were removed from the core and instead implemented in Lua using voxelmanips |
| 22:24 |
Sokomine |
perhaps that as well. if it wouldn't make them slower? |
| 22:25 |
Sokomine |
it's an incredibly useful, well-working format, that .mts format. only disadvantage is that it can't be read from lua as we don't have a lib to uncompress the data at hand |
| 22:35 |
|
paramat joined #minetest-dev |
| 22:36 |
paramat |
hmmmm, i'll compile latest and test your work https://github.com/minetest/minetest/commit/9e4e7072da8f565eef37da7558053a436b9cbba3 soon, with plantlife and snow combination, and with 2 of my own mods |
| 22:36 |
hmmmm |
well I already tested it but okay |
| 22:38 |
paramat |
also 'Add LuaVoxelManip methods: get_node_at() and set_node_at()' seems very useful |
| 22:58 |
iqualfragile |
how often are player files saved? |
| 23:14 |
PilzAdam |
iqualfragile, every server_map_save_interval seconds, but only if they are modified |
| 23:15 |
iqualfragile |
is that in secs? |
| 23:16 |
|
Exio joined #minetest-dev |
| 23:16 |
PilzAdam |
yes, seconds is in seconds |
| 23:25 |
hmmmm |
alright so how is this: local vm = VoxelManip(pmin, pmax); creates a LuaVoxelManip with a buffer allocated, filled with CONTENT_IGNORE |
| 23:26 |
hmmmm |
if you allocate a VoxelManip in that manner, you don't need to pass the pmin and pmax parameters to VoxelManip:read_from_map() |
| 23:26 |
hmmmm |
if you specify a pmin/pmax in the ctor and also in read_from_map(), the area will be reallocated for the area specified in the latter |
| 23:27 |
hmmmm |
and of course, reverse compatibility is maintained by not specifying a pmin/max in the ctor but in the read_from_map: i.e. local vm = VoxelManip(); vm:read_from_map(pmin, pmax) |
| 23:27 |
hmmmm |
any comments? |
| 23:33 |
iqualfragile |
PilzAdam: heh, i should sleep |
| 23:34 |
paramat |
so i guess this allows writing a vm to map without having to read from map first, so faster for certain uses |
| 23:34 |
|
proller joined #minetest-dev |
| 23:38 |
hmmmm |
actually i'd argue it's faster for most uses |
| 23:39 |
|
hisforeverkid joined #minetest-dev |
| 23:39 |
hmmmm |
whenever you want to place some thing on the map |
| 23:39 |
hmmmm |
if you know the coordinates |
| 23:40 |
hisforeverkid |
hi I;d like to know how to plant a pinecone? |
| 23:40 |
paramat |
oh yeah for mapgen in singlenode, you don't need to read the map at all |
| 23:40 |
hmmmm |
like if you wanted to make sphere of stone, or something, you can just draw the sphere in the voxelmanip without loading map first, and then when you go to write it to map, it'll only write the pieces of the voxelmanip that aren't content_ignore |
| 23:40 |
hmmmm |
the idea is that content_ignore is sort of like a transparent pixel in a drawing |
| 23:40 |
paramat |
nice |
| 23:42 |
paramat |
this is for both mapgen object vm and non mapgen object vm? |
| 23:43 |
VanessaE |
now THAT should be useful for sure |
| 23:43 |
hisforeverkid |
ok sorry |
| 23:43 |
hmmmm |
well both, but the map has already been read for the mapgen object vm |
| 23:43 |
hmmmm |
so what's the point |
| 23:43 |
paramat |
yeah |
| 23:49 |
|
hisforever joined #minetest-dev |
| 23:56 |
|
proller joined #minetest-dev |
