| Time |
Nick |
Message |
| 01:25 |
kahrl |
ugh... git diff|wc |
| 01:25 |
kahrl |
6018 18557 169140 |
| 01:26 |
kahrl |
I just cleaned up some code... |
| 01:26 |
PilzAdam |
looks like fun |
| 01:27 |
kahrl |
to be fair a lot of that was copy&paste, but still... |
| 02:13 |
|
ch98 joined #minetest-dev |
| 02:20 |
Exio4 |
kahrl: it is all your fault |
| 02:20 |
Tesseract |
kahrl: git diff --shortstat |
| 02:21 |
kahrl |
77 files changed, 3615 insertions(+), 3743 deletions(-) |
| 02:22 |
kahrl |
(wc is now at: 9194 29550 258584) |
| 03:20 |
|
mrtux_ joined #minetest-dev |
| 03:20 |
|
mrtux_ joined #minetest-dev |
| 03:54 |
|
Miner_48er joined #minetest-dev |
| 03:57 |
|
ssieb joined #minetest-dev |
| 04:14 |
|
diemartin joined #minetest-dev |
| 04:22 |
kahrl |
if anyone has nothing to do: https://github.com/kahrl/minetest/commit/3924f2b7625b113bf641cf9843f0342c948ce51c |
| 04:23 |
VanessaE |
oof |
| 04:23 |
VanessaE |
someone's been busy. |
| 04:25 |
kahrl |
wait, that's the wrong commit, try: https://github.com/kahrl/minetest/commit/98194f4d5d61882d1cf45f356fd1f868651d51bc |
| 04:25 |
VanessaE |
still huge :P |
| 04:27 |
kahrl |
I believe if you disregard the boilerplate comments and code added by new header/source files it removes more code than it adds |
| 04:28 |
kahrl |
(by making GUIEngine reuse the ScriptApi framework that's already in place for the game) |
| 04:30 |
Tesseract |
GitHub hates mobile devices. Even their app has huge performance issues. |
| 04:31 |
Tesseract |
kahrl: What about #862? It will take me far to long to do the 0.0.0.0, :: thing... |
| 04:34 |
kahrl |
what was the problem with 862 again? |
| 04:45 |
|
diemartin joined #minetest-dev |
| 05:20 |
|
kaeza joined #minetest-dev |
| 05:50 |
|
mrtux joined #minetest-dev |
| 06:00 |
|
neko259 joined #minetest-dev |
| 06:09 |
|
darkrose joined #minetest-dev |
| 06:38 |
celeron55 |
wtf kahrl |
| 06:38 |
celeron55 |
nobody is going to review that |
| 06:38 |
celeron55 |
8D |
| 06:39 |
hmmmm |
once thing i don't get is why you have two engine.logs |
| 06:39 |
hmmmm |
s/once/one/ |
| 06:41 |
kahrl |
hmmmm: in the docs? I copied that from lua_api.txt |
| 06:42 |
celeron55 |
as random nitpicking, i hate calling functions "fct" |
| 06:42 |
celeron55 |
"fn" and "function" and "func" are fine; "fct" is not |
| 06:43 |
kahrl |
again, just copied that :P but I could change it |
| 06:43 |
celeron55 |
i know 8) |
| 06:43 |
hmmmm |
so wait, what's the purpose of this |
| 06:43 |
hmmmm |
seems like some of it is just undoing what sapier did |
| 06:43 |
celeron55 |
nobody can say anything meaningful about this unless you make a summary of what it does |
| 06:44 |
kahrl |
celeron55: I have to sleep now but I will do tomorrow |
| 06:44 |
kahrl |
hmmmm: what in particular? |
| 06:44 |
hmmmm |
you're going to sleep tomorrow? excellent |
| 06:44 |
hmmmm |
let's focus on this now |
| 06:44 |
hmmmm |
ah, adding the lua_State parameter back to the script_* callbacks |
| 06:44 |
kahrl |
:P |
| 06:45 |
kahrl |
oh, you mean script_run_callbacks? |
| 06:45 |
hmmmm |
yeah |
| 06:46 |
kahrl |
I did that to make s_base.h smaller because it's included a bunch of times |
| 06:46 |
kahrl |
and it's really an internal thing |
| 06:46 |
kahrl |
(some of what I did there is remove unneeded includes and make include files smaller) |
| 06:47 |
hmmmm |
that's always welcome |
| 06:47 |
celeron55 |
i'll do a compile time benchmark |
| 06:47 |
* kahrl |
dozes off |
| 06:50 |
|
EdB joined #minetest-dev |
| 06:55 |
celeron55 |
with: |
| 06:55 |
celeron55 |
real 5m20.484s |
| 06:55 |
celeron55 |
user 9m5.074s |
| 06:55 |
celeron55 |
sys 0m19.885s |
| 07:01 |
celeron55 |
without: |
| 07:01 |
celeron55 |
real 5m7.871s |
| 07:01 |
celeron55 |
user 8m58.605s |
| 07:01 |
celeron55 |
sys 0m18.199s |
| 07:01 |
celeron55 |
it increases compile time a bit |
| 07:02 |
celeron55 |
of course the main benefit in smaller headers is shortening of incremental compiles, but that's very hard to compare |
| 07:02 |
hmmmm |
i say we keep all of minetest in a single .cpp file for maximum compile |
| 07:02 |
celeron55 |
8)) |
| 07:02 |
hmmmm |
and with clang it'd be zomgbbqfast |
| 07:04 |
celeron55 |
anyway i got these warnings from kahrl's branch; i guess those could be fixed at the same time: http://paste.dy.fi/v6d |
| 07:04 |
celeron55 |
they're once again just copied from the current code but anyway |
| 07:06 |
celeron55 |
but it's good to acknowledge that assuming headers are kept as lightweight as possible, incremental compile times tend to be reversely proportional to the number of compile units, and total compile time tends to be proportional to the amount of compile units |
| 07:07 |
celeron55 |
it isn't beneficial to go to either extreme |
| 07:08 |
celeron55 |
actually, with bloated headers that becomes much more apparent |
| 07:08 |
celeron55 |
...but only when non-header stuff is modified |
| 07:08 |
celeron55 |
with bloated headers a header modification is such a pain it's better to not even think about it |
| 07:09 |
* celeron55 |
blah blah |
| 07:09 |
celeron55 |
i'll go do something more productive than rant about obvious things -> |
| 07:13 |
hmmmm |
mapgen.h has that problem |
| 07:13 |
hmmmm |
gotta get around to fixing that sometime. |
| 07:29 |
celeron55 |
(also in modern C++ development you basically just put everything in templated headers and then buy a supercomputer to compile it... it's insane)' |
| 07:43 |
|
WilliamBundy joined #minetest-dev |
| 07:48 |
|
WilliamBundy joined #minetest-dev |
| 07:48 |
WilliamBundy |
Hello. |
| 07:48 |
|
smoke_fumus joined #minetest-dev |
| 07:48 |
WilliamBundy |
Does anybody have any words of wisdom regarding modifying the physics of Minetest? |
| 07:50 |
smoke_fumus |
WilliamBundy: garry's mod would be proud. |
| 07:51 |
WilliamBundy |
smoke_fumus, Not that extreme. |
| 07:52 |
WilliamBundy |
smoke_fumus, But I wouldn't be against trying to weld ODE or Bullet onto the engine |
| 07:52 |
WilliamBundy |
smoke_fumus, if it was possible to make that work with the voxel setting. |
| 07:53 |
smoke_fumus |
why bullet? go directly to physiX |
| 07:54 |
WilliamBundy |
Is that open source now? |
| 07:54 |
smoke_fumus |
nope its still propiretary, but nothing restricts you from using it as the component |
| 07:55 |
WilliamBundy |
I wonder how good its linux support is. |
| 07:55 |
* smoke_fumus |
shrugs |
| 07:56 |
smoke_fumus |
ps3/360 supports it. some mac games work with it too. though i don't remember which ones |
| 07:56 |
smoke_fumus |
arkham asylum to example |
| 07:57 |
WilliamBundy |
I'd personally prefer to go with the open source ones, especially if the minetest source is under GPL |
| 07:58 |
WilliamBundy |
But, yes, modifying the built-in physics of minetest. |
| 07:59 |
celeron55 |
many are probably against any such thing, but in any case we only allow LGPL or more free libraries (GPL or proprietary won't be ever accepted) |
| 08:00 |
WilliamBundy |
I'm sure ODE is under such a licence, Wolfire is using it in Overgrowth, a commercial release |
| 08:00 |
celeron55 |
ODE is under BSD so that is fine license-wise |
| 08:02 |
WilliamBundy |
It's a pretty drastic change though, any way you look at it. |
| 08:03 |
* Taoki |
fully supports having physics in MT. Either BulletX or ODE... Bullet is more popular though |
| 08:04 |
smoke_fumus |
popular doesn't mean good. |
| 08:04 |
WilliamBundy |
I'd want to do tests before running with an implementation. |
| 08:04 |
smoke_fumus |
Look at blender to example - overblown piece of crap. |
| 08:05 |
WilliamBundy |
smoke_fumus, or: free modeling software! Now I don't have to shell thousands on commercial ones! |
| 08:05 |
smoke_fumus |
WilliamBundy: ....wings 3d? |
| 08:06 |
smoke_fumus |
besides - stop being cheap skunk. 3dsmax has self-educational student license, it has per-project licensing and it has subscription licensing, not only prime buying price |
| 08:07 |
smoke_fumus |
but back to free ones. In wings 3d you are shaping clay with fingers. In blender you shaping clay too. With the friggin fork. |
| 08:07 |
|
Calinou joined #minetest-dev |
| 08:08 |
smoke_fumus |
which also needs to open its teeth through dozen of shortcuts |
| 08:08 |
kaeza |
wtf |
| 08:08 |
WilliamBundy |
Didn't know about Wings. Haven't used/seen/tried 3dsmax, nor have I had to do 3d modeling. |
| 08:09 |
smoke_fumus |
you see? |
| 08:09 |
smoke_fumus |
popular does not mean good |
| 08:09 |
smoke_fumus |
http://www.wings3d.com/ |
| 08:09 |
WilliamBundy |
Windows, OSX, and Ubuntu should be prime examples of that. |
| 08:10 |
* smoke_fumus |
shrugs |
| 08:10 |
smoke_fumus |
well, what are you offering as a replacement for most used system? |
| 08:10 |
WilliamBundy |
Not to mention Vanilla Minecraft, Halo4+, Call Of Duty 5+, Skyrim, etc. |
| 08:10 |
WilliamBundy |
For physics? There's a bunch of smaller ones which I've come across |
| 08:10 |
WilliamBundy |
Whose names I can vaguely remember |
| 08:10 |
smoke_fumus |
pfft. uhuh. cod and skyrim might've accmulated users yes. Not as big of an audience like for, say Doom2 |
| 08:10 |
smoke_fumus |
in total i mean |
| 08:11 |
WilliamBundy |
Now we're edging into differing definitions of popularity. |
| 08:11 |
smoke_fumus |
Timed waves > point splash |
| 08:12 |
WilliamBundy |
There are usually good reasons to go with the most popular choice in programming/development circumstances |
| 08:12 |
WilliamBundy |
I'm no fan of C++, but lots of people use it, which means I have to learn it. |
| 08:12 |
smoke_fumus |
or, well - you know - most of people are cheap skunks which don't see good software behind their own greed |
| 08:13 |
smoke_fumus |
also again - 3dsmax self-educational license is completely free on condition that you will use it only for non-commercial works |
| 08:13 |
smoke_fumus |
which in your case - is fine |
| 08:13 |
WilliamBundy |
It's not greed when the marginal value of the time wasted is less than the cost of the better software |
| 08:15 |
WilliamBundy |
Back to what I wanted help with, the physics code looks like it's spread out over player, localplayer, collision and environment |
| 08:15 |
celeron55 |
smoke_fumus: in fact it's not possible to include anything restricted to "non-commercial" in minetest |
| 08:16 |
smoke_fumus |
celeron55: you don't charge a penny for minetest |
| 08:16 |
smoke_fumus |
it is non-commercial |
| 08:16 |
WilliamBundy |
But I could make a game for it, and sell it. |
| 08:16 |
smoke_fumus |
AD from site doesn't count as they doesn't restrict model delivery to customer |
| 08:16 |
celeron55 |
our releases are under LGPL and CC BY-SA, which mean they can be used for any commercial purpose if wanted |
| 08:16 |
smoke_fumus |
yeap, and you will break license |
| 08:16 |
Calinou |
Minetest is FOSS, and thus ability to use it commercially is a requirement |
| 08:16 |
WilliamBundy |
So long as I released my changes. |
| 08:17 |
WilliamBundy |
smoke_fumus, No, not at all. |
| 08:17 |
celeron55 |
any license that disallows commercial usage is incompatible |
| 08:17 |
smoke_fumus |
celeron55: then you should point out in license agreement that some of the parts of game are CC BY-SA but models are non-commertical CC-NC |
| 08:17 |
smoke_fumus |
that will do it |
| 08:17 |
WilliamBundy |
celeron55, This is for source inclusion in core? |
| 08:18 |
celeron55 |
yeah and that'd blow right through of our values |
| 08:18 |
smoke_fumus |
no it will not |
| 08:18 |
smoke_fumus |
it will be basic undestanding of law |
| 08:18 |
celeron55 |
you can make a separate game that is licensed in whatever way you like of course |
| 08:18 |
WilliamBundy |
So long as modifications to your code are released. |
| 08:18 |
smoke_fumus |
that will break license too. you are the dev - you point out what licensed under what |
| 08:19 |
smoke_fumus |
if they change license from lgpl - they break it |
| 08:19 |
smoke_fumus |
its their own damn problems |
| 08:19 |
smoke_fumus |
same with CC-NC |
| 08:19 |
WilliamBundy |
smoke_fumus, Dual licencing: you choose the licence |
| 08:19 |
smoke_fumus |
you responsibilities lie behind YOUR part of contibution to the project |
| 08:19 |
WilliamBundy |
LGPL: any changes made to this code must be released, may be compiled with GPL-INcompatible libraries |
| 08:20 |
smoke_fumus |
if some jackass will download source, and release it along witn models - you and autodesk can sue him |
| 08:20 |
smoke_fumus |
for the model use specifically |
| 08:20 |
kaeza |
... |
| 08:20 |
celeron55 |
smoke_fumus: we don't do things like that; that'd be just plain dicky |
| 08:21 |
smoke_fumus |
No, that will be fair |
| 08:21 |
smoke_fumus |
he read license agreement |
| 08:21 |
smoke_fumus |
models were pointed out as CC-NC |
| 08:21 |
smoke_fumus |
his ass is busted now. Case closed. |
| 08:21 |
WilliamBundy |
smoke_fumus, Have you read the GPL and LGPL? |
| 08:22 |
smoke_fumus |
WilliamBundy: i'm talking about the case where you release say mintest with CC BY-SA but IN license agreement point out that MODELS are CC-NC and reusing them for commercial purpose would be illegal |
| 08:22 |
smoke_fumus |
since they are created on non-commercial license of 3dsmax |
| 08:22 |
smoke_fumus |
once jackass uses em to make a $ - you lay a lawsuit on his ass |
| 08:22 |
smoke_fumus |
since he broke user agreement |
| 08:23 |
smoke_fumus |
if you wish to do that before autodesk i mean :D |
| 08:23 |
WilliamBundy |
Why would you want proper 3d models in a big-voxel game? |
| 08:23 |
smoke_fumus |
but if HE uses these models which YOU released under CC-NC - you held no responsibility for HIS actions |
| 08:23 |
smoke_fumus |
just saying |
| 08:23 |
WilliamBundy |
celeron55, It's nice to see a community that embraces the openness of their source/game |
| 08:23 |
celeron55 |
when a release of minetest is made, part of the release is the licenses that we use; it's inseparable from what is released and it's part of our product, and part of what our users appreciate |
| 08:24 |
smoke_fumus |
no, your users mainly appreciate gameplay and having a good time with product :D |
| 08:24 |
WilliamBundy |
smoke_fumus, yeah, but then he'd be stupid (not having done his homework), and would only be liable to be sued by the makers of 3dsmax or whoever found out. |
| 08:25 |
WilliamBundy |
*if the found out |
| 08:25 |
smoke_fumus |
WilliamBundy: i know. i just saying that you CAN. doesn't mean that you SHOULD. |
| 08:25 |
celeron55 |
smoke_fumus: even if they don't directly appreciate it, they appreciate some results of the community that it creates |
| 08:25 |
smoke_fumus |
i agree on that |
| 08:27 |
celeron55 |
of course it's inefficient if you just look at the direct end result; nobody can argue with that; but it simply isn't the only priority here |
| 08:28 |
WilliamBundy |
What does BS stand for in the source? |
| 08:28 |
celeron55 |
https://github.com/minetest/minetest/blob/master/src/constants.h#L66 |
| 08:29 |
WilliamBundy |
Didn't know where to look, thanks. |
| 08:29 |
Taoki |
<WilliamBundy> What does BS stand for in the source? - Code that's considered bulls**t :P |
| 08:30 |
Taoki |
J/K... dunno what myself |
| 08:30 |
smoke_fumus |
:D |
| 08:30 |
smoke_fumus |
search google code by //* fuck or something like that |
| 08:30 |
smoke_fumus |
you would be surprised xD |
| 08:30 |
WilliamBundy |
Tilesize, essentially, making sure you're not breaking stuff with float/int conversions. |
| 08:31 |
smoke_fumus |
WilliamBundy: so, in minetest, does tilesize IS 1 standard opengl unit which is 1m? |
| 08:31 |
celeron55 |
(dunno if it makes more harm than good, but it's there and it's also embedded in all network/file formats so it's practically impossible get rid of it) |
| 08:32 |
WilliamBundy |
I don't think it's very important, overall, I was just wondering why it was there. |
| 08:32 |
smoke_fumus |
standardizing your inputs. certanly more good, except if you expect .RAW files. than you will need ugly import construction with rescaling |
| 08:33 |
smoke_fumus |
*then |
| 08:35 |
WilliamBundy |
Right now I'm most intent on making the movement feel more satisfying/realistic |
| 08:35 |
WilliamBundy |
Not really realistic, but believable. |
| 08:36 |
Taoki |
What I'd love to see physics for are dropped items and ragdoll deaths for dead mobs / players |
| 08:36 |
Taoki |
Yes, we can and should have ragdolls for something like Minetest :) |
| 08:36 |
Taoki |
Oh, and perhaps to make mined blocks drop in pieces... that too of course |
| 08:36 |
WilliamBundy |
I'd like to see blocks drop from broken nodes, but that's beyond me at this point. |
| 08:37 |
WilliamBundy |
First I'd like to make jumping feel more parabolic |
| 08:37 |
Taoki |
Yes. Imagine that instead of particles when breaking a node (or alongside them), a the block drops down in cracks that roll around the ground |
| 08:38 |
WilliamBundy |
That not only sounds difficult and time consuming, but also annoying gameplay-wise |
| 08:39 |
Taoki |
I think it would look very nice |
| 08:40 |
Taoki |
Can be small pieces to not be confusing |
| 08:40 |
WilliamBundy |
Oh, and another question: what's the theoretical limit of world-size in minetest? It seems to use something similar to cubic chunks (minecraft mod), so, greater than 65000x65000x65000? |
| 08:40 |
WilliamBundy |
Taoki, I don't understand the effect you're going for |
| 08:41 |
Taoki |
WilliamBundy: Mined blocks breaking and falling to pieces with realistic physics |
| 08:43 |
WilliamBundy |
At what density then? Usually, the texels are 1/16m, which would mean creating 32768 cubes |
| 08:44 |
WilliamBundy |
for all of them. |
| 08:44 |
Taoki |
Or, we can just have the dropped item fall (like in Minecraft) only with Bullet / ODE physics instead |
| 08:44 |
Taoki |
Yeah, that is a good question |
| 08:44 |
WilliamBundy |
The idea behind those are that they'd be opened up to lua |
| 08:44 |
Taoki |
Prolly best to have the item drop like in MC. But again, with real physics in our case |
| 08:44 |
Taoki |
sure |
| 08:45 |
WilliamBundy |
So map/game makers, could include complicated physics things in their games |
| 08:45 |
VanessaE |
technic has that, and it works fairly well |
| 08:45 |
Taoki |
Anyway, someone with enough experience should test and see which works best (BulletX or ODE) |
| 08:45 |
Taoki |
yes |
| 08:45 |
Taoki |
If they're added however, they should allow both physical dropped objects, as well as armature ragdolls. |
| 08:45 |
WilliamBundy |
VanessaE, You mean minecraft-style falling blocks? |
| 08:45 |
Taoki |
Imagine sheep ragdolling down the blocky hills when you hit them :) Or sand monsters, etc |
| 08:46 |
Taoki |
So... awesome |
| 08:46 |
VanessaE |
yup |
| 08:46 |
Taoki |
Yes, Technic has those |
| 08:46 |
VanessaE |
they don't fall to pieces like you guys were discussing |
| 08:46 |
WilliamBundy |
VanessaE, I think the falling item-block mechanic is one of the coolest subfeatures of minecraft |
| 08:47 |
WilliamBundy |
Very satisfying in the alpha versions to pick up 50 things at once and hear all of the little pops as they appear in your inventory |
| 08:47 |
VanessaE |
but if they fall, they can be made to fall to pieces too I'd think (fake it with a few randomly-chosen, large meshes that look like scattered pieces) |
| 08:47 |
Taoki |
Mods would allow that yes |
| 08:47 |
WilliamBundy |
If we're going that far with the physics, it might just be better to treat each block as a collection of fragments |
| 08:47 |
WilliamBundy |
And breaking them bit by bit with every strike |
| 08:48 |
WilliamBundy |
once ~60% are broken, one last strike breaks the rest. |
| 08:48 |
Taoki |
Would be even more awesome :) |
| 08:48 |
WilliamBundy |
But that wasn't my intention with the addition of a middleware physics engine. |
| 08:48 |
Taoki |
Yeah, that would be a separate feature |
| 08:49 |
WilliamBundy |
For cycles burned and programmer time used v. gameplay additions, I don't think it's worth it until we get better computers |
| 08:50 |
VanessaE |
WilliamBundy: almost sounds like that request I made sometime back for persistent node damage |
| 08:51 |
WilliamBundy |
Mostly, I'd like to see it used for mechanical power systems, entities, and the occasional effect. |
| 08:51 |
|
jin_xi joined #minetest-dev |
| 08:52 |
WilliamBundy |
VanessaE, would be an interesting game mode for modders to use |
| 08:52 |
WilliamBundy |
I can imagine it having lots of uses in a combat game |
| 08:52 |
WilliamBundy |
A per-node setting. |
| 08:53 |
Taoki |
Anway, as far as physics go, the important part is someone with the skill and knowledge to integrate ODE or BulletX into Minetest, and allow the LUA API to enable it on entities. |
| 08:53 |
WilliamBundy |
Taoki, First things first, adding hooks to existing physics in Minetest |
| 08:53 |
WilliamBundy |
Even more first things first: figuring out where the physics is and how it works. |
| 08:54 |
Calinou |
"ODE" as if it wasn't terrible |
| 08:54 |
WilliamBundy |
Calinou, I have no experience with it, I just know that it exists. |
| 08:54 |
Taoki |
There should probable be a set_physics function with balues such as: 0 = default simple physics (currently used for thrown items), 1 = BulletX physics, 3 = BulletX physics + armature ragdolls (if that entity is set to a rigged mesh, such as b3d or x) |
| 08:54 |
Calinou |
bullet is probably a better choice |
| 08:54 |
Taoki |
**values |
| 08:54 |
WilliamBundy |
Calinou, agreed. |
| 08:54 |
Taoki |
Erm 2 not 3 |
| 08:54 |
Taoki |
Yes, agreed too |
| 08:54 |
WilliamBundy |
Taoki, don't get ahead of yourself. |
| 08:55 |
Taoki |
ODE is nice but Bullet seems more firmly developed and common |
| 08:55 |
Calinou |
ODE: every game implementing it has a terrible and buggy implementation |
| 08:55 |
Calinou |
bullet: it works |
| 08:55 |
WilliamBundy |
Overgrowth? |
| 08:55 |
Taoki |
Calinou: Years ago when I tried it in opensim, Bullet looked worse than ODE. But both were fine |
| 08:56 |
WilliamBundy |
Anyway, this isn't a feature I'd consider until the UX/basic gameplay is at minecraft levels of polish. |
| 08:57 |
WilliamBundy |
Part of the big attraction of minecraft to modders/devs is the amount of stuff it does for you |
| 08:57 |
WilliamBundy |
Animations, default menus, extensible systems |
| 09:16 |
WilliamBundy |
Does the player have a real velocity property? or just speed, reset every frame on input? I can't find where the integration happens, so I don't know exactly what it does. |
| 09:47 |
|
sullome joined #minetest-dev |
| 10:36 |
|
iqualfragile joined #minetest-dev |
| 10:42 |
WilliamBundy |
With a newfound, though elementary, understanding of the movement code, my wtf/min are over 9000. |
| 10:43 |
|
EdB joined #minetest-dev |
| 10:53 |
|
Akien joined #minetest-dev |
| 10:54 |
|
Calinou joined #minetest-dev |
| 11:10 |
WilliamBundy |
Modifying other people's code is like playing old adventure games. |
| 11:17 |
celeron55 |
this code has been evolving continuously for three years, so there's all kinds of stuff to be found 8) |
| 11:18 |
WilliamBundy |
I've managed to minimally add something that fixes my pains with jumping/moving, but I'm beginning to think that strapping bullet on is a good idea. |
| 11:19 |
WilliamBundy |
I'll tease my changes into a pull request on github, if that's alright with you |
| 11:22 |
kaeza |
putting a Bullet in Minetest's HEAD seems a bit extreme |
| 11:23 |
kaeza |
</badpun> |
| 11:23 |
WilliamBundy |
What about it's trunk? |
| 11:23 |
WilliamBundy |
(is that worse?) |
| 11:26 |
celeron55 |
that means the same thing but in subversion's terms |
| 11:27 |
celeron55 |
good pun though actually, though 8) |
| 11:27 |
celeron55 |
-though |
| 11:27 |
WilliamBundy |
I've never used subversion |
| 11:27 |
WilliamBundy |
Thankfully. |
| 11:29 |
|
PilzAdam joined #minetest-dev |
| 12:01 |
WilliamBundy |
Is it planned to add minecraft-style block-dropping (rotating cubes) to minetest_game? |
| 12:01 |
sfan5 |
there are rotating cubes |
| 12:01 |
WilliamBundy |
Not by default? |
| 12:01 |
sfan5 |
but some mods still define some property in node defs that makes them not appear cubic |
| 12:01 |
sfan5 |
... |
| 12:01 |
Calinou |
you can drop them, but stuff mined directly goes into inventory. |
| 12:02 |
Calinou |
this is a feature, not a bug. |
| 12:02 |
Calinou |
there's no fun in having to collect stuff you mine, tbh |
| 12:02 |
sfan5 |
it was inventoryimage |
| 12:02 |
WilliamBundy |
Ah, that was always a feature I liked so |
| 12:02 |
Calinou |
there are mods for that |
| 12:02 |
sfan5 |
if there is no inventory image defined they will look cubic when dropped, otherwise flat |
| 12:02 |
WilliamBundy |
sfan5, after being mined |
| 12:03 |
* sfan5 |
points at what Calinou said |
| 12:03 |
WilliamBundy |
Yes, I know. |
| 12:30 |
Calinou |
https://github.com/minetest/minetest/pull/866 |
| 12:30 |
Calinou |
inb4 refusal |
| 12:30 |
Calinou |
WilliamBundy: there used to be less friction, this is no longer the case :P |
| 12:30 |
WilliamBundy |
In the air? |
| 12:31 |
WilliamBundy |
It feels pretty subtle to me. |
| 12:31 |
WilliamBundy |
I remember playing a version wayback when you floated everywhere (it felt like) |
| 12:33 |
WilliamBundy |
Would you prefer I rewrite the description telling of the immersion breaking jarring stop the player would come to? |
| 12:40 |
Exio4 |
what's up with the minetest.conf settings for movement_damping_ground and movement_damping_air? |
| 12:43 |
WilliamBundy |
If I say "What settings?" are you going to reply: "Exactly." |
| 12:43 |
WilliamBundy |
*? |
| 12:43 |
Exio4 |
nah :P |
| 12:43 |
Exio4 |
https://github.com/minetest/minetest/blob/master/minetest.conf.example#L320 |
| 12:43 |
Exio4 |
like those, plus the thing of they being managed by the server, not a client-side setting |
| 12:46 |
WilliamBundy |
Let me look at the headers |
| 12:47 |
WilliamBundy |
The movement code is only in LocalPlayr |
| 12:47 |
WilliamBundy |
LocalPlayer* |
| 12:48 |
WilliamBundy |
I'm assuming that the server must have a copy of that too |
| 12:48 |
Exio4 |
as far as i know, those settings are "managed" by the server, and the client just uses the ones that the server sends (or fallbacks to the defaults) |
| 12:49 |
Exio4 |
there isn't any "fly protection" right now |
| 12:49 |
WilliamBundy |
Settings-wise? All of those are constants in the code, which don't appear to be set by anythin.g |
| 12:49 |
Exio4 |
WilliamBundy: those settings in server's minetest.conf .. |
| 12:50 |
WilliamBundy |
# By default, all the settings are commented and not functional. |
| 12:50 |
WilliamBundy |
Does that mean they don't work at all? or aren't used? |
| 12:50 |
Exio4 |
that is the .example |
| 12:50 |
Exio4 |
look at defaultsettings.cpp |
| 12:51 |
|
troller joined #minetest-dev |
| 12:52 |
WilliamBundy |
I don't know what to say. Looks like lazy design/incomplete implementation |
| 12:53 |
WilliamBundy |
DRY violation |
| 12:55 |
Exio4 |
would you use doxygen for generating the configuration example? |
| 12:55 |
Exio4 |
good idea! |
| 12:55 |
WilliamBundy |
Not that, in player.cpp |
| 12:56 |
WilliamBundy |
I'm trying to find where these get set, if not in the constructor |
| 12:56 |
WilliamBundy |
/ Initialize movement settings at default values, so movement can work if the server fails to send them |
| 12:57 |
WilliamBundy |
Wouldn't it be better to have a copy of the default settings on hand and draw them from there? |
| 13:01 |
|
Akien_ joined #minetest-dev |
| 13:08 |
PilzAdam |
WilliamBundy, seems like you dont understand our config system |
| 13:09 |
WilliamBundy |
PilzAdam: Not yet, at least. |
| 13:09 |
WilliamBundy |
More and more by the second. |
| 13:10 |
PilzAdam |
defaultsettings.cpp contains the default values for settings that are needed by the engine; minetest.conf overrides these settings |
| 13:10 |
PilzAdam |
minetest.conf.example has nothing to do with this, this file is only for documentation |
| 13:10 |
WilliamBundy |
PilzAdam, I was looking for how it was all hooked together |
| 13:11 |
PilzAdam |
in case of the player physics the server has the settings and sends it to the client |
| 13:11 |
PilzAdam |
the settings in player.cpp are just fallback defaults in case the server doesnt send them (for some reason) |
| 13:12 |
WilliamBundy |
They're actually set in the client.cpp file under TOCLIENT_MOVEMENT |
| 13:12 |
PilzAdam |
yep |
| 13:13 |
WilliamBundy |
A simple fix? |
| 13:14 |
WilliamBundy |
add the stuff in defaultsettings, add a few lines to Server:SendMovement, and add a few lines to client. |
| 13:14 |
PilzAdam |
basically that |
| 13:14 |
PilzAdam |
but it requires a protocol version bump |
| 13:15 |
PilzAdam |
for now just read it in a try-catch block in the client |
| 13:15 |
PilzAdam |
so it doesnt crash if a new client connects to an old server |
| 13:17 |
WilliamBundy |
what should I catch for? |
| 13:17 |
PilzAdam |
SerializationError |
| 13:18 |
WilliamBundy |
Are clients supposed to be backwards compatible like that? |
| 13:18 |
PilzAdam |
yes |
| 13:20 |
PilzAdam |
btw, we plan to implement node-specific friction, does this conflict with your changes? |
| 13:20 |
WilliamBundy |
It shouldn't. |
| 13:21 |
WilliamBundy |
That was something I was going to look into doing myself. |
| 13:21 |
WilliamBundy |
Depending on how you choose to implement friction, my changes are a base for that. |
| 13:23 |
PilzAdam |
so basically doing this in server side settings would be wrong, we should move it to nodedef from the beginning on |
| 13:25 |
WilliamBundy |
I don't think so. |
| 13:27 |
WilliamBundy |
What happens in the default code is, when the player stops pressing a key, the target speed becomes zero |
| 13:27 |
PilzAdam |
first adding setttings and changing the protocol, and then later moving these settings to nodedef and changing protocol again doesnt seem good to me |
| 13:28 |
WilliamBundy |
Maybe the ground_damping part of it, but air damping might well be system-wide |
| 13:28 |
PilzAdam |
well, air is hardcoded in the core anyway |
| 13:30 |
WilliamBundy |
This changes it so that the target speed becomes a fraction of the previous speed, based on a damping value if no key was pressed. |
| 13:30 |
WilliamBundy |
So, actually, this is all to do with stopping motion, not resisting it. |
| 13:31 |
WilliamBundy |
Friction would have to change the speed while the key is pressed down. |
| 13:31 |
celeron55 |
why would you do that |
| 13:31 |
WilliamBundy |
Target speed under high friction is slower than under low friction |
| 13:32 |
celeron55 |
what does friction have to do with speed |
| 13:32 |
WilliamBundy |
friction is a force that opposes motion |
| 13:32 |
celeron55 |
eh |
| 13:32 |
WilliamBundy |
So, the net force is lower |
| 13:33 |
WilliamBundy |
therefore the max speed is lower |
| 13:33 |
celeron55 |
i guess i won't know what you're actually doing until you have made it |
| 13:33 |
WilliamBundy |
What you probably want is max max speeds mapped to nodedefs |
| 13:33 |
|
Zeitgeist_ joined #minetest-dev |
| 13:33 |
WilliamBundy |
I guess the "basic" version of the damping fix is already a pull request |
| 13:34 |
WilliamBundy |
It's not hooked into the settings, but it may not need to be. |
| 13:34 |
|
Neological joined #minetest-dev |
| 13:35 |
WilliamBundy |
Technically, in a game like this, we aren't implementing friction (for players at least, for entities it might be different), but more like difficulty moving through terrain |
| 13:58 |
celeron55 |
to talk on this high a level, i must mention that if walking in some places is made slower, then walking in some other places must be made faster |
| 13:59 |
celeron55 |
otherwise it averages at too boring |
| 13:59 |
celeron55 |
that's much of personal preference i guess though |
| 14:11 |
WilliamBundy |
The Better Than Wolves mod for minecraft implements this already |
| 14:11 |
WilliamBundy |
Though he added it to add incentive to road building. |
| 14:12 |
WilliamBundy |
In fact I'd call that mod a model for survival-type games |
| 14:12 |
WilliamBundy |
But I imagine FlowerChild would have a fit about that. |
| 14:16 |
WilliamBundy |
He changes it so that walking on stone, cobblestone, gravel, bricks, wood and some other ones is faster |
| 14:17 |
WilliamBundy |
Walking on grass/dirt is normal speed (or slower) |
| 14:17 |
WilliamBundy |
tall grass, snow, sand, leaves and some others are way slower |
| 14:31 |
harrison |
i was conceived at |
| 14:31 |
harrison |
Woodstock |
| 14:31 |
harrison |
in the back of a VW microbus |
| 14:31 |
harrison |
and raised in an anarchist commune |
| 14:31 |
harrison |
by wolves |
| 14:31 |
harrison |
with tiedyed fur |
| 14:33 |
WilliamBundy |
and? |
| 14:35 |
|
Calinou joined #minetest-dev |
| 14:40 |
harrison |
I no longer consider myself an anarchist. |
| 14:41 |
harrison |
Code testers needed for new renderer. Must have desktop i7 or better. |
| 14:43 |
WilliamBundy |
anomie is pretty terrible, but I think I could get used to anarchy. |
| 14:47 |
kaeza |
darkrose, https://dl.dropboxusercontent.com/u/100008207/screenshot_1842826857.jpg |
| 14:48 |
kaeza |
can you see those stripes in the leaves? |
| 14:50 |
sfan5 |
^ z-fighting |
| 14:51 |
darkrose |
yeah, wierd... you've got new style leaves (or whatever it is) turned off too |
| 14:51 |
kaeza |
yup, I don't like it |
| 14:51 |
kaeza |
(+ no smooth lighting |
| 14:51 |
kaeza |
) |
| 14:52 |
darkrose |
yeah, can reproduce, probably removed something I shouldn't have :D |
| 14:53 |
kaeza |
ah well, it ain't so bad after all |
| 14:53 |
kaeza |
maybe I should open an issue/whatever on gitorious? |
| 14:54 |
|
hmmmm joined #minetest-dev |
| 15:00 |
celeron55 |
by the way, how can you use gitorious? for all i've tried to do there, it's worse than anything |
| 15:00 |
celeron55 |
github and bitbucket are bad enough |
| 15:01 |
sfan5 |
github is bad? |
| 15:02 |
darkrose |
my only gripe with gitorious is it's lack of issue tracker... or extremely well hidden one if it is there |
| 15:03 |
celeron55 |
sfan5: well, github and bitbucket are the best out there, so maybe it's a bit unfair to call them bad... but it's not like there's nothing to improve |
| 15:03 |
sfan5 |
gitorious is really hard to use |
| 15:14 |
|
Jordach joined #minetest-dev |
| 15:29 |
|
rubenwardy joined #minetest-dev |
| 15:40 |
|
neko259 joined #minetest-dev |
| 15:47 |
thexyz |
gitlab is good |
| 15:47 |
thexyz |
if you need self-hosted one |
| 16:14 |
troller |
dirt_with_snow remover and weather stuff: https://github.com/proller/minetest/commit/b5a7b15c89bc0a36acec94c8a7454fd6fb5a9958 |
| 16:23 |
Exio4 |
you are doing the same thing that happened with finite_liquids |
| 16:24 |
troller |
happened what? |
| 16:24 |
PilzAdam |
its kinda funny how everyone tells you to develop it in a seperate branch and you simply ignore that |
| 16:25 |
troller |
i'm develop it in a separate branch and want to merge working things to master |
| 16:28 |
troller |
and this ^^ fixes forever staying dirt_with_snow after snow removing |
| 16:29 |
Exio4 |
you should have develop the 'whole weather feature set' and complete the TODO before pushing it to upstream |
| 16:29 |
Exio4 |
that is why branches are here |
| 16:30 |
troller |
and never push it to upstream because all features needs 1-2 years? |
| 16:30 |
troller |
or more |
| 16:32 |
Exio4 |
you are making a change now, a fix the other week |
| 16:32 |
Exio4 |
and a new feature the other |
| 16:36 |
troller |
who write ideal code and never fix it? |
| 16:36 |
Exio4 |
you write unfinished code and push it to upstream |
| 16:36 |
Exio4 |
it is different. |
| 16:37 |
troller |
i write finished small chunks |
| 16:38 |
troller |
some problems can occur after months of testing |
| 16:38 |
PilzAdam |
thats the problem, we dont want you to make small chunks |
| 16:39 |
PilzAdam |
nobody can see what goal you are aiming at, and its hard to judge if these things are good or not if you dont see the context |
| 16:40 |
troller |
and nobody will allow one big chunk |
| 16:40 |
troller |
my goal - interesting dynamic world |
| 16:41 |
PilzAdam |
well, if you think that your patch would never be merged then you probably work on the wrong feature |
| 16:44 |
troller |
nobody here wants big changes |
| 16:45 |
PilzAdam |
what makes you think that? |
| 16:46 |
troller |
experience of merging not big patches |
| 16:57 |
celeron55 |
it's a tough problem really |
| 16:58 |
celeron55 |
or, actually |
| 17:01 |
celeron55 |
well think of it this way: nobody will allow these small broken chunks |
| 17:01 |
celeron55 |
so a big working chunk is better |
| 17:01 |
celeron55 |
also, if you'd rebase your work as often as you currently push it, you woudln't have rebase problems |
| 17:01 |
celeron55 |
wouldn't* |
| 17:02 |
celeron55 |
the only problem that exists is forming some kind of trust between others and your work; i'd recommend working with some of the windows packagers to build test versions of your branch |
| 17:05 |
celeron55 |
we don't want to give you a way to hide a bad end result or bad performance or anything behind small creepy patches |
| 17:06 |
celeron55 |
you don't have a track record of doing good code and the right things; it's just a fact that you need to swallow |
| 17:10 |
hmmmm |
like the random version changes for no other reason than to support something *in the future* |
| 17:10 |
hmmmm |
"useful for debugging", "some mods can use it now" - really..? |
| 17:10 |
hmmmm |
useful for whose debugging |
| 17:11 |
hmmmm |
i don't know, maybe i should start paying closer attention and scrutinizing pull requests closer anymore |
| 17:11 |
hmmmm |
s/closer/more/ |
| 17:13 |
hmmmm |
i'll admit maybe it's my fault all this happened, because i unconsciously thought someone else would point out problems and other weird things with the pull requests |
| 17:14 |
hmmmm |
pull requests, requests to push, whatever |
| 17:16 |
PilzAdam |
I wonder who actually agreed to push the weather stuff |
| 17:23 |
celeron55 |
me i guess, but this isn't going really how i thought it'd go |
| 17:24 |
celeron55 |
this is a problem because *all* of what we have done in the past is just improving what we have had |
| 17:24 |
celeron55 |
weather is something we *haven't* had |
| 17:24 |
celeron55 |
so first of all, nobody wants to even talk about it |
| 17:24 |
celeron55 |
that's not a good ground to do reasons on |
| 17:25 |
celeron55 |
umm... i mean, decisions |
| 17:26 |
celeron55 |
it could be very bad for the long term to say "no more features", altough it's easy for the core devs at the current moment |
| 17:26 |
celeron55 |
that's why everyone should speak up about it |
| 17:30 |
celeron55 |
and ultimately there should be a decision whether it will be merged if it is executed reasonably well |
| 17:31 |
celeron55 |
if there is not, at least i am disappointed (and obviously proller is) |
| 17:34 |
celeron55 |
i could even use not answering something well argued to this issue as a reason for voting towards taking away core dev statuses, because having too many naysayers is definitely poisonous (however, those are tough decisions as it's a very slippy slope between too much badly coded hasty features and too much conservatism) |
| 17:34 |
harrison |
make me a core dev! we can switch to raytraced voxels! |
| 17:35 |
celeron55 |
*inserts harrison into the imaginary "hell no, never" list* |
| 17:35 |
Jordach |
haha |
| 17:36 |
harrison |
i thought you would say that |
| 17:36 |
harrison |
celeron55 what cpu do you dev on? |
| 17:36 |
* sfan5 |
bets on an Intel Celeron |
| 17:36 |
celeron55 |
doesn't sound like anything relevant |
| 17:37 |
harrison |
you are just insecure. i have that effect on some people. this is your house so i will pipe down before being asked. |
| 17:40 |
sullome |
Hello everybody. Is someone working on chat now? |
| 17:43 |
hmmmm |
you know, Celeron G1610s are great bang-for-the-buck processors |
| 17:44 |
hmmmm |
celeron, how much of a problem do you think it'll create if we revert the entire weather thing? |
| 17:45 |
hmmmm |
i really want to get 0.4.8 going like asap but there are too many unfinished things that just don't qualify as "stable" at all |
| 17:46 |
PilzAdam |
hmmmm, your schematic change needs to go in before 0.4.8 since it changes the API |
| 17:46 |
PilzAdam |
and we dont want to change the API of stable releases |
| 17:46 |
hmmmm |
pilzadam, i'm still trying to figure out if it's a good idea to change it or not |
| 17:46 |
PilzAdam |
sullome, what do you mean "working on chat"? |
| 17:46 |
hmmmm |
but the thing is, once we get 0.4.8 out, we can start doing the faster release model and people won't rely on upstream as much |
| 17:46 |
hmmmm |
as it'd be easier to break things without ill consequence |
| 17:46 |
celeron55 |
it can't be reverted completely in the strict meaning of that word (we're not dropping support for reading map version 26 as 25), but otherwise it wouldn't be too much of a problem i guess |
| 17:46 |
celeron55 |
a political problem it could be though |
| 17:47 |
hmmmm |
technically speaking, if things break in between versions then it's their fault for using something completely unstable |
| 17:47 |
hmmmm |
so we'd have much more freedom in that regard |
| 17:47 |
hmmmm |
and from now on |
| 17:47 |
hmmmm |
big features NEED to be fully developed into something useful in their own branch BEFORE pushing to upstream |
| 17:47 |
celeron55 |
that wouldn't make any sense because people have run worlds for a long time with possibly some version 26 stuff |
| 17:48 |
celeron55 |
we can't require those to revert to weeks old backups |
| 17:48 |
hmmmm |
like with voxelmanip and schematics and crap like that... those were all done in one go, and it worked out relatively painless (until people wanted me to tack shit on top of the schematics anyway) |
| 17:48 |
celeron55 |
and yes, this serves as a proof that big features should be developed to useful stage between going upstream |
| 17:49 |
celeron55 |
before* |
| 17:50 |
hmmmm |
come 0.4.8, can we add an explicit disclaimer that we aren't responsible for screwups that happen as a result of using unstable versions? the freedom to change things between versions is very important |
| 17:51 |
hmmmm |
so then if something didn't work out like the weather, we don't require hacks for things that never even officially made it in the first place |
| 17:51 |
hmmmm |
and schematic api as well |
| 17:52 |
celeron55 |
it would create a problem |
| 17:52 |
celeron55 |
the problem that the code would get way less testing |
| 17:52 |
sullome |
PilzAdam, (maybe my bad english) |
| 17:52 |
sullome |
Now: client type message, and then it show in chat. register_on_chat_send() in LUA don't overwrite default message processing, it just do something else. (Maybe I'm not right, I don't know.) |
| 17:52 |
sullome |
And I think, that this is bad. If I want to do (?) a local chat on my server, I can't do it by mods! If there is a way to disable default message processing, it would be better. |
| 17:52 |
sullome |
(Again, sorry for bad english) |
| 17:52 |
hmmmm |
(sorry for the bad lag) |
| 17:52 |
celeron55 |
currently we have community-run servers that run git head that make the code go through very real-world testing |
| 17:53 |
celeron55 |
and regular unstable builds that do the same thing |
| 17:54 |
PilzAdam |
sullome, the Lua function can override the default processing, but it cant disable that the client who has send it doesnt put it into his chat |
| 17:54 |
celeron55 |
it's not reasonable to move to a different development model unless some kind of a flag is added to worlds that make minetest ask users whether they want to potentially break it infinitely and that they require backups; or something similar so that there's less chance that people break stuff accidentally |
| 17:54 |
hmmmm |
like in FreeBSD, *practically nobody but developers* uses -CURRENT in the real world at all, and yet it somehow has a reputation of almost completely bugfree upon release |
| 17:55 |
hmmmm |
but then again i guess that's more doable because they have way more developers |
| 17:55 |
celeron55 |
they also don't advertise features in the midway of development and don't have end-user application developers (modders to us) that immediately use every kernel and system library feature when they can get their hands on them |
| 17:56 |
celeron55 |
there are many reasons why you're talking about a relatively large change to our culture |
| 17:57 |
celeron55 |
a workaround could be to switch development to a new real-unstable branch if that is desired |
| 17:57 |
celeron55 |
and then put enough bells and horns in the way of people getting it |
| 17:57 |
hmmmm |
well i think that's stupid because it merely centralizes instability instead of people just developing features in their own branches |
| 17:57 |
celeron55 |
it's been actually done before in MT's history |
| 17:57 |
celeron55 |
the need for it tends to be periodical |
| 17:57 |
sullome |
PilzAdam, Lua function can? Err... please, tell me how. I made a simple mod for testing... |
| 17:57 |
sullome |
minetest.register_on_chat_message(function(name, message) |
| 17:57 |
sullome |
minetest.chat_send_all(name .. " send a message!") |
| 17:57 |
sullome |
end) |
| 17:57 |
sullome |
And it's not work. Default processing still.... runs (?). |
| 17:58 |
celeron55 |
sullome: don't talk about modding in here |
| 17:58 |
hmmmm |
sullome, sounds like a modding problem, should probably discuss it in #minetest for better responses |
| 17:58 |
celeron55 |
go to #minetest or #minetest-mods or something |
| 17:58 |
sfan5 |
sullome: try adding "return true" |
| 17:58 |
sullome |
Sorry |
| 17:58 |
sullome |
Thanks |
| 17:58 |
|
sullome left #minetest-dev |
| 18:00 |
hmmmm |
but anyway |
| 18:00 |
hmmmm |
having a super unstable branch, i suppose, would be needed if more than one person is working on a huge new feature |
| 18:00 |
hmmmm |
we should write all of this procedure down actually |
| 18:01 |
hmmmm |
one person working on a new feature -> personal branch |
| 18:01 |
hmmmm |
multiple people working on a really huge new feature -> minetest repo branch |
| 18:04 |
celeron55 |
when has the second one even last happened |
| 18:05 |
hmmmm |
i guess lua's introduction? before me, of course |
| 18:05 |
hmmmm |
and i'm thinking we'd need to use it again for 0.5.x |
| 18:09 |
celeron55 |
it looks like a "next" branch was used when 0.4.0 was being made |
| 18:09 |
celeron55 |
when moving from 0.4.dev-* to that, i mean |
| 18:12 |
celeron55 |
there's really nothing like that going on currently so whatever, it shouldn't really be needed... except if weather is going to be developed as a non-personal thing |
| 18:14 |
hmmmm |
no, no, weather is a personal thing definitely. i'm saying this next branch is what we'd use for 0.5.x.. you know, *that*. |
| 18:14 |
celeron55 |
yeah i get that |
| 18:18 |
hmmmm |
so, er, i need more feedback on the schematic version change before i do it, because this *will* break things for people and it's important that it's the right decision |
| 18:19 |
hmmmm |
the thread on the forums didn't really work out as you can tell |
| 18:19 |
hmmmm |
i'd also have to use a modified version of readnode to read raw schematic data, one that sets param1 to 0xFF by default instead of 0 but i fear that this is inconsistent |
| 18:21 |
celeron55 |
i don't really want to get myself involved with the schematic thing; you should be able to handle it by yourself |
| 18:21 |
hmmmm |
the specifics of what would need to be changed are in that thread, https://forum.minetest.net/viewtopic.php?id=6808 so seriously, any feedback? i really wonder if this is worth it. i've also learned my lesson that tacking on ugly features for reverse compatibility when it's still somewhat early is a bad idea. |
| 18:21 |
celeron55 |
it's probably easier to do it in a more compatible way than you think though |
| 18:22 |
|
iqualfragile_ joined #minetest-dev |
| 18:22 |
hmmmm |
i know how to do it in a more compatible way, just fix up the values they give for the schematics. but that adds cruft |
| 18:22 |
celeron55 |
well if you're determined to stick with it, commit it already |
| 18:22 |
celeron55 |
every minute makes it worse |
| 18:23 |
celeron55 |
but breaking compatibility without valid enough reason doesn't make people happy anyway |
| 18:24 |
hmmmm |
if we keep adding workarounds for every change, we'll end up like windows |
| 18:24 |
celeron55 |
you can add a wrapper to builtin/deprecated.lua with a date in comments when it should be removed |
| 18:24 |
celeron55 |
and loud error loggings |
| 18:25 |
hmmmm |
i could, but the modders who wrote things using schematics already are active and can change their mods in no time at all |
| 18:25 |
celeron55 |
... |
| 18:26 |
celeron55 |
just do it god damnit |
| 18:26 |
celeron55 |
no need to be so pedantic |
| 18:26 |
hmmmm |
then if it doesn't work for an end user, they can say "oh, did you update to 0.4.8? you can't use the unstable version" |
| 18:26 |
hmmmm |
what? this is important |
| 18:26 |
hmmmm |
alright w/e. |
| 18:27 |
celeron55 |
my opinion will be, without change, to add it for a period to builtin/deprecated.lua and announce the change clearly on the forum; but it's still up to you what you do |
| 18:27 |
celeron55 |
actually, if it's just an unreleased modding api thing, nobody will care |
| 18:27 |
celeron55 |
it's like three magnitudes less important than file formats |
| 18:28 |
hmmmm |
that's great then |
| 18:28 |
PilzAdam |
hmmmm, a question about the new code: if I have 1 node (lets call it "a") in the schematic, but set the probability for it to 0, will this node be checked when you place the schematic, i.e. will it print "'a' not defined" if its missing? |
| 18:29 |
celeron55 |
as long as nobody fucks up file formats, there won't be much problems |
| 18:29 |
hmmmm |
pilzadam, yes it will |
| 18:29 |
PilzAdam |
thats not good |
| 18:29 |
hmmmm |
if you're wondering about ignore nodes, they're changed to air. |
| 18:29 |
hmmmm |
if you read the code you'd know that^ |
| 18:29 |
hmmmm |
air with 0 probability |
| 18:30 |
PilzAdam |
so I cant create schematics for minetest_game in a world that has a different node than "air" |
| 18:31 |
PilzAdam |
even if I change the probability of that airlike node to 0 |
| 18:31 |
hmmmm |
there will always be air, no matter what. |
| 18:31 |
PilzAdam |
what? |
| 18:32 |
PilzAdam |
imagine a custom game, e.g. a spacegame that has vacuumin instead of air |
| 18:32 |
hmmmm |
ignore and air are always registered so i don't see any problem |
| 18:32 |
hmmmm |
what's your point exactly? i don't get it |
| 18:32 |
celeron55 |
PilzAdam: well, even a space game will have air by the default "empty" node; it's just a naming thing |
| 18:33 |
PilzAdam |
if I create a schematic in that game and change all probabilities of the vacuum node to 0, then it would still complain if I want to place that schematic in minetest_game, since vacuum is not define there |
| 18:33 |
PilzAdam |
wouldnt it? |
| 18:34 |
celeron55 |
(the empty node being "air" is inherited directly from the very first versions of minetest) |
| 18:34 |
hmmmm |
no not at all |
| 18:34 |
hmmmm |
there is always a node titled "air", in every version |
| 18:34 |
hmmmm |
any game rather |
| 18:34 |
hmmmm |
it's builtin |
| 18:34 |
hmmmm |
there is literally no problem here |
| 18:34 |
PilzAdam |
I guess I suck at explaining :-) |
| 18:35 |
PilzAdam |
let me rephrase that: what do you write to the file if the probability of a node is 0? |
| 18:35 |
hmmmm |
whatever the node is that was at that position |
| 18:35 |
PilzAdam |
and it also checks the nodename in resolveNodenames(), even if you never actually place it? |
| 18:35 |
hmmmm |
that's correct |
| 18:36 |
PilzAdam |
I dont like that |
| 18:36 |
hmmmm |
there are things you'll never like |
| 18:36 |
hmmmm |
can you propose a clean solution to this? |
| 18:36 |
|
jin_xi joined #minetest-dev |
| 18:36 |
hmmmm |
er |
| 18:36 |
PilzAdam |
the previous way of writing ignore to the file instead, and then simply place air at ignores position was better |
| 18:37 |
hmmmm |
i'll just change it to air if the probability is 0 |
| 18:37 |
PilzAdam |
yea, air works too |
| 18:37 |
celeron55 |
i guess a more current explanation of the issue would be if someone builds something at the bottom of the ocean, creates a schematic and expects it to be placeable without water on the beach? |
| 18:37 |
hmmmm |
now there's no need for writing ignore in the schematic file ever, and we don't have to do an annoying check to see if the node was defined |
| 18:37 |
celeron55 |
(i don't understand anything about this though) |
| 18:37 |
PilzAdam |
celeron55, not really |
| 18:38 |
PilzAdam |
celeron55, it is possible to set the probabilty of each water node to 0, thus it will never place it |
| 18:38 |
PilzAdam |
but the problem is that it will still check if water is defined when placing it |
| 18:38 |
PilzAdam |
so you cant place it in a game that has no water, even if it never places the water |
| 18:39 |
hmmmm |
celeron, the "0 probability node" is equivalent to having some image with some (or many) pixels with an alpha of 0 |
| 18:39 |
celeron55 |
sounds like a problem that has a solution |
| 18:39 |
hmmmm |
for overlays like |
| 18:39 |
PilzAdam |
hmmmm, if you write air to the file, then it will replace the node at that position when placing, right? |
| 18:39 |
celeron55 |
my take on this is "just fix it, it's not like you can't" |
| 18:39 |
hmmmm |
there really is no problem after this, though |
| 18:40 |
hmmmm |
pilzadam, wha? |
| 18:40 |
hmmmm |
okay let's go through this again |
| 18:40 |
hmmmm |
we have a node that's marked as having 0 probability |
| 18:40 |
hmmmm |
to avoid the error you're talking about (which isn't really a problem because now you have replacement lists), we also change the node name at that position to air |
| 18:41 |
PilzAdam |
when placing that schematic, will it place the air node or simply skip the position? |
| 18:41 |
hmmmm |
so when it gets loaded and the names are resolved, the nodes that are never placed are marked as air but that's just for the sake of shutting the node resolving up |
| 18:41 |
hmmmm |
it skips the position! |
| 18:41 |
hmmmm |
that's the point! |
| 18:41 |
PilzAdam |
ok, good |
| 18:41 |
hmmmm |
if you wanted it to write an air node instead, you'd write a goddamn air node |
| 18:47 |
sfan5 |
celeron55: could you explain to me what packet "4f 45 74 03 00 01 00 03 ff dd 01 00 29 39 78 00 01 19 40" is supposed to be? |
| 18:48 |
sfan5 |
I get that it is a reliable packet from peer id 01, but I don't get what is inside the TYPE_ORIGINAL packet |
| 19:07 |
celeron55 |
it looks like a TOCLIENT_TIME_OF_DAY packet |
| 19:08 |
celeron55 |
it says the current time is 14712 and time speed is 72 |
| 19:09 |
celeron55 |
(00 29 = 0x29, just refer to clientserver.h from there on) |
| 19:21 |
kahrl |
celeron55, that first thing http://paste.dy.fi/v6d pointed to is strange |
| 19:22 |
kahrl |
there is an unsigned int bytes_read but the code checks if (bytes_read < 0)?! |
| 19:22 |
celeron55 |
oh don't care about strange things if they are strange; my GCC is some random broken version from a year ago :P |
| 19:22 |
kahrl |
no, the warning itself is right, it's the code that is strange :P |
| 19:23 |
celeron55 |
it sometimes gives warnings about things that make absolutely no sense, like a warning about indexing above boundaries in some place where there are no indexing found in a whole file 8) |
| 19:23 |
celeron55 |
oh, well that's indeed strange |
| 19:24 |
kahrl |
(the warning comes from the fact that irrlicht's io::IReadFile::read only returns nonnegative values but uses a signed type) |
| 19:25 |
kahrl |
er, getSize()* but it's the same with read() |
| 19:27 |
kahrl |
actually, CReadFile::getSize() can return negative values if the file is larger than 2GB. Not sure about memory files read from a zip, probably the same |
| 19:28 |
hmmmm |
more like Crap::getBrokenSize() |
| 19:29 |
hmmmm |
but then again, IIRC windows can't have zip files larger than 4gb |
| 19:30 |
hmmmm |
anyway i'm going to commit this https://github.com/kwolekr/minetest/commit/f12078263dd56cfbfa59a140d37f7f2d14fa2dde |
| 19:31 |
hmmmm |
sorry, https://github.com/kwolekr/minetest/commit/b592b1b8f845e634f36c4cd5382893a54b0688e5 |
| 19:32 |
PilzAdam |
there is no other place in lua-api.txt where we have hex numbers |
| 19:32 |
PilzAdam |
why dont you simply write 255? |
| 19:32 |
hmmmm |
because i used 0xFF in the core and forgot, i guess |
| 19:33 |
hmmmm |
anyway, look! https://github.com/kwolekr/minetest/commit/b592b1b8f845e634f36c4cd5382893a54b0688e5#L4R838 happy? |
| 19:35 |
kahrl |
we should replace all numbers in lua_api.txt with hex |
| 19:35 |
kahrl |
^ location = eg. {type="player", name="celeron0x37"} |
| 19:35 |
hmmmm |
you know, i always wondered why his number is 55. it's kinda arbitrary |
| 19:36 |
hmmmm |
why do people append numbers to their nicks anyway. |
| 19:36 |
PilzAdam |
I guess celeronFiftyFive was too long |
| 19:37 |
jin_xi |
55 stands for ee for shizzle |
| 19:38 |
kahrl |
Intel Celeron Registered Trademark LV, Esq. |
| 19:38 |
hmmmm |
i have an interview at Intel :)) |
| 19:40 |
kahrl |
go make the processors faster so we don't have to optimize minetest ;) |
| 19:41 |
kahrl |
we could finally port it to python |
| 19:42 |
jin_xi |
wow: Over the past twelve months, 98 developers contributed new code to Minetest. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh. |
| 19:46 |
Exio4 |
kahrl: haha |
| 20:04 |
hmmmm |
ugh |
| 20:04 |
hmmmm |
proller i sware to god |
| 20:04 |
troller |
? |
| 20:05 |
hmmmm |
your changes to emerge.cpp makes a possible race condition |
| 20:05 |
hmmmm |
you need to modify the environment inside of an environment lock |
| 20:07 |
troller |
how to fix it? |
| 20:08 |
hmmmm |
don't bother, i'm doing it right now myself |
| 20:08 |
troller |
thank you |
| 20:09 |
|
drizz left #minetest-dev |
| 20:11 |
hmmmm |
troller, getHeat and getHumidity modify the block as well as returns it |
| 20:11 |
hmmmm |
don't you think it should be called getHeatAndUpdate |
| 20:12 |
troller |
maybe yes, its from first version - they have no cache |
| 20:12 |
hmmmm |
what's the point of heat_time and humidity_time? |
| 20:13 |
troller |
cache time |
| 20:13 |
hmmmm |
why are they separate i mean |
| 20:13 |
troller |
hm.. |
| 20:13 |
hmmmm |
shouldn't it be like weather_last_updated |
| 20:13 |
troller |
but it need to update heat from humidity and humidity from heat |
| 20:13 |
hmmmm |
when would you ever update them separately? |
| 20:14 |
Exio4 |
unfinished code ^ |
| 20:15 |
troller |
hmmmm, its new idea to join them |
| 20:16 |
hmmmm |
whatever, i'll leave it up to you to do that |
| 20:16 |
troller |
Exio4, finished code not exists |
| 20:16 |
Exio4 |
what? |
| 20:16 |
troller |
hmmmm, ok |
| 20:24 |
hmmmm |
the only thing you use SeverEnvironment for in getHeat/getHumidity is the game time |
| 20:24 |
hmmmm |
why don't you just pass the game time as a parameter instead? |
| 20:24 |
Tesseract |
kahrl: There wasn't anything wrong with it, you just mentioned that you would like to have bind_address = 0.0.0.0, :: ... and not have ipv6_server. But that would take a lot mort time to implement. |
| 20:26 |
Exio4 |
|
| 20:26 |
Exio4 |
er |
| 20:26 |
Exio4 |
fail |
| 20:28 |
* troller |
testing server with d = sqlite3_exec(m_database, "PRAGMA synchronous = NORMAL", NULL, NULL, NULL); |
| 20:29 |
troller |
hmmmm, game time as a parameter to getHeat/getHumidity ?? |
| 20:29 |
Exio4 |
to the class that contains getHEat/Humidity |
| 20:29 |
Exio4 |
Heat* |
| 20:29 |
Exio4 |
(i guess) |
| 20:29 |
hmmmm |
it's just not correct for a member of Map to deal with the environment, it's supposed to be separate from that |
| 20:30 |
hmmmm |
the environment has a map |
| 20:31 |
hmmmm |
oh, by the way, |
| 20:31 |
hmmmm |
map->getHeat(m_server->m_env, MAP_BLOCKSIZE*i->first ,i->second); is wrong |
| 20:31 |
hmmmm |
that second parameter should be getBlockPos(i->first) |
| 20:32 |
hmmmm |
it'll be incorrect for negative positions |
| 20:32 |
Exio4 |
can anyone tell me why the got merged at first? |
| 20:32 |
Exio4 |
it got* |
| 20:32 |
hmmmm |
it was a really huge patch and nobody actually went through each thing and scrutinized it |
| 20:33 |
Exio4 |
the only who said "yes" was c55 and he stated that he didn't try, yet PilzAdam, (sfan5 iirc), and some other people complained a bit about it |
| 20:33 |
Exio4 |
s/try/try it/ |
| 20:33 |
hmmmm |
i complained about it too for a more fundamental reason, that is, it's more or less something for a mod to do |
| 20:34 |
hmmmm |
there are definite plans for client side lua in the future, so adding something as static and specific as this is pretty ugly |
| 20:34 |
Exio4 |
well, lets see who didn't complained, the list then may be shorter ;) |
| 20:35 |
troller |
(f32)env->getGameTime() * env->getTimeOfDaySpeed() , env->getTimeOfDayF(), -- pass all as params??? |
| 20:36 |
hmmmm |
troller, i'm doing it right now |
| 20:36 |
hmmmm |
i don't see where you use those however |
| 20:36 |
troller |
getHeat |
| 20:37 |
hmmmm |
oh |
| 20:37 |
hmmmm |
wow |
| 20:37 |
hmmmm |
i completely missed those |
| 20:38 |
hmmmm |
give me some time to think |
| 20:39 |
hmmmm |
you know, in this case, doesn't this belong in ServerEnvironment? |
| 20:39 |
hmmmm |
the heat and humidity have nothing to do with the map itself |
| 20:39 |
hmmmm |
but rather the environment in which the map resides |
| 20:40 |
hmmmm |
i'm going to move ServerMap::getHeat/Humidity to ServerEnvironment, because it makes more sense |
| 20:41 |
troller |
whats with Map::getHeat(v3s16 p) ? |
| 20:42 |
hmmmm |
those are fine, since they only query data from the map |
| 20:42 |
troller |
its now only for debug on client, but.. |
| 20:42 |
troller |
ok |
| 20:42 |
hmmmm |
those really could be called getHeat and getHumidity |
| 20:42 |
hmmmm |
since they do nothing more than retrieve the data |
| 21:19 |
|
kaeza joined #minetest-dev |
| 22:10 |
|
smoke_fumus joined #minetest-dev |
| 22:39 |
kahrl |
some include file statistics: http://paste.dy.fi/n8Q |
| 22:39 |
kahrl |
this is the number of headers included in each source file, including deep includes, using the code in my scriptapicleanup branch |
| 22:40 |
kahrl |
(it doesn't count headers of external libraries) |
| 23:37 |
kahrl |
who would have thought? adjacency sets are faster than an adjacency matrix: http://paste.dy.fi/n9V |
| 23:53 |
kahrl |
I wonder if there's any way to make server.h less fat |
| 23:53 |
kahrl |
all the lua api source files need it |
| 23:54 |
kahrl |
stuff like ServerThread can be moved to server.cpp |
| 23:54 |
kahrl |
should I replace most of the class-type fields in Server with pointers? (so that forward declarations can be used) |
| 23:56 |
Exio4 |
will it help for the cases that when you change a .h you need to recompile 95% of the source code, other time? |
| 23:57 |
Exio4 |
;P |
| 23:57 |
kahrl |
hopefully |
