Time |
Nick |
Message |
00:03 |
ShadowNinja |
Taoki: Why not sypport it if all it takes is an #ifdef? |
00:03 |
Taoki |
ShadowNinja: I was wondering whether an #ifdef can be used. But I'm not sure how to do that for Irrlicht. |
00:03 |
Taoki |
In either case, it means the improvement won't work for people with Irrlicht 1.7. If that is acceptable I don't mind. |
00:04 |
Taoki |
Not sure about my workaround to the restarting animation glitch, that might work. But non-looped animations will not. |
00:16 |
ShadowNinja |
Taoki: #if (IRRLICHT_VERSION_MAJOR == 1 && IRRLICHT_VERSION_MINOR > 8) || IRRLICHT_VERSION_MAJOR > 1 |
00:17 |
Taoki |
Thanks, I'll try this |
00:17 |
|
domtron joined #minetest-dev |
00:18 |
Taoki |
ShadowNinja: Will another Travis build be triggered if I force update the branch? I won't make another commit since I'll then be requested to squish them and don't know how especially on Github |
00:20 |
ShadowNinja |
Taoki: Yes, Travis knows to rebuild. |
00:20 |
ShadowNinja |
(and I can force it anyway) |
00:20 |
Taoki |
Nice. I'll hopefully find a solution in a few minutes |
00:26 |
Taoki |
Fixed and pushed. It should work now... unless the start / end frame checks also require 1.7, then I have to do it for those as well |
00:26 |
Taoki |
Travis compilation is in progress, no need to retrigger it |
00:35 |
Taoki |
Awesome, no more issues now :) |
00:43 |
Taoki |
ShadowNinja: Is the formatting for the #if tags good? Those I can break into multiple lines if it's too long, and if the compiler doesn't mind of course |
00:45 |
ShadowNinja |
Taoki: They're fine. |
00:45 |
Taoki |
Nice. I can put the code aside for now in that case. I assume others will have to test it before it's merged so |
00:51 |
|
paramat joined #minetest-dev |
00:51 |
|
Player_2 joined #minetest-dev |
00:54 |
|
Wayward_One joined #minetest-dev |
01:29 |
paramat |
now merging game#412 |
01:29 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/412 -- mapgen.lua: Add dirt/sand/gravel blobs to mgv5/mgv7. Use blob ore for clay. Tune flowers by paramat |
01:42 |
|
Wayward_One joined #minetest-dev |
02:09 |
|
Wuzzy2 joined #minetest-dev |
02:30 |
|
paramat left #minetest-dev |
02:32 |
|
cheapie joined #minetest-dev |
02:57 |
|
Zeno` joined #minetest-dev |
03:03 |
Zeno` |
ShadowNinja, Does %g work better? |
03:06 |
Zeno` |
nvm |
03:07 |
ShadowNinja |
Zeno`: No, it's even worse. Things as short as 12345678 use exponential notation (Currently gets to 12345678912345678 or so without losing precision). |
03:08 |
Zeno` |
yeah :) |
03:11 |
Zeno` |
you could always specify precision but I don't really know what the problem was, so *shrug* |
03:22 |
|
domtron joined #minetest-dev |
03:30 |
ShadowNinja |
Zeno`: The problem is that large integers (used for node hashes) need to be serialized precisely, but floats need to work too. |
03:32 |
Zeno` |
Ah, I see now |
04:34 |
|
domtron joined #minetest-dev |
04:49 |
|
chchjesus joined #minetest-dev |
05:30 |
|
hmmmm joined #minetest-dev |
05:30 |
hmmmm |
jesus christ I can't stand it |
05:30 |
hmmmm |
I don't want to be here right now but minetest is headed toward disaster |
05:31 |
hmmmm |
at least respect my last wish: stop with the protocol breakage. |
05:31 |
|
hmmmm left #minetest-dev |
06:10 |
|
Megaf_ joined #minetest-dev |
06:10 |
|
chchjesus joined #minetest-dev |
06:37 |
|
gravgun joined #minetest-dev |
07:18 |
|
blaze joined #minetest-dev |
07:29 |
|
crazyR joined #minetest-dev |
07:54 |
|
Anchakor_ joined #minetest-dev |
08:11 |
|
kilbith joined #minetest-dev |
08:11 |
|
nore joined #minetest-dev |
08:11 |
|
Hunterz joined #minetest-dev |
08:14 |
|
MattJ joined #minetest-dev |
08:24 |
|
neoascetic joined #minetest-dev |
09:00 |
|
Amaz joined #minetest-dev |
09:04 |
|
gravgun joined #minetest-dev |
09:04 |
|
Calinou joined #minetest-dev |
09:18 |
|
Krock joined #minetest-dev |
09:37 |
|
alexxs joined #minetest-dev |
09:48 |
|
roniz joined #minetest-dev |
09:55 |
|
ImQ009 joined #minetest-dev |
09:56 |
|
nore joined #minetest-dev |
09:59 |
|
rubenwardy joined #minetest-dev |
10:09 |
|
VargaD joined #minetest-dev |
10:10 |
|
VargaD_ joined #minetest-dev |
10:12 |
|
Calinou joined #minetest-dev |
10:13 |
|
rubenwardy joined #minetest-dev |
10:21 |
|
twoelk joined #minetest-dev |
11:03 |
|
SmugLeaf joined #minetest-dev |
11:24 |
|
MinetestForFun joined #minetest-dev |
11:26 |
|
rubenwardy joined #minetest-dev |
11:29 |
|
Zeno` joined #minetest-dev |
11:39 |
|
SopaXorzTaker joined #minetest-dev |
11:43 |
|
rubenwardy_ joined #minetest-dev |
12:04 |
sfan5 |
is there not going to be a 0.4.13 or why are we planning to merge 0.5 pulls into master soon? |
12:07 |
Krock |
network changes are coming and 0.5.0 would be good for a compatilibity break |
12:24 |
|
MinetestForFun joined #minetest-dev |
12:25 |
sfan5 |
apparently not |
12:25 |
sfan5 |
nrz announced in the forum that we will be merging incompatible changes (that are for 0.5) on 1st march |
12:42 |
|
fz72 joined #minetest-dev |
12:52 |
|
T4im joined #minetest-dev |
12:56 |
|
kilbith joined #minetest-dev |
13:14 |
|
leat joined #minetest-dev |
13:14 |
|
selat joined #minetest-dev |
13:51 |
|
nrzkt joined #minetest-dev |
14:00 |
|
shadowzone joined #minetest-dev |
14:17 |
Wayward_One |
did i miss something? i was under the impression the next release would be 1.0 |
14:18 |
nrzkt |
no :p |
14:18 |
nrzkt |
but this is a version bump, yes |
14:18 |
nrzkt |
and this release will happen when the roadmap will be done, or nearly done |
14:19 |
Wayward_One |
ah, ok |
14:20 |
nrzkt |
nore, Zeno`, no problem if i add the following line in README.txt into "In case you downloaded the source code": If you want to use source code for your public server, please follow a stable-X branch instead of master, which could break your players' experience |
14:21 |
nore |
perhaps put something explicit about protocol incompatibility |
14:23 |
nrzkt |
then what do you suggests ? |
14:23 |
|
rubenwardy joined #minetest-dev |
14:31 |
nore |
nrzkt: "the server on the master branch is incompatible with stable clients" |
14:31 |
nore |
just add something like that after what you say |
14:32 |
nrzkt |
could be incompatible ? because it's not everytime :) |
14:33 |
nore |
I suggest adding that when we merge the first incompatibility |
14:33 |
nore |
and removing it after the 0.5 release |
14:39 |
T4im |
since there's no backporting to the stable branches you should probably keep master as long compatible as possible and put the breaking changes into their own branch |
14:39 |
nrzkt |
backport could be possible, bugfixes and maybe some little functions |
14:42 |
T4im |
but unlikely to happen.. also keep in mind that master usually is associated with "current stable version" as its usually the default branch (and thus the default one when checking out), I would expect quite a few servers out there to run on some version of master due to that |
14:42 |
nrzkt |
informations have been posted about htat. |
14:44 |
T4im |
doesn't change my point :P just adds a warning sign to it |
14:45 |
T4im |
on the bright side, that might mean less mobile clients on servers for a while, hehe |
14:46 |
nrzkt |
no |
14:46 |
T4im |
there will be servers updating to current master, even if that breaks old clients (including mobile ones I assumed) |
14:46 |
nrzkt |
this means servers admins must be careful :) stable-0.4 contains all the compatiblity, and informations have been posted for how switch to stable-0.4 branch |
14:47 |
T4im |
still doesn't change my point about it still happening.. information provided or not :p |
14:47 |
nrzkt |
no problem :) |
14:48 |
T4im |
new mod features leads to mods using new features... requiring new minetest server versions.. so there will be servers updating just to use updated mods eventually.. |
14:48 |
T4im |
happened in the past |
14:49 |
nrzkt |
you are right |
14:51 |
nrzkt |
then the modders must be careful and manage their compatibility layer too, because it's not our job, we will give high level API in 0.5 to improve mods performance, and it's why there is a break. In FOSS you couldn't keep a compatibility layer everytime, it's unmaintainable at a moment. Network layer is a great part, and because everything will be rewrite we couldn't provide a compatible layer. If you are an admin you |
14:51 |
nrzkt |
must be careful about your product. |
14:52 |
T4im |
saying "its not our problem" does not solve the problem :P in this case it creates it |
14:53 |
nrzkt |
maybe, but, because it's a FOSS you can create the compat layer if you want :) |
14:53 |
nrzkt |
i cannot provide a compat layer because _INIT packet must be changed. |
14:53 |
celeron55 |
where's this forum post that was talked about? |
14:53 |
nrzkt |
https://forum.minetest.net/viewtopic.php?f=18&t=11289 |
14:55 |
T4im |
nrzkt: I wish there was a way for a mod to add such a layer.. but I wouldn't even know how to querry what minetest version the server is running without adding heuristics, that you simply cannot demand from most modders... I think only debug builds offer that information to mods... |
14:56 |
nrzkt |
a mod couldn't manage network layer. |
14:56 |
nrzkt |
and modders are not affected by this network change, we are not modifying the LUA api |
14:56 |
T4im |
not yet ;) |
14:57 |
nrzkt |
you need to have a LUA api to know which is the MT server version ? |
14:57 |
|
MinetestForFun joined #minetest-dev |
14:58 |
nrzkt |
also we could add a thing to main.cpp to show the version and warn users |
14:58 |
T4im |
well depends.. as long as there's only lua api additions, there are easier ways to test.. but if there should be behavior changes (and I opened some issues to point out there are some required as they currently are not working as documented), you might have to |
14:58 |
nrzkt |
i don't think we must change the LUA calls, but add some newer |
14:58 |
T4im |
the api has broken calls atm |
14:59 |
Zeno` |
apparently there *is* a way to change the protocol without breaking protocol |
14:59 |
Zeno` |
I haven't looked though. But apparently the mechanism is there (or so I've been told) |
14:59 |
nrzkt |
oh T4im, maybe, but not because of me |
15:00 |
nrzkt |
in fact Zeno` protocol version handling at this moment isn't very reliable because it's based on packet length... |
15:00 |
T4im |
I know.. but your point was, mods should manage those cases if they are fixed after compatibility breakage |
15:00 |
nrzkt |
mods will not be affected by protocol break. |
15:00 |
T4im |
currently the only way to use those fixes is by ignoring any compatibility issues |
15:01 |
T4im |
they won't... but servers will in reuslt |
15:01 |
Zeno` |
I've been meaning to ask. When was the March 1st deadline/cutoff discussed and set? |
15:02 |
Zeno` |
nrzkt? |
15:04 |
nrzkt |
we can change it if you want :) but it was because the patch was discussed and over discussed and it's now ready for merge, and i will have time in march to do a great PR 4/4, after this will be difficult :) |
15:05 |
Zeno` |
I'd just like to know where it was discussed and how the decision was made :( |
15:06 |
Zeno` |
Because there are a few core devs here who knew nothing about that decision until they read the minetest forum |
15:06 |
nrzkt |
it was a little bit partial, because of my timetable :s |
15:06 |
rubenwardy |
#2320 does compile of me |
15:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/2320 -- Fix superflous shader setting updates by gregorycu |
15:07 |
rubenwardy |
"error: ‘v3f’ has no member named ‘getAs3Values’" is the problem in travis, it is probably an issue with different libraries |
15:07 |
rubenwardy |
* versions |
15:07 |
nrzkt |
irrlicht 1.7, not 1.8 |
15:07 |
Zeno` |
nrzkt, some warning or discussion might have been nice :( |
15:07 |
nrzkt |
then we can change this if you want, tell me |
15:08 |
nrzkt |
after the merge of network PR 3/4 we must merge the damage patch and the inventory patch too |
15:09 |
Zeno` |
What I am saying is, is that there seemed to be a lack of communication |
15:09 |
Zeno` |
but perhaps I was asleep when it was discussed |
15:10 |
nrzkt |
no, you drunk but doesn't forget anything :) |
15:10 |
T4im |
no drinking and deving, Zeno` :x |
15:10 |
Zeno` |
heh |
15:11 |
nrzkt |
xD |
15:12 |
|
UnknownSentinel joined #minetest-dev |
15:15 |
celeron55 |
nrzkt: i think we must have the incompatible version in a separate branch initially |
15:16 |
celeron55 |
here are two reasons why: |
15:17 |
celeron55 |
1) master has been compatible with the stable version since forever; people aren't going to catch up fast enough (this not a major reason, but a reason nonetheless) |
15:18 |
celeron55 |
2) master has been compatible with itself since forever; this is probably impossible to get through to users who want to use a bleeding edge version |
15:18 |
sfan5 |
^ ack |
15:18 |
nrzkt |
then we should maintain 3 branches ? |
15:18 |
sfan5 |
there is nothing to maintain in stable-0.4 |
15:18 |
sfan5 |
-> "only" 2 |
15:19 |
celeron55 |
i mean, the branch that includes the initial incompatible network changes is going to continuously change in incompatible ways because the problems aren't limited to the initial breaks |
15:19 |
celeron55 |
if it doesn't need to continuously change, then we don't actually have big enough problems to mandate a breakage in the first place |
15:20 |
celeron55 |
a separate branch will also serve as a reality check for whether there actually are enough fixed problems to make it worth being incompatible |
15:22 |
T4im |
oh, that ^ is probably the best reason yet.. allows you to change network layer more flexible with continuous breaking changes without having to hold yourself back until the final break is merged into master, nrzkt |
15:22 |
celeron55 |
once we agree that it indeed has improved things by an amount that makes it worth being incompatible, and we agree that it doesn't need to break much anymore, it can be rebased on top of master |
15:23 |
nrzkt |
okay celeron55 |
15:24 |
|
Anchakor joined #minetest-dev |
15:24 |
|
Robby joined #minetest-dev |
15:24 |
celeron55 |
it does not seem that there's much else going on regarding to the network layer, so keeping the network modification branch up-to-date doesn't seem like a too large issue |
15:26 |
nrzkt |
in fact some PR are related to protocol incompat and nobody must change the Send and read functions, and this wouldn't be too difficult |
15:26 |
celeron55 |
even while mostly you are working on it, the branch should be in the organization repository so that others also can use the rare chance of radically fixing things |
15:27 |
celeron55 |
and reviewing it becomes easier and whatnot |
15:28 |
rubenwardy |
#2375 |
15:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/2375 -- Fix superflous shader setting updates by rubenwardy |
15:31 |
celeron55 |
something like "network-rework" might be a good branch name |
15:32 |
|
fdfgdfgd joined #minetest-dev |
15:32 |
nrzkt |
okay, if you want celeron, i'll create it next week |
15:35 |
rubenwardy |
It works! #2375 |
15:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/2375 -- Fix superflous shader setting updates by rubenwardy |
15:36 |
celeron55 |
once the branch exists, it becomes everyone's reponsibility to use it to fix long-standing issues and to judge when it's fixing enough things to be worth the incompatibility |
15:38 |
|
UnknownSentinel joined #minetest-dev |
15:38 |
|
Megaf joined #minetest-dev |
15:53 |
|
ImQ009 joined #minetest-dev |
16:00 |
celeron55 |
someone asks by email for the option to turn player name visibility completely off |
16:00 |
celeron55 |
maybe someone could implement that, altough it could always be cheated with a modified client |
16:01 |
celeron55 |
they want to play hide and seek 8) |
16:02 |
VanessaE |
actually, bring able to turn player names off with a keypress is useful when taking screenshots |
16:02 |
rubenwardy |
Related: https://github.com/minetest/minetest/issues/1345 |
16:02 |
VanessaE |
(e.g. for a "server overview" image, since it's not hard at all for players themselves to get lost in the image, but the player names stand out regardless) |
16:03 |
nrzkt |
#2376 |
16:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/2376 -- Add find_surface_nodes_in_area LUA call which permit to only get the nodes which are under air nodes by nerzhul |
16:07 |
nrzkt |
please review it, it permits to improve performances of plantlife, but not only if there are other mods which needs to know surface nodes |
16:08 |
|
kilbith joined #minetest-dev |
16:16 |
|
SopaXorzTaker joined #minetest-dev |
16:16 |
|
ImQ009 joined #minetest-dev |
16:18 |
|
rubenwardy joined #minetest-dev |
16:21 |
|
DFeniks joined #minetest-dev |
16:30 |
|
MinetestForFun joined #minetest-dev |
16:31 |
nrzkt |
celeron55: i changed the topic on the forum :) |
17:01 |
|
Anchakor_ joined #minetest-dev |
17:11 |
|
MinetestForFun_ joined #minetest-dev |
18:03 |
|
shadowzone joined #minetest-dev |
18:04 |
|
Miner_48er joined #minetest-dev |
18:26 |
|
fz72 joined #minetest-dev |
19:20 |
|
est31 joined #minetest-dev |
19:22 |
celeron55 |
somebody who says he is a noob and uses dali linux asks by email for an x86 binary package with libraries included |
19:22 |
celeron55 |
why is a noob using dali linux, is my question |
19:23 |
celeron55 |
well anyway, if somebody is interested in making such a package, there's one person in this world who needs it |
19:25 |
|
zat joined #minetest-dev |
19:27 |
shadowzone |
x86.. |
19:28 |
celeron55 |
he also says blender has such a package and it works for him |
19:30 |
|
EvergreenTree joined #minetest-dev |
19:32 |
EvergreenTree |
I was wondering, should something as small as #2378 warrent a pull request? |
19:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/2378 -- Add src/network/CMakeFiles/ and src/client/CMakeFiles to gitignore by 4Evergreen4 |
19:34 |
kilbith |
does anyone can disable the Debug build option on Launchpad please ? |
19:34 |
kilbith |
kind of slowness |
19:36 |
est31 |
kilbith, you mean at startup? |
19:36 |
kilbith |
yes |
19:36 |
est31 |
thats because of the unittests |
19:36 |
est31 |
nrzkt is working on a solution |
19:36 |
est31 |
but right now there is a discussion on whether to compile them into release builds |
19:37 |
kilbith |
and perhaps a bit less FPS than my own compiled build |
19:37 |
kilbith |
(Release type) |
19:38 |
est31 |
https://github.com/minetest/minetest/commit/b3aeba684b4e27e9fdf2c07949750bb567e40d6b |
19:39 |
kilbith |
that build is intrinsically slower than the release one anyways |
19:39 |
kilbith |
"Debug build is slower, but gives much more useful output in a debugger." |
19:39 |
kilbith |
> http://dev.minetest.net/Compiling_Minetest |
19:40 |
est31 |
thats true |
19:41 |
* est31 |
wonders whether it might be a good idea when the network breaks to discontinue launchpad daily build repo, or to force a manual step. |
19:41 |
est31 |
as in renaming the package |
19:47 |
|
roniz joined #minetest-dev |
19:54 |
|
manax joined #minetest-dev |
19:56 |
|
Aaron1011 joined #minetest-dev |
19:57 |
|
daswort joined #minetest-dev |
19:57 |
|
Robby joined #minetest-dev |
20:01 |
|
Megal joined #minetest-dev |
20:05 |
|
pitriss joined #minetest-dev |
20:08 |
|
casimir joined #minetest-dev |
20:13 |
|
pitriss left #minetest-dev |
20:17 |
|
chrisf joined #minetest-dev |
20:19 |
|
disablec1 joined #minetest-dev |
20:45 |
manax |
Can someone explain the separation of code in player vs localplayer? I'm looking at getStandingNodePos(), which seems like it should be in player, but it requires crouch stuff, which also seems like it should be in player... So, wondering. |
20:53 |
Wayward_One |
i think i may have found another memory leak... almost ran out of memory after 30 minutes of playing, recent git, only minetest and irc running |
20:53 |
* Wayward_One |
git pulls to be sure |
21:26 |
|
shadowzone joined #minetest-dev |
21:28 |
Wayward_One |
yep, seems to be a memory leak... just git pulled, joined a server about 10 minutes ago, and memory use is up from about 400Mb to 1.8Gb, and it's gradually climbing |
21:29 |
|
MinetestForFun joined #minetest-dev |
21:36 |
est31 |
it seems that the reason #2378 travis failed was because of an offtime of one of sfan5's servers: https://travis-ci.org/minetest/minetest/jobs/51748219#L4425 |
21:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/2378 -- Add src/network/CMakeFiles/ and src/client/CMakeFiles to gitignore by 4Evergreen4 |
21:39 |
|
everamzah joined #minetest-dev |
21:49 |
sfan5 |
est31: i restarted them |
21:52 |
|
MinetestForFun joined #minetest-dev |
21:54 |
est31 |
sfan5, ok,added comment so that nobody thinks this is the PR's fault |
22:03 |
|
MinetestForFun_ joined #minetest-dev |
22:27 |
Fritigern |
Interesting, MT4.11 will be in the Ubuntu 15.04 repositories. I guess that's a lot better than it was... |
22:28 |
est31 |
but its not 0.4.12 :( |
22:31 |
Fritigern |
Of course not. Because there is not 4.12 yet |
22:33 |
kilbith |
Fritigern, don't be so sure of that ;) |
22:34 |
Fritigern |
I just pulled and built, and I am at 4.11-255-gcd4324e |
22:34 |
Fritigern |
So yeah, i am very sure |
22:34 |
est31 |
thats because of an error |
22:34 |
est31 |
there is 0.4.12 |
22:34 |
est31 |
~topic |
22:34 |
ShadowBot |
est31: Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
22:34 |
est31 |
~topic #minetest |
22:34 |
ShadowBot |
est31: Welcome to #minetest, the official channel of Minetest | Version: 0.4.12 (2015-02-18) | Responses may take a while, so be patient. | Rules: http://wiki.minetest.net/IRC#Rules | Development: #minetest-dev | Server list: http://minetest.net/servers | IRC logs: http://irc.minetest.ru/minetest/ |
22:34 |
est31 |
see? |
22:35 |
est31 |
Fritigern, its issue #2357 |
22:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/2357 -- Make git version discovery work on master by est31 |
22:36 |
Fritigern |
Wow, what a mess |
23:08 |
|
MinetestForFun_ joined #minetest-dev |
23:12 |
|
MinetestForFun joined #minetest-dev |
23:24 |
|
MinetestForFun joined #minetest-dev |