| Time |
Nick |
Message |
| 00:01 |
sapier |
and you're gonna add +1 if protocol is updated next time? ;) |
| 00:02 |
cmdskp |
I already did ;) |
| 00:02 |
cmdskp |
but that may be incremented further before I find a way round myself ^_^ |
| 00:02 |
sapier |
usually you should change things in a way old clients wont even notice it |
| 00:02 |
sapier |
e.g. by adding additional fields |
| 00:02 |
sapier |
old clients just ignore them |
| 00:03 |
sapier |
new clients should handle both old style and new one prefering the new one if present |
| 00:03 |
|
red-001 joined #minetest-dev |
| 00:03 |
cmdskp |
yes, unfortunately, I'm not up to scratch on the network system to determine the best way to handle it, so I'm hoping for some help with this bit :) |
| 00:04 |
sapier |
it's always better to check what you actually need then check some number that might or might not be correct |
| 00:04 |
|
gregorycu joined #minetest-dev |
| 00:05 |
red-001 |
is anyone working on client sided lua? |
| 00:05 |
cmdskp |
From my understanding, looking at other parts of the code around it, they used to pass in a version number as a byte in some sections and then determine from that what is needed |
| 00:06 |
cmdskp |
or what is expected |
| 00:06 |
est31 |
red-001, no, but its a promised bride. |
| 00:06 |
est31 |
both hmmm and c55 want to do it, and have done preparations |
| 00:07 |
* red-001 |
wonders how hard it would be to do |
| 00:08 |
sapier |
est31 me to about a year ago ;-P |
| 00:08 |
red-001 |
why not anymore? |
| 00:08 |
sapier |
eventually someone will really do it |
| 00:09 |
red-001 |
and (hopeful) get their PR merged |
| 00:09 |
sapier |
well I was distracted from doing it by some formspec things I merged for someone else ... resulting in me to fix all the "changes" |
| 00:09 |
est31 |
red-001, there are many issues client side lua has to do |
| 00:09 |
est31 |
fulfill |
| 00:09 |
est31 |
like sandboxing |
| 00:10 |
est31 |
and other issues are disputed between core devs |
| 00:10 |
sapier |
est31 actually all of them are already done |
| 00:10 |
est31 |
e.g. whether to run it in the main thread, or in a separate thread |
| 00:10 |
sapier |
90% of it's code is already in |
| 00:10 |
est31 |
sapier, you mean SN's sandboxing? |
| 00:10 |
sapier |
nope |
| 00:10 |
est31 |
its nice, but has to be more strict. |
| 00:10 |
red-001 |
then whats stopping it? |
| 00:11 |
est31 |
idk |
| 00:11 |
sapier |
when I implemented the lua based mainmenu I already did write it in a way you can create lua stacks with minimal content |
| 00:11 |
red-001 |
if 90% of the code is done |
| 00:11 |
est31 |
everybody wanting to do it and saying "i want to do it" then not doing work on it until sb else says "I do it" |
| 00:11 |
sapier |
actually the async worker threads of mainmenu ARE those minimal environments |
| 00:12 |
sapier |
My plan by that time was starting the client side lua with some minimal feature set |
| 00:13 |
sapier |
e.g. first only supporting prediction of formspec inventory changes |
| 00:13 |
est31 |
cmdskp, where exactly do you want to get the version? |
| 00:14 |
sapier |
but I'm not very eager to spend my time on work someone else already started |
| 00:14 |
cmdskp |
line 1664 of content_cao |
| 00:15 |
sapier |
so unless hmmm and celeron don't say "do it" I'm not gonna start working at it again |
| 00:16 |
cmdskp |
a test for the client to check if the server is returning protocol version 27, I believe |
| 00:16 |
est31 |
cmdskp, can you give me a github link of that line? |
| 00:16 |
sapier |
imho first prototype is about one week of work ... assuming most of the preparations I did are still intact |
| 00:16 |
est31 |
cmdskp, click on the line, it will change the url then copy it here |
| 00:16 |
cmdskp |
https://github.com/cmdskp/minetest/blob/54ede741a9b01b34b8a64cf2cc929398a5d167d5/src/content_cao.cpp#L1665 |
| 00:17 |
cmdskp |
ty |
| 00:17 |
est31 |
cmdskp, I think you only have to catch the serialisation error here |
| 00:17 |
est31 |
using exceptions like if clauses hehe |
| 00:18 |
est31 |
but idk, its better than raising protocol version for nothing |
| 00:18 |
est31 |
or do you already raise it for some other reason? |
| 00:18 |
cmdskp |
ah, that's good to know - I wonder considering the comments below about if sends nothing |
| 00:18 |
sapier |
est31 is right catching the serializatiin error is the common way this is done |
| 00:19 |
sapier |
protocol version change usual is only done if there's something incompatible |
| 00:19 |
cmdskp |
the only reason I can think of is to deny an old client connection to a server running with slippery engaged - it'd be advantageous to the client to not be slipping compared to those up-to-date |
| 00:20 |
cmdskp |
on ice, for example |
| 00:20 |
sapier |
isn't slippery something like "hunger" ... I guess some ppl wont like it very much |
| 00:20 |
est31 |
yeah |
| 00:21 |
est31 |
in fact I dont I have to admit |
| 00:21 |
cmdskp |
fortunately, I've included a method to override slippery to allow cancelling it out |
| 00:21 |
est31 |
still it should be added imo bc some ppl like it |
| 00:21 |
cmdskp |
for modders |
| 00:21 |
cmdskp |
It's setup in the node groups too, so people can include or not as they wish :) |
| 00:22 |
sapier |
to be honest I'd not like it ... but if others do |
| 00:23 |
cmdskp |
It won't be active unless people add a slippery=X to a node |
| 00:23 |
sapier |
especially as I don't see a good way to implement this for entities or items |
| 00:23 |
cmdskp |
entities and items slip too |
| 00:23 |
sapier |
e.g. what to do for entities with > 1x1 collision boxes ... calculate average slippery? |
| 00:24 |
cmdskp |
they use the node slippery factor to adjust their relative speed |
| 00:24 |
sapier |
which one? center? corner? |
| 00:25 |
est31 |
well in fact the problem exists for 1x1 collision boxes too |
| 00:25 |
cmdskp |
That's handled by Irrlicht I believe, which appears to use the whole bounding box for collisions |
| 00:25 |
sapier |
e.g. have a huge whale 3x4 and a single line of ice in the middle ... shall it slip to the end just becaus it's center is above the ice? ;-) |
| 00:26 |
sapier |
est31 yes but there the effect isn't that obvious |
| 00:26 |
cmdskp |
Oh, it doesn't keep slipping normally, just for a few nodes (depending on the setting) |
| 00:27 |
sapier |
I implemented friction for my monorail mod ages ago ... effects of physical correct implementation sometimes feel strange in minetest environment :-) |
| 00:27 |
sapier |
especially if you implement air resistance too :-) |
| 00:27 |
cmdskp |
It would be computationally expensive to check the whole area under an entities collision box |
| 00:27 |
gregorycu |
Hello all |
| 00:28 |
est31 |
hi gregorycu ! |
| 00:28 |
sapier |
still without calculating inertion the result will be suboptimal |
| 00:28 |
est31 |
inertion? |
| 00:28 |
gregorycu |
I think I better have a look at some of my PRs |
| 00:28 |
cmdskp |
It does raise an interesting option to add - a slip factor on non-player entities to stop the slippery, like I've added for players with physics_override |
| 00:29 |
sapier |
so adding slipery somehow results in needing inertion ... needing medium resistance (different in water then in air ;-) ) |
| 00:29 |
est31 |
i know what an inertial system is, but inertion... |
| 00:29 |
cmdskp |
that way you can prevent big entities from slipping at all, if desired and perform a more thorough check inside the entity onstep |
| 00:29 |
sapier |
sounds like a feasable workaround ... maybe not even enable slipery for those by default |
| 00:31 |
sapier |
but I still don't like it yet I'll try to show you issues it's up to you and those who like the feature to evaluate how important those issues are |
| 00:31 |
cmdskp |
that's possible, there's no real reason to have entities slide except for coolness and fun-factor to see thrown items slide across the ice =D That and expections I guess, if someone has set ice to slip and entities don't by default would seem incongruous :) |
| 00:31 |
est31 |
yeah collision box calculations are a place where areastores can profit as well |
| 00:32 |
cmdskp |
I'm afriad I must initiate my sleep cycle, but thank you for an interesting discussion. Food for thought :) |
| 00:32 |
sapier |
well I'd wanted a "on_collision" entity callback for some time guess I'm the only one who sees use for it |
| 00:33 |
cmdskp |
I was wanting that too for handling momentum on carts |
| 00:33 |
sapier |
I guess I have to fix the facedir rotation limit once again ... seems like it always rotates to same direction even if rotation to different direction would be way less change :-/ |
| 00:34 |
* cmdskp |
exits to sleep cycle :) |
| 00:35 |
est31 |
real programmers don't count sheep, they count nops xD |
| 00:35 |
sapier |
I hate nop slides |
| 00:37 |
est31 |
just use custom microcode for your platform, and patch your compiler |
| 00:38 |
sapier |
I've got enough work on working around cpu bugs ... hate to do this .. fixing hardware bugs in software .... |
| 00:39 |
sapier |
https://github.com/minetest/minetest/pull/3454/commits what about merging the non irrlicht updates till irrlicht fixes it's issues? |
| 00:40 |
est31 |
sapier, you do embedded stuff, being one of the few devs who use that piece of hw? |
| 00:41 |
sapier |
for what I know I'm one of about 3 ppl using that particular part of the asic yes |
| 00:42 |
sapier |
well that part is used in other asics too ... yet in different revisions |
| 00:42 |
sapier |
but hw bugs seem to be usually added to each new version instead of being fixed |
| 00:44 |
est31 |
lol |
| 00:44 |
est31 |
sapier, fine with me merge the commits |
| 00:44 |
est31 |
but note there is more recent curl version out |
| 00:44 |
est31 |
ermm sorry |
| 00:44 |
est31 |
its most recent |
| 00:44 |
est31 |
openssl too |
| 00:45 |
sapier |
I'll check once again ... well it's updating quite some libs not surprising its outdated after some weeks |
| 00:46 |
sapier |
but android build server has to be updated using gcc 4.9 fails on old version used there |
| 00:46 |
est31 |
yeah suprised to see there still was potential to update |
| 00:46 |
est31 |
after all, I'd pushed a similar commit not a long time ago |
| 00:46 |
sapier |
I'd wanted to update irrlicht but obviously current dev version has major issues |
| 00:47 |
est31 |
2f58e4d9624b4f31c5064dc640e0ad40d8adb9ea |
| 00:48 |
sapier |
was there any reason for not using gmp in openssl? |
| 00:49 |
est31 |
no |
| 00:49 |
est31 |
i just didnt thought of it |
| 00:50 |
est31 |
I mostly needed it for other things |
| 00:50 |
est31 |
like, cryptography when logging in |
| 00:51 |
|
sapier1 joined #minetest-dev |
| 00:53 |
|
sapier joined #minetest-dev |
| 00:54 |
sapier |
I don't see a more recent openssl version then 1.0.1e |
| 00:58 |
sapier |
1.0.2e of course |
| 01:00 |
|
Robby joined #minetest-dev |
| 01:02 |
|
gregorycu joined #minetest-dev |
| 01:23 |
|
sapier left #minetest-dev |
| 01:30 |
gregorycu |
Did c55 do his farblock stuff? |
| 01:34 |
gregorycu |
Or farmap, whatever it is called |
| 01:47 |
|
Robby joined #minetest-dev |
| 01:54 |
VanessaE |
gregorycu: he has yet to merge it |
| 01:54 |
gregorycu |
Thanks |
| 01:54 |
VanessaE |
but there is a fork you can play with. |
| 01:54 |
VanessaE |
https://github.com/celeron55/minetest/tree/far_map_wip |
| 01:56 |
gregorycu |
How's it look? |
| 02:04 |
VanessaE |
https://daconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-13_13-03-08.png |
| 02:04 |
VanessaE |
https://daconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-13_12-59-47.png |
| 02:04 |
VanessaE |
it looks like that. :) |
| 02:04 |
VanessaE |
in my GPU I can see "terrain" 1 km into the distance, and still with respectable framerates. |
| 02:05 |
VanessaE |
those ^^^ screenshots I think have the farmap limit set to around 500m |
| 02:08 |
gregorycu |
lol png |
| 02:09 |
gregorycu |
Interesting stuff |
| 02:11 |
VanessaE |
why wouldn't I use PNG for a screenshot? :) |
| 02:11 |
VanessaE |
celeron55: ^^^^ |
| 02:18 |
gregorycu |
PNGs are lossless, but large size for things like screenshots |
| 02:19 |
VanessaE |
yeah I know |
| 02:19 |
VanessaE |
but where it comes to screenshots, pixel-accuracy is important to me :) |
| 02:30 |
gregorycu |
Yeppers |
| 02:35 |
|
gregorycu_ joined #minetest-dev |
| 02:56 |
|
younishd_ joined #minetest-dev |
| 02:57 |
gregorycu |
Who else does windows dev here? |
| 03:28 |
gregorycu |
sofar |
| 03:29 |
sofar |
nooooo |
| 03:30 |
gregorycu |
Too bad |
| 03:30 |
gregorycu |
Found you |
| 03:30 |
gregorycu |
So, you've been looking at my PR that "optimises" spreadLight |
| 03:31 |
gregorycu |
https://github.com/minetest/minetest/pull/3331#issuecomment-167665040 |
| 03:31 |
sofar |
well, just a casual look. |
| 03:31 |
gregorycu |
Yep |
| 03:31 |
gregorycu |
Are you able to indicate exactly how you timed spreadLight |
| 03:32 |
gregorycu |
TimeTaker was used, as you said |
| 03:32 |
sofar |
there's a commented out TimeTaker, that's all I did |
| 03:32 |
gregorycu |
I want to make sure I have the same setup as you, to give me the best chance at your results |
| 03:32 |
sofar |
I honestly don't even know if that's the right way |
| 03:33 |
gregorycu |
Cool, thank you |
| 03:34 |
gregorycu |
Hopefully I can speak with paramat too |
| 03:35 |
sofar |
map.cpp: //TimeTaker timer("spreadLight"); |
| 03:35 |
sofar |
map.cpp- vmanip.spreadLight(bank, light_sources, nodemgr); |
| 03:36 |
sofar |
that one |
| 03:36 |
sofar |
hey, question for you windowzy person |
| 03:36 |
sofar |
why does minetest go nomnoms on system ram and occupy 3gb or memory? |
| 03:37 |
gregorycu |
It shouldn't |
| 03:38 |
sofar |
perhaps I should update |
| 03:38 |
sofar |
resolution is 2560x1600, maybe that matters? |
| 03:38 |
sofar |
nvidia hw? |
| 03:38 |
gregorycu |
I wouldn't think so, to be honest |
| 03:38 |
gregorycu |
ATI |
| 03:39 |
gregorycu |
vmanip.spreadLight(bank, light_sources, nodemgr); |
| 03:39 |
gregorycu |
That's behind an #if 0 |
| 03:40 |
gregorycu |
You mean line 831? |
| 03:40 |
sofar |
I believe that the macro works out that if you uncomment it, it does an extra recalc pass and times that |
| 03:40 |
gregorycu |
etc |
| 03:40 |
sofar |
#826-828 yes |
| 03:44 |
gregorycu |
Where does info stream get printed? |
| 03:54 |
cheapie |
This "AreaStore" thing looks cool, but I can't find any obvious way to save/load them to/from disk. Is that even possible? |
| 04:30 |
|
est31 joined #minetest-dev |
| 04:30 |
gregorycu |
For me spreadLight is called non-stop |
| 04:30 |
est31 |
cheapie, it isn't possible as of now, but this PR will enable it: https://github.com/minetest/minetest/pull/3309 |
| 04:31 |
cheapie |
est31: OK. |
| 04:31 |
est31 |
cheapie, so you'll have to use a table and insert/remove from it while operating on the areastore |
| 04:31 |
est31 |
& then save that table |
| 04:32 |
|
est31 joined #minetest-dev |
| 04:33 |
est31 |
gregorycu, its printed nowhere |
| 04:33 |
est31 |
gregorycu, execute minetest with the --info param |
| 04:33 |
gregorycu |
I added the info switch |
| 04:33 |
gregorycu |
yeah |
| 04:44 |
gregorycu |
sofar, for me spreadLight is getting called like 100 times a second for no obvious reason |
| 04:44 |
gregorycu |
Did you experience this? |
| 04:50 |
sofar |
gregorycu: nope |
| 04:52 |
|
asl97 joined #minetest-dev |
| 04:54 |
|
Player2 joined #minetest-dev |
| 04:58 |
|
yyt16384 joined #minetest-dev |
| 05:50 |
|
gregorycu_ joined #minetest-dev |
| 06:38 |
|
Hunterz joined #minetest-dev |
| 06:52 |
gregorycu |
Does anyone know paramat's time zone? |
| 06:53 |
gregorycu |
That dude and I have unfinshed business |
| 06:55 |
asl97 |
gregorycu: unless paramat has given false information, just check his/her github profile page: https://github.com/paramat |
| 06:56 |
gregorycu |
UK, which is 11 hours behind me... 7am |
| 06:56 |
gregorycu |
Thanks, i should fill out that info on my profile too |
| 07:47 |
|
Krock joined #minetest-dev |
| 08:04 |
|
Darcidride joined #minetest-dev |
| 08:05 |
gregorycu |
In minetest parlance, what is a chunk? |
| 08:07 |
gregorycu |
vs node vs block |
| 08:08 |
hmmmmm |
a chunk is a make-believe cubic region of some mapchunks |
| 08:08 |
hmmmmm |
mapblocks i mean |
| 08:08 |
hmmmmm |
it's not an actual data structure |
| 08:13 |
|
nrzkt joined #minetest-dev |
| 08:31 |
sofar |
http://i.imgur.com/Jvoeq7R.png |
| 08:31 |
sofar |
^^ completely client-side drawn connecting nodeboxes |
| 08:31 |
sofar |
only a single nodedef |
| 08:33 |
RealBadAngel |
that looks promising |
| 08:33 |
RealBadAngel |
i could re-do my concrete posts with that |
| 08:34 |
sofar |
yes |
| 08:34 |
sofar |
plus mesecons wire |
| 08:34 |
sofar |
that's probably the best user for it too |
| 08:35 |
sofar |
although it'll break the current mesecons wire, since it connects diagonally |
| 08:35 |
sofar |
this only connects 6 ways (up, down, n-e-w-s) |
| 08:35 |
RealBadAngel |
it has to be done in all directions |
| 08:35 |
RealBadAngel |
you know why its diagonally only? |
| 08:36 |
sofar |
it's not only diagonally |
| 08:36 |
RealBadAngel |
it has separate vertical one |
| 08:36 |
sofar |
it's diagonally up |
| 08:36 |
sofar |
right |
| 08:36 |
sofar |
which is weird since it can also go vertical |
| 08:36 |
RealBadAngel |
to get one climbing all possible walls, theres over 1k nodedefs needed |
| 08:36 |
sofar |
but that's a different node |
| 08:37 |
RealBadAngel |
ask nore, he made such code |
| 08:37 |
RealBadAngel |
and thats only for just one type of wire |
| 08:37 |
sofar |
well right now this code could be extended to allow specifying how to connect to a diagonally connected face |
| 08:38 |
sofar |
but let me make this into a decent PR tomorrow so people have something to test |
| 08:38 |
RealBadAngel |
such code is aviable in redpower2 clone, its open source |
| 08:38 |
sofar |
I also have a simple "wall" mod to go with it |
| 08:38 |
RealBadAngel |
i mean connection rules |
| 08:39 |
RealBadAngel |
its called redproject i think |
| 08:39 |
sofar |
I gotta hit the hay first. Will put make-up and a dress on this code tomorrow so people can ogle it |
| 08:40 |
sofar |
actually, I should convert fences to this code as well |
| 08:40 |
sofar |
so that people see that it's relatively flexible |
| 08:40 |
RealBadAngel |
indeed |
| 08:40 |
RealBadAngel |
that has to be generic |
| 08:41 |
sofar |
http://i.imgur.com/SBURS20.png |
| 08:41 |
RealBadAngel |
have you checked my posts? |
| 08:41 |
RealBadAngel |
from technic modpack |
| 08:43 |
gregorycu |
Thanks hmmmmm |
| 08:43 |
sofar |
I didn't... I'm fedup with people saying "look at my code" and it's gplv3 ... so I can't merge it back |
| 08:44 |
RealBadAngel |
https://github.com/minetest-technic/technic/tree/master/concrete |
| 08:44 |
sofar |
it's not rocket science, just reimplement it |
| 08:44 |
RealBadAngel |
my code is usually wtfpl ;) |
| 08:44 |
sofar |
yeah you're not crazy, like some people maintaining hostile forks |
| 08:45 |
RealBadAngel |
technic is actually lgpl v2 |
| 08:45 |
sofar |
and then claiming I plagiarize them with 6 lines of fucking trivial code |
| 08:45 |
RealBadAngel |
yeah i seen that |
| 08:45 |
sofar |
YOU KNOW WHAT GRINDS MY GEARS? |
| 08:45 |
sofar |
;^) |
| 08:46 |
sofar |
it makes more more angry since he knows other people can't merge it back, but meanwhile he himself pushes code around from and to various gpl trees |
| 08:46 |
sofar |
and it's not helping anyone |
| 08:50 |
RealBadAngel |
folks doing that are acting like real dicks |
| 08:51 |
RealBadAngel |
i dont like such attitude |
| 08:57 |
sofar |
ok |
| 08:57 |
sofar |
ONE more screenshot |
| 08:57 |
sofar |
then I go to bed |
| 08:57 |
sofar |
http://i.imgur.com/lNECgTt.png |
| 08:57 |
sofar |
tadaa, new fences using this method |
| 08:58 |
sofar |
textures used was jungletree and tree (custom texture pack) |
| 08:58 |
RealBadAngel |
can i see lua code for that fence? |
| 09:21 |
|
enesbil joined #minetest-dev |
| 10:31 |
OldCoder |
Is it a known bug that for 0.4.12 clients everything disappears at around 23250 in any direction? |
| 10:31 |
OldCoder |
As opposed to 32000 |
| 10:45 |
|
yyt16384 joined #minetest-dev |
| 10:52 |
|
Calinou joined #minetest-dev |
| 11:02 |
gregorycu |
lol |
| 11:12 |
|
red-001 joined #minetest-dev |
| 11:25 |
|
zupoman joined #minetest-dev |
| 11:30 |
red-001 |
do I need to add a description of a new privilege some where in the documentation? |
| 11:43 |
|
CraigyDavi joined #minetest-dev |
| 11:49 |
|
CraigyDavi joined #minetest-dev |
| 11:57 |
nrzkt |
red-001, yes |
| 12:03 |
red-001 |
where? |
| 12:04 |
red-001 |
as in I defined it |
| 12:04 |
red-001 |
where to document it? |
| 12:19 |
yyt16384 |
Should RemoteClient::SetBlockNotSent and RemoteClient::SetBlocksNotSent set m_nothing_to_send_pause_timer to 0? |
| 12:19 |
yyt16384 |
It will not be in a "nothing to send" state after marking the block as not sent. |
| 12:20 |
yyt16384 |
This seems to cause modified blocks be sent only every 2 seconds |
| 12:25 |
|
rubenwardy joined #minetest-dev |
| 12:27 |
|
cmdskp joined #minetest-dev |
| 12:44 |
celeron55 |
yyt16384: why is there such a race to modify that part of the codebase now that i have a stalled branch with big rework on it |
| 12:45 |
celeron55 |
can someone take far_map_wip and remove the far map stuff from it and merge it upstream instead of fixing the current code that is vastly inerior? |
| 12:46 |
celeron55 |
inferior* |
| 12:46 |
celeron55 |
it has a reworked map sending implementation that i developed along with the far map stuff |
| 12:49 |
gregorycu |
Sorry bro |
| 12:49 |
gregorycu |
Everyone converges on the stuff that needs the most work? |
| 12:51 |
celeron55 |
i guess so but it's not good |
| 12:51 |
celeron55 |
most work will end up being lost |
| 12:51 |
gregorycu |
Agreed |
| 12:52 |
gregorycu |
How do we avoid this problem |
| 12:53 |
celeron55 |
given the circumstances, probably in no way |
| 12:54 |
gregorycu |
it's better than nobody wanting to do any work :) |
| 12:54 |
gregorycu |
Now where the hell is paramat |
| 12:55 |
celeron55 |
i'm now considering trying to rip apart the map sending stuff and the farmap stuff in my branch |
| 12:55 |
celeron55 |
this is going to take days i guess but maybe it is worth it |
| 12:55 |
gregorycu |
I heard the farmap stuff is pretty good |
| 12:56 |
celeron55 |
it can't be done by picking commits; i need to first pick commits, then squash everything that can't be separated based on commits and then edit and delete files until there aren't any unwanted changes left |
| 12:56 |
gregorycu |
Hopefully your git-fu is better than mine |
| 12:57 |
celeron55 |
the farmap stuff is technically fine but it needs vast usability improvements |
| 12:58 |
celeron55 |
like removing the viewing range auto-adjust and changing the configuration UI to make it reasonable to adjust by users, and figuring out sane defaults |
| 12:58 |
celeron55 |
lots of work |
| 12:58 |
celeron55 |
i'm not sure how to get that work done though |
| 12:58 |
gregorycu |
Whats wrong with the autoadjust? |
| 12:59 |
celeron55 |
it won't be able to work properly |
| 12:59 |
gregorycu |
Won't the far map just "fill in the blanks"? |
| 12:59 |
celeron55 |
it can't know how the user wants to balance the far and short ranges |
| 13:00 |
gregorycu |
Ahh, I see what you mean |
| 13:00 |
celeron55 |
and fps |
| 13:00 |
gregorycu |
The two extremes are seeing very far with farmap, or short distance with very little farmap |
| 13:00 |
gregorycu |
seeing very far with lots of farmap * |
| 13:01 |
gregorycu |
You could just make it a static % |
| 13:01 |
celeron55 |
also different computers can render different amounts with the two styles; they don't perform equally related to each other |
| 13:01 |
celeron55 |
also farmap takes way more memory |
| 13:01 |
gregorycu |
Is that something you can detect? Available memory? |
| 13:02 |
celeron55 |
not in a useful way |
| 13:02 |
celeron55 |
this was discussed previously with hmmmm |
| 13:02 |
celeron55 |
i have already decided this, you can't say anything that would change my mind about the auto-adjust |
| 13:02 |
gregorycu |
I don't even have a position on auto-adjust |
| 13:03 |
celeron55 |
i made the auto-adjust and i know what it's capable of; it's not capable of this |
| 13:03 |
gregorycu |
I was asking what was wrong with it |
| 13:03 |
celeron55 |
a thing that also messes up the auto-adjust is that with the map sending changes, the map sending is controlled by the client's view range |
| 13:03 |
celeron55 |
not by server's configuration |
| 13:04 |
celeron55 |
so then you're controlling both the network and the rendering |
| 13:04 |
celeron55 |
based on rendering |
| 13:05 |
gregorycu |
I have idea, but you've probably thought of them, so no point speaking them |
| 13:05 |
celeron55 |
even now without any of the changes, i think most people want to get rid of the auto-adjust and don't use it at all |
| 13:06 |
celeron55 |
personally i certainly don't use it |
| 13:06 |
gregorycu |
Doesn't it currently have problems (without your changes?) |
| 13:06 |
gregorycu |
Where it see-saws or something |
| 13:08 |
celeron55 |
sometimes you hear people complaining about it |
| 13:08 |
celeron55 |
i believe it is tuned as well as it can be; if you made it less bouncy, then it would be too slow in other scenarios |
| 13:09 |
celeron55 |
and the algorithm itself is as good as i could make it; i certainly won't attempt to make it more clever |
| 13:09 |
gregorycu |
I think the issue is that when it increases the range, the first frame updates draw lists etc. which causes the frame rate to take a hit |
| 13:10 |
gregorycu |
I was looking at it some time ago, I can't remember |
| 13:10 |
celeron55 |
sounds plausible |
| 13:11 |
celeron55 |
anyway |
| 13:11 |
gregorycu |
I think a more "clever" solution would be to exclude that processing from calculating the current frame rate (because it's a one-off) |
| 13:11 |
gregorycu |
But probably not worth it |
| 13:12 |
celeron55 |
the way i personally want to control my far map range is in such a way that it is static no matter what happens, and the way i then want to control my normal rendering range is that it is static too, because increasing it for the sake of seeing farther makes no sense when the far map is already doing it |
| 13:13 |
celeron55 |
the point of the auto-adjust is to increase the range when the rendering performance allows for it on an empty terrain or a tower or something |
| 13:13 |
celeron55 |
that point doesn't exist then anymore |
| 13:13 |
gregorycu |
There is another point though |
| 13:14 |
gregorycu |
That's when you start to see farmap vs real rendering |
| 13:14 |
gregorycu |
another = new |
| 13:14 |
celeron55 |
yes, but it's nicer to have more fps than have that point move around |
| 13:16 |
gregorycu |
I think different people would want different things (not saying it's worthwhile complicating everything to satisfy everyone) |
| 13:16 |
gregorycu |
(Some people use auto-adjust, some do not) |
| 13:17 |
celeron55 |
have you tried the far_map_wip branch? |
| 13:17 |
gregorycu |
I haven't |
| 13:17 |
celeron55 |
it's much easier to think about what people might think about this issue when you have first-hand experience of it |
| 13:18 |
celeron55 |
it's more different than you think |
| 13:18 |
celeron55 |
(likely) |
| 13:18 |
gregorycu |
Yeah, I'll try it soon |
| 13:18 |
celeron55 |
(if it's not, then that is useful information too; but you don't know until you try) |
| 13:19 |
gregorycu |
I want to get this perf shit sorted with paramat |
| 13:20 |
gregorycu |
And I need to consider getting a linux vm happening so I can do these tests myself |
| 13:22 |
gregorycu |
I think he did his perf tests with a 121^3 chunk which was not something I considered when optimising code |
| 13:22 |
celeron55 |
if others in the core team think that far map with related rework and fixes should be merged with the farmap defaulting to being disabled, i could do that |
| 13:25 |
gregorycu |
Seems like a good stepping stone |
| 13:25 |
celeron55 |
or, well, i guess even in an enabled form |
| 13:53 |
|
behalebabo joined #minetest-dev |
| 14:18 |
|
Hunterz joined #minetest-dev |
| 14:25 |
|
zat joined #minetest-dev |
| 14:28 |
gregorycu |
"i modified one of my mapgen mods to use the non-mapgen object voxelmanip, which uses 'update map' for lighting calculation, which calls 'updateLighting' which calls 'spreadLight'. I made only 1 mapchunk be generated and this mapchunk is identical in each run. Here 'spreadLight' is acting on a 112^3 node volume" |
| 14:28 |
gregorycu |
Anyone know what this means? He made a 112^3 "voxelmanip" |
| 14:29 |
Krock |
a voxelmanipulator with those area specifications |
| 14:29 |
Krock |
112m in each direction |
| 14:30 |
gregorycu |
A voxelmanip is an object to transactionally change the map right? |
| 14:31 |
Krock |
yes, it gives you an array with all node IDs. you can change them if you like |
| 14:32 |
Krock |
and when you're done, the complete piece gets written to the map |
| 14:32 |
Krock |
vm:get_data() and vm:set_data(data) + vm:write_to_map() |
| 14:33 |
gregorycu |
So he wrong a 112^ chunk of map, which caused updateLighting to be called on that chunk |
| 14:33 |
gregorycu |
Cool, I'll give that a try |
| 14:33 |
gregorycu |
s/wrong/wrote/ |
| 14:34 |
Krock |
oh, that's done with vm:calc_lighting(p1, p2 |
| 14:35 |
|
Amaz joined #minetest-dev |
| 14:36 |
gregorycu |
Do people actually update 112^3 chunks in practice? |
| 14:36 |
|
red-001 joined #minetest-dev |
| 14:36 |
Krock |
that's a huge amount of nodes, so I doubt that happens frequently |
| 14:37 |
Krock |
but there are such operations to fix the bugged light |
| 14:37 |
celeron55 |
the map generator uses chunks of roughly that size |
| 14:38 |
celeron55 |
not sure what exactly, but that's not very far off |
| 14:38 |
red-001 |
what causes the light bugs? |
| 14:38 |
gregorycu |
ok |
| 14:39 |
Krock |
usually 16*5 in each dimension |
| 14:39 |
Krock |
sometimes more.. dunno why |
| 14:39 |
gregorycu |
Then the lighting code needs to be able to handle 112^3 nicely |
| 14:40 |
gregorycu |
I'm not sure what causes the light bugs |
| 14:40 |
gregorycu |
Maybe trees? |
| 14:44 |
red-001 |
https://github.com/minetest/minetest_game/pull/602 |
| 14:44 |
red-001 |
https://github.com/minetest/minetest_game/pull/667 |
| 14:51 |
rubenwardy |
#602 |
| 14:52 |
red-001 |
can someone take a look at it |
| 14:52 |
red-001 |
? |
| 14:53 |
|
younishd joined #minetest-dev |
| 14:56 |
gregorycu |
Must only be called in a mapgen thread... |
| 14:57 |
gregorycu |
do |
| 14:57 |
gregorycu |
h |
| 14:57 |
Krock |
game#602 |
| 14:57 |
Krock |
ShadowBot! |
| 14:58 |
gregorycu |
Classic shadow bot |
| 14:58 |
red-001 |
https://github.com/minetest/minetest_game/pull/602 |
| 14:59 |
|
cmdskp joined #minetest-dev |
| 14:59 |
red-001 |
something tells my I will wait a long time for this to be merged |
| 14:59 |
red-001 |
me* |
| 14:59 |
gregorycu |
Well, brand new concepts generally do |
| 15:00 |
gregorycu |
take a long time, that is |
| 15:00 |
red-001 |
no that has write access even commented on it |
| 15:02 |
gregorycu |
It's the holiday season, people are on holidays/busy |
| 15:03 |
red-001 |
yeah I guess your right |
| 15:03 |
red-001 |
I made the pr in summer through |
| 15:03 |
gregorycu |
This is where github is alittle weak |
| 15:04 |
gregorycu |
Usually before any work is done, people would discuss the concept, come to agreement |
| 15:04 |
gregorycu |
Then somebody would go off and code it to spec |
| 15:04 |
gregorycu |
PRs only become code style / form reviews |
| 15:04 |
gregorycu |
Not a discussion about a feature and how it should work |
| 15:05 |
red-001 |
also If someone gets a chance take a look at https://github.com/minetest/minetest_game/pull/667 |
| 15:20 |
rubenwardy |
Reviewed both, red-001 |
| 15:20 |
red-001 |
thanks |
| 15:35 |
|
gravgun joined #minetest-dev |
| 15:35 |
|
hmmmm joined #minetest-dev |
| 15:46 |
sofar |
http://i.imgur.com/zaJq8jo.png |
| 15:46 |
|
est31 joined #minetest-dev |
| 15:46 |
est31 |
can sb have a look at https://github.com/minetest/minetest/pull/3434 |
| 15:47 |
est31 |
we _really_ have to do a pr merging session where we merge trivial PRs like this |
| 15:47 |
est31 |
otherwise contributor after contributor gets annoyed. |
| 16:18 |
|
Hunterz joined #minetest-dev |
| 16:22 |
|
red-001 joined #minetest-dev |
| 16:39 |
sofar |
https://github.com/minetest/minetest/pull/3503 |
| 16:49 |
|
cmdskp joined #minetest-dev |
| 16:54 |
|
fling joined #minetest-dev |
| 17:04 |
|
fling joined #minetest-dev |
| 17:33 |
|
cmdskp joined #minetest-dev |
| 17:58 |
|
DFeniks joined #minetest-dev |
| 18:14 |
|
zupoman joined #minetest-dev |
| 18:45 |
|
twoelk joined #minetest-dev |
| 19:42 |
|
Fixer joined #minetest-dev |
| 19:59 |
|
cmdskp joined #minetest-dev |
| 20:36 |
|
CraigyDavi joined #minetest-dev |
| 20:44 |
|
zat joined #minetest-dev |
| 20:57 |
|
Gael-de-Sailly joined #minetest-dev |
| 21:00 |
red-001 |
could the old settings tab be returned? |
| 21:00 |
red-001 |
The new one is quite confusing |
| 21:01 |
red-001 |
It could be used as an advance settings tab |
| 21:03 |
Gael-de-Sailly |
some people have proposed it on october but nothing has changed |
| 21:06 |
Gael-de-Sailly |
https://forum.minetest.net/viewtopic.php?p=195208#p195208 |
| 21:09 |
red-001 |
well I might as well open a PR for this |
| 21:09 |
red-001 |
as nothing is being do |
| 21:10 |
Gael-de-Sailly |
pilzadam said that it will be done |
| 21:10 |
red-001 |
ok |
| 21:10 |
Gael-de-Sailly |
but it was on october |
| 21:10 |
red-001 |
well he probably forgot |
| 21:11 |
red-001 |
I doubt It will that this long to add back something so trivial |
| 21:12 |
Gael-de-Sailly |
because that's not the priority for the devs |
| 21:12 |
red-001 |
well a unusable user interface is a thing that can destroy any game |
| 21:13 |
red-001 |
or engine |
| 21:13 |
Gael-de-Sailly |
yes, I've said it many times, the "user-friendly" side is very important |
| 21:15 |
red-001 |
good old minetest once doesn't merge PR because a setting in minetest.conf is not user friendly |
| 21:15 |
red-001 |
and sometimes this happens |
| 21:15 |
gravgun |
"user-friendly": term not found in coredevs/vocabulary.txt |
| 21:15 |
gravgun |
:P |
| 21:15 |
Gael-de-Sailly |
well said |
| 21:15 |
red-001 |
user-friendly = nil |
| 21:16 |
red-001 |
Is this used on android too? |
| 21:16 |
red-001 |
or does android have it's own ui |
| 21:16 |
gravgun |
"Remembering PR": term found in coredevs/vocabulary_ignore.txt, ignored |
| 21:17 |
red-001 |
:) |
| 21:17 |
Gael-de-Sailly |
they think to many things at the same time |
| 21:17 |
red-001 |
they think -1 things |
| 21:17 |
Gael-de-Sailly |
so they forgot the "less important" ones |
| 21:17 |
asl97 |
imo, there wasn't much reason why they can't just include both the overridable function and setting, user could already change the game themselve |
| 21:17 |
Gael-de-Sailly |
and generally the "user-friendly" is less important |
| 21:18 |
Gael-de-Sailly |
that's the problem |
| 21:21 |
Gael-de-Sailly |
the advanced settings it was my idea at the beginning, but it has been done the wrong way |
| 21:21 |
Gael-de-Sailly |
The old interface has been removed |
| 21:21 |
red-001 |
well it OK for an advance settings tab |
| 21:22 |
red-001 |
I wonder what is it with open source projects and complicated settings |
| 21:22 |
Gael-de-Sailly |
There should be both tabs with a BUTTON to SWITCH |
| 21:22 |
red-001 |
or just two tabs |
| 21:23 |
red-001 |
'settings' and 'advance settings' |
| 21:23 |
Gael-de-Sailly |
no, you keep the old interface, and add an "advanced settings" button |
| 21:23 |
red-001 |
yeah thats what I meant |
| 21:24 |
red-001 |
something like this http://postimg.org/image/spj5akqml/ |
| 21:24 |
red-001 |
which PR megerd this? |
| 21:24 |
Gael-de-Sailly |
yes, that's good too |
| 21:25 |
Gael-de-Sailly |
merged what? |
| 21:25 |
Gael-de-Sailly |
the new settings? |
| 21:26 |
red-001 |
yes |
| 21:26 |
Gael-de-Sailly |
iirc that was a commit from PilzAdam |
| 21:26 |
red-001 |
nvm found it |
| 21:26 |
* Gael-de-Sailly |
is checking... |
| 21:26 |
red-001 |
https://github.com/minetest/minetest/commit/6f2d9de7691c99b833f71c1414230c5d04c42ae0 |
| 21:27 |
Gael-de-Sailly |
I have this one: https://github.com/minetest/minetest/commit/006ef5b4a5e362eed848ca26b411a8059d74b965 |
| 21:28 |
red-001 |
thanks |
| 21:28 |
red-001 |
that seems to be it |
| 21:33 |
red-001 |
imo it's time android gets it's own ui |
| 21:35 |
kaadmy |
red-001: yes |
| 21:36 |
Gael-de-Sailly |
good bye |
| 21:55 |
|
Dragonop joined #minetest-dev |
| 21:58 |
|
twoelk joined #minetest-dev |
| 22:02 |
red-001 |
wow |
| 22:02 |
|
sapier joined #minetest-dev |
| 22:03 |
red-001 |
an no existing game set as menu_last_game cause minetest to crash |
| 22:04 |
sapier |
I've got a quite ugly question: Is minetest really reading mesh from harddrive and loading to irrlicht EVERYTIME any property of an entitie does change? |
| 22:05 |
* red-001 |
doesn't know |
| 22:07 |
red-001 |
Is that as bad as it sounds? |
| 22:07 |
celeron55 |
i'd guess the client doesn't save or load meshes from the hard drive at any other point than the initial cache synchronization |
| 22:07 |
celeron55 |
it might re-parse them though |
| 22:08 |
sapier |
as irrlicht output isn't cought I'm quite sure at least reparsing is done |
| 22:09 |
sapier |
hopefully not reading from disk but as filename is passed to irrlicht I assume that's at best operating systems task |
| 22:09 |
celeron55 |
the re-parsing is a workaround due to irrlicht not being able to make copies of a mesh for setting different vertex colors |
| 22:10 |
sapier |
argh |
| 22:10 |
celeron55 |
the filename is probably just due to irrlicht's weird interface which requires filenames for virtual files |
| 22:10 |
sapier |
hmm could be yes |
| 22:10 |
sapier |
well I've other issues to fix atm but flooding console with irrlicht messages ain't very good too |
| 22:11 |
sapier |
most strange thing is it seems to only happen if you're in mainmenu on a server |
| 22:12 |
sapier |
so I'm not even sure it's related to setting properties |
| 22:15 |
celeron55 |
i don't see how the entity mesh creation thing would even be triggered from setting properties |
| 22:15 |
kaadmy |
sapier: i think it does, but i dunno |
| 22:15 |
celeron55 |
it runs once when an entity is created on the client, and never again for the same entity |
| 22:16 |
sapier |
mesh is a property you can change it on an existing one too so there has to be some way to do it. Yet I'm not sure if it's really set properties as somehow "pause menu" is involved |
| 22:17 |
sapier |
well not exactly "pause" as in multiplayer it ain't pause |
| 22:17 |
OldCoder |
Interesting bug came up last night. Tried 0.4.11 and 12, -O2 and -O3, gcc 4.6.3 and 4.9.3, different glibc releases, different Irrlichts |
| 22:17 |
OldCoder |
Same issue almost exactly for all combinations. Screen goes blank at exactly a uniform distance from the origin. |
| 22:18 |
OldCoder |
When I switched glibc's, the distance changed slightly. It is exact for each test down to 0.1. |
| 22:18 |
OldCoder |
In the neighborhood of 23300 or 23253 depending |
| 22:19 |
OldCoder |
Has anything like this been observed or reported in recent years? |
| 22:19 |
celeron55 |
wait, what |
| 22:19 |
OldCoder |
Interesting part is that every changeable component has been changed |
| 22:19 |
OldCoder |
Hm? Which part is unclear? |
| 22:19 |
celeron55 |
actually yes, the mesh is re-created and the scene node is fully re-created when any property changes |
| 22:19 |
OldCoder |
celeron55, are you addressing sapier or me? |
| 22:20 |
OldCoder |
Ah, Sapier |
| 22:20 |
OldCoder |
Has anybody ever heard of the issue I've described? |
| 22:21 |
sapier |
guess I'll have to take care not to write identical settings too often :-( |
| 22:21 |
celeron55 |
and that happens because in handling of GENERIC_CMD_SET_PROPERTIES, expireVisuals() is always called |
| 22:21 |
celeron55 |
and if the visuals are set expired, the entire scene node is re-created from scratch |
| 22:22 |
sapier |
maybe we should only do this if any of the visible properties changes |
| 22:22 |
celeron55 |
well... obviously so |
| 22:23 |
red-001 |
https://github.com/minetest/minetest/pull/3504 |
| 22:23 |
celeron55 |
i bet the next bug related to that is going to be a new visual property added after this to which somebody forgets to add the expiration trigger and it gets desynced |
| 22:24 |
celeron55 |
unless you come up with a good way of avoiding that |
| 22:25 |
sapier |
true that's almost sure gonna happen |
| 22:27 |
sapier |
"best" way would be separating visible properties from non visible ones ... but as this can't be done in a compatible way it's no go |
| 22:28 |
celeron55 |
OldCoder: how do you go to that distance? if this can't be reproduced (i certainly can't; tried it now), it's not fixable |
| 22:28 |
celeron55 |
i tried teleporting in a test world to around 23whatever in some steps and at no point did it go blank |
| 22:28 |
celeron55 |
except when i accidentally teleported inside a mountain |
| 22:28 |
OldCoder |
I know, celeron55, will work on reproducing. I TP to 22500 and walk the rest of the way |
| 22:29 |
OldCoder |
The interesting part is that I've changed *everything* even several years worth of glibc |
| 22:29 |
OldCoder |
Not sure what else could be changed: Different optimization, different Irrlicht, different compiler, 2 years worth of MT... |
| 22:29 |
* OldCoder |
figured it was an incompatibility with glibc -lm |
| 22:30 |
OldCoder |
But it happens with both old and new glibc |
| 22:30 |
OldCoder |
Wanted to ask if a limit below 32000 had ever been observed |
| 22:30 |
* OldCoder |
takes it the answer is no |
| 22:30 |
celeron55 |
tried flying; doesn't happen |
| 22:31 |
OldCoder |
Thank you. So, limits below 32000 have not been observed? |
| 22:32 |
OldCoder |
I mean, in past bugs? |
| 22:32 |
OldCoder |
That is the only question for right now |
| 22:35 |
celeron55 |
i have not heard of such |
| 22:35 |
OldCoder |
O.K. Thanks. I'll comment further if specifics are identified. |
| 22:35 |
celeron55 |
and i can't imagine what could cause it; it's probably something very weird |
| 22:35 |
OldCoder |
Yes; hence the description as interesting |
| 22:35 |
celeron55 |
are you running 32-bit or 64-bit? |
| 22:36 |
OldCoder |
32 bit |
| 22:36 |
celeron55 |
okay, that could explain something |
| 22:36 |
OldCoder |
Do most people do 64 these days? |
| 22:36 |
OldCoder |
Oh? Tips on directions to look in? |
| 22:36 |
celeron55 |
well, practically everyone, including me |
| 22:36 |
OldCoder |
So if I find somebody else with 32 bits |
| 22:36 |
OldCoder |
And they observe the issue, I have a clue |
| 22:36 |
OldCoder |
O.K. That is something to try. Will comment further at a later date. Thank you. |
| 22:37 |
celeron55 |
i would do that first, and then go from there |
| 22:37 |
OldCoder |
o/ |
| 22:37 |
red-001 |
how do you set minetest to compile in x64 |
| 22:37 |
red-001 |
I have 64 bit winodows |
| 22:38 |
red-001 |
but minetest compiles in 32 bits |
| 22:38 |
sapier |
just flew from 22500 to 24500 no darkening for me too |
| 22:38 |
celeron55 |
red-001: on linux it compiles to whatever the system is; on windows you'll have to ask from someone who has made 64-bit builds because nobody else probably has any idea |
| 22:38 |
OldCoder |
sapier, thank you! |
| 22:39 |
OldCoder |
Will find others who have 32-bit OSes and see if this is an issue |
| 22:39 |
OldCoder |
Most possible explanations are ruled out, so need to check this one |
| 22:39 |
red-001 |
OldCoder |
| 22:39 |
red-001 |
I have 32 bit minetest |
| 22:39 |
OldCoder |
red-001, But a 64 bit machine |
| 22:39 |
OldCoder |
and OS, right? |
| 22:39 |
red-001 |
yes |
| 22:39 |
celeron55 |
i'm booting up my 32bit laptop now |
| 22:39 |
OldCoder |
Well, thanks; it's a long-shot |
| 22:40 |
red-001 |
maybe it's just a bug with 32 bit minetest |
| 22:40 |
* OldCoder |
is betting on a glibc math library issue |
| 22:40 |
OldCoder |
I should have noticed it years ago but never spent much time on the boundaries |
| 22:41 |
kaadmy |
i have a 32 bit OS and MT |
| 22:41 |
OldCoder |
Would not have mentioned it here yet but was bemused by the fact that changing MT releases, compilers, Irrlicht releases, optimizations.. |
| 22:41 |
OldCoder |
kaadmy, could you try this? fly to 23000,100,0 |
| 22:41 |
OldCoder |
then from there to 24000 |
| 22:41 |
kaadmy |
ok |
| 22:41 |
OldCoder |
ty |
| 22:42 |
OldCoder |
BTW encountered this because we're proceeding with stacked realms |
| 22:42 |
red-001 |
I made a PR to add back the old settings tab https://github.com/minetest/minetest/pull/3504 |
| 22:42 |
OldCoder |
Lots of fun possibilities there |
| 22:43 |
kaadmy |
wonder if the bug happens on mobile? |
| 22:43 |
kaadmy |
checking |
| 22:43 |
celeron55 |
i am not seeing the issue on this; keep in mind that this is not an upstream build but instead contains some of my farmap work-in-progress stuff; however i don't think it should have an effect |
| 22:43 |
OldCoder |
There is no evidence yet it happens for anybody but me |
| 22:43 |
OldCoder |
I thank people for commenting. I will try it under Windows on the same machine |
| 22:44 |
OldCoder |
and see just how machine or OS specific it is. If nobody else can reproduce it, it can't be fixed... |
| 22:44 |
celeron55 |
(that was 32-bit debian 7 or something like that) |
| 22:44 |
OldCoder |
But I trust people agree it is interesting. Time again was appreciated. Talk to you later. celeron55 I will try Windows on the same hardware. Then the same Linux on different hardware. |
| 22:44 |
* OldCoder |
is systematic :-) |
| 22:44 |
OldCoder |
Ttyl |
| 22:45 |
red-001 |
I'm running a debug build of minetest and I'm getting some strange crashes |
| 22:45 |
OldCoder |
Crashes happen |
| 22:45 |
OldCoder |
Zzz <- napping ttyl |
| 22:45 |
red-001 |
when I try to start a singleplayer game |
| 22:46 |
red-001 |
http://s000.tinyupload.com/index.php?file_id=69600612174384718924 |
| 22:46 |
red-001 |
link to the dump |
| 22:46 |
kaadmy |
OldCoder: tried on mobile, doesn't have any problems |
| 22:49 |
kaadmy |
what version of mt causes those problems oldcoder? |
| 22:50 |
OldCoder |
kaadmy, PM; there is insufficient evidence for group discussion. But all versions. I will research and report evidence if such turns up. |
| 22:50 |
* OldCoder |
can narrow it down to either the hardware or the OS and will do so |
| 23:10 |
|
red-001 joined #minetest-dev |
| 23:13 |
|
cmdskp joined #minetest-dev |
| 23:20 |
cmdskp |
@sapier: I found today that entities aren't affected by slippery(only players) and items needed some work from the original PR (which I hadn't included the lua for handling items). I think it's best to leave other entities to handle slipping themselves, but support for built-in items to support slippery when used by mods on nodes would seem reasonable? |
| 23:21 |
cmdskp |
so entities will remain unaffected |
| 23:21 |
sapier |
aren't items just entities? |
| 23:21 |
red-001 |
and mobs |
| 23:21 |
red-001 |
i think |
| 23:22 |
|
gregorycu joined #minetest-dev |
| 23:22 |
cmdskp |
it appears, items are handled with a specific section in the lua code inside the builtin folder |
| 23:22 |
cmdskp |
which handles stopping them when you throw them away |
| 23:23 |
cmdskp |
that's the bit that slippery adds to, if its set on a node |
| 23:23 |
cmdskp |
the specific file is: builtin\game\item_entity.lua :) |
| 23:25 |
cmdskp |
though, as I say, I didn't include this with my merge, I spotted it in the original PR and fixed it today to respect an amount of slip or stop, as by default |
| 23:25 |
cmdskp |
had visitors round ^_^ so haven't had much time |
| 23:28 |
sapier |
is there any way lua code runs in parallel in current minetest? |
| 23:29 |
VanessaE |
sapier: not as yet. |
| 23:29 |
VanessaE |
except for that async stuff once used in the main menu I think |
| 23:29 |
sapier |
strange because I see a bug which could be explained best by some undesired concurrency |
| 23:31 |
sapier |
considering minetest crashes completely I'd not surprised if there is something unwanted in it |
| 23:35 |
sapier |
wow :-) that's curious |
| 23:36 |
sapier |
best explanation I've got is lua garbage collector is removing a function deleted from a table while it's still in use |
| 23:37 |
cmdskp |
now that's a little bit serious, to say the least! |
| 23:38 |
VanessaE |
heh |
| 23:38 |
sapier |
I have to think more about this that'd be way to bad to not being discovered by now |
| 23:38 |
sapier |
yet there's a bug in minetest too I don't get a callstack in gui just a grey screen |
| 23:40 |
cmdskp |
Could anyone recommend a nice Lua editor/syntax checker (preferably for Windows)? |
| 23:40 |
red-001 |
notepad c++ is nice |
| 23:41 |
red-001 |
not really a lua editor |
| 23:41 |
kaadmy |
https://www.gnu.org/software/emacs/ |
| 23:41 |
sapier |
eclipse ldt ... there's even debugger support ... but there's some regression in latest version (at least on linux) but eclipse usually is way less stable on limux |
| 23:41 |
sapier |
linux |
| 23:41 |
Calinou |
http://atom.io :) |
| 23:41 |
red-001 |
kaadmy you mean echo? |
| 23:41 |
Calinou |
there's a Lua linter available as a package |
| 23:42 |
cmdskp |
"else if" catches me way too often with a complete crash out... =) I'd forgotten about Eclipse IDE having Lua support potential! |
| 23:42 |
red-001 |
https://notepad-plus-plus.org/ |
| 23:42 |
cmdskp |
ty |
| 23:42 |
sapier |
well eclipse is a little bit overkill true but if you're doing c++ like me you're used to it anyway |
| 23:43 |
red-001 |
or vs |
| 23:43 |
red-001 |
Visual studio |
| 23:43 |
sapier |
well for vs you need to have an microsoft account |
| 23:43 |
sapier |
but if you've got win10 you probably have one anyway |
| 23:43 |
sapier |
including security copy of your hard drive crypto key at nsa servers :-) |
| 23:44 |
Calinou |
you can use Windows 10 with local account |
| 23:44 |
cmdskp |
atom's interesting looking - net heard of it before. But I'm fairly comfortable to Eclipse too for Java - choices choice! :D I do like smaller editors for scripting...I'll try each! |
| 23:44 |
red-001 |
It's not exactly hard to make a Microsoft account |
| 23:44 |
cmdskp |
I'm currently using Visual Studio for Minetest compiling |
| 23:44 |
sapier |
Calinou: you can use android without google account too :-) |
| 23:44 |
Calinou |
Atom suits any language really |
| 23:44 |
kaadmy |
trying atom right now ;) |
| 23:44 |
Calinou |
it shines in Web development, but can do C++, Java, Lua, Rust… just fine |
| 23:44 |
Calinou |
it's a bit slow to load, and uses quite a bit of RAM, you are warned |
| 23:44 |
sapier |
imho win10 is for pc what android is for mobiles |
| 23:44 |
kaadmy |
and i have yet to try using Rust |
| 23:44 |
Calinou |
but if you edit files < 100 KB, speed should be good |
| 23:45 |
|
paramat joined #minetest-dev |
| 23:45 |
Calinou |
sapier, Windows 10 is pretty usable with local account, unlike Android |
| 23:45 |
kaadmy |
but imo terminal-based text editors are the best |
| 23:45 |
cmdskp |
awe, shame Atom is for Win7 and later - I have Win7 but my video drivers are not very stable compared to XP (ironic that! =D) |
| 23:45 |
Calinou |
there is Slap for the command-line: https://github.com/slap-editor/slap |
| 23:46 |
red-001 |
cmdskp |
| 23:46 |
red-001 |
notepad++ runs in xp iirc |
| 23:46 |
gregorycu |
paramat |
| 23:46 |
gregorycu |
So good to see you |
| 23:46 |
cmdskp |
does it offer syntax checking? Not just colouring? |
| 23:46 |
red-001 |
hi paramat |
| 23:46 |
gregorycu |
He's mine, leave him alone |
| 23:46 |
cmdskp |
I would like to catch some of my little idiosyncracies when switching from C++ to Lua =D |
| 23:47 |
red-001 |
what do you mean? |
| 23:47 |
Calinou |
no, out of the box, Notepad++ does only colouring |
| 23:47 |
Calinou |
I doubt there's a plugin for Lua linting |
| 23:47 |
paramat |
Fixer, yes permanent fire has no sound that's intentional |
| 23:47 |
red-001 |
https://github.com/minetest/minetest_game/pull/667 |
| 23:47 |
red-001 |
https://github.com/minetest/minetest_game/pull/602 |
| 23:47 |
paramat |
heh |
| 23:47 |
Fixer |
paramat, ok |
| 23:47 |
kaadmy |
cmdskp: just build from source, that might work. |
| 23:48 |
kaadmy |
<offtopic> does anybody here play DooM? |
| 23:49 |
Calinou |
try the non-dev channel, kaadmy |
| 23:49 |
Calinou |
you're in -dev :p |
| 23:49 |
sapier |
Calinou: I use android without google account ;-) But once I did look at adb debug output what this os does even do without account ... terrible ... windows doesn't even provide a way to see it :-) |
| 23:49 |
paramat |
apologies to all, mtgame devs are very elusive at the moment, and i am super busy |
| 23:52 |
gregorycu |
cmdskp: Why did you branch from my repo, out of interest, as opposed to the master branch |
| 23:52 |
paramat |
will merge https://github.com/minetest/minetest/pull/3499 'Minimal: Add mapgen alias for air' in a moment |
| 23:53 |
cmdskp |
gregorycu: I'm not sure what pulled my interest - but I had troubles after trying to branch to the original Minetest github, the site seemed to keep redirecting me to the fork I had made from yours. |
| 23:54 |
gregorycu |
Interesting |
| 23:54 |
cmdskp |
I'm sure it was something I had found a couple weeks ago from a mod in the forum or perhaps via google's results |
| 23:54 |
cmdskp |
I'm afraid I'm new to github's wonders |
| 23:54 |
gregorycu |
Me too |
| 23:54 |
gregorycu |
And lua |
| 23:54 |
paramat |
now merging 3499 |
| 23:54 |
gregorycu |
Well, somewhat new |
| 23:56 |
cmdskp |
Lua's interesting, I do question some of the language design, but I think it's quite useful for teaching with, esp. inside Minetest |
| 23:57 |
red-001 |
github for windows is just pain awful |
| 23:57 |
gregorycu |
I prefer python |
| 23:57 |
cmdskp |
python's not something I've used in earnest yet |
| 23:58 |
paramat |
merged |
| 23:58 |
cmdskp |
I'm more a Java/C++(and way long ago, Assembly Language) guy ^_^ But I have a fond spot for BASICs and Lua reminds me of them a bit. |
| 23:58 |
gregorycu |
Java lol |
| 23:58 |
gregorycu |
I'm proficient in C++, C#, and python |
| 23:59 |
Calinou |
Python would not be suitable for a game like Minetest, where the KISS principle is still quite important |
| 23:59 |
paramat |
will merge game 763 in a moment 'Default: Add mapgen alias for air' again |
