| Time |
Nick |
Message |
| 00:30 |
|
khonkhortisan joined #minetest-dev |
| 00:33 |
hmmmm |
i was going to but i got caught up in the main menu crap |
| 00:33 |
hmmmm |
if you do start on it, please do it in C instead of C++ |
| 00:54 |
|
mrtux joined #minetest-dev |
| 00:57 |
|
khonkhortisan_ joined #minetest-dev |
| 01:05 |
|
mrtux joined #minetest-dev |
| 01:09 |
hmmmm |
ehhgh |
| 01:10 |
hmmmm |
how do you tell if someone changed the selection on a dropdown box for the main menu? |
| 01:17 |
kahrl |
you can with textlists (and tables) but I'm pretty sure not with dropdowns |
| 01:19 |
hmmmm |
that's pretty arbitrary. i have no idea what's going on with formspec, what would I have to do to fix that? |
| 01:20 |
|
mrtux joined #minetest-dev |
| 01:21 |
kahrl |
catch EGET_COMBO_BOX_CHANGED in GUIFormSpecMenu::OnEvent and generate an event for lua |
| 01:21 |
hmmmm |
thanks |
| 01:29 |
hmmmm |
adding an event is probably going to break lots of things |
| 01:30 |
hmmmm |
at least sapier's main menu, anyway. there's a lot of code that's like: "if <some element that generates events but isn't an OK button> then handle thing, tabbuilder.ignore_redraw = true; return; end" |
| 01:30 |
hmmmm |
so basically everything needs to be restructured due to some dopey design |
| 01:31 |
hmmmm |
"yes, let's treat ALL events as close the formspec unless something else is explicitly specified!" |
| 01:31 |
kahrl |
yeah it's great ;) |
| 01:34 |
|
iqualfragile_ joined #minetest-dev |
| 01:35 |
VanessaE |
I believe RBA complained rather vocally about that some time back |
| 01:36 |
VanessaE |
when he was working on Unified Inventory's search function - we wanted the enter key to trigger the actual search button. No good, enter = exit. |
| 01:40 |
|
jojoa1997 joined #minetest-dev |
| 01:41 |
hmmmm |
VanessaE, that was something different though |
| 01:41 |
hmmmm |
I think I recall that saga... the problem was that the client would need to predict what the server wants to do when input has been accepted |
| 01:42 |
hmmmm |
all of this bullshit will be fixed, come client-side modding |
| 01:42 |
hmmmm |
no more guesswork will be involved |
| 01:45 |
VanessaE |
but...but.. |
| 01:45 |
VanessaE |
what would minetest be without at least some hassle and guesswork? :) |
| 01:45 |
hmmmm |
good |
| 01:45 |
khonkhortisan |
not developed by a random group of *guesses* |
| 01:46 |
khonkhortisan |
lunatics. looked it up |
| 01:47 |
hmmmm |
so uh what's with the first 40 lines of GUIFormSpecMenu::OnEvent |
| 01:48 |
hmmmm |
I don't get it.. why are there two adjacent break statements, why is there a default case with a comment that says "can't happen at all!" and then an assertion for it, ... |
| 01:48 |
hmmmm |
strikes me as very sloppy |
| 01:51 |
kahrl |
looks like template coding |
| 01:51 |
kahrl |
some button in an IDE that generates switch () { break; default: break; } |
| 01:53 |
hmmmm |
what's the rationale behind the checks for if the ID is > 257? |
| 01:54 |
kahrl |
IDs 0...257 are reserved for elements that don't correspond to a field |
| 01:54 |
hmmmm |
ah ok |
| 02:41 |
|
kaeza joined #minetest-dev |
| 03:12 |
|
kahrl_ joined #minetest-dev |
| 03:48 |
|
ImQ009 joined #minetest-dev |
| 04:24 |
|
mrtux joined #minetest-dev |
| 05:02 |
|
neko259 joined #minetest-dev |
| 05:04 |
|
e1z0 joined #minetest-dev |
| 05:14 |
celeron55 |
PilzAdam: can you write down the way how you can create and generate "pilztest" trees? |
| 06:36 |
|
ShadowNinja joined #minetest-dev |
| 07:17 |
|
smoke_fumus joined #minetest-dev |
| 07:32 |
|
jin_xi joined #minetest-dev |
| 07:34 |
jin_xi |
pilztest uses decorations and schematics for trees |
| 07:46 |
|
ShadowNinja joined #minetest-dev |
| 08:14 |
|
Ritchie joined #minetest-dev |
| 08:30 |
|
djdduty joined #minetest-dev |
| 08:30 |
|
djdduty joined #minetest-dev |
| 08:39 |
|
Calinou joined #minetest-dev |
| 10:06 |
|
Ritchie_ joined #minetest-dev |
| 10:24 |
|
Akien joined #minetest-dev |
| 10:40 |
|
proller joined #minetest-dev |
| 12:07 |
|
iqualfragile joined #minetest-dev |
| 12:16 |
|
ImQ009 joined #minetest-dev |
| 12:27 |
|
PilzAdam joined #minetest-dev |
| 13:06 |
|
nyuszika7h joined #minetest-dev |
| 13:15 |
|
Taoki joined #minetest-dev |
| 13:20 |
|
proller joined #minetest-dev |
| 13:24 |
|
BlockMen joined #minetest-dev |
| 14:16 |
|
Akien joined #minetest-dev |
| 14:20 |
|
lanxu joined #minetest-dev |
| 15:11 |
|
Jordach joined #minetest-dev |
| 15:14 |
|
hmmmm joined #minetest-dev |
| 15:32 |
|
smoke_fumus joined #minetest-dev |
| 15:55 |
BlockMen |
any comments on #886, #928 or #930? |
| 16:00 |
kahrl_ |
BlockMen: #886 seems fine |
| 16:02 |
proller |
897 895 892 882 wants too |
| 16:03 |
kahrl |
#930 could be made more generic, I believe |
| 16:04 |
kahrl |
as in allow images to take half the screen, for example |
| 16:06 |
kahrl |
#928 has buffer overflows |
| 16:07 |
kahrl |
you read a color using split() but then you don't check that there are actually 4 parts |
| 16:08 |
BlockMen |
kahrl, so like -0.5 == half screen ? (#930) |
| 16:09 |
BlockMen |
and you mean at #928 like here? -> https://github.com/minetest/minetest/pull/928/files#L1R1378 so checking if color.size() == 4 ? |
| 16:11 |
kahrl |
#930: either that or adding a bool scale_from_screen (or whatever) seems fine |
| 16:11 |
kahrl |
#928: exactly |
| 16:13 |
BlockMen |
ok, gonna change that. thanks. |
| 16:22 |
kahrl |
proller: #895 ummm... why do you set liquid_loop_max even lower |
| 16:22 |
kahrl |
it should be restored to 10000 if anything |
| 16:22 |
proller |
because transform calls more frequent |
| 16:22 |
kahrl |
also the default values should be tuned for normal liquids not finite liquids (because normal liquids are the default) |
| 16:23 |
proller |
its ok for normal too |
| 16:24 |
proller |
if queue big - transform may work 10 times per second = 5000 nodes per second |
| 16:24 |
proller |
its better than one looong call |
| 16:26 |
proller |
processing 10000 nodes cause stuck of server |
| 16:26 |
kahrl |
okay |
| 16:32 |
kahrl |
proller: I'd just get rid of the whole #if 0 block here: https://github.com/proller/minetest/commit/283799333cfacc981c45222f1f373fc4704655d5#L4R1217 |
| 16:33 |
BlockMen |
kahrl, done |
| 16:33 |
kahrl |
m_modified_blocks should probably be renamed to something with "liquid" in the name |
| 16:33 |
proller |
it can be modifyen not only by liquids |
| 16:34 |
proller |
its just list for sending |
| 16:34 |
kahrl |
but the interval they are sent in is called liquid_send |
| 16:35 |
proller |
maybe better to rename it to.. |
| 16:37 |
proller |
block_send_every ? |
| 16:38 |
proller |
block_send_minimal ? |
| 16:39 |
kahrl |
well currently it's only used by liquids so a generic name would be confusing imo |
| 16:39 |
kahrl |
abms don't use it for example |
| 16:39 |
proller |
they need to use it |
| 16:40 |
BlockMen |
proller, does #880 fix the liquid range for infinite liquids too? |
| 16:40 |
proller |
yes |
| 16:40 |
BlockMen |
ok :) |
| 16:40 |
proller |
and removes range |
| 16:41 |
kahrl |
880? |
| 16:41 |
BlockMen |
ups..#882 |
| 16:41 |
proller |
https://github.com/minetest/minetest/pull/882 |
| 16:45 |
|
Calinou joined #minetest-dev |
| 16:47 |
proller |
880 fixes most issues with finite |
| 16:48 |
proller |
and some old |
| 16:49 |
|
Jordach joined #minetest-dev |
| 16:50 |
BlockMen |
880 fixed the umlauts issue :P -> https://github.com/minetest/minetest/pull/880 |
| 16:51 |
proller |
ups, 882 |
| 16:56 |
|
neko259 joined #minetest-dev |
| 17:02 |
proller |
modified block send is strange |
| 17:02 |
proller |
is here range lomit to player for sending? |
| 17:02 |
proller |
limit |
| 17:15 |
|
Taoki joined #minetest-dev |
| 17:20 |
hmmmm |
you should change m_liquid_transform_every to m_liquid_transform_interval |
| 17:22 |
proller |
done |
| 17:23 |
hmmmm |
people might not "get" the former right away unless they say it out loud |
| 17:24 |
BlockMen |
hmmmm, any comments on #886, #928 or #930? |
| 17:37 |
|
ImQ009 joined #minetest-dev |
| 17:51 |
hmmmm |
I wrote a comment for #930 |
| 17:51 |
hmmmm |
as for #928, i have no idea what that does but it looks okay |
| 17:52 |
hmmmm |
#886, i guess..... would anybody find this useful? |
| 17:53 |
hmmmm |
for 886, lines 340-343 could use rangelim() instead |
| 17:54 |
hmmmm |
I would prefer if you didn't access the settings every single draw call |
| 17:59 |
celeron55 |
the line where doing a binary tree string lookup matters really is beyond doing it a couple of times per frame |
| 17:59 |
celeron55 |
if it's done in a loop that is done in a frame, that matters |
| 18:01 |
celeron55 |
it hinders usability if new settings aren't taken into use automatically at runtime |
| 18:02 |
hmmmm |
some original HUD code was written like that and I optimized it by moving the calls into the ctor and saved quite a bit of time |
| 18:02 |
hmmmm |
that is NOT just a binary tree lookup |
| 18:02 |
hmmmm |
you forgot about the lock, all the string comparisons, then the conversion |
| 18:03 |
hmmmm |
settings is *SLOW* |
| 18:04 |
BlockMen |
hmmmm, #930 is a nice suggest. i will change to that |
| 18:04 |
hmmmm |
if code is being added/modified in some subsystem that i'm involved with, i'd like people to avoid unnecessary calls. that's the key word here, unnecessary. it's not making things more inconvenient or putting some burden on development, it's just a matter of being prudent |
| 18:06 |
BlockMen |
#886 hud.resize is called in every loop of game.cpp AFAIK. So moving the reading of the setting out of the function should do it, right? |
| 18:27 |
|
smoke_fumus joined #minetest-dev |
| 18:31 |
hmmmm |
yes, make it a member variable and set its value in the hud constructor like the other settings |
| 18:40 |
BlockMen |
ok. #930 is changed already |
| 18:45 |
celeron55 |
and now you can't handily resize the hotbar in a singleplayer game by using /set? |
| 18:50 |
BlockMen |
celeron55, do you think that is needed? |
| 18:51 |
celeron55 |
well, i probably won't use that hotbar resizing functionality at all |
| 18:52 |
celeron55 |
but things should generally be made in some way that doesn't unnecessarily hinder functionality |
| 18:55 |
|
werwerwer joined #minetest-dev |
| 18:55 |
BlockMen |
in general you are right. but imo things like hotbar size, shaders(on/off), etc can be changed by gui (settings tab) |
| 19:10 |
|
Ritchie_ joined #minetest-dev |
| 19:19 |
PilzAdam |
BlockMen, especially HUD things need to be adjustable at runtime |
| 19:19 |
PilzAdam |
you dont want to restart Minetest over and over again to find the right setting |
| 19:21 |
BlockMen |
PilzAdam, well THEN we should add an ingame setting screen |
| 19:21 |
celeron55 |
and what does that ingame setting screen do other than, like, set settings? |
| 19:22 |
celeron55 |
well, that'd be some kind of a reloadable settings struct then i guess |
| 19:22 |
celeron55 |
and that gets us to the core of C and C++: writing everything at least 5 times |
| 19:23 |
celeron55 |
good thing i'm not doing that but hmm is |
| 19:23 |
celeron55 |
hmmmm* |
| 19:25 |
BlockMen |
celeron55, nothing else. but that would be the right way to let user change settings, not /set ... |
| 19:27 |
|
Ritchie_ joined #minetest-dev |
| 19:27 |
|
proller joined #minetest-dev |
| 19:33 |
BlockMen |
PilzAdam, any comment on #930? |
| 19:50 |
|
BlockMen left #minetest-dev |
| 19:51 |
hmmmm |
celeron55, if you're going to add *that* which requires changing code anyway, you might as well just add a setHudSize() or whatever |
| 19:51 |
hmmmm |
not hard.. |
| 19:56 |
celeron55 |
yeah, nice spaghetti for each setting 8) |
| 19:56 |
celeron55 |
spaghetti is always better than a bit slow code |
| 19:59 |
|
kaeza joined #minetest-dev |
| 20:00 |
|
sapier joined #minetest-dev |
| 20:16 |
Jordach |
it'll go better with some new sauce |
| 20:32 |
hmmmm |
you have literally no basis for saying that it's spaghetti until you actually see the end result |
| 20:38 |
proller |
897 895 892 882 ! |
| 20:40 |
kaeza |
42 |
| 20:41 |
hmmmm |
no idea what the wingsuit thing is about |
| 20:41 |
hmmmm |
i've heard some people who don't like it |
| 20:42 |
hmmmm |
i suppose 895 is good, i'm not entirely sure of the ramifications though |
| 20:42 |
hmmmm |
you tested it i trust, and it doesn't break anything? |
| 20:43 |
proller |
you can feel winsuit only when jumping from 100+ |
| 20:43 |
sapier |
tztz complaining about mainmenu event handling when there haven't even been events when mainmenu was created ;-) |
| 20:43 |
hmmmm |
sapier |
| 20:43 |
hmmmm |
hey man i've got some questions for you |
| 20:43 |
proller |
all is 1 month testing on sky server |
| 20:43 |
sapier |
ok I'm here ask ;-) |
| 20:43 |
hmmmm |
i'm trying to add an event for changing a dropdown item but i'm not having much luck |
| 20:44 |
sapier |
what's wrong ? |
| 20:44 |
hmmmm |
i have it all wired up and it's executing gotText with the CHG:itemindexhere |
| 20:44 |
hmmmm |
and I'm not seeing anything from the Lua side |
| 20:44 |
hmmmm |
here's my code |
| 20:44 |
|
Akien joined #minetest-dev |
| 20:45 |
hmmmm |
hold on |
| 20:46 |
hmmmm |
https://github.com/kwolekr/minetest/commit/2738e2cd53e07a1e04e1555a6580576ebd039b3e |
| 20:46 |
hmmmm |
I have no idea what's going on btw |
| 20:47 |
proller |
commit 895? next step - make one send block queue with optimizations |
| 20:47 |
sapier |
ok your problem is at c++ side did I understanc correct? |
| 20:48 |
hmmmm |
sapier, I think so, yeah |
| 20:48 |
sapier |
and the problem is no event is generated? |
| 20:48 |
hmmmm |
yup |
| 20:48 |
sapier |
why did you comment s.send? |
| 20:49 |
hmmmm |
s.send is already set in parseDropDown |
| 20:49 |
sapier |
ahh yes I remember dropdown is interpreted as text input field not as button |
| 20:49 |
hmmmm |
oh great... what does this mean? |
| 20:50 |
hmmmm |
where's it set? how do I change that? |
| 20:50 |
kahrl |
hmmmm: have you tried uncommenting the first line of engine.button_handler? |
| 20:50 |
sapier |
for buttons you can decide if a button is pressed by checking if it's present in the fields table |
| 20:50 |
sapier |
if it's not there it's not been pressed |
| 20:50 |
hmmmm |
i haven't, kahrl |
| 20:50 |
sapier |
text fields are always sent |
| 20:52 |
sapier |
so if you change it that way you need to ad some other mechanism to decide if it's an event issued by dropdown change or a button press ... but thats a different issue |
| 20:52 |
hmmmm |
kahrl, the problem is that button_handler isn't getting called though |
| 20:53 |
hmmmm |
sapier, if the element is a dropdown then it's obviously not a button press |
| 20:53 |
hmmmm |
so i would need to reorganize the code that assumes a dropdown won't create a button press event |
| 20:53 |
sapier |
if you want to send an event it is |
| 20:53 |
hmmmm |
but i already understand that |
| 20:53 |
sapier |
everything triggering a send event is a "button press" ;-) |
| 20:54 |
|
BrandonReese joined #minetest-dev |
| 20:54 |
sapier |
just because there wasn't another mechanism except button press but yes we could rename it to "event" too |
| 20:54 |
hmmmm |
right.... oh wait a minute |
| 20:55 |
hmmmm |
gotText() taking the map calls handleMainMenuButtons |
| 20:55 |
sapier |
but there's nothing obvious wrong I assume you already tried to uncomment first line in button handler to see if it's called? |
| 20:55 |
hmmmm |
which is always called if m_text_dst (which it obviously is, since i'm getting that printf) |
| 20:55 |
hmmmm |
not the first commented line, a different one |
| 20:55 |
hmmmm |
hold on a minute |
| 20:56 |
hmmmm |
see, i don't understand why I wouldn't be getting it because there's no break-out-of-function return in button_handler |
| 20:56 |
sapier |
you added "CHG" in front of the string so you renamed the field to "CHG:<yourdropdownname>" |
| 20:56 |
hmmmm |
unless i am totally missing something |
| 20:57 |
hmmmm |
oh... |
| 20:57 |
hmmmm |
yup, I'm getting button_handler it turns out |
| 20:57 |
hmmmm |
alright, thanks.. |
| 20:57 |
hmmmm |
i feel pretty stupid now |
| 20:57 |
sapier |
but you're getting this EVERYTIME >>ANY<< button is called! |
| 20:58 |
hmmmm |
alright |
| 20:58 |
hmmmm |
i understand what i need to d onow, explode_textlist_event(fields["dd_createworld_preset"]) and then all that nonsense |
| 20:59 |
sapier |
actualy the explode is done on the value NOT the name |
| 21:00 |
kahrl |
I recommend adding 1 to the result of getSelected for consistency with textlist |
| 21:00 |
hmmmm |
yeah, gonna do that |
| 21:01 |
hmmmm |
what i have there is clearly sloppy and unfinished |
| 21:01 |
sapier |
getSelected is only usefull in mainmen but yes it'd be usefull |
| 21:01 |
sapier |
you have to find a way to do this in game to ... atm dropdown is designed as a special textedit field fhile textlist is more like a buttonlist |
| 21:01 |
hmmmm |
sapier, this whole thing is only useful for the main menu.. mods with dropdown boxes are going to start closing when they select an item |
| 21:02 |
hmmmm |
if i understand the system correctly |
| 21:02 |
sapier |
what do you mean with "start closing"? |
| 21:02 |
hmmmm |
it's going to accept input as if it were a button press |
| 21:02 |
hmmmm |
and formspecs exit when input is accepted |
| 21:02 |
sapier |
yes but a button press is not closing a formspec |
| 21:02 |
sapier |
no |
| 21:02 |
hmmmm |
oh sorry |
| 21:02 |
hmmmm |
it's the enter key that does that |
| 21:02 |
sapier |
it's just sending a fields event |
| 21:03 |
sapier |
enter or escape yes |
| 21:03 |
hmmmm |
anyway |
| 21:03 |
hmmmm |
it seems my actual problem was the if-elseif chain |
| 21:03 |
hmmmm |
I didn't realize that *all* of the fields are sent |
| 21:03 |
hmmmm |
thanks though |
| 21:04 |
sapier |
there aren't all fields sent |
| 21:04 |
sapier |
button and similar fields aren't sent |
| 21:04 |
kahrl |
this should be documented in lua_api.txt |
| 21:04 |
sapier |
that's formspec behaviour as long as it's there ;-) but yes it could be made more clear |
| 21:06 |
|
sapier left #minetest-dev |
| 21:12 |
hmmmm |
btw i didn't look at the documentation at all until now and i agree it's crap |
| 21:30 |
proller |
all wingsuit sense is here https://github.com/minetest/minetest/pull/897/files#L2R564 |
| 21:31 |
proller |
if many peoples dislike it - it can be simply removed |
| 21:32 |
proller |
rest of pull - falling optimizing and bugfixing |
| 21:34 |
proller |
to start disliking it you must build something 150+ nodes high and jump |
| 21:39 |
|
Akien joined #minetest-dev |
| 21:39 |
kahrl |
I explained what I disliked and it wasn't related to jumping off a pole |
| 21:40 |
proller |
it was something with fast move, but what exactly? |
| 21:41 |
kahrl |
it makes it slower and disallows changing direction midair |
| 21:42 |
kahrl |
(this is fast_move without free_move) |
| 21:44 |
proller |
ok. its bug, fixing.. |
| 22:08 |
|
loggingbot_ joined #minetest-dev |
| 22:08 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 22:10 |
proller |
fixed |
| 22:18 |
proller |
now it disabled when e pressed |
| 22:23 |
kahrl |
ah that's much better |
| 22:23 |
kahrl |
still kicks in if you fall very far with fast_move but that's probably intended |
| 22:25 |
kahrl |
environment.cpp: In member function ‘virtual void ClientEnvironment::step(float)’: 2125:9: warning: unused variable ‘speedl’ [-Wunused-variable] |
| 22:32 |
proller |
speedl fixed |
| 22:33 |
proller |
what if falling very far? |
| 22:34 |
proller |
i tried - pressing e allow you to move at +20nps, but it much lower than fall speed |
| 22:35 |
kahrl |
well it's the same as wingsuit without fast_move |
| 22:36 |
kahrl |
but it doesn't come up during my normal usage of fast_move so I'm okay with it |
| 22:41 |
proller |
its because now air have viscosity |
| 22:42 |
proller |
and not very big speed loss |
| 22:42 |
proller |
commit whole? |
| 22:44 |
kahrl |
let's see what the others think |
| 22:48 |
celeron55 |
i continue to fail to see the point |
| 22:51 |
proller |
why? |
| 22:59 |
proller |
try to jump with it and without |
| 23:03 |
celeron55 |
isn't one of the points of falling that you fall and most probably die if you haven't planned on what you are standing? |
| 23:06 |
proller |
you have small chance to hit water |
| 23:06 |
proller |
most likely you die |
| 23:07 |
proller |
but it will be fun |
| 23:08 |
proller |
but somebody can make parachute mod |
| 23:13 |
celeron55 |
whatever, i can't really say no or yes and can't bother to check the code |
| 23:14 |
celeron55 |
the problem with this once again is that this is completely random coming out of nowhere |
| 23:15 |
celeron55 |
and there's no clue whatsoever into what kind of coherent whole it belongs |
| 23:16 |
celeron55 |
have you thought at all what does it do to the balance of the game? |
| 23:17 |
proller |
it add semi-hidden unique feature |
| 23:17 |
celeron55 |
if so, can you note down your thougths and also if there's something else you're about to do to get things more to the same direction |
| 23:17 |
proller |
and make falling not boring |
| 23:18 |
proller |
its good addition to floatlands and any sky-filling mod |
| 23:19 |
hmmmm |
falling is boring? |
| 23:19 |
proller |
in this direction - cant think anything except parachute mod |
| 23:19 |
celeron55 |
is it compatible with everything you can imagine? |
| 23:20 |
kahrl |
what would a parachute mod do? currently the wingsuit is hardcoded |
| 23:20 |
proller |
hmmmm, yes, now you can slowly move 4nps and cant fly around something |
| 23:21 |
proller |
kahrl, open parachute -> stop falling |
| 23:21 |
celeron55 |
i don't have anything against adding something that allows more useful movement in floatlands, but it's not like this is the only possible implementation on that |
| 23:22 |
celeron55 |
assuming the code is perfect, i think i'll give a yes for this altough i have no idea what i'm doing; you'll need an another yes still though |
| 23:23 |
celeron55 |
or, well, not really, but at least you need no 'no's 8) |
| 23:25 |
proller |
it doesnt touch usual gameplay wha can said 'no'? |
| 23:26 |
proller |
except PilzAdam of course |
| 23:32 |
proller |
maybe in future make changeable fly control value, for something like real wingsuit mod, but now now too few players to use it |
| 23:56 |
|
Shadowfire_ joined #minetest-dev |
| 23:56 |
hmmmm |
now why is it that a mod can't have the same effect |
| 23:56 |
hmmmm |
oh, this is movement speed control for the player |
| 23:56 |
PilzAdam |
mods can control the speed, but not the velocity itself |
| 23:57 |
hmmmm |
see, it certainly feels like proller is coding a lot of "specific" things that would be better as client-side mods |
| 23:57 |
PilzAdam |
mods can also limit the movement speed of the players, by setting gravity to 0 when the player reaches it |
| 23:57 |
hmmmm |
i feel a lot of what he does goes against the idea of minetest as no more than an engine |
