| 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->setFrameLoop((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/commit/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/minetest/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/commit/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/90ffaba24008ff625896886b4018be8765546404/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/86f032045ce40c976cbd90b65fcffac00dec7e73#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/commit/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/minetest/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/commit/7cdbb805d9f230b2cf00150884dc3fa4fbcde16f ? |
| 15:41 |
BlockMen |
and i would like to push this aswell |
| 15:41 |
BlockMen |
https://github.com/BlockMen/minetest/commit/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/6536859ca72edcd46482e2d7e602684ed26a7822#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/src/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/commit/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/minetest/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 |
