Minetest logo

IRC log for #minetest-dev, 2014-04-12

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:12 BlockMen seolfor, look in your start menu for
00:12 BlockMen else look in the installation directory of msvc for vcvarsall.bat
00:13 seolfor i got it already... i hate compileing in windowns
00:13 seolfor im trying to build it more then 6h >.>
00:14 seolfor right now i got problems with zlib
00:22 proller joined #minetest-dev
00:31 BlockMen left #minetest-dev
00:43 daspork joined #minetest-dev
01:57 Exio4 lets rewrite half of minetest using an FPS engine
01:58 Exio4 with hell lots of client-side movement prediction :D
02:01 Exio4 but shouldn't it be using things like what a FPS would use for the movement prediction? if it is a "so bad" problem
03:13 Eater4 joined #minetest-dev
04:13 robmyers joined #minetest-dev
05:42 werwerwer joined #minetest-dev
05:45 seolfor joined #minetest-dev
05:46 seolfor good morning everybody
05:48 seolfor after half of day I spend on building / finding necessary dependencies i come to great solution
05:49 seolfor can somebody send me pack of all precompiled dpendencies for minetest ? ^_^
05:52 seolfor is there enybody ?
06:51 PenguinDad joined #minetest-dev
07:14 deltib joined #minetest-dev
07:30 ImQ009 joined #minetest-dev
07:48 darkrose joined #minetest-dev
07:52 restcoser joined #minetest-dev
08:05 diemartin joined #minetest-dev
08:31 celeron55 http://gousios.gr/blog/Exploration-pull-requests/
09:03 tomreyn joined #minetest-dev
09:25 celeron55 has anyone been testing this? https://github.com/minetest/minetest/pull/1217
09:29 BlockMen joined #minetest-dev
09:31 BlockMen concerning #1114, i guess old servers must be handled somehow. maybe using hardcoded frames if none are send to client?
09:31 ShadowBot https://github.com/minetest/minetest/issues/1114 -- Add third person view by BlockMen
09:35 celeron55 yes, hardcoded frames are fine
09:35 celeron55 also, why are integer values transferred in the F1000 format over network?
09:36 celeron55 it should use U16, S16, U32 or S32
09:38 rdococ joined #minetest-dev
09:41 BlockMen so writeU16 for each key frame instead of sending vector?
09:41 celeron55 there is writeV2S16 and writeV2S32 for integer vectors
09:41 celeron55 if you want that
09:42 * sfan5 still wants opinions on #1210
09:42 ShadowBot https://github.com/minetest/minetest/issues/1210 -- Add redis database backend by sfan5
09:42 BlockMen ah, ok
09:46 celeron55 sfan5: i guess it can be added, but it's the first one that will go if some internal interfaces are to be changed and you aren't around to modify it
09:47 sfan5 if you are doing that next week I'll not be there
09:47 sfan5 the code should also be fairly easy to understand
09:48 sfan5 also why is there so much code duplicated in loadBlock?
09:48 celeron55 maybe we should add a contrib/ directory to mark what things the full core team is not committed to supporting but are there because somebody volunteers to maintain them
09:48 celeron55 then we can more easily take in stuff like this
09:49 sfan5 inb4 fore contrib/ getting bigger than src/ in a few months
09:49 sfan5 for*
09:49 celeron55 i'm okay with that
09:49 celeron55 it means more stuff got in because of contrib/ then
09:49 sfan5 yeah, that would be a good sign
09:49 celeron55 then some of it can be moved out from there if it turns out to be widely used
09:50 sfan5 the build system is a bit unflexibe
09:50 sfan5 all of the important stuff is in src/CMakeLists.txt
09:51 sfan5 I suggest moving all import stuff to /CMakeLists.txt and making src/CMakeLists.txt only add sources & include dirs to the project
09:52 celeron55 i'm fine with improving the cmake build file structure
09:52 sfan5 then contrib/ has serveral directories in it that have a CMakeLists.txt which does the same like src/CMakeLists.txt
09:53 * sfan5 gets to work
09:53 BlockMen how do i convert v2s16 to v2f?
09:54 celeron55 why do you need to?
09:54 celeron55 use a v2s16 all the way
09:54 celeron55 if there's no lua implementation for those, add them
09:54 BlockMen because the animation is currently handled by m_animation_range  (v2f) in content_coa.cpp
09:54 BlockMen should i change it ing eneral then?
09:55 BlockMen *s/coa/cao
09:56 celeron55 does fractional frames mean something?
09:56 celeron55 like if you tell it to start at frame 10.5, does it differ from starting from frame 10
09:57 celeron55 if not, then they should be integers
09:57 BlockMen idk but i guess not (since you cant have half frames in blender for example)
09:58 celeron55 i guess it would be interpolation but i don't know what sense it would make to start mid-interpolation
09:59 celeron55 oh it already does m_animated_meshnode->setFrameL​oop((int)m_animation_range.X, (int)m_animation_range.Y);
09:59 celeron55 so v2f is just dumb
09:59 BlockMen then i have to change set_animation now aswell (since it is also send as v2f)
09:59 BlockMen fine
10:02 celeron55 if some existing thing sends then as v2f, you can't change the protocol there; just leave it for that part
10:03 celeron55 this is once again an example why we can't have enough commit reviewing and why we have too little even now while pulls have stupidly long merge times
10:04 celeron55 ...also this is why all the network protocol packets and file formats should be centralized to an easily reviewable place
10:04 celeron55 because they matter most
10:16 BlockMen so then only sendLocalAnimations should use v2s16? also strange then
10:18 celeron55 we'll get the other one up-to-date later
10:19 celeron55 i think that if there's an error somewhere, it doesn't make sense to copy the error to everywhere else just because it exists there
10:20 celeron55 in this case fixing the original error can't be done by just changing it; it requires a new protocol version
10:21 celeron55 which isn't a huge issue by itself, but shouldn't be done at the same time
10:22 celeron55 (a protocol version and support for the old version on the server-side, that is)
10:29 BlockMen k
10:33 BlockMen one thing before i change it, setFrameLoop uses s32, should i use v2s2 also or v2s16 ?
10:34 BlockMen *v2s32
10:39 celeron55 i don't know; how many frames animations have at maximum?
10:39 celeron55 i'd guess a frame count of 32767 would be really hard to reach
10:39 Jordach joined #minetest-dev
10:40 celeron55 well, i'm not against using s32; it's not so much overhead (except maybe if you ask hmmmm)
10:43 BlockMen i guess no model will ever reach that values, i just thought of continuity
10:44 celeron55 they could reach if they have a huge number of animations
10:44 celeron55 if someone has to do some kind of N*M solution for mulitple independent cases
10:44 BlockMen yeah, they could, but then the model is also fuking large
10:44 celeron55 s/cases/features/
10:44 BlockMen at least as .x file
10:45 celeron55 it's true; even if each frame would be just one byte, it would be a large file 8)
10:46 BlockMen well, idc at all if its s16 or s32, your decision
10:46 celeron55 okay, i'm pulling s32 out of my ass then
10:47 celeron55 (because it's generally good to oversize these by at least 100x the expected maximum)
10:47 BlockMen ewww...
10:47 BlockMen and ok ;)
10:48 celeron55 by the way, i now started doing a rework where i put creation of every packet to a function in a central source file
10:49 celeron55 but i might give up and give this for someone else to do... but not before i've finished the design
10:49 BlockMen sounds good (except the give some else part^^)
10:50 BlockMen and umm..well, we have read_v2s16 but not read_v2s32
10:50 BlockMen grmbl
10:50 celeron55 implement it :P
10:52 * BlockMen is already doin
10:57 celeron55 looks like i have to fix a big bunch of serialization-related const correctness issues too; well i guess this is for the better
11:05 celeron55 https://github.com/celeron55/minetest/commi​t/a967278efe118a1c2b3eb930fec1d30faa8fc081
11:05 celeron55 something like this
11:06 celeron55 i guess nobody can disagree about doing this
11:08 sfan5 idea: create utility program to auto-create this file
11:09 celeron55 running utility programs on windows with cmake is harder than flying to the moon
11:09 celeron55 please no
11:09 sfan5 add_custom_command(..)
11:10 celeron55 and in what language will you write it?
11:11 sfan5 how about c++?
11:13 celeron55 hmm... well i guess i could try
11:13 celeron55 i have had infinite problems in the past attempting to do things like that with cmake
11:14 celeron55 it just fails in some ridiculous way or you end up with stupid dependency issues like generating headers and their dependants every time or non-regenerating things while they should regenerate
11:14 celeron55 psoilnar generates code using a python script
11:14 celeron55 guess if i could make cmake run it like it should?
11:14 celeron55 NOPE.
11:15 celeron55 no way, i had to give up
11:15 celeron55 and it's just on linux; i can't imagine what MSVC is like
11:16 celeron55 then add compilation of the utility program to the mix and i can't imagine it working
11:16 celeron55 so, feel free to try; i might not, due to reasons
11:20 sfan5 ok
11:20 BlockMen lol, i guess i made a mistake somehwere. now the model is running trough all animations :D
11:22 PilzAdam joined #minetest-dev
11:39 celeron55 hopy crap there are many packets
11:40 celeron55 we need to take turns writing this 8D
11:41 Taoki BlockMen: Hey. How go things with the camera code?
11:42 BlockMen Taoki, read log ;)
11:43 Taoki ok
11:45 Taoki celeron55: What's your take on last night's issue BTW? BlockMen added a Lua function to set a list of local animations for viewing yourself in 3rd person mode. But the right way is to make the function work for all players, so everyone is animated client-side and we don't send a new animation from Lua whenever a player starts / stops moving. But it's hard to detect when others are walking / mining
11:46 Taoki Should he leave it like that? Or should we network more information about each player to clients (when someone is moving, mining, pressed keys, etc)? Best way would be for players to have a real velocity, because then we could adjust animation speed to movement speed as well
11:47 Taoki And we could have a client-side move animation for BOTH players (local and non-local) as well as entities (such as mobs) which is handled based on speed. But the speed we can generate from last vs. current position right now is laggy and jittery
11:48 Taoki IMO, the current way (setting only local animations for moving and digging in Lua) is wrong, but might have to happen because better isn't possible. Is there really nothing we can do though?
11:51 BlockMen someone an idea why this (https://github.com/BlockMen/minetest/commit​/6536859ca72edcd46482e2d7e602684ed26a7822) breaks the animation?
11:53 Taoki Hmm... none
11:53 Taoki BTW... my set_animation should be doing the same thing. I might have not thought of using v2f back then, nor integers. IIRC I send the start and end frame as two floats
11:53 Taoki Or do I...
11:54 ImQ009 joined #minetest-dev
11:55 Taoki BlockMen: BTW: // values for default model (for servers < 0.4.10) ---- I don't agree with hard coding a frame range in any way! Different games (not minetest_game) will use their own models. I suggest that when the function isn't called, there are no local animations at all
11:55 celeron55 BlockMen: no
11:55 celeron55 BlockMen: print out the values, maybe it helps
11:56 BlockMen Taoki, irc.minetest.ru/minetest-dev/2014-04-12#i_3645673
11:56 Taoki There must never be an animation which is hard coded, because player models depend only on games and mods. So please remove that
11:56 BlockMen and have you seen 3rd pv without animations? its crap
11:56 Taoki Still a very bad idea IMO.
11:57 Taoki BlockMen: The player.lua file in minetest_game can set the local animations
11:57 Taoki Same way it sets all animations currently
11:57 BlockMen but since local anim = 0 it is not animated at all
11:58 Taoki BlockMen: Can you make it instead so that when local_anim is 0, it uses the server animations like before?
11:58 Taoki IMO that's a lot better
11:58 Taoki Hard coded animation ranges means an engine dependency over a modle that's part of a specific game / mod
11:58 BlockMen its only for older server (that cant send the frames yet)
11:58 Taoki I'd suggest anything at all but that personally
11:59 BlockMen and do you know only one server that uses not default model atm?
11:59 Taoki There will be more servers with more unioque games (not minetest_game)
11:59 celeron55 lol what
11:59 Taoki The engine mustn't hard code things related to each game in mart IMO
11:59 Taoki **part
11:59 celeron55 Taoki: it's for backwards compatibility
11:59 celeron55 stop arguing about it, that's just dumb
12:00 Taoki celeron55: Yes, but for a model that's part of onne game (minetest_game).
12:00 celeron55 there's nothing you can do about it
12:00 Taoki There is. You can just not use local animations when none are set
12:00 celeron55 does any current server break with that?
12:01 BlockMen no, on current server its animated (currently), could be hard coded or send by server (very laggy)
12:01 Taoki Currently, the local model isn't animated at all from what I understand. I'm suggesting that when set_local_animations is not sent, the local model uses the server-side animations, like the local animation system didn't exist
12:01 BlockMen i prefer the hard coded backfall
12:01 Taoki And player.lua in minetest_game will of course set them
12:01 Taoki So it won't be the case
12:02 BlockMen but lagging as hell
12:02 BlockMen *the server set anims
12:02 celeron55 well okay, i don't know which is better
12:02 Taoki BlockMen: Which is why the function should be added in player.lua under register_on_joinplayer
12:02 Taoki There won't be any difference then
12:02 celeron55 please rationalize your opinions; otherwise this discussion is useless
12:03 Taoki ok
12:03 celeron55 i think the question is, which option breaks less things
12:04 Taoki It's just that the minetest engine itself is meant to be an engine. minetest_game is the current default game, but not the only one. IMO the engine shouldn't contain hard-coded options for something specific to minetest_game. Anything game-specific should be set via ua or game config.
12:04 BlockMen since there is currently not one server (i know of) that uses not the default player model the hardcoded would "break" less
12:04 Taoki Maybe someone makes a new game for the Minetest engine which uses new player models entirely. The frame ranges will be completely broken then
12:05 celeron55 Taoki: but why would anyone use 0.4.9 with those?
12:05 Taoki BlockMen: There will be in time. I have plans for that myself. And IMO that's not a reason to do it this way
12:05 celeron55 those who use 0.4.9 use old games that don't contain those models
12:05 celeron55 those who use different models can use 0.4.10
12:05 Taoki You mean the 0ld 2D player sprites?
12:05 Taoki They don't use animation at all, so for them nothing will happen I imagine
12:06 celeron55 hmm... there is an issue about this actually; the issue is that if you make a new model in 0.4.10 and want it to not be animated at all, you *have* to set the local animations to make it not animated
12:06 celeron55 that's actually quite dumb
12:07 Taoki BlockMen: There's discussion of replacing (or at least additionally adding) other games over minetest_game. I also have plans (when I make my own) to use detailed high-poly player models and more. So yeah
12:07 celeron55 in that sense not having any default animation ranges would be better
12:07 celeron55 a lot better actually; i think i now agree with taoki because of this
12:08 Taoki celeron55: I'm suggesting that when no local animations are set, the local model takes the server animations like all other player models. As if the local animation system did not exist
12:08 Taoki Also the old behavior, in case someone removed m_is_local_player in content_cao to allow rendering local player model
12:08 BlockMen umm...if you want make a new model in 0.4.10 and dont want it be animated at all you include no key frames in the model?
12:08 BlockMen there is no reason to disable animations just for 3rd pv
12:08 Taoki BlockMen: Sure. But then you also send no more set_animation updates in Lua
12:09 celeron55 what does the client do when it does have frames, but they are for a different purpose than player walking animations?
12:09 Taoki I know. You might misunderstand what I mean
12:10 BlockMen celeron55 : is you set "wrong" key frames they are shown own, so if you set digging at walking it show digging when walking then
12:10 celeron55 i think the client should not apply local animations when the server hasn't told it in which frames they are; does BlockMen still disagree with this?
12:11 Taoki BlockMen: Idea is, if the set_local_animation command in Lua isn't issued on a player model, the local animation system does not apply to it, and that model keeps using server animations like other players do (current / old way). IMO that's the cleanest way. And it won't be the case in minetest_game because we'll add set_local_animations to register_on_joinplayer
12:11 Taoki celeron55: That's what I mean yes
12:11 Taoki Cleanest way I believe, and safest
12:11 celeron55 servers that run 0.4.9 will run old games that have server-side animations and expect the clients to show those, so this is the correct behavior
12:11 BlockMen i still disagree. the example celeron55 gave makes no sence at all
12:12 celeron55 if the clients didn't show those server-side animations, it would be wrong
12:12 Taoki Also, here's another reason: Consider the hard-coded animations are added, and peple start playing with them. Me or someone else later makes a change to the player model, and changes the length of an animation, then we put that change on GIT and in the next Minetest release. Unless people with old server recompile, their local animations will be broken
12:12 iqualfragile joined #minetest-dev
12:12 BlockMen they show all server side animations except those for walking, digging, standing and w+digging
12:13 celeron55 the minetest client's main purpose is to do what the server wants it to do; if it doesn't do that, it fails its main purpose and that is pretty bad
12:13 Taoki In this case however, server Lua would also update the frames when the model changes, always compatible
12:13 Taoki Even with old servers
12:13 Taoki Sorry, I meant people with old client
12:14 Taoki So if animation randers are hard-coded changes to the player model on the server would require those clients to update... namely official changes and new Minetest releases
12:14 Taoki **ranges
12:15 BlockMen sorry, but i dont get the point. it only applies for old servers (which all use the default model). if there are games up to come with different models there is no reason to use them with older mt version (up to 0.4.9)
12:15 BlockMen so this hard coded fallback would break nothing
12:16 celeron55 BlockMen: when you update the server and the client to 0.4.10, the client still has the behavior that if it doesn't receive local animation definitions, it will animate based on the old model
12:16 BlockMen *except the case 0.4.10 come out in 12 months
12:16 celeron55 which it clearly should not do
12:16 Taoki It's still not optimal and a good idea IMO. Because we're hard coding animation ranges for a player model in a specific game (minetest_game). Things like this make minetest become "the engine of minetest_game", rather than "an engine for games to work with"
12:17 celeron55 BlockMen: i am completely done with this argument now
12:17 BlockMen yeah, ofc. but with 0.4.10 the server send the animations, so any game can customize the frames
12:17 celeron55 it shouldn't send them if it doesn't need to
12:17 Taoki True. But if no local animations are sent, it woudl still operate on hard-coded keyframes which are not reliable
12:17 celeron55 and the case where it doesn't need to isn't the old behavior; it is the "no behavior" case
12:18 Taoki Most reliable way is to use server side animations. Clients which haven't updated bare the lag a little bit until they get the latest client
12:18 celeron55 seriously, this has now ended; i will revert anything that defaults to old animation ranges
12:18 celeron55 so then, here's this https://github.com/celeron55/minete​st/commits/central_packet_creation
12:18 celeron55 i made stub functions for all server->client packets
12:19 BlockMen wow, really creat discussion behavior, celeron55
12:19 BlockMen *great
12:19 Taoki nice (that package change I mean)
12:20 celeron55 BlockMen: sorry; but it seemed to be an efficient way to end the argument
12:20 * Taoki does find it a bit funny that celeron55 told me there's nothing to discuss when I suggested no hardcoded frames, and now tells blockmen the same about the opposite. In the sense that, we should probably analyze ideas more carefully and not with a strong opinion as much, generally speaking. But me and c55 agree on it now
12:21 Taoki Well I do have a strong opinion too I guess, but yeah
12:22 BlockMen i never told anyone that there is nothing to discuss, so its not just the other side round now, Taoki
12:23 Taoki I don't want to sound mean about it either, if BlockMen thinks oppositely. Not saying there's nothing to discuss myself, just why I think it's a bad idea to ever hardcode animation frames
12:24 celeron55 reopening the discussion made me see a problem that i didn't realize originally, so that was good
12:24 Taoki Actually, I work with a lot of game engines... and few are meant to support modding as much as minetest is. Not even they ever hard-code any animation as far as I know. Though in most cases animations are hard-coded within each model file, and player client-side only, so it's somewhat a different story
12:24 Taoki *a lot = serveral really
12:25 rdococ joined #minetest-dev
12:25 Taoki **played client-side only, damn my typing
12:25 OldCoder joined #minetest-dev
12:25 Taoki Idea is, minetest would add a dependency even FPS games with hard-coded weapons and player classes and all don't have, when you can use your own player models
12:26 BlockMen well, w/e. i set back the pull to float values and there is nothing to discuss about
12:26 celeron55 what
12:26 Taoki BlockMen: I agree that sending frame ranges as integers is best if possible... less bandwidth at least. Also, I wanted to say something about that...
12:27 Taoki BlockMen: The reason animations might break with integers COULD be how Irrlicht expects them. IRR probably wants animations to be given to it as v3f
12:27 Taoki So you might have to convert, after sending animations as integers which is cheaper
12:27 celeron55 irrlicht wants them as v2s32
12:28 Taoki Ah, ok. In that case it's really strange they don't work that way
12:28 celeron55 blockmen probably messed up something in either end of the protocol
12:29 celeron55 couldn't find what though
12:29 celeron55 and now he deleted the commit
12:29 Taoki It's possible that he might have forgotten a function as v3f somewhere
12:29 Taoki :(
12:30 celeron55 oh it's still here https://github.com/BlockMen/minetest/commi​t/6536859ca72edcd46482e2d7e602684ed26a7822
12:30 celeron55 it's v2f, not v3f
12:30 Taoki celeron55: I'm still curious what you think about the issue of local animations in general. BlockMen's current code does it for local player only. What if we could do it for all players client-side, and get rid of the set_animation commands for moving and digging?
12:31 Taoki This would however require sending more information about each player to clients
12:31 Taoki Because calculating other player's veolcities in content_cao - step() is jittery and unreliable
12:31 celeron55 how do other player's animations even work currently?
12:32 Taoki celeron55: Server-side Lua sends each animation update. So for example, when forward / backward / left / right keys are pressed or unpressed, the server sends a set_animation package with either "walk" or "stand" animation
12:32 Taoki This means more bandwidth as well as a slower result for clients
12:32 celeron55 i think that is good enough
12:33 celeron55 anything more clever is just limiting
12:33 Taoki Ok. IMO set_animation should only be there for mods to set custom animations, but walking and digging and standing should be handled by client
12:33 Taoki Yeah, true in a sense
12:33 Taoki For example, a mod might make multiple walking animations, or think of a more clever way to do this
12:33 celeron55 the lagginess will be fixed when the server is made less choppy
12:34 celeron55 it currently tends to stop processing things for too long periods
12:34 Taoki yeah
12:34 celeron55 without that, there would be no issues with animations
12:34 Taoki celeron55: Yesterday I suggested bringing the default server step from 0.1 to 0.05. But sapier said that increases load too much. It would really help with smoother player updates over the network
12:34 celeron55 it won't help anything
12:35 Taoki I see. No need to in that case yeah
12:35 celeron55 if the server stops for multiple seconds, it doesn't matter what that value is
12:35 celeron55 or even multiple hundreds of milliseconds
12:35 Taoki That value still means 10 position updates per second if I understand right. Pretty little for smooth movement, even with client-side interpolation
12:35 celeron55 you can try improving the position interpolation algorithm if you want though
12:36 Taoki Hmmmm... know what could help? If client-side position interpolation could generate a curve between all positions. That might make it more reliable rather than just blending between the values. Not sure if it alread does that
12:36 celeron55 i don't think this is important at all; also most of the time the position updates are just completely wasted because most of the time you simply don't look at the other players
12:37 celeron55 or really anything that moves
12:38 Taoki Right. Would be nice if you could only send them for players you see. Though the server needs to know your field of view and camera position / rotation and use that in a smart way
12:38 Taoki Hopefully can be done later
12:38 Taoki Oh, BTW...
12:38 Taoki Is there any reason why we don't have a draw distance limit for players yet? It seems Minetest still renders and sends all players present on the world, no matter how far they are
12:39 celeron55 we have
12:39 Taoki I don't think we should send players who are in chunks that aren't loaded or visible
12:39 celeron55 it's just not used by default
12:39 Taoki ok
12:39 celeron55 it's called unlimited_player_transfer_distance
12:39 celeron55 which is true by default
12:40 Taoki Why is it default? Does it help anything, other than seeing the floating name tags for everyone?
12:40 celeron55 if you switch that off, you won't see player names either though
12:40 celeron55 i guess the positions of far-away players could be sent much more rarely in any case
12:40 Taoki Don't think I need to see name tags for a very far player
12:41 celeron55 people are used to it and i guess they like it
12:42 celeron55 of course real survival/pvp servers switch it off already
12:44 celeron55 maybe we could set it to false for the next release and see what people say
12:45 Taoki I'd prefer that personally yes
12:50 Garmine joined #minetest-dev
13:00 Shardvex joined #minetest-dev
13:32 VanessaE personally I'd prefer to have nametags remain visible, but somewhat faded/translucent if they're really distant, but player models should definitely not be drawn at all if they're beyond the player's current view range
13:36 kahrl joined #minetest-dev
13:59 sfan5 celeron55: I wrote an utility program that does this
13:59 sfan5 but my code is absolutly horrible
14:00 sfan5 example: http://pastie.org/9075163 -> http://pastie.org/9075165
14:05 celeron55 https://github.com/celeron55/minetest​/blob/90ffaba24008ff625896886b4018be8​765546404/src/clientserver.cpp#L223
14:05 celeron55 some of these look like this
14:06 celeron55 if this is automated, something like this is needed https://github.com/celeron55/minetest/commit/8​6f032045ce40c976cbd90b65fcffac00dec7e73#diff-1
14:07 Eater4 joined #minetest-dev
14:07 celeron55 then for special types it is easy to just do stuff like this https://github.com/celeron55/minetest/commi​t/b93b88e9b26985d6f9b1eb31546fd3dd53a0dd1a#​diff-70868aa6d6b96c0c1623c761500d23c4R107
14:08 celeron55 then you don't need to know the names of serialization functions for types, because for a given type they are always STraits<type>::read/write
14:08 celeron55 and it will recurse into containers
14:09 celeron55 so that if you define STraits<std::vector<T>>::write to write a size and then the contents using STraits<T>::write, a vector containing any serializable type will work without any code additions
14:10 celeron55 but dunno if this is needed for now
14:11 celeron55 it can be hard to control cross-version compatibility if things are automated too much; or at least the automation has to be coded to fully understand everything about it
14:12 celeron55 and then if people screw up in some leftover-screwable way, it's impossible to fix in a compatible way
14:12 celeron55 for example byy forgetting to increase protocol version at the right moment
14:13 celeron55 -y
14:13 sfan5 in case you're interested, here's my code: http://pastie.org/pastes/9075187​/text?key=hntmo9dbrcuefyifnnkmkw
14:13 Taoki VanessaE: Problem is that too many nametags fill the screen with text you can't make anything of, when too many players are on. In my caase I find it rather a bother
14:14 celeron55 https://github.com/celeron55/minete​st/commits/central_packet_creation
14:14 celeron55 i'm going to continue this when i'm more bored
14:14 celeron55 if someone is bored enough to do this, please do
14:16 celeron55 why doesn't minetest save the last used game for me?
14:16 nore joined #minetest-dev
14:16 celeron55 the menu always starts at the same one
14:16 VanessaE Taoki: well Minecraft solved that problem by changing the size of the player tag based on the distance to that player
14:16 celeron55 did sapier remove the feature when he reworked this or what's the deal with this
14:16 VanessaE so at least nearby players are easy to read
14:16 celeron55 it's annoying
14:16 Taoki VanessaE: Right... wouldn't hurt if we had that too. Even so, seeing the name tags of super-far players kinda sucks IMO
14:17 Taoki MC doesn't do it either
14:17 VanessaE perhaps.
14:17 Taoki Past a certain point the name tag starts to fade
14:17 VanessaE seeing them AT ALL would be nice (the fond is too damn small as it is)
14:17 VanessaE font*
14:18 Taoki BTW. celeron55 is probably going to kill me for suggesting we do something else more like Minecraft. But is there any chance we might see a better chat window / system? Like one with larger fonts, and perhaps not in the upper-left corner of the screen where it's harder to look
14:18 Taoki I can barely follow the chat as is, because it doesn't get my attention
14:18 Taoki And a whole window appearing when you type doesn't feel like the best way to me either. Rather than in-line chatting
14:18 Taoki Like a formspec window to type chat in
14:19 VanessaE you mean more like a typical IRC client.
14:19 Taoki I mean more like the MineCraft chat area :P Not because it's MC but because it's easier to follow and use
14:20 Taoki Though if we make large fonts and put them in bottol-left corner, people will say we're copying Minecraft too much again x.x
14:21 VanessaE well where the chat is placed matters little, honestly; and I thought changing the size of the font used therein is already possible from the config
14:21 VanessaE well no, I suppose it isn't
14:21 VanessaE I'm thinking of the command console.
14:22 VanessaE now, color-coding the chat by default would be VERY useful
14:22 Taoki Chat postion isn't that bat I guess. But I really wish the fonts could be made a lot larger
14:22 Taoki And have a transparent black background. Which was already suggested, but IIRC rejected. I'd still want that
14:22 VanessaE even basic stuff like join/part messages and a different color for nicks vs. the text, nick highlighting, etc.
14:22 Taoki Other than that, inline typing would be appreciated, as it would feel easier and better
14:22 hmmmm joined #minetest-dev
14:23 Taoki Yes, different colors would make the chat easier to follow too
14:23 VanessaE the chat is impossible to follow now, if it moves fast enough - I *have* to use my IRC client to follow Inchra #minetest directly if I want to keep up with servers' chats.
14:23 VanessaE and that's mostly just one server.
14:24 Taoki Yeah
14:24 VanessaE with my servers'*
14:25 VanessaE 5-10 lines on the minetest screen with no scrollback, no nick highlights and no color coding of any kind makes it just plain impossible, plus PMs sent to me simply di not stand out at all.
14:25 VanessaE do*
14:25 VanessaE (no scrollback if you don't summon the console, but when you do that, you can't move around)
14:28 celeron55 you can make the fonts rather large by just using the font_size setting, but it doesn't affect the console and some of the layouting becomes quite cramped
14:28 celeron55 the default font size is quite small though... i think it could be increased to 16 or 18
14:29 celeron55 but this sucks because it's resolution-independent; fonts that work for a bad-eyesighted person at full-hd quickly become too large for people with older screens
14:29 celeron55 or i mean dependent; or whatever
14:29 Taoki Ah, good to know... I can try a different size
14:30 celeron55 it should just be made easily configurable in the main menu so that people can use whatever they want
14:30 Taoki But yeah I'd suggest making it larger by default please. It prolly demotivates players because it's hard to see when one another talk... the current chat barely gets attention
14:30 Taoki True
14:30 Taoki Can even try adding a setting myself for that later... I assume that should be possible in the formspec main-menu
14:32 celeron55 it doesn't take effect without restart at the moment
14:33 celeron55 the menu needs a way to do the thing that is at around main.cpp:1500 currently
14:34 celeron55 oh wait, the monospace font is configurable separately
14:34 celeron55 mono_font_size
14:35 celeron55 http://i.imgur.com/aIDOBOe.jpg <- it works just fine no matter how large it is 8)
14:37 Taoki Nice. That's console... font size for it is good imo. Chat is mostly the problem
14:43 rubenwardy joined #minetest-dev
15:29 celeron55 (font_size adjusts the chat and menus)
15:30 Taoki For menus it would be nice too yes
15:36 zat joined #minetest-dev
15:36 kaeza joined #minetest-dev
15:37 BlockMen joined #minetest-dev
15:37 BlockMen any problems with https://github.com/BlockMen/minetest/commi​t/7cdbb805d9f230b2cf00150884dc3fa4fbcde16f ?
15:41 BlockMen and i would like to push this aswell
15:41 BlockMen https://github.com/BlockMen/minetest/commi​t/e149d1ad9a623b9f8ca597839f7b850841c54781
15:44 celeron55 seems ok to me, altough i wonder why the first one was made that way originally
15:46 BlockMen ok, then i gonna push them
15:48 BlockMen done
15:49 NakedFury joined #minetest-dev
15:49 Taoki BlockMen: Have you decided what to do with those animations and the TPV patch?
15:50 Taoki Just eager to see third-person support in :) But please remove them hard-coded frames is all
15:57 BlockMen If you can celeron55 perfer lags for the user, im fine with it. I will patch my client and dont care then. It way the "discussion" was ended is the problem at all
15:58 BlockMen but #1114 is ready from my side, maybe someone should test again before merging
15:58 ShadowBot https://github.com/minetest/minetest/issues/1114 -- Add third person view by BlockMen
15:59 Taoki BlockMen: I guess I prefer lags... eh eh :P It will be ok like that though, no worries.
16:00 BlockMen Taoki, i said idc about that anymore...
16:00 Taoki BlockMen: Will you be removing them from this commit https://github.com/BlockMen/minetest​/commit/6536859ca72edcd46482e2d7e602​684ed26a7822#commitcomment-5992027 Asking because the integer based vectors are better, so I was hoping you could keep these
16:00 Taoki ok, sorry
16:01 celeron55 (it could be made optionally configurable if someone really wants it so much)
16:02 BlockMen Taoki, maybe you should look at the current code and not at old commits
16:02 BlockMen celeron55, i wont add
16:02 Taoki ... right
16:03 Taoki Yeah better not to IMO, don't think anyone needs it THAT badly :P
16:03 Taoki Would prolly make a mess of things
16:03 Taoki Anyway will look at current code
16:03 Taoki OK awesome, looks good to me :)
16:04 Taoki BlockMen: As far as I'm concerned, merge right away. Looks great now ^^
16:05 BlockMen i wont merge anything until someone has tested
16:05 Meisaka joined #minetest-dev
16:05 kaeza it's compiling!
16:08 kaeza works pretty well
16:09 Taoki Awesome
16:16 celeron55 uh oh
16:16 celeron55 i tried to run this in valgrind but minetest won't start... not due to this patchset though
16:17 celeron55 /home/celeron55/softat/minetest/s​rc/script/cpp_api/s_base.cpp:73: ScriptApiBase::ScriptApiBase(): Assertion 'm_luastack' failed.
16:18 celeron55 hmm, this could be due to luajit
16:20 celeron55 yes, disabling luajit helped
16:25 Calinou joined #minetest-dev
16:37 BlockMen anyone would like to agree to #1114?
16:37 ShadowBot https://github.com/minetest/minetest/issues/1114 -- Add third person view by BlockMen
16:37 BlockMen *any core dev
17:16 celeron55 clientserver.h actually still specifies the old float values
17:17 celeron55 that being fixed, i'll agree to it
17:18 celeron55 i'm sure that there will be some error in this that may or may not be found too late though
17:18 celeron55 everything this large has them
17:22 PenguinDad BlockMen: works fine for me in singleplayer
17:33 smoke_fumus joined #minetest-dev
17:41 rubenwardy_ joined #minetest-dev
17:45 BlockMen celeron55, ok. and these 3 commits or squashing?
18:01 celeron55 separate are fine
18:06 BlockMen ok, then i gonna push them now
18:11 BlockMen aaand done :)
18:15 BlockMen i gonna make a news post too
18:26 PilzAdam BlockMen, player:set_bone_position() doesnt work in 3rd person view
18:27 BlockMen PilzAdam, so the function is broken at all?
18:28 PilzAdam BlockMen, it works on the models of other players
18:29 PilzAdam BlockMen, also you have to tweak isBlockInSight(); in 3rd person view you can see blocks disappearing at the edge of the window
18:31 BlockMen i will look for it
18:31 PilzAdam and its rather easy to look through walls
18:31 celeron55 isBlockInSight is probably getting the player's position instead of the camera's position
18:31 celeron55 so it breaks
18:35 BlockMen celeron55, sounds reasonable
18:37 VanessaE ugh
18:37 VanessaE the camera jumping around when there's something that should obstruct it is hard to get used to
18:37 VanessaE (in the 3rd person view)
18:38 VanessaE I wonder if maybe the camera shouldn't just clip instead?
18:39 PilzAdam VanessaE, maybe it should use the noclip setting too
18:39 VanessaE perhaps
18:39 celeron55 do you mean the screen should be black if the camera's position would be inside something?
18:39 PilzAdam BlockMen, is it wanted that the camera is sometimes lower when the player is moving up?
18:39 celeron55 that would probably be even more annoying
18:39 PilzAdam it only does this sometimes, and in no other direction
18:40 VanessaE celeron55: I mean it should xray-view up to the block the player is standing on, maybe.  but that would probably be hard to do.
18:40 VanessaE behave as if the obstructing block is transparent
18:40 BlockMen PilzAdam, never noticed or reported before :\
18:41 BlockMen VanessaE, i fear that would be really hard to do
18:41 BlockMen but maybe allow moving in nodes with noclip priv sound good IMO
18:41 PilzAdam BlockMen, hold shift and jump while moving fast
18:42 VanessaE if you're in a hole, for example, 3rd person mode becomes useless
18:42 VanessaE because the camera ends up moving right up against the player model's head
18:42 BlockMen PilzAdam, wut? why do you do that at all?!
18:42 PilzAdam its the fastest way to travel
18:42 PilzAdam you basically glitch hills up
18:43 BlockMen VanessaE, 3rd pv cant be always usefull. but what would you suggest as solution for your example?
18:44 BlockMen PilzAdam, never tried but ok, will look at it too
18:44 PilzAdam you can move arround in almost any terrain without being slowed down, thanks to the sneak glitch
18:45 VanessaE BlockMen: like I said, noclip the wall.
18:46 VanessaE either that or just don't allow the camera to cross the wall at all.  let the player turn but leave the camera pressed against the wall until the player moves enough to let the camera spring back to where it should be
18:46 PilzAdam (btw, BlockMen, you can also sneak glitch up a 2 nodes high wall)
18:47 VanessaE it's okay if the camera can bob up and down to clear smaller obstacles, but it's not good for the camera to suddenly spring forward right into the back of the player's head.
18:49 BlockMen VanessaE, the code checks from player up to the wanted camera position for nodes. and in a 2x1 whole the is no chance to get a better position. (except with noclip + noclip priv)
18:50 VanessaE BlockMen: so rotate the camera up and over the player
18:50 VanessaE forward view should NOT be obstructed by the player's head!
18:50 VanessaE that's my point
18:50 VanessaE and you need to spring-load the camera mount
18:51 VanessaE treat this like a steadicam
18:51 VanessaE 3rd person view is nice, but sudden, jerky camera movements look like shit, honestly
18:52 VanessaE if the camera has nowhere to go but into the player's head, then it needs to go up and over the player
18:52 PilzAdam ^
18:53 BlockMen VanessaE, since the camera is directly controled by players pitch, etc the camera would change then the players pitch. idk if that would be wise...
18:53 VanessaE I don't mean the pitch of the camera view.
18:53 VanessaE I mean the position of the camera relative to the player
18:53 VanessaE keep the pitch and yaw control the same as it is now, that's fine
18:53 BlockMen maybe a automatik offset would be better then that you look beside the players head?
18:54 BlockMen VanessaE, oh. so you ment moving camera just slightly over the head?
18:54 VanessaE yes
18:56 VanessaE essentially, converting smoothing back into something similar to the first-person view but by jut moving the camera rather than switching viewpoints.
18:56 VanessaE but only for as long as is necessary to avoid giving the user a macro view of her player model's hairdo :P
18:57 VanessaE if the player pitches the view down from there, then yeah, they'll see the top of the model's head.  That's fine and expected
18:57 BlockMen well, its a first implementation, there is always space for improvement ;)
18:57 VanessaE s/smoothing/smoothly/
19:34 nore BlockMen, https://github.com/minetest/minetest/commi​t/c0ab09af747fc431dfb459ede30788cb9cd1c56b​#diff-e2b656616d911eb8d3605c2ef99f50bbL44 ??
19:36 BlockMen nore, you mean the removed game.h?
19:36 nore yes
19:36 BlockMen it was added with the first commit and removed with the second because the enum was moved to camera.h instead of game.h
19:36 nore nvm, I just saw it was moved to camera.h
19:37 BlockMen faster :P
19:41 salamanderrake joined #minetest-dev
20:05 ch98 joined #minetest-dev
20:07 iqualfragile joined #minetest-dev
20:28 kaeza joined #minetest-dev
20:43 Jordach joined #minetest-dev
20:50 Taoki Aaand, this is my latest suggested addition for Minetest for the time being: https://forum.minetest.net​/viewtopic.php?pid=137320
20:55 VanessaE nice
20:55 Meisaka left #minetest-dev
20:55 Taoki Thanks. Would prolly make it more motivating to interact with others on server, and easier to see who's with you
21:01 sfan5[iPod] joined #minetest-dev
21:03 BlockMen what about https://github.com/minetes​t/minetest_game/issues/249 ? i think this cant called "new feature".
21:05 celeron55 well, comments?
21:06 VanessaE meh
21:06 VanessaE I'm used to the potato :P
21:06 PenguinDad Taoki: looks niche
21:07 PenguinDad *nice
21:07 Taoki Thanks
21:08 BlockMen i think Taokis image shows why im bring this up http://i61.tinypic.com/288uvpd.jpg
21:08 BlockMen it fits now (since sam II) less than ever before
21:09 VanessaE but put minetest_game/250 in for sure.
21:21 BlockMen minetest_game/250 is a feature, 249 more like a "visual" fix IMO
21:31 iqualfragile_ joined #minetest-dev
21:32 BlockMen celeron55, also: is there a specific reason that common, survival and build are not deleted yet?
21:34 Taoki Oh, they're no longer used? Good thing
21:34 Taoki Made no sense to me IMO
21:35 BlockMen Taoki, https://forum.minetest.net/viewtopic.php?id=6034
21:35 Taoki Ah, cool
21:36 BlockMen oh, umm. that answers at least my question for common
21:41 Jordach bigger question
21:41 Jordach why don't we used part of the player model directly and don't render anything else for the fist, which could be player_textures compat
21:41 Jordach (eg, and faces / tris marked Arm.R)
21:42 * VanessaE kicks Jordach's ass
21:43 VanessaE (seriously, don't do that.  not everyone will want a squar-ish on-screen hand)
21:44 Jordach VanessaE, some conf toggle
21:44 VanessaE better to make it depend on the presence of a texture
21:45 VanessaE if no texture file for the hand is present either in the game files or in a texture pack, then use the skin
21:45 VanessaE (well, use the skin/model/your idea I mean)
21:47 celeron55 that would require assuming something about the model texture which shouldn't be done
21:48 VanessaE I think what Jordach wants is more like what minetest++ did, where the actual model appeared on-screen
21:48 VanessaE (well, the hand thereof), and not just a rendering of it
21:50 VanessaE my wording just sucks
21:57 Jordach_ joined #minetest-dev
22:08 BlockMen sooo 249 is dead now because someone prefers potatos?
22:13 rsiska joined #minetest-dev
22:13 VanessaE I doubt that
22:20 BlockMen sry, that was bad formulated. i should stop forcing an decision and ask in a few days again ;)
22:21 proller ask every 4 months ;)
22:23 BlockMen you should switch back to "troller" ;P
22:26 sapier joined #minetest-dev
22:29 sapier celeron55 for what I remember saving last game did work by some time I'm gonna check why it's broken again
22:51 EvergreenTree joined #minetest-dev
23:09 Jordach joined #minetest-dev
23:10 iqualfragile joined #minetest-dev
23:39 _BrandonReese joined #minetest-dev
23:44 cheapie joined #minetest-dev
23:47 BlockMen left #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext