Time Nick Message 17:55 shaft I don't understand why my PR was closed and seemingly no one discusses it anymore. The mod is clearly not working as intended with the current release of MT 5.8. https://github.com/minetest-mods/ts_furniture/pull/20 17:59 grorp shaft: regarding that PR, my response didn't mean that there is no bug, but that the bug might be in MTG instead of the engine 18:00 shaft It requires default. It's a mod for MTG 18:01 grorp wrong. default is not a mod for MTG, but a mod from MTG / part of MTG. 18:02 grorp ah lol just misunderstood 18:03 shaft How am I supposed to test where the bug is from? Mineclone doesn't have default and I'm not sure which games have default and nothing else from MTG 18:06 grorp I came to this conclusion because the bug didn't go away when using old engine versions, but it did go away when using old MTG versions 18:07 shaft Why didn't you say so earlier. Thank you. That sounds very conclusive. 18:09 grorp sorry, I thought it was obvious from my comment. I should have been more explicit. 18:10 MTDiscord grorp, shaft: it's a feature :P, see https://github.com/minetest/minetest_game/blob/master/mods/player_api/init.lua - different animations get different eye heights in newer MTG versions, so adjusting it yourself should be unnecessary 18:10 MTDiscord (as in, you may not adjust it yourself, otherwise you're applying it twice) 18:11 shaft And other games don't? 18:11 MTDiscord it depends on the game 18:11 MTDiscord i don't know how other games manage eye height / eye offsets 18:11 MTDiscord many are probably fine leaving it entirely static 18:12 shaft How is anyone supposed to make mods work with multiple games? 18:12 shaft I don't like this philosophy tbh 18:12 MTDiscord making mods work with multiple games is inherently a nontrivial problem 18:12 MTDiscord games can be arbitrarily different, not everything will be a MTG-esque mod soup 18:13 shaft Would someone reopen my issue and merge my fix if I check for MTG and version number? 18:14 MTDiscord just account for eye height 18:14 shaft MTG version > 5.5.0 18:14 MTDiscord no need for a version check 18:14 MTDiscord the code is currently assuming a certain eye height 18:14 MTDiscord newer MTG versions break this assumption by having variable eye height 18:15 MTDiscord simply take the difference between the expected and actual eye height and add it to the offset 18:19 MTDiscord commented (the same) on the issue 18:22 shaft Games other than MTG don't necessarily have player_api either 18:23 MTDiscord so? 18:23 MTDiscord use player_api if present, otherwise don't 18:23 MTDiscord games other than MTG needn't have a player model 18:23 MTDiscord or the animation you want 18:23 MTDiscord they may map frame ranges entirely differently 18:24 MTDiscord ts_furniture depends on default tho 18:24 MTDiscord so it seems to be a mod tailored for MTG (default is the "core" MTG mod) 18:24 MTDiscord it should explicitly depend on player_api as well though 18:25 MTDiscord imma open the feature request for randomizing load order 18:26 MTDiscord Generally if you want your mod to work with every game, you are going to have to actually add support for every game. There isn't necessarily a point you will reach where you've covered every possible game. 18:26 MTDiscord it's pretty much trivial to implement, just need to make sure people are fine with it 18:33 shaft I'm sorry to have you spoonfeeding me but how do I get the world eyeheight and eyeheight of the model? 18:38 MTDiscord There is no world eyeheight. There is the eyeheight object property of the player. You can get that via player:get_properties().eye_height. 18:55 shaft I understood now. 18:58 jonadab I still think default: has way too many things in it. It should have, like, air and stone, and everything else should be from other modules (even if they're ones included in MTG by default). 18:59 jonadab Though it's far too late to change that now; it would invalidate too many add-on modules. 19:02 Krock don't depend on default if you don't want it 19:03 ireallyhateirc yeah, its only value is supporting mods that were written for it back when it was official 19:03 ireallyhateirc most features from MTG can be redone in 1 month if you're motivated 19:03 ireallyhateirc because it's mostly node definitions and biome definitions 19:05 shaft How do I fiddle the changes upstream back into my PR repository? There is probably a super easy solution I don't know about. 19:25 jonadab Sure. 19:34 shaft Okay but I don't know how, so I did it the stupid way now. Is someone going to reopen my PR or should I make a new one? 20:21 dumpster_lord I encountered a weird bug where vector.equals returns false for vectors that look equal 20:22 dumpster_lord I have this code: https://codeberg.org/lord_of_the_dumpster/perfect_city/src/commit/e96930bc92e1c1050e9500ef9ee90065f2105809/mods/pcity_mapgen/roads_layout.lua#L234 20:22 dumpster_lord and this condition: https://codeberg.org/lord_of_the_dumpster/perfect_city/src/commit/e96930bc92e1c1050e9500ef9ee90065f2105809/mods/pcity_mapgen/roads_layout.lua#L241 20:25 dumpster_lord and here is the output from console: https://paste.debian.net/1316214/ 20:27 dumpster_lord asking here before it turns out I'm doing something wrong 20:30 grorp does comparing the components yourself give the same result? 20:31 dumpster_lord I'll check, gimmie a sec 20:34 dumpster_lord I used this: if vec.x ~= vec2.x or vec.z ~= vec2.z or vec.y ~= vec2.y then 20:34 dumpster_lord and still the same effect 20:36 dumpster_lord The code in builtin/common is trivial: https://github.com/minetest/minetest/blob/1aba7f1fde101819f15ee2c28d52096605ce5253/builtin/common/vector.lua#L72 20:36 dumpster_lord Possibly something buggy hiding in the metatable stuff? 20:37 dumpster_lord All vectors are made with vector.new 20:45 grorp unlikely. sounds more like floating point imprecision. does adding a small tolerance give the same result? 20:47 dumpster_lord I'll try forcibly running math.floor on them 20:48 MTDiscord It definitely looks like a floating point issue. But dump is supposed to write numbers with the maximal precision. 20:51 dumpster_lord doing vector.floor helped 20:51 dumpster_lord I'm puzzled why dump() didn't show it though 20:53 dumpster_lord So I guess I should stop trusting console prints and remove all floats from my code 20:54 sfan5 bad news: lua only has float numbers 20:54 dumpster_lord Is dump() provided by lua or minetest? 20:55 dumpster_lord can we somehow make it at least print the numbers are different? 20:57 grorp by minetest 20:57 dumpster_lord So I guess I can start an issue for this on github? 21:02 MTDiscord dumpster_lord, grorp: basic_dump in builtin/common/misc_utils.lua seems to tostring numbers, which loses precision. it should use something like ("%.17g"):format(num) instead. 21:03 MTDiscord (though that will result in much more verbose output for some cases..) 21:04 dumpster_lord by "it" you mean dump() code or my debug prints? 21:04 MTDiscord dump() code. your debug prints too. 21:04 MTDiscord print tostrings behind the scenes. tostring on numbers does not print enough significant digits; it rounds. 21:05 MTDiscord "remove all floats from code" is not a solution anywhere. yes, floats are imprecise. no, they aren't always imprecise. you need to know when they are how imprecise (very roughly), but also when they are precise. for example using floats as integers is precise in certain (relatively large) ranges. 21:06 dumpster_lord I'll write my own vector.sloppy_equals for that 21:14 MTDiscord ideally don't "pollute" the vector table 21:15 MTDiscord I am looking at a broken set_eye_offset problem. Would appgurueu be among us? 21:25 MTDiscord sure, what's the matter? 21:28 MTDiscord I'm an idiot, I should have connected Lars == Lars. I tried to repro the issue and found skinsdb and 3d_armor lack a certain line, you were the last to try and repro in ts_furniture. I had a question, which is now obsolete, I found the solution. Looks like I need to bug both skinsdb and 3d_armor to add that line to their register_model call 21:30 MTDiscord I suppose they leave eye height static when registering models, while player_api has it dynamic by default? 21:30 MTDiscord You proposed in ts_furniture https://github.com/minetest-mods/ts_furniture/pull/20 adding the eye offset to the affected mods. Would it not be smarter to add the definiton to the offending mods skinsdb and 3d_armor? 21:31 MTDiscord No, its about the model definiton 21:31 MTDiscord Last comment in https://gitea.your-land.de/your-land/bugtracker/issues/6760 21:31 MTDiscord yes, i'm aware 21:32 MTDiscord note that player_api registers eye_height overrides for the animations while skinsdb does not 21:32 MTDiscord specifically for sit and lay 21:33 MTDiscord beds and boats have the same issue, its not about emote or ts_furniture 21:33 MTDiscord yes 21:33 MTDiscord so the problem with ts_furniture (and beds and boats) is, it has code that sets an eye offset to lower the effective eye height. but this may not be done now that player_api already does that based on the animation. 21:34 MTDiscord now what further complicates the issue is that 3d_armor and skinsdb override the model def, undoing these per-animation eye height overrides 21:35 MTDiscord If I add the line regarding eye_height to player_api.register_model defintion, at least boats, emote and beds work as expected. 21:35 MTDiscord yes 21:35 MTDiscord one way to fix everything for the newest versions of player_api would be: give 3d_armor and skinsdb these missing overrides (and the eye_height field), remove the set_eye_offset from ts_furniture 21:36 MTDiscord Ok, so there is already a solution planned and I did a lot of stuff otehr had already done : D Meh 😛 21:36 MTDiscord idk whether i would call this "planned" :P 21:36 MTDiscord i'm not maintaining 3d_armor or skinsdb or ts_furniture, just saying what one way to fix it would be 21:37 MTDiscord (if you want to support older versions of player_api too, you need to be a bit cleverer, because then you may still need the set_eye_offset. you could do something like a player_api version check by feature, or you could just get the eye height and force the eye height you expect via an eye offset.) 21:39 MTDiscord I see, that's where the problems start. Anyways, that's the decision of the maintainers then 21:39 MTDiscord let me comment on your bugtracker... 21:40 MTDiscord how do you manage mods? do you run forks / patchsets? 21:42 MTDiscord We mirror upstream, then fork them, then PR changes in master to our stable branch 21:43 MTDiscord All I need to know is that I'm not sitting on someting that needs to go upstream 21:44 MTDiscord When upstream deals with it and knows what's up, I'm good, duty done. They will fix in their due time, hopefully until we deliver the next modset update 21:47 MTDiscord commented: https://gitea.your-land.de/your-land/bugtracker/issues/6760#issuecomment-81251 21:48 MTDiscord Thanks 🙂 21:48 MTDiscord np 21:49 shaft https://github.com/minetest-mods/ts_furniture/pull/21 if anyone wants to test