| Time |
Nick |
Message |
| 00:26 |
|
MinerDad joined #minetest-dev |
| 00:27 |
|
jin_xi joined #minetest-dev |
| 01:16 |
|
paramat joined #minetest-dev |
| 01:37 |
paramat |
c55: "we need to add features to the engine based on what subgames want to do" < mulitthreaded lua mapgen is a priority then =) |
| 01:38 |
VanessaE |
paramat: and multithreaded mesh generation too |
| 01:39 |
paramat |
eased 3d noise in mgv5 must have been added in c55's revival branch. i feel we should make non-eased the default: higher, more dramatic and faster, the option is still there for eased set in .conf |
| 01:41 |
paramat |
13hrs ago irealised i broke mgv7 biomes, the reason behind tenplus1's bugs, i need a day or two to fix |
| 01:43 |
paramat |
hmmmm this is up to you of course but i would like to see simplex noise developed before/instead of the original slow perlin noise. simplex looks amazing, is not cubic-looking and is faster |
| 01:44 |
paramat |
anything based on simplicies/triangles is awesome |
| 01:44 |
hmmmm |
it's not faster |
| 01:44 |
hmmmm |
hmmm |
| 01:44 |
paramat |
okay wikipedia was wrong heh |
| 01:44 |
hmmmm |
adding multiple meshgen threads should be trivial since that's an embarassingly parallel task (as opposed to map generation) |
| 01:45 |
hmmmm |
wikipedia probably said that it's faster in the sense that it has a lower algorithmic complexity |
| 01:45 |
paramat |
yes thats what it said |
| 01:46 |
hmmmm |
but n^2 > 2^n for lower values of n |
| 01:46 |
hmmmm |
we don't use anything greater than 3 dimensional noise |
| 01:47 |
hmmmm |
its actual speed depends a lot on how well i'm able to optimize it in the same manner i optimized the original noise |
| 01:48 |
paramat |
still much more interesting than another cubic-looking perlin noise, speed aside |
| 01:48 |
hmmmm |
i don't think i necessarily need to use simplex noise to fix that |
| 01:48 |
hmmmm |
i'm going to try cubic interpolation and see if that helps |
| 01:52 |
paramat |
i actually prefer non-eased mgv5 to eased, is it okay to pull that small change for 0.4.11? |
| 01:52 |
|
exio4 joined #minetest-dev |
| 01:53 |
|
n4x joined #minetest-dev |
| 01:54 |
paramat |
oh hang on that will mean retuning the cave params and lava params, perhaps better left until after |
| 01:55 |
paramat |
easing affects tunnel width and height of highest lava |
| 01:56 |
|
MinerDad joined #minetest-dev |
| 01:56 |
paramat |
what could be done is un-ease terrain noise only |
| 01:57 |
VanessaE |
hmmmm: well multiple mesh gen threads may be relatively simple, but actually I was suggesting splitting the one mesh gen thread from the rest of the client rendering tasks so that new block meshes don't kill client fps while they're being created. |
| 01:57 |
paramat |
lava blobs look much better eased, uneased they are all thin and fragmented |
| 01:59 |
paramat |
i'll make a pull for un-easing terrain noise only and leave it up to others to merge/not merge before 0.4.11 |
| 02:00 |
electrodude512 |
while we're on the topic of splitting stuff into threads, could you add a general way for mods to spawn lua functions in separate threads? |
| 02:01 |
electrodude512 |
I'm working on a computer mod, and ideally computers should all run in a thread separate from the main server thread |
| 02:08 |
electrodude512 |
if threads are added, would they share a lua environment (forked via LuaState* lua_newthread(LuaState*)) and use locks (define a lua_lock and a lua_unlock) or would they be isolated from each other? |
| 02:08 |
electrodude512 |
for mapgen, they could probably be isolated, but for most other things they would be almost useless if they were isolated |
| 02:11 |
electrodude512 |
http://lua-users.org/wiki/ThreadsTutorial |
| 02:15 |
|
shadowzone joined #minetest-dev |
| 02:22 |
electrodude512 |
there's also [Lua Lanes](http://cmr.github.io/lanes/), which seems a lot easier and a lot less error-prone, it's basically isolated lua_States in separate threads with special "keeper" lua_States for communication between different threads |
| 02:23 |
electrodude512 |
but it's obviously less natural than just multiple threads |
| 02:25 |
hmmmm |
paramat, i'd really rather not... that's a very cosmetic change and you can modify it in your own config if you really wanted to |
| 02:25 |
hmmmm |
electrodude512, sorry we can't do that |
| 02:26 |
hmmmm |
unfortunately it's not as simple as making separate lua threads |
| 02:27 |
electrodude512 |
yeah, I read about it, it looked too scary |
| 02:27 |
electrodude512 |
but lua lanes looks good |
| 02:27 |
hmmmm |
unless you could come up with a good way to make transactional environment accesses |
| 02:28 |
paramat |
okay no problem, i was just wondering if it was important to be truer to the non-eased original. i still love the eased version |
| 02:28 |
electrodude512 |
hmmmm: what do you mean by "transactional environment accesses" |
| 02:28 |
electrodude512 |
why not just lua lanes? |
| 02:29 |
hmmmm |
because there are large data structures with lots of contention in the core that must be locked while lua is executing |
| 02:29 |
electrodude512 |
it's like having completely separate threads, except they can communicate (albeit what could be viewed as somewhat awkwardly through messages), instead of not being able to communicate at all |
| 02:30 |
electrodude512 |
did you even look at lua lanes yet? |
| 02:30 |
electrodude512 |
I agree with you, normal lua threads would be impossible |
| 02:30 |
hmmmm |
it would be okay if only a single thread had access to the minetest api |
| 02:30 |
electrodude512 |
ok, and have the rest talk to the one thread with the minetest api through lua lanes |
| 02:31 |
electrodude512 |
but put the minetest api and the mapgen api in different threads, for obvious reasons |
| 02:35 |
electrodude512 |
actually, does isolating the mapgen api and the rest of the minetest api into separate threads like that even make sense? |
| 02:36 |
electrodude512 |
for ore and terrain gen it makes sense (but that's not in lua so who cares), but functions registered via minetest.register_on_generated need minetest.set_node and minetest.get_node |
| 02:37 |
electrodude512 |
maybe put a lock on just the minetest api functions that mapgen needs? |
| 02:37 |
electrodude512 |
or better yet, as many of the mt api functions as possible, and make the ones that proper, safe locking isn't possible for only available in one thread |
| 02:38 |
electrodude512 |
s/as many of/for as many of/ |
| 02:40 |
hmmmm |
it's really not that simple |
| 02:40 |
electrodude512 |
why not? |
| 02:41 |
electrodude512 |
what isn't? locking or threading in general? |
| 02:41 |
electrodude512 |
the only problem with lua lanes is that both the mapgen and the main threads should have access to the mt api |
| 02:41 |
hmmmm |
well the api that don't need to be locked is marked with NO_MAP_LOCK_REQUIRED |
| 02:41 |
hmmmm |
everything else that doesn't have that needs to be locked when it's called |
| 02:41 |
hmmmm |
which is the vast majority of the API |
| 02:42 |
hmmmm |
i don't think you understand how much contention is exactly going on with the environment |
| 02:42 |
hmmmm |
there are both read and write accesses hammering on it constantly |
| 02:43 |
electrodude512 |
are we talking about just the map or the whole mt api in general? |
| 02:43 |
hmmmm |
it's also been tried before, very early on... it ends up being slower to have individual envlocks around the apis than it is to just lock it once while lua is executing |
| 02:43 |
hmmmm |
almost all of the api deals with the map |
| 02:45 |
electrodude512 |
would you agree that the only problem, if we use lua lanes, is between the main and mapgen threads? |
| 02:45 |
hmmmm |
no |
| 02:45 |
electrodude512 |
and that any other threads can just talk to a server coroutine or something in the main thread instead of having any access to the mt api? |
| 02:45 |
hmmmm |
lua lanes is not a silver bullet |
| 02:46 |
electrodude512 |
what if you don't give additional lua lanes threads access to the mt api? |
| 02:50 |
electrodude512 |
then how is there a problem? |
| 02:51 |
hmmmm |
if api access is restricted to a single thread, then there is no problem. |
| 02:51 |
hmmmm |
lua threads aren't constantly running in the background though |
| 02:52 |
hmmmm |
you realize this right? |
| 02:52 |
electrodude512 |
yeah |
| 02:52 |
electrodude512 |
but I want one that is running constantly in the background for my mod, but it doesn't need mt api access |
| 02:52 |
hmmmm |
hey - if you can get multithreaded lua working in a non-lame manner that's thread safe, i'm all for it |
| 02:53 |
hmmmm |
this will work out for you, but the majority of the mods that do intensive processing need map access |
| 02:54 |
hmmmm |
meaning it's not really worth it |
| 02:54 |
electrodude512 |
I went back and read the irc history, and realized that VanessaE was talking about putting the non-lua part of the in a separate thread, not the lua part |
| 02:54 |
VanessaE |
yeah |
| 02:54 |
VanessaE |
well no |
| 02:54 |
electrodude512 |
s/the in/the mapgen in/ |
| 02:55 |
VanessaE |
I mentioned the mesh generator, not the mapgen |
| 02:55 |
electrodude512 |
oh, yeah |
| 03:00 |
electrodude512 |
I guess I was just too eager to talk about threads because they would be nice for my mod, and I got confused with stuff I was reading earlier today about people talking about mapgen happening in a seperate thread |
| 03:01 |
VanessaE |
as for separate threads, you can do a sort of "cooperative" threading by using minetest.register_globalstep() |
| 03:02 |
VanessaE |
as long as you divide your task into small pieces, watch dtime and dump out of your code when it gets too high |
| 03:02 |
VanessaE |
plants_lib does this to reduce latency with its mapgen code |
| 03:02 |
VanessaE |
but too much beyond this would be offtopic for this channel. |
| 03:02 |
electrodude512 |
yeah, but that doesn't take advantage of a multicore cpu |
| 03:03 |
VanessaE |
yes I know |
| 03:04 |
|
exio4 joined #minetest-dev |
| 03:04 |
|
exio4_ joined #minetest-dev |
| 03:05 |
electrodude512 |
not like it makes a difference for me, I only have a 2 core computer |
| 03:07 |
electrodude512 |
i'll probably just do what you said about plants_lib and put the computer resumer function in a coroutine and coroutine.resume it a few times until it's taken too long |
| 03:08 |
electrodude512 |
we're already using minetest.register_globalstep(), so it's a pretty easy change |
| 03:10 |
electrodude512 |
if I find any other mods (or come up with any ideas for other mods) that could benefit from having multiple threads and don't need lots of map access, I'll think about making a fork and PR that adds lua lanes support (if I have time and if it's not too complicated) |
| 03:14 |
VanessaE |
bbl |
| 03:19 |
|
MinerDad joined #minetest-dev |
| 03:33 |
|
proller joined #minetest-dev |
| 03:54 |
|
DFeniks joined #minetest-dev |
| 03:57 |
Bratmon |
I don't think you'll find that many mods that are processor heavy, but don't need map access. |
| 03:57 |
|
paramat left #minetest-dev |
| 04:03 |
electrodude512 |
yeah, a computer mod is really the only thing |
| 04:04 |
electrodude512 |
that would |
| 04:18 |
|
exio4 joined #minetest-dev |
| 04:46 |
|
kaeza joined #minetest-dev |
| 05:00 |
|
n4x joined #minetest-dev |
| 05:31 |
|
exio4 joined #minetest-dev |
| 05:52 |
|
paramat joined #minetest-dev |
| 05:53 |
paramat |
hmmmm, please could you merge https://github.com/minetest/minetest/pull/1995 ? Re-add hacky fix for underwater grass, to fix mgv7 user's biomes |
| 05:58 |
|
n4x joined #minetest-dev |
| 06:10 |
|
sol_invictus joined #minetest-dev |
| 06:22 |
|
pro joined #minetest-dev |
| 06:25 |
hmmmm |
sure |
| 06:26 |
hmmmm |
when we branch our biome implementations out, i'm going to move generateBiomes() from mapgens to the biomemanager |
| 06:26 |
paramat |
man i make so many mistakes :/ |
| 06:26 |
hmmmm |
i'm going to solve that issue by re-querying biomes at points for which the observed height is not equal to the heightmap at that point |
| 06:27 |
hmmmm |
how are you going to solve it? |
| 06:27 |
paramat |
good idea |
| 06:27 |
paramat |
that occured to me too |
| 06:28 |
hmmmm |
also after the release i'm going to add a typedef for ManualMapVoxelManipulator so you might want to get all your pending code in before that change |
| 06:28 |
hmmmm |
(i.e. lots of merge conflicts) |
| 06:29 |
paramat |
so far my idea is in my biomeapinodes branch, each registered biome has 'node_underwater_top' 'node_underwater_filler', or just one underwater node |
| 06:31 |
paramat |
my plans are a bt simplistic because i guess i'm a little limited by my level of C++ coding |
| 06:32 |
hmmmm |
the concepts you're implementing are usually more important than how sophisticated the code for it is |
| 06:32 |
paramat |
is one week after release fast enough to get my pending code in? |
| 06:32 |
hmmmm |
yeah |
| 06:32 |
paramat |
of course it may not be completely finished by then |
| 06:33 |
paramat |
i was going to 'consult' players on my potential changes |
| 06:34 |
paramat |
okay i'll try to wrap up and submit my current ideas soon after release |
| 06:36 |
paramat |
so much to do! mapgen alone could be 2 full time jobs |
| 06:38 |
paramat |
BTW nice ore veins, how did you generate those? |
| 06:39 |
hmmmm |
i stole the general idea for v5 caves |
| 06:40 |
hmmmm |
it's impossible to get nice output with 3d noise by itself |
| 06:40 |
paramat |
nice |
| 06:40 |
paramat |
in my lua mapgens i recalculate biome at each new surface found when working downwards |
| 06:41 |
hmmmm |
when i first played minecraft classic and minetest, i always thought ores were grouped together |
| 06:41 |
paramat |
before that it was at every node |
| 06:41 |
hmmmm |
when i actually got into their design and implementation, i was diappointed that was just a blob of them and there were no veins |
| 06:41 |
hmmmm |
this way you could actually find a "hotspot" for a certain ore and set up a mine there |
| 06:42 |
paramat |
yes i like the idea of ores in certain areas |
| 06:42 |
paramat |
i'm working on that in lua mapgen |
| 06:43 |
|
Wayward_One joined #minetest-dev |
| 06:45 |
|
exio4 joined #minetest-dev |
| 06:46 |
|
n4x joined #minetest-dev |
| 06:51 |
paramat |
however my hotspots may be 1kn+ apart, i like to force players to travel whahaha |
| 07:08 |
|
SmugLeaf joined #minetest-dev |
| 07:08 |
|
SmugLeaf joined #minetest-dev |
| 07:09 |
|
SmugLeaf joined #minetest-dev |
| 07:10 |
hmmmm |
well i can do that too by changing the spread factor parameters |
| 07:10 |
hmmmm |
and increasing the threshhold |
| 07:10 |
|
SmugLeaf joined #minetest-dev |
| 07:11 |
hmmmm |
what i have now is good because what you don't often realize is that nodes underground are much rarer than they seem when i generate them in air for testing |
| 07:11 |
|
Weedy joined #minetest-dev |
| 07:12 |
|
Weedy joined #minetest-dev |
| 07:13 |
|
ShadowNinja joined #minetest-dev |
| 07:15 |
|
Weedy joined #minetest-dev |
| 07:17 |
|
andre_pl joined #minetest-dev |
| 07:22 |
|
MinerDad joined #minetest-dev |
| 07:30 |
paramat |
yep |
| 07:47 |
|
Hunterz joined #minetest-dev |
| 07:56 |
|
exio4 joined #minetest-dev |
| 07:57 |
|
n4x joined #minetest-dev |
| 08:00 |
|
pro joined #minetest-dev |
| 08:11 |
|
selat joined #minetest-dev |
| 08:23 |
|
Calinou joined #minetest-dev |
| 08:37 |
|
kilbith joined #minetest-dev |
| 08:51 |
paramat |
hmmmm are spread values floats or integers? 'spread = {x=512.0, y=512.0, z=512.0},' this is for my noiseparams format example in lua_api.txt |
| 08:52 |
hmmmm |
i think they're floats |
| 08:52 |
hmmmm |
there's no practical reason why they should be though |
| 08:53 |
paramat |
that's what i assumed since in higher octaves they are divided and so usually end up as gloats |
| 08:53 |
paramat |
lol floats |
| 08:57 |
paramat |
think i'll remove the decimal as few players will define spread as a decimal |
| 09:00 |
Zeno` |
they are definitely considered as a float but I think in an example paramat might be right |
| 09:01 |
Zeno` |
i.e. https://github.com/minetest/minetest/blob/master/src/script/lua_api/l_noise.cpp#L82 |
| 09:03 |
paramat |
okay hmmmm and others please review/merge https://github.com/minetest/minetest/pull/1982 there's more to do but i have more important things to do and the incorrect format should be removed before 0.4.11 |
| 09:06 |
Zeno` |
Format of 'size' for 2D perlin maps: {x=dimx, y=dimy, z=1} <--- is specifying the z=1 there necessary? |
| 09:07 |
paramat |
i think hmmmm is working on making that unnecessary |
| 09:07 |
Zeno` |
oh ok :) |
| 09:07 |
hmmmm |
it is unnecessary |
| 09:07 |
paramat |
oh heh |
| 09:08 |
paramat |
really? you advised me to set it to z = 1, not remove it |
| 09:08 |
Zeno` |
The only other thing that makes me ask myself a question is this: for 3D perlin maps the z component of 'size' must not equal 1 otherwise 'nil' is returned |
| 09:08 |
Zeno` |
I'd rather know what valid values for z are |
| 09:09 |
Zeno` |
or at least if they have to be > 1 |
| 09:09 |
Zeno` |
i.e. is 0 or -8 ok? |
| 09:09 |
Zeno` |
Good to see a start to the documentation at last :) |
| 09:09 |
hmmmm |
let's be rational here |
| 09:10 |
hmmmm |
you're not going to set a negative size |
| 09:10 |
Zeno` |
hmmmm, I'm looking at it from the point of someone who has never used it |
| 09:10 |
Zeno` |
I mean, negative values are obviously not valid, but *shrug* |
| 09:12 |
|
MinerDad joined #minetest-dev |
| 09:13 |
|
n4x joined #minetest-dev |
| 09:13 |
|
Krock joined #minetest-dev |
| 09:15 |
|
ImQ009 joined #minetest-dev |
| 09:18 |
paramat |
ah: hmmmm wrote "the 'correct' way to do things would be to omit Z in the future" |
| 09:18 |
Zeno` |
Anyway, my point was that maybe size must be > 1 might be clearer |
| 09:18 |
paramat |
i was confused by: hmmmm wrote "for now I recommend you just set Z == 1 because people are probably going to run your mod on a version older than 0.4.11" |
| 09:18 |
|
Amaz joined #minetest-dev |
| 09:19 |
Zeno` |
I'm confused :) |
| 09:19 |
Zeno` |
Oh I see, the documentation should take into account versions prior to 0.4.11? That would make sense |
| 09:19 |
paramat |
okay will change, hmmmmm wrote "it just has a single ctor and the 'size Z' parameter has a default of 1@ |
| 09:20 |
paramat |
*" |
| 09:20 |
paramat |
well i think it should be written for 0.4.11 so i can omit the z = 1, since it is set to 1 by default |
| 09:20 |
paramat |
will change |
| 09:28 |
paramat |
zeno yes i agree for 3d noise size.z > 1 is clearer |
| 09:30 |
|
CraigyDavi joined #minetest-dev |
| 09:31 |
paramat |
will change that too |
| 09:34 |
Krock |
Pull #1990 is rebased now |
| 09:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1990 -- Add language setting by srifqi |
| 09:36 |
Krock |
Hmm interesting message: "10:37:33: ERROR[main]: MSVC localization workaround active restating minetest in new environment!" |
| 09:36 |
Zeno` |
Looks strangely similar to https://gist.github.com/Zeno-/15645da139c390994b74 |
| 09:37 |
Krock |
Zeno`, I see you also had the problem with the Android setting |
| 09:37 |
Zeno` |
yep |
| 09:38 |
Zeno` |
oh.. which problem? |
| 09:38 |
Krock |
space-problem |
| 09:38 |
Zeno` |
Maybe; I didn't even test it :D |
| 09:38 |
Krock |
just comment-out the android part <.< |
| 09:39 |
Zeno` |
was only meant as a start for srifqi, but maybe he didn't get the link I sent him |
| 09:40 |
Zeno` |
how did you rebase it? |
| 09:40 |
Zeno` |
I mean, add it to the PR? |
| 09:40 |
Krock |
he gave me the permission to do so |
| 09:40 |
Zeno` |
oh, :D |
| 09:40 |
Krock |
otherwise - haxx |
| 09:41 |
paramat |
okay perhaps ready now https://github.com/minetest/minetest/pull/1982 |
| 09:42 |
paramat |
also don't forget https://github.com/minetest/minetest/pull/1995 oh hmmmmm has gone |
| 09:42 |
Zeno` |
After more testing today, #1987 does increase performance on Linux but in a different area to where the optimisation has an effect on Windows (based on the .png in the PR) |
| 09:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/1987 -- Change TileSpec::frames to be std::vector not std::map by gregorycu |
| 09:43 |
Zeno` |
So I think that should be merged before 0.4.11 release |
| 09:43 |
Zeno` |
I'll add a thumbs up to the PR |
| 09:44 |
Zeno` |
I'm ok with 1982 |
| 09:45 |
paramat |
pull 1995 is a bugfix to be merged for 0.4.11, it's tested and TenPlus1 will hopefully test it too |
| 09:45 |
|
nore joined #minetest-dev |
| 09:46 |
paramat |
thanks, perhaps best wait for hmmmmm to check 1982 |
| 09:46 |
Zeno` |
I don't even understand what 1995 does hehe |
| 09:46 |
Zeno` |
yeah, I'm just saying I'm ok with it; I like it :) |
| 09:47 |
Krock |
Zeno`, look at its codes, it prevents grassy nodes under water |
| 09:47 |
paramat |
1995: 18hrs ago i realised i had broken mgv7 biomes |
| 09:47 |
Zeno` |
Krock, I understood that part; I don't understand what the issue was (and perhaps I don't want or need to, lol) |
| 09:48 |
Krock |
-.- why not just use the 1st node below the top-node? for a grass biome, it would be dirt |
| 09:49 |
Krock |
perhaps, this also would work for sand |
| 09:49 |
paramat |
that was my idea Krock |
| 09:49 |
Krock |
paramat, but you check for c_dirt_with_grass |
| 09:49 |
Zeno` |
Has anyone else tested #1988? |
| 09:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/1988 -- Fix #1374 by adding a listpredict piece to the formspec by MinerDad7 |
| 09:49 |
paramat |
but it breaks TenPlus1's underwater layers of sand on gravel |
| 09:50 |
paramat |
so hmmmm's hacky fix is going back in |
| 09:50 |
paramat |
to act exactly as it did before |
| 09:51 |
paramat |
however i will be modifying the biome api very soon in a backwards compatible way |
| 09:51 |
paramat |
after release |
| 09:53 |
paramat |
then multiple biome api's will be enabled and hmmmmm starts work on his new biome system to run parallel to my work |
| 09:54 |
paramat |
for each mapgen base terrain players will have a choice of biome apis to use |
| 09:54 |
paramat |
more choice and variety, no possibilities are lost |
| 09:58 |
paramat |
best 1995 waits for hmmmmm's approval too |
| 09:58 |
Krock |
^ looks okay for me |
| 09:59 |
Krock |
(except of the spaces in the noise definition) |
| 10:01 |
|
ImQ009 joined #minetest-dev |
| 10:02 |
paramat |
those spaces result in lined up code, don't worry |
| 10:02 |
Krock |
:/ |
| 10:04 |
* Zeno` |
tries not to fret |
| 10:10 |
|
paramat left #minetest-dev |
| 10:11 |
Zeno` |
Krock, try renaming your minetest.exe to mt.exe and run using mt |
| 10:11 |
Zeno` |
Just for interest's sake |
| 10:11 |
Krock |
even qwertz.exe runs fine |
| 10:11 |
Krock |
changing it to mt.exe won't change anything |
| 10:11 |
Zeno` |
it should not change anything |
| 10:12 |
Zeno` |
I want to see if it does |
| 10:12 |
Krock |
it doesn't |
| 10:12 |
Zeno` |
you just tested it? |
| 10:12 |
Krock |
it's quite simple to rename that stuff |
| 10:12 |
Zeno` |
please, just rename it mt.exe |
| 10:12 |
Krock |
I did |
| 10:12 |
Zeno` |
and make sure you run it by typing mt and not mt.exe |
| 10:13 |
Krock |
I can't run files without a .exe or .com tailing |
| 10:13 |
Zeno` |
in the command line you cannot simply type mt? |
| 10:13 |
Zeno` |
you don't normally type dir.exe in full do you? |
| 10:14 |
Krock |
It could not find the command 'mt' |
| 10:14 |
Zeno` |
weird |
| 10:14 |
celeron55 |
why do you think that would have any effect? |
| 10:14 |
sfan5 |
Zeno`: windows only runs .exe files |
| 10:14 |
Krock |
and about the dir.exe, I can use both because it searchs for .exe, .com and .bat executables |
| 10:15 |
sfan5 |
but you can omit the .exe when running them |
| 10:15 |
Zeno` |
celeron55, It won't fix anything I'm just wondering about line 171 of gettext.cpp |
| 10:15 |
Zeno` |
sfan5, and that's what I'm asking Krock to try :) rename to mt.exe and launch by typing mt |
| 10:15 |
Krock |
Lool. renaming it to minetest.com gives funny errors |
| 10:15 |
sfan5 |
Zeno`: that doesn't work because . is not in $PATH |
| 10:15 |
Krock |
11:17:11: ERROR[main]: Failed to restart with current locale: |
| 10:16 |
|
chchjesus joined #minetest-dev |
| 10:16 |
Zeno` |
sfan5, I assumed he would cd to the correct path |
| 10:16 |
Zeno` |
Krock, so that's an additional error? |
| 10:16 |
Zeno` |
error/bug? |
| 10:16 |
Krock |
Zeno`, 1 min. pressing printscreen |
| 10:16 |
celeron55 |
wtf, why does this matter in anything |
| 10:17 |
Krock |
No idea but it's funny to see that .exe thing in gettext.cpp |
| 10:18 |
Krock |
because .com is a valid extention too |
| 10:18 |
celeron55 |
nobody has used .com for anything since 20 years ago |
| 10:19 |
Zeno` |
why does renaming it to mt.exe and launching with mt and getting an additional error matter? |
| 10:19 |
celeron55 |
Zeno`: he renamed it to something.com |
| 10:19 |
Zeno` |
I didn't ask him to do that :) |
| 10:19 |
sfan5 |
Zeno`: afaik windows only searches for foobar.{exe,com,bat} files in the PATH when you type "foobar" |
| 10:20 |
Zeno` |
I believe that renaming to mt.exe will result in Krock> 11:17:11: ERROR[main]: Failed to restart with current locale: |
| 10:20 |
Zeno` |
and that is what I am trying to determine. I can't directly test this |
| 10:20 |
Krock |
http://i.imgur.com/MP3o59u.png |
| 10:22 |
Zeno` |
So, what's that do? Crash or just ignore the language change? |
| 10:24 |
Krock |
minetest.exe closes the console window and does not throw any significant error while minetest.com coesn't close the console window and fails to load the new language |
| 10:24 |
Krock |
*doesn't |
| 10:24 |
Zeno` |
what about mt.exe? |
| 10:24 |
Krock |
that acts like minetest.exe |
| 10:25 |
Krock |
only the file extention is important in this case |
| 10:25 |
Zeno` |
According to if (appname.substr(appname.length() -4) != ".exe") { not just the extension is important |
| 10:25 |
Zeno` |
But if there is no error there is no error (even though according to the standard there probably should be one) |
| 10:26 |
Zeno` |
*shrug* |
| 10:26 |
sfan5 |
wtf is that msvc workaround even doing |
| 10:26 |
Krock |
^ |
| 10:26 |
Zeno` |
relaunching minetest |
| 10:26 |
Zeno` |
//very very dirty workaround to force gettext to see the right environment |
| 10:26 |
Krock |
I think it tries to emulate a new system configuratoin with other language |
| 10:27 |
Krock |
funny thing is, removing "language = de" setting solves the problem for me :) |
| 10:27 |
Krock |
and the language in the menu does not change with that setting removal |
| 10:27 |
sfan5 |
uhh |
| 10:28 |
sfan5 |
wat |
| 10:28 |
sfan5 |
why not just check whether argv[0] contains a . |
| 10:28 |
|
psedlak joined #minetest-dev |
| 10:32 |
Zeno` |
Anyway this change should, logically, trigger that dormant bug so if the language PR is to be merged that has to be fixed as well |
| 10:32 |
|
gravgun joined #minetest-dev |
| 10:32 |
Zeno` |
I need to set up a windows toolchain one day |
| 10:33 |
|
chchjesus joined #minetest-dev |
| 10:33 |
sfan5 |
Zeno`: sudo apt-get install vagrant && vagrant init ubuntu/precise64 && vagrant up && wget http://meow.minetest.net/mingw_w64_x86_64_ubuntu12.04_4.9.1.7z |
| 10:33 |
sfan5 |
there you go ;) |
| 10:34 |
|
n4x joined #minetest-dev |
| 10:34 |
Zeno` |
I will try that when I install Ubuntu :D |
| 10:34 |
sfan5 |
vagrant works on other distros too |
| 10:35 |
Zeno` |
I kind of broke cross-compiling in yum (or somehow my yum databases got messed up) |
| 10:35 |
Zeno` |
It was working a few months ago and not now |
| 10:35 |
Zeno` |
Perhaps I should upgrade to fedora 20 |
| 10:40 |
celeron55 |
don't touch the workaround, it's very needed |
| 10:43 |
Zeno` |
yes of course it's needed |
| 10:43 |
Zeno` |
nobody was suggesting changing it I don't think |
| 10:44 |
Zeno` |
well maybe just fixing the bug |
| 10:48 |
|
kahrl joined #minetest-dev |
| 10:49 |
|
selat joined #minetest-dev |
| 10:49 |
kahrl |
why isn't it simply something along the lines of CreateProcessW(GetModuleFileNameW(NULL), GetCommandLineW(), ...) |
| 10:50 |
kahrl |
well GetModuleFileNameW(NULL, buf, sizeof buf); ... CreateProcessW(buf, ...) but you know what I mean |
| 10:51 |
kahrl |
gah, not sizeof buf, but sizeof buf/sizeof *buf |
| 10:51 |
Zeno` |
:D |
| 11:05 |
Zeno` |
Any comments on #1851? |
| 11:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/1851 -- Cleanup updateCameraDirection and fix random input not working by Zeno- |
| 11:27 |
|
kilbith joined #minetest-dev |
| 11:54 |
|
n4x joined #minetest-dev |
| 11:55 |
|
exio4 joined #minetest-dev |
| 12:01 |
|
Zeno` joined #minetest-dev |
| 12:04 |
nore |
sfan5: I'm ok with #379 |
| 12:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/379 -- Client tries to open mesh files from any path without check [edited] |
| 12:05 |
sfan5 |
I'll merge it now |
| 12:07 |
nore |
ok |
| 12:49 |
|
MinerDad joined #minetest-dev |
| 12:58 |
|
Zeno` joined #minetest-dev |
| 13:01 |
|
pro joined #minetest-dev |
| 13:08 |
|
selat joined #minetest-dev |
| 13:10 |
|
roniz joined #minetest-dev |
| 13:17 |
|
Zeno` joined #minetest-dev |
| 13:17 |
Zeno` |
Can #1987 be merged? |
| 13:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/1987 -- Change TileSpec::frames to be std::vector not std::map by gregorycu |
| 13:18 |
Zeno` |
Or, put another way, is there a reason for it not to be merged? |
| 13:19 |
|
exio4 joined #minetest-dev |
| 13:20 |
|
n4x joined #minetest-dev |
| 13:20 |
Krock |
Zeno`, the feature freeze. it could be labaled with feature... |
| 13:20 |
Zeno` |
It's not a new feature |
| 13:21 |
|
y joined #minetest-dev |
| 13:23 |
Zeno` |
Also, #1851 (bug fix) |
| 13:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/1851 -- Cleanup updateCameraDirection and fix random input not working by Zeno- |
| 13:25 |
jin_xi |
hm, isnt a ff meant to test such changes in the absence of adding features? |
| 13:25 |
Zeno` |
these are not features though |
| 13:25 |
jin_xi |
anyways i find it strange to consider 1987 a feature |
| 13:25 |
Zeno` |
1851 certainly isn't |
| 13:26 |
Zeno` |
it's not a feature :/ |
| 13:36 |
celeron55 |
none of those are important for the release to be succesful, they can be just put in right after release |
| 13:36 |
celeron55 |
then nobody has to worry about them at all |
| 13:37 |
celeron55 |
and they will be 100% tested without any extra effort in 0.4.12 |
| 13:38 |
celeron55 |
it's generally a bad idea to try to overly minimize the "lag" from creating something to putting it in a release, because then people start expecting it and it will just cause extra stress to everyone involved |
| 13:39 |
celeron55 |
(it should be a constant flow with enough time for every step) |
| 13:39 |
celeron55 |
at the moment the release is supposed to go out at any moment |
| 13:50 |
celeron55 |
(i'm guessing hmmmm will decide when as he's been generally doing that) |
| 13:56 |
|
shadowzone joined #minetest-dev |
| 13:57 |
Zeno` |
yeah I guess random movement isn't exactly critical |
| 14:21 |
|
prol joined #minetest-dev |
| 14:24 |
|
T4im joined #minetest-dev |
| 14:28 |
|
MinetestForFun joined #minetest-dev |
| 14:56 |
|
Amaz joined #minetest-dev |
| 14:56 |
|
GrimKriegor joined #minetest-dev |
| 15:31 |
Zeno` |
actually |
| 15:31 |
Zeno` |
I think #1987 must be merged before 0.4.11 is released |
| 15:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/1987 -- Change TileSpec::frames to be std::vector not std::map by gregorycu |
| 15:31 |
Zeno` |
There is nothing to test |
| 15:32 |
Zeno` |
It's not a feature; it's an optimisation by choosing the correct data type |
| 15:32 |
Zeno` |
not much different to changing something from using double to float |
| 15:32 |
Zeno` |
s/using/changing |
| 15:33 |
Zeno` |
std::map was just wrong |
| 15:33 |
Zeno` |
"feature freeze" does not mean ignoring simple optimisations |
| 15:42 |
|
CraigyDavi joined #minetest-dev |
| 15:46 |
Krock |
Zeno`, ask someone who would agree that. And then finally merge it :P |
| 15:46 |
Zeno` |
I just asked :) |
| 15:55 |
Zeno` |
Any objections to merging 1987 (a trivial change of data type)? |
| 15:56 |
Zeno` |
(to a more appropriate data type? There is no reason whatsoever that should be std::map) |
| 15:58 |
* Zeno` |
stages |
| 16:09 |
|
MinerDad joined #minetest-dev |
| 16:21 |
|
ottodachshund joined #minetest-dev |
| 16:22 |
|
Zeno`` joined #minetest-dev |
| 16:29 |
|
SmugLeaf joined #minetest-dev |
| 16:29 |
|
JZTech103 joined #minetest-dev |
| 16:29 |
|
Brat_Mon joined #minetest-dev |
| 16:29 |
Zeno` |
ok, no objections? |
| 16:31 |
|
Weedy_ joined #minetest-dev |
| 16:32 |
|
Tesseract joined #minetest-dev |
| 16:32 |
|
64MABGERZ joined #minetest-dev |
| 16:34 |
|
kahrl_ joined #minetest-dev |
| 16:35 |
|
hacker joined #minetest-dev |
| 16:35 |
|
JZTech101 joined #minetest-dev |
| 16:36 |
|
T4im joined #minetest-dev |
| 16:38 |
|
pitriss` joined #minetest-dev |
| 16:39 |
|
Zeno` joined #minetest-dev |
| 16:40 |
|
Ritchie joined #minetest-dev |
| 16:41 |
Zeno` |
ok, merging |
| 16:43 |
|
Megaf joined #minetest-dev |
| 16:43 |
|
johnnyjoy joined #minetest-dev |
| 16:43 |
|
proller joined #minetest-dev |
| 16:43 |
|
Anchakor joined #minetest-dev |
| 16:44 |
|
RealBadAngel joined #minetest-dev |
| 16:44 |
|
chrisf joined #minetest-dev |
| 16:44 |
|
sfan5 joined #minetest-dev |
| 16:44 |
|
Taoki_1 joined #minetest-dev |
| 16:45 |
|
puhfa joined #minetest-dev |
| 16:45 |
|
SmugLeaf joined #minetest-dev |
| 16:46 |
|
kaeza joined #minetest-dev |
| 16:46 |
|
kilbith joined #minetest-dev |
| 16:46 |
|
selat joined #minetest-dev |
| 16:46 |
|
mrtux joined #minetest-dev |
| 16:46 |
|
sfan5 joined #minetest-dev |
| 16:46 |
|
CraigyDavi joined #minetest-dev |
| 16:50 |
|
T4im joined #minetest-dev |
| 16:51 |
kaeza |
what is the compiler used for official builds? MSVC? |
| 16:52 |
|
VargaD joined #minetest-dev |
| 16:52 |
Zeno` |
mingw |
| 16:52 |
sfan5 |
kaeza: the offial builds use msvc |
| 16:53 |
|
MichaelRpdx joined #minetest-dev |
| 16:53 |
Zeno` |
they do? |
| 16:53 |
sfan5 |
kaeza: the official mingw builds use ... surprise! .. mingw |
| 16:53 |
sfan5 |
Zeno`: yes |
| 16:53 |
Zeno` |
so... why is this not documented somewhere? All the docs and the repo suggest mingw |
| 16:53 |
kaeza |
sfan5, if the main target is MSVC, I guess #1959 is not so much of a blocker, but it still could be fixed before release |
| 16:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/1959 -- Checking public serverlist checkbox causes minetest to freeze. |
| 16:54 |
kaeza |
Zeno`, have you managed to get a working mingw environment? |
| 16:54 |
Zeno` |
kaeza, yes and no |
| 16:55 |
Zeno` |
kaeza, yes I can compile, but it does not run :) |
| 16:55 |
kaeza |
Zeno`, you need to compile the C++ libs by yourself |
| 16:55 |
kaeza |
the plain C ones work fine |
| 16:57 |
|
shadowzone joined #minetest-dev |
| 16:57 |
Zeno` |
kaeza, I dunno. I followed the cmake errors installing stuff as it encountered errors. I'll reboot into Windows again tomorrow I guess |
| 16:58 |
kaeza |
alright |
| 16:58 |
Zeno` |
What would I need to compile that is not covered by cmake? |
| 16:58 |
kaeza |
my build environment uses the same libs as sfan5's builds, except for C++ libs which I had to compile myself from sources |
| 16:58 |
kaeza |
mainly Irrlicht I think |
| 16:58 |
kaeza |
lemme see |
| 16:59 |
Zeno` |
I disabled sound in Windows 7 |
| 17:01 |
Zeno` |
sfan5, who compiles the official Windows releases? |
| 17:02 |
sfan5 |
Zeno`: BlockMen for MSVC and me for MinGW |
| 17:03 |
Zeno` |
sfan5, that doesn't make sense. You said the official Windows release was MSVC... so how does mingw come into the equation? |
| 17:03 |
sfan5 |
there is always msvc and mingw |
| 17:04 |
|
CraigyDavi joined #minetest-dev |
| 17:05 |
Zeno` |
so how can a release happen on the 24th since Blockmen has been MIA for months? |
| 17:07 |
kaeza |
Zeno`, I'd have to make a huge cleanup to my build env, but basically, I ran this ( https://gist.github.com/kaeza/11bb76e32d6996ccb7dd ), compiled Irrlicht and CURL, then mucked up in cmake-gui to point it to the new libs |
| 17:07 |
kaeza |
it's just a modified buildbot |
| 17:07 |
Zeno` |
thanks kaeza... bookmarked and I'll try again tomorrow |
| 17:08 |
sfan5 |
Zeno`: if BlockMen doesn't turn up I'll have to install MSVC in a VM |
| 17:11 |
Zeno` |
I'm just trying to understand, but isn't it unusual for there to be two official builds for Windows? How does the Windows user know which one to choose? |
| 17:12 |
sfan5 |
MSVC is the preferred one |
| 17:13 |
Zeno` |
If I was a Windows user and tried to install, say, Skyrim and I was presented with an option to choose between an MSVC build and a MinGW build I'd be baffled and probably not install either |
| 17:16 |
sfan5 |
Zeno`: so you think it's too hard to click on a bold download link? |
| 17:16 |
Zeno` |
sfan5, I'd think "why can't they decide" and not bother, yes |
| 17:18 |
Zeno` |
A typical user would sit there baffled I imagine |
| 17:18 |
Zeno` |
what is MSVC? What is MinGW? ARRGH too hard... can't decide |
| 17:19 |
Zeno` |
I don't click on "Get Firefox" and get presented with a list of different compilers it was built with |
| 17:21 |
Zeno` |
Because, as a user, why should I care? |
| 17:21 |
|
n4x joined #minetest-dev |
| 17:24 |
kaeza |
I can agree that having two Windows builds is quite unusual. most software only provides one build (and most of the time they don't bother explaining which compiler is used) |
| 17:25 |
kaeza |
is there a reason for that? (I'm not saying it's bad or good) |
| 17:25 |
|
mpa1212 joined #minetest-dev |
| 17:25 |
|
twoelk joined #minetest-dev |
| 17:29 |
|
petrusd987 joined #minetest-dev |
| 17:36 |
VanessaE |
why not just put the non-preferred link somewhere else on the page entirely? |
| 17:38 |
|
rubenwardy joined #minetest-dev |
| 18:02 |
|
ottodachshund joined #minetest-dev |
| 18:07 |
|
ottodachshund joined #minetest-dev |
| 18:07 |
Brat_Mon |
kaeza, the reason is because they (should) benchmark the two versions. |
| 18:08 |
Brat_Mon |
And only use the better one. |
| 18:14 |
|
hmmmm joined #minetest-dev |
| 18:25 |
|
Bratmon joined #minetest-dev |
| 18:34 |
|
Calinou joined #minetest-dev |
| 18:35 |
|
MinerDad joined #minetest-dev |
| 18:37 |
|
n4x joined #minetest-dev |
| 19:05 |
|
shadowzone joined #minetest-dev |
| 19:19 |
|
GrimKriegor joined #minetest-dev |
| 19:22 |
|
prol joined #minetest-dev |
| 19:29 |
|
Miner_48er joined #minetest-dev |
| 19:29 |
|
roniz joined #minetest-dev |
| 19:45 |
Tesseract |
kaeza: The reason is that for some users MSVC runs a lot faster and for others MinGW is a lot faster. |
| 19:52 |
|
n4x joined #minetest-dev |
| 20:10 |
|
prol joined #minetest-dev |
| 20:34 |
|
roniz joined #minetest-dev |
| 20:52 |
|
prol joined #minetest-dev |
| 21:09 |
|
n4x joined #minetest-dev |
| 21:20 |
|
DuDraig joined #minetest-dev |
| 21:32 |
|
shadowzone joined #minetest-dev |
| 21:58 |
|
electrodude512 joined #minetest-dev |
| 22:23 |
|
CraigyDavi joined #minetest-dev |
| 22:28 |
|
n4x joined #minetest-dev |
| 22:55 |
|
CraigyDavi joined #minetest-dev |
| 23:17 |
|
CraigyDavi joined #minetest-dev |
| 23:38 |
kilbith |
the new ladder brings a nice optical illusion when wielded : https://cdn.mediacru.sh/U/UAtABt05mwna.png |
| 23:39 |
kilbith |
signlike, and it seems like a nodebox model |
| 23:47 |
|
n4x joined #minetest-dev |
| 23:48 |
|
exio4 joined #minetest-dev |
