| Time |
Nick |
Message |
| 00:06 |
|
paramat left #minetest-dev |
| 00:07 |
|
sloantothebone joined #minetest-dev |
| 00:17 |
|
kahrl joined #minetest-dev |
| 00:20 |
|
cheapie joined #minetest-dev |
| 01:20 |
|
werwerwer joined #minetest-dev |
| 02:25 |
|
Player_2 joined #minetest-dev |
| 03:12 |
|
OldCoder joined #minetest-dev |
| 03:35 |
|
Lunatrius` joined #minetest-dev |
| 04:21 |
|
Sokomine joined #minetest-dev |
| 04:26 |
|
Player_2 joined #minetest-dev |
| 04:41 |
|
Fritigern joined #minetest-dev |
| 04:53 |
|
maxela joined #minetest-dev |
| 04:57 |
|
kaeza joined #minetest-dev |
| 05:28 |
|
proller joined #minetest-dev |
| 05:33 |
|
Siva joined #minetest-dev |
| 05:34 |
|
AndChat|494769 joined #minetest-dev |
| 05:37 |
|
maxela joined #minetest-dev |
| 05:39 |
|
AndChat-494769 joined #minetest-dev |
| 05:41 |
|
Hunterz joined #minetest-dev |
| 05:47 |
|
maxela joined #minetest-dev |
| 06:03 |
|
Siva_AndroIRC joined #minetest-dev |
| 06:18 |
|
Krock joined #minetest-dev |
| 06:22 |
|
Calinou joined #minetest-dev |
| 06:35 |
|
maxela joined #minetest-dev |
| 06:37 |
|
nrzkt joined #minetest-dev |
| 06:50 |
|
hmmmmm joined #minetest-dev |
| 06:55 |
|
blaze joined #minetest-dev |
| 07:17 |
|
Darcidride joined #minetest-dev |
| 07:24 |
|
blaze joined #minetest-dev |
| 07:47 |
|
AndChat|494769 joined #minetest-dev |
| 07:55 |
|
Amaz joined #minetest-dev |
| 08:18 |
|
proller joined #minetest-dev |
| 08:37 |
|
Ardonel joined #minetest-dev |
| 08:55 |
|
kilbith joined #minetest-dev |
| 08:56 |
|
kilbith left #minetest-dev |
| 08:59 |
|
book` joined #minetest-dev |
| 09:14 |
|
kilbith joined #minetest-dev |
| 09:15 |
|
Megaf_ joined #minetest-dev |
| 09:25 |
|
Krock2 joined #minetest-dev |
| 09:47 |
|
JohannesG joined #minetest-dev |
| 09:50 |
|
maxela joined #minetest-dev |
| 09:54 |
|
H-H-H joined #minetest-dev |
| 09:55 |
|
Krock joined #minetest-dev |
| 10:15 |
|
EnB joined #minetest-dev |
| 10:27 |
|
est31 joined #minetest-dev |
| 10:42 |
|
AndChat|494769 joined #minetest-dev |
| 10:52 |
|
proller joined #minetest-dev |
| 10:54 |
|
proller joined #minetest-dev |
| 10:58 |
|
troller joined #minetest-dev |
| 11:05 |
|
proller joined #minetest-dev |
| 11:07 |
|
T4im joined #minetest-dev |
| 11:25 |
|
cib0 joined #minetest-dev |
| 11:53 |
Krock |
Are the changed Mapblocks updated instantly or is there some delay? |
| 12:01 |
nrzkt |
server side or client side ? |
| 12:15 |
Krock |
client side |
| 12:32 |
|
book` joined #minetest-dev |
| 13:44 |
|
Darcidride joined #minetest-dev |
| 14:00 |
|
rubenwardy joined #minetest-dev |
| 14:09 |
|
Puma_rc joined #minetest-dev |
| 14:53 |
|
DFeniks joined #minetest-dev |
| 15:04 |
|
Guest85485 joined #minetest-dev |
| 15:21 |
|
hmmmm joined #minetest-dev |
| 15:26 |
|
younishd joined #minetest-dev |
| 15:31 |
|
nrzkt joined #minetest-dev |
| 15:54 |
|
kilbith joined #minetest-dev |
| 16:12 |
|
Hunterz joined #minetest-dev |
| 16:16 |
|
Amaz joined #minetest-dev |
| 16:35 |
|
Robert_Zenz joined #minetest-dev |
| 16:40 |
|
ElectronLibre joined #minetest-dev |
| 16:57 |
|
paramat joined #minetest-dev |
| 16:58 |
|
MinetestForFun joined #minetest-dev |
| 17:01 |
paramat |
can hmmmm or anyone approve #3194 ? i'm fairly sure it's okay but a quick check would be good |
| 17:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/3194 -- Mapnode: Add rotateAlongYAxisFull supporting 24 facedirs by paramat |
| 17:01 |
Calinou |
ShadowNinja, merged https://github.com/minetest/minetest.github.io/pull/32 and now top icon is broken :( |
| 17:02 |
Calinou |
I know why, will fix it |
| 17:02 |
hmmmm |
paramat, sure I'm looking at it |
| 17:02 |
hmmmm |
question though, about the index variable |
| 17:02 |
hmmmm |
why is it param2 * 4 + rot exactly? |
| 17:03 |
Calinou |
pushed fix |
| 17:05 |
hmmmm |
the array size is 24 * 4, but they're broken up into 6 chunks of 16 |
| 17:07 |
hmmmm |
also it would make me feel better if you made that (param2 % 24) * 4 + rot instead |
| 17:23 |
paramat |
no it's 24 chunks of 4, i copied the [24 * 4] format from a lookup table elsewhere. each line is the initial facedir (first value) then the 3 resulting facedirs under rotations 90, 180 and 270 degrees |
| 17:28 |
paramat |
the 6 chunks visible are just to separate facedirs 0-3 from 4-7 etc, i copied the format from https://github.com/minetest/minetest/blob/master/src/mapblock_mesh.cpp#L706 |
| 17:30 |
paramat |
okay (param2 % 24) in case higher bits are used for something else, will do |
| 17:40 |
paramat |
thanks |
| 17:55 |
|
samuellwn joined #minetest-dev |
| 18:31 |
|
FR^2 joined #minetest-dev |
| 18:44 |
|
paramat left #minetest-dev |
| 19:41 |
VanessaE |
nrzkt: are you aware that the public server list does not work (no content) on the android build currently offered on minetest.net ? |
| 19:41 |
VanessaE |
(tick the checkbox, nothing happens - list is empty) |
| 19:45 |
|
paramat joined #minetest-dev |
| 19:53 |
paramat |
now merging 3194 |
| 19:56 |
paramat |
complete |
| 20:08 |
|
Amaz joined #minetest-dev |
| 20:15 |
|
cib0 joined #minetest-dev |
| 20:32 |
|
ElectronLibre left #minetest-dev |
| 20:40 |
|
Lunatrius` joined #minetest-dev |
| 20:41 |
VanessaE |
wtf? connection timing out while trying to load a SINGLEPLAYER world?! |
| 20:41 |
nrzkt |
VanessaE: no i'm not aware est31 tested the build, i only distribute it. |
| 20:41 |
VanessaE |
ok. well now you're aware :) |
| 20:41 |
nrzkt |
since the armv7 change i cannot run minetest anymore on myphone |
| 20:43 |
VanessaE |
in my case I was playing around on my S4 phone |
| 20:43 |
VanessaE |
the timeout issue I just mentioned is on my PC, though. |
| 20:46 |
VanessaE |
ok so apparently I can't start a singleplayer game anymore. |
| 20:47 |
VanessaE |
not even a "minimal" world works. |
| 20:48 |
VanessaE |
seems to work fine connecting to a remote server. |
| 20:56 |
|
est31 joined #minetest-dev |
| 20:56 |
est31 |
VanessaE, cant reproduce |
| 20:56 |
est31 |
engine 1adc7bf5c60830cc8dcbab3 |
| 20:56 |
est31 |
game: ?? dunno, something outdated |
| 20:56 |
est31 |
can you reproduce with minimal game? |
| 20:56 |
VanessaE |
[09-22 16:47] <VanessaE> not even a "minimal" world works. |
| 20:56 |
|
nrzkt joined #minetest-dev |
| 20:57 |
VanessaE |
engine is a56aedb4e |
| 20:57 |
VanessaE |
it just sits there "connecting to server..." and eventually times out. |
| 20:58 |
est31 |
fatal: ambiguous argument 'a56aedb4e': unknown revision or path not in the working tree. |
| 20:58 |
|
nrzkt joined #minetest-dev |
| 20:58 |
VanessaE |
it's there, I just re-cloned and recompiled to check. |
| 20:58 |
est31 |
ah paramat's commit |
| 20:58 |
est31 |
lemme see |
| 20:59 |
VanessaE |
only thing I can think of is an ipv6 issue |
| 20:59 |
|
nrzkt joined #minetest-dev |
| 20:59 |
celeron55 |
that happens on my laptop |
| 20:59 |
celeron55 |
i have a setup with multiple local networks and whatever |
| 21:00 |
|
waressearcher2 joined #minetest-dev |
| 21:00 |
est31 |
recompiling |
| 21:00 |
celeron55 |
before i made it, MT didn't have issues |
| 21:00 |
waressearcher2 |
where exactly place in source code that is limits world's size ? or its all around source code and not just one variable ? |
| 21:00 |
est31 |
waressearcher2, there are multiple limits |
| 21:00 |
est31 |
first there is one for world coordinates |
| 21:00 |
est31 |
it cant be changed because its inherent to the type |
| 21:01 |
celeron55 |
i think what this network set-up causes is that you can't just listen for UDP packets at "any" and send UDP packets to 127.0.0.1; they don't end up in that listening socket |
| 21:01 |
est31 |
then there is a second limit to stop the mapgen reach that first limit and do funny things |
| 21:01 |
VanessaE |
of course my box does not respond to "ping6 ::1" (but I dunno if it should) |
| 21:01 |
celeron55 |
it will work if i modify MT's source to connect to an explicit local address, in this case something like 192.168.0.5 or whatever |
| 21:01 |
est31 |
then there is a limit for objects to get spawned, its set to the same as that mapgen limit |
| 21:02 |
VanessaE |
come to think of it, I can't ping 127.0.0.1 either. must be a config problem on my end. |
| 21:02 |
est31 |
also, as player, you can't get into non-generated blocks, so the mapgen limit exists for you as well |
| 21:03 |
celeron55 |
(i can ping 127.0.0.1 just fine) |
| 21:03 |
est31 |
yeah, even on a56aedb4e I dont have problems |
| 21:03 |
VanessaE |
ok looks like I just botched something in my routing. |
| 21:03 |
celeron55 |
(and run TCP programs that listen at 0.0.0.0 and connect to them as 127.0.0.1 or "localhost" |
| 21:03 |
celeron55 |
) |
| 21:05 |
|
nrzkt joined #minetest-dev |
| 21:05 |
est31 |
waressearcher2, there is the setting map_generation_limit, does that help you? |
| 21:08 |
paramat |
it's because we use s16 (signed 16 bit integers) for world co-ordinates |
| 21:09 |
waressearcher2 |
paramat: why not 32 ? |
| 21:10 |
waressearcher2 |
est31: yes |
| 21:10 |
paramat |
heh |
| 21:10 |
est31 |
I guess if we have 32, people will demand for 64 |
| 21:10 |
paramat |
the discussion to increase world size has been had many times, it's not going to happen =) |
| 21:10 |
est31 |
and if we have 64, people will demand 128 etc |
| 21:11 |
paramat |
to much work |
| 21:11 |
waressearcher2 |
so s16 was choosen on purpose ? |
| 21:11 |
est31 |
waressearcher2, some number had to be chosen |
| 21:11 |
waressearcher2 |
you could've use s32 but choose s16 on purpose ? |
| 21:11 |
est31 |
I think the old world format was somewhat limited to 1000 nodes or so |
| 21:11 |
est31 |
so compared to that it was quite an enlargement |
| 21:12 |
paramat |
it's just big enough, remember the vertical space for stacked realms |
| 21:13 |
est31 |
yeah 30km vertical is really enough |
| 21:13 |
est31 |
or even 62 |
| 21:13 |
est31 |
one idea would be to do it like TBC_x suggested, and to not have absolute coordinates anymore |
| 21:14 |
waressearcher2 |
how TBC_x suggested ? |
| 21:14 |
|
VanessaE joined #minetest-dev |
| 21:14 |
VanessaE |
there, that's sorted. stupid network manager :-/ |
| 21:14 |
paramat |
s32 is too big, currently the edge is distant but reachable |
| 21:15 |
est31 |
well, we just dont have absolute x,y,z coords anymore |
| 21:15 |
VanessaE |
paramat: I've had people tell me they've been way out past +/- 31K on minecrarft before, though I agree that 31/62K for vertical is more than enough |
| 21:15 |
est31 |
but instead the position is given relative to a center point |
| 21:15 |
VanessaE |
-r |
| 21:15 |
est31 |
and ofc there is not just one center point |
| 21:16 |
est31 |
so, for example, you divide the map into VAEs of size 62kx62kx62k |
| 21:16 |
est31 |
and the moment a player reaches an edge of a VAE, a new VAE is created next to it |
| 21:17 |
est31 |
and they are made "attached" so that there are no physics calculations on them |
| 21:17 |
est31 |
there would be some need for mapgen magic to blend over between the two |
| 21:17 |
VanessaE |
in any case, we should either expand the horizontal limit to some ridiculous amount, or stop using the phrase "near infinite" |
| 21:17 |
est31 |
but I guess that would be possible |
| 21:18 |
paramat |
yes 'almost infinite' should go |
| 21:18 |
waressearcher2 |
paramat: "to much work", consider how much work was done for previous 6 month or a year on minetest, could it be more work than that ? I mean minetest code grows anyway, so why not to implement that is more requested ? |
| 21:18 |
est31 |
that idea would bring the mapblock approach to coordinates |
| 21:19 |
paramat |
there are much more important things to do, and we are understaffed |
| 21:19 |
est31 |
yea understaffed indeed |
| 21:19 |
paramat |
and a larger world is not much needed |
| 21:19 |
waressearcher2 |
understaffed but not underpaid |
| 21:22 |
VanessaE |
some minecrafters will argue that a larger world IS needed. there's other stuff that's needed more, though. |
| 21:22 |
paramat |
i consider the smallest dimension of a world more important, MC may be vast horizontally but i consider it much more limited than MT due to world height |
| 21:23 |
paramat |
vertical space brings much more interesting things.. |
| 21:23 |
VanessaE |
indeed, but there's only just so much vertical space people can find a use for |
| 21:23 |
nrzkt |
atm using better than u16 is a little bit difficult in core, many concerns |
| 21:24 |
VanessaE |
after a couple thousand meters, you've about exhausted what one could do I think. |
| 21:24 |
VanessaE |
nrzkt: as I understood it, the biggest concern is how it affects some Lua-facing coordinate hash functions |
| 21:24 |
est31 |
yeah |
| 21:24 |
est31 |
that would be a problem |
| 21:25 |
est31 |
those hashes would need to be stored in userdata |
| 21:25 |
VanessaE |
for the code I've written that uses them, it wouldn't affect anything (my code in biome_lib, for example, only cares that there is a unique value, but not how it's hashed) |
| 21:26 |
est31 |
well, the problem is that it won't be unique anymore |
| 21:26 |
|
proller joined #minetest-dev |
| 21:26 |
VanessaE |
it wouldn't be unless you extend the hash format. |
| 21:26 |
est31 |
general problem of hashing :) |
| 21:26 |
est31 |
yea |
| 21:26 |
VanessaE |
what is it now? z*(4096^2) + y*4096 + x or some such? |
| 21:26 |
est31 |
yea I think so |
| 21:27 |
est31 |
and there isnt much space left |
| 21:27 |
est31 |
< 20 bits |
| 21:27 |
VanessaE |
wait, you're talking about some feature in the map itself? |
| 21:28 |
VanessaE |
(or in how it's sent to the client) |
| 21:28 |
est31 |
no about the hash |
| 21:28 |
est31 |
the hash function outputs a lua number |
| 21:28 |
est31 |
and usually its stored as IEEE float |
| 21:28 |
VanessaE |
well, I'm talking about internal representation in the engine and how it's passed along to Lua for e.g. the coords-to-hash and related functions |
| 21:29 |
est31 |
and floats of this size have a limit of 2 ^ fifty something if you use them as ints |
| 21:29 |
est31 |
coords to hash is entirely lua I think |
| 21:29 |
est31 |
that isn't the problem |
| 21:30 |
est31 |
if we have a position table, its stored as three numbers |
| 21:30 |
est31 |
x y z |
| 21:30 |
est31 |
all three have each the space of 2^ fifty something |
| 21:31 |
est31 |
and only 15 are used |
| 21:31 |
est31 |
so lotsa space left there |
| 21:31 |
est31 |
but yeah, if we considered 64 bit based positions, there would be a problem |
| 21:32 |
T4im |
technically its not a hash function, or the size would not be an issue :P |
| 21:33 |
est31 |
yeah just at these small numbers, it is very well possible that a collision occurs |
| 21:33 |
est31 |
so not that good of an idea to convert it into a "real" hash function |
| 21:40 |
VanessaE |
but what position table are you talking about here, that's my question |
| 21:40 |
VanessaE |
if it's something internal to the engine, who cares how it's stored? change it to something better. If it's part of the map...well...do the same thing. |
| 21:41 |
VanessaE |
i.e. for the map, why be afraid of adding a couple of bytes to something that's gonna compress-away anyhow? |
| 21:41 |
T4im |
hash_node_position is also being used as keys in tables, which get serialized |
| 21:41 |
T4im |
for example autocrafter |
| 21:41 |
T4im |
;) |
| 21:41 |
T4im |
eh sorry I mean tp tubes |
| 21:41 |
T4im |
their locations are stored... so are probably nodes of other mods |
| 21:42 |
est31 |
VanessaE, the coords of a mapblock aren't compressed |
| 21:42 |
est31 |
only its content |
| 21:42 |
VanessaE |
est31: what about what the database backend does to it? |
| 21:42 |
est31 |
well yeah, that one can indeed do such things |
| 21:43 |
VanessaE |
(of course sqlite does nothing in that regard, but leveldb does) |
| 21:44 |
VanessaE |
if mods are gonna break, they're gonna break and nothing can really be done to fix that in the engine, but if the map format were to change to accommodate larger coord ranges, what's the big deal? |
| 21:45 |
VanessaE |
I mean, it's changed before, what, three times I guess? |
| 21:46 |
VanessaE |
and server/client protocol (where it outright breaks) has changed even more |
| 21:46 |
est31 |
the problem is that we cant provide mods with a "please do this instead" hint how to stop them breaking |
| 21:46 |
est31 |
because there is no better native lua datatype |
| 21:46 |
est31 |
none that can store that much data |
| 21:47 |
VanessaE |
then introduce a new hashing function that doesn't care about coordinate ranges, and don't worry if the mods break. |
| 21:47 |
est31 |
I mean if we really had 32 bit coords, we would need 128 bit integers |
| 21:49 |
VanessaE |
I see the problem with the numeric range in Lua though |
| 21:49 |
VanessaE |
that just means the hash would have to be returned as a string then. |
| 21:49 |
VanessaE |
with a BIG warning somewhere that it has changed. |
| 21:50 |
T4im |
it's a fixed index atm, 1:1 based on the size of the map.. there's certainly some way to encode the coordinates a bit "denser" |
| 21:50 |
VanessaE |
or new Lua function calls for the purpose, with warnings that the old calls don't return unique values outside the +/-31k range |
| 21:53 |
VanessaE |
all I'm saying is that it's not an unsolvable problem. |
| 21:55 |
est31 |
agreed |
| 21:57 |
est31 |
if we change the format though, we should also consider what to do with VAEs |
| 21:57 |
est31 |
eg how to manage those |
| 21:57 |
VanessaE |
what is there to even do with them now? they're vaporware :P |
| 21:58 |
est31 |
VanessaE, some people say we should hack around the problem and store them into the "free" space we have thanks to the fact that we stop at 31k and dont go where the data types would allow us to go |
| 21:58 |
VanessaE |
fuck no |
| 21:58 |
VanessaE |
VAE's ought to be stored as their own entries in the map database. |
| 21:59 |
est31 |
Thats my opinion at this as well |
| 21:59 |
VanessaE |
trying to use the "free" space at the edges of the map is gonna lead to headaches down the road |
| 21:59 |
paramat |
agreed |
| 21:59 |
VanessaE |
especially if this same "make the map bigger" argument comes up again |
| 21:59 |
est31 |
it will break mods of course |
| 21:59 |
est31 |
that has to be kept in mind |
| 22:00 |
VanessaE |
fair enough, but you can't break what hasn't been implemented yet |
| 22:00 |
VanessaE |
mods don't care where or how data is stored in the map anyway |
| 22:00 |
est31 |
ah yeah |
| 22:00 |
est31 |
in fact you are right |
| 22:00 |
est31 |
it will break mods either way |
| 22:01 |
est31 |
just people argue that if you store the blocks in that free space, you already have coords to give them so that you can use existing callbacks for modding on those positions |
| 22:02 |
est31 |
that would be an advantage of that approach i admit |
| 22:03 |
est31 |
but the more proper solution IMO is to give mods a fourth position argument, or a separate "realm" value. |
| 22:04 |
paramat |
wooo 4D |
| 22:05 |
T4im |
that would allow for very easy interaction between realms too :D place something in one realm, let it have some fringe effect on another in the same position |
| 22:06 |
est31 |
lol |
| 22:07 |
T4im |
protection checking etc would be easier for a 4d position then as well |
| 22:08 |
est31 |
heh lol these things are all bugs, not positive features |
| 22:10 |
est31 |
you would have kinda of a discrete topology on the realm coord |
| 22:12 |
est31 |
well, its topology is a bit more complicated |
| 22:13 |
T4im |
well, not talking about fading in and out between realms, though that would of course be a very near effect too :P |
| 22:13 |
T4im |
neat* |
| 22:17 |
|
cib0 joined #minetest-dev |
| 22:17 |
est31 |
but yeah talking with topology terms is quite stupid |
| 22:21 |
VanessaE |
another thought: extend the map, damn the torpedoes. on startup, if the map is the extended variety, then disable all existing lua-facing functions that deal with coord hashes entirely, making only the newer functions available. |
| 22:21 |
VanessaE |
i.e. make mods that depend on them fail hard instead of silently fucking up. |
| 22:23 |
VanessaE |
all existing maps would be treated as they are now (with those functions available), anything created after that point is "extended" and the API only offers the newer functions |
| 22:23 |
VanessaE |
that's the sanest way I can think of, anyways. |
| 22:24 |
est31 |
or just make it a setting |
| 22:24 |
est31 |
it can work with both extended and non extended maps |
| 22:24 |
T4im |
expose some sort of map version to builtin, then adapt lua behavior accordingly? |
| 22:25 |
VanessaE |
T4im: that was my thought, yeah |
| 22:25 |
est31 |
and then if you flip the switch the mods will fail |
| 22:25 |
est31 |
but I think I dont want to extend it to 32 bit as well |
| 22:25 |
est31 |
because I think its better done with VAEs |
| 22:25 |
VanessaE |
then extend it to 64 bit ;) |
| 22:25 |
VanessaE |
um, VAEs are supposed to be for big stuff that moves around I thought? |
| 22:25 |
est31 |
and then its only limited by the VAE id counter |
| 22:27 |
est31 |
I'd like to have a second non physically interacting VAE type that's position,rotation etc can either freely modified by lua without a physics engine asking it do do things, or be "attached" to other VAEs, or the "main root" map |
| 22:27 |
VanessaE |
mmh |
| 22:27 |
est31 |
so if you walk into one direction for a long time, the server creates VAEs with new blocks |
| 22:28 |
VanessaE |
that just seems super-hacky |
| 22:28 |
est31 |
and it allows the map to be far more larger |
| 22:28 |
est31 |
because |
| 22:28 |
est31 |
because you aren't limited in xyz per se |
| 22:28 |
est31 |
you are only limited by the VAE id |
| 22:28 |
T4im |
why not solve the "Infinite world size" problem by letting people pop up on the other side of the map? :P |
| 22:28 |
est31 |
which can be e.g. 32 bit |
| 22:28 |
VanessaE |
T4im: that would help to a small degree |
| 22:29 |
est31 |
T4im, mods can already do this |
| 22:29 |
T4im |
by teleporting you mean? |
| 22:29 |
est31 |
yea |
| 22:29 |
T4im |
nah, I mean tiling it seamlessly |
| 22:29 |
VanessaE |
but it doesn't do much to address the larger concern: as much as it pains me to say it, minecraft beats the shit out of minetest on this front. |
| 22:29 |
T4im |
as if minetest would provide a sphere as map |
| 22:29 |
T4im |
(at least horizontally) |
| 22:30 |
est31 |
T4im, you mean a cube? |
| 22:30 |
est31 |
there are no spheres in minetest |
| 22:30 |
est31 |
:) |
| 22:30 |
VanessaE |
technically it would be a torus wouldn't it? :) |
| 22:31 |
est31 |
no |
| 22:31 |
VanessaE |
sure it would - north wraps around to south |
| 22:31 |
T4im |
but west to east too.. |
| 22:31 |
VanessaE |
with a globe topology, you'd have to "bounce" off of the "pole" and end up somewhere further east or west |
| 22:32 |
VanessaE |
if only X wraps, it's a cylinder. if X and Z both wrap, it has to be a torus. |
| 22:33 |
est31 |
VanessaE, the difference between torus and sphere (or cube xD) is that on spheres you can contract every circle into a single point |
| 22:33 |
est31 |
on a torus this isnt possible |
| 22:33 |
VanessaE |
fair enough |
| 22:34 |
T4im |
a hollow sphere |
| 22:35 |
waressearcher2 |
speaking of spheres toruses and cubes as map http://www.youtube.com/watch?v=bJr4QlDxEME#t=60s |
| 22:35 |
T4im |
unless digging through the bottom should end weirdly :> |
| 22:37 |
est31 |
I like how the renderer shows the landscape if the voxels aren't loaded |
| 22:38 |
T4im |
or better yet, est31 will rewrite the physics entirely and we let the player end up on a kleinbottle |
| 22:38 |
est31 |
lol |
| 22:38 |
T4im |
i.e. if he walks far enough, he'll be upside down to the other players :p |
| 22:39 |
VanessaE |
hah |
| 22:40 |
est31 |
http://media.indiedb.com/images/downloads/1/69/68101/thumb0.1.6.jpg |
| 22:41 |
|
cg joined #minetest-dev |
| 22:41 |
est31 |
this is way better than fog |
| 22:41 |
T4im |
nice |
| 22:42 |
est31 |
(not for the fire, but about how it renders only part of the map as voxels) |
| 22:42 |
T4im |
certainly hart to mod/game change though |
| 22:42 |
T4im |
hard* |
| 22:42 |
cg |
ok guys, in .13 and .12 dev builds i cant save into the (worldpath)/player dir, is that now locked out or????? |
| 22:42 |
T4im |
from a mod you mean? |
| 22:42 |
cg |
yes |
| 22:42 |
T4im |
do you have security enabled? if so, then yes |
| 22:43 |
T4im |
probably that is |
| 22:43 |
waressearcher2 |
est31: you said there is a mod that teleports player when he reaches edge, don't you think that mod could've achieved the same by just turning player 90 degree left or right ? |
| 22:43 |
cg |
it seems to have broken my mod again lol |
| 22:43 |
cg |
ive got it disabled |
| 22:46 |
cg |
http://pastebin.com/iqKKXq6T |
| 22:46 |
cg |
that code works untill 0.4.12dev |
| 22:48 |
T4im |
you show me read code there, not save-into-directory code |
| 22:49 |
T4im |
btw, you might want to look at some of the comments in https://github.com/minetest/minetest_game/pull/669/files |
| 22:49 |
T4im |
it applies to your code too ;) |
| 22:50 |
T4im |
oh, wait you're talking about the erase? |
| 22:51 |
cg |
it wont read or write inth the dir |
| 22:51 |
cg |
into* |
| 23:02 |
T4im |
cg: lets move that somewhere outside of -dev, I don't think it's an engine issue, so lets not bother this fine people; and perhaps send more context, it might help (is that part of cg72_game?) |
| 23:04 |
T4im |
(at least I can't reproduce any issue like that locally in a dev build) |
| 23:05 |
VanessaE |
sounds like the result of that mod security patch, if not a simple permissions issue. |
| 23:06 |
paramat |
http://i.imgur.com/fRA61E9.png mwahaha, a new option for mgv7 |
| 23:06 |
|
paramat left #minetest-dev |
| 23:27 |
|
rubenwardy joined #minetest-dev |
| 23:54 |
|
H-H-H joined #minetest-dev |
