| Time |
Nick |
Message |
| 00:12 |
|
Jeija left #minetest-dev |
| 00:18 |
|
sapier1 joined #minetest-dev |
| 00:19 |
sapier1 |
https://github.com/celeron55/minetest/pull/383 -- This pull request is essential to take player <-> mob interaction to a new level plz review |
| 00:23 |
PilzAdam |
maybe it would be better to just add minetest.show_forspec_to_player(playername, formspec) |
| 00:23 |
sapier1 |
would this be linked to a detached inventory? |
| 00:24 |
PilzAdam |
you can always show detached inventories in formspec, if you mean this |
| 00:24 |
RealBadAngel |
thexyz, could you merge bugfixes to my code in formspec? https://github.com/celeron55/minetest/pull/382 |
| 00:25 |
sapier1 |
nice ... didn't know that I'm gonna have a try if only showing a formspec is enough |
| 00:25 |
PilzAdam |
https://github.com/celeron55/minetest/blob/master/doc/lua_api.txt#L763 |
| 00:26 |
thexyz |
RealBadAngel: later, better ask darkrose or PilzAdam now (it's 4:30am here) |
| 00:27 |
RealBadAngel |
sure |
| 00:27 |
RealBadAngel |
PilzAdam, can you? |
| 00:27 |
PilzAdam |
umm, its 1:30 AM here ;-) |
| 00:27 |
RealBadAngel |
same as here ;) |
| 00:28 |
RealBadAngel |
those are fixes to my own code |
| 00:32 |
RealBadAngel |
btw as a comment for c55's intentional stuff in cave generator: http://realbadangel.pl/clouds1.png |
| 00:34 |
RealBadAngel |
thats why im plain against it. its fucked up |
| 00:35 |
sapier1 |
@PilzAdam I'm gona change It as requested |
| 02:13 |
sapier1 |
@PilzAdam are you sure the pull request is updated? |
| 02:14 |
PilzAdam |
it has a commit form 21 minutes ago |
| 02:14 |
sapier1 |
strange now its correct ... |
| 02:15 |
VanessaE |
fwiw I show it being 18 minutes into the *future* |
| 02:15 |
sapier1 |
ok lets see if this is ok the problem I was talking about in minetest was lua only as soon as using detached inventories correct they work correct with this changes too |
| 02:16 |
PilzAdam |
sapier1, why do you add create_detached_fromspec()? |
| 02:16 |
PilzAdam |
why not just pass the formspec string to show_fromspec()? |
| 02:16 |
sapier1 |
to reduce number of bytes transfered |
| 02:17 |
PilzAdam |
can you always create detached formspecs? |
| 02:17 |
sapier1 |
formspecs sometimes get really big |
| 02:17 |
sapier1 |
I think so do you have an idea where this isn't possible? |
| 02:17 |
PilzAdam |
typo: line 893 of init.lua |
| 02:18 |
PilzAdam |
just asking if you have to create them on startup |
| 02:18 |
PilzAdam |
s/init.lua/lua-api.txt |
| 02:18 |
sapier1 |
no you may create them anytime |
| 02:19 |
sapier1 |
if you reuse a name it's updated ... same as for detached inventories |
| 02:19 |
PilzAdam |
missing ":" in 895 & 896 of lua-api.txt |
| 02:21 |
sapier1 |
I assumed formspecs do not change very often so doing it same way as inventories seemd to be reasonable to me |
| 02:46 |
|
iqualfragile1 joined #minetest-dev |
| 03:11 |
|
ecube joined #minetest-dev |
| 04:19 |
|
SpeedProg joined #minetest-dev |
| 04:49 |
|
hmmmm joined #minetest-dev |
| 04:58 |
|
hmmmm joined #minetest-dev |
| 05:02 |
|
hmmmm joined #minetest-dev |
| 05:04 |
|
sapier1 left #minetest-dev |
| 05:13 |
|
ShadowNinja_ joined #minetest-dev |
| 05:58 |
|
ecube joined #minetest-dev |
| 06:01 |
|
kaeza1 joined #minetest-dev |
| 06:51 |
celeron55 |
i think formspecs should be just sent directly like PilzAdam noted |
| 06:52 |
celeron55 |
there's no reason not to |
| 06:52 |
celeron55 |
it will make a very simple implementation |
| 07:34 |
hmmmm |
you know this is so kludgy the way i have it set up.. maybe the ServerEnvironment should have the EmergeManager |
| 07:35 |
hmmmm |
celeron, can you explain to me what the "environment" is? |
| 07:35 |
hmmmm |
i think i'm going to change this to make the mapgens on the EmergeManager ctor |
| 07:37 |
hmmmm |
actually i can't do that, the lua api is run before the server environment is created |
| 07:37 |
hmmmm |
what was your logic behind doing that? |
| 07:41 |
hmmmm |
you know what, i don't think it even matters anymore since i made the decision to make it not configurable from lua |
| 07:42 |
hmmmm |
ServerEnvironment's ctor will create EmergeManager, but i don't really know if it should be a member of Server or ServerEnvironment |
| 07:54 |
celeron55 |
the environment is the game's state |
| 07:55 |
hmmmm |
maybe what i have is appropriate, then |
| 07:55 |
celeron55 |
or, to speak in an OOP way, it's the game |
| 07:56 |
celeron55 |
i don't know if something that dynamically fetches stuff to be included in the game should be a part of the game or part of... the things that run the game |
| 07:57 |
celeron55 |
if such is put in the environment, then where is the limit? |
| 08:06 |
|
Jeija joined #minetest-dev |
| 08:16 |
|
serengeor joined #minetest-dev |
| 09:15 |
|
marktraceur joined #minetest-dev |
| 09:53 |
|
Calinou joined #minetest-dev |
| 10:28 |
|
marktraceur joined #minetest-dev |
| 10:34 |
|
SpeedProg1 joined #minetest-dev |
| 10:36 |
|
SpeedProg joined #minetest-dev |
| 10:43 |
|
sapier joined #minetest-dev |
| 10:44 |
sapier |
hello, is there any reason why inv reference in on_move of a detached inventory is a different value than invref returned on create of detached inventory? |
| 11:13 |
|
marktraceur joined #minetest-dev |
| 11:40 |
|
serengeor_ joined #minetest-dev |
| 11:43 |
|
serengeor joined #minetest-dev |
| 11:44 |
|
bnd joined #minetest-dev |
| 12:00 |
|
Jeija joined #minetest-dev |
| 12:26 |
|
kaeza1 joined #minetest-dev |
| 12:45 |
|
Jeija left #minetest-dev |
| 12:46 |
|
jin_xi joined #minetest-dev |
| 12:51 |
|
serengeor joined #minetest-dev |
| 13:27 |
|
PilzAdam joined #minetest-dev |
| 13:40 |
PilzAdam |
This post http://minetest.net/forum/viewtopic.php?pid=61211#p61211 says that the attachment bug isnt completly fixed |
| 14:14 |
celeron55 |
how so? the official 0.4.4 release has the bug |
| 14:14 |
celeron55 |
and the fix was client-side |
| 14:15 |
celeron55 |
hmm... actually, if falling nodes are affected, then there is something wrong on the server side |
| 14:16 |
celeron55 |
i guess content_sao.* needs to be looked through |
| 14:19 |
|
marktraceur joined #minetest-dev |
| 14:20 |
RealBadAngel |
hi |
| 14:21 |
RealBadAngel |
can anyone merge fixes to my code? https://github.com/celeron55/minetest/pull/382 |
| 14:24 |
thexyz |
what does it fix? |
| 14:25 |
RealBadAngel |
item_image method |
| 14:26 |
thexyz |
how about being more precise?) |
| 14:26 |
RealBadAngel |
It fixes some missing code in implementation of formspec's item_image method. |
| 14:27 |
thexyz |
so, it was not working before, right? |
| 14:27 |
RealBadAngel |
yes |
| 14:28 |
thexyz |
fine |
| 14:29 |
RealBadAngel |
i havent noticed the missing part (strange since i had that on my local copy) because i wasnt using it |
| 14:29 |
RealBadAngel |
just Muvebic tried to use it and ask me to fix it |
| 14:31 |
kaeza |
PilzAdam: how can I find the *exact* MT version I have? i.e including the date? |
| 14:31 |
|
marktraceur joined #minetest-dev |
| 14:34 |
thexyz |
RealBadAngel: pushed |
| 14:34 |
RealBadAngel |
thx |
| 14:36 |
RealBadAngel |
i will have later on today another pull to the treegen. adding new turtle commands, with selectable angles |
| 14:36 |
thexyz |
ok |
| 14:36 |
thexyz |
but don't break windows builds that time, plz |
| 14:36 |
sapier |
is https://github.com/celeron55/minetest/pull/383 in shape to be merged? |
| 14:37 |
RealBadAngel |
thexyz, im tryin to learn from my lessons |
| 14:37 |
sapier |
it adds triggering display of formspec via lua |
| 14:37 |
thexyz |
sapier: that change affects networking, better cast celeron55 here |
| 14:38 |
thexyz |
from what I see you didn't modify PROTOCOL_VERSION |
| 14:38 |
thexyz |
RealBadAngel: fine |
| 14:39 |
RealBadAngel |
thexyz, one more thing, according to yesterdays debate on cave gen. have you seen already this: http://realbadangel.pl/clouds1.png ? |
| 14:40 |
thexyz |
no, I haven't |
| 14:41 |
RealBadAngel |
just click and comment |
| 14:41 |
sapier |
yes changes are additions client will still work with older servers as well as client will ignore messages from newer servers ... I didn't know when protocol version needs to be changed |
| 14:45 |
RealBadAngel |
thexyz, and? |
| 14:46 |
thexyz |
I see, that should be fixed |
| 14:46 |
thexyz |
let me check logs |
| 14:47 |
RealBadAngel |
i agree. but c55 said that was intentional, and im plain against mapgen at all |
| 14:47 |
thexyz |
http://irc.minetest.ru/minetest-dev/2013-01-01#i_2773098 |
| 14:49 |
RealBadAngel |
i agree to make holes in the montains |
| 14:49 |
RealBadAngel |
but not in outer space for christ sake |
| 14:50 |
RealBadAngel |
no matter how high will you go dozens of caves will generate around you |
| 14:51 |
thexyz |
I mean, better discuss it with hmmmm |
| 14:51 |
thexyz |
not with me |
| 14:51 |
RealBadAngel |
hmmm said he wont touch cave gen |
| 14:51 |
RealBadAngel |
hes doin mapgen and goin to move cavegen to its own file |
| 14:53 |
|
iqualfragile joined #minetest-dev |
| 14:53 |
thexyz |
then just wait for new mapgen |
| 14:53 |
RealBadAngel |
yup, but the cave gen will be still broken then |
| 14:53 |
sapier |
can anyone tell me if doing a compatible proctocol change requires increasing PROTOCOL_VERSION too? |
| 14:54 |
RealBadAngel |
i proposed just some fine tuning, not revolutions |
| 14:54 |
thexyz |
though that can make maps inconsistent (if part of cave is already generated) |
| 14:55 |
RealBadAngel |
small pain in some map parts |
| 14:55 |
RealBadAngel |
and great speed up overall |
| 14:55 |
RealBadAngel |
anyway, with new mapgen all will be forced to make new maps |
| 14:56 |
RealBadAngel |
all the ore generation mods will change |
| 14:56 |
RealBadAngel |
plants, trees |
| 14:58 |
RealBadAngel |
why to cry over some non regular caves? |
| 14:58 |
RealBadAngel |
wait, in fact BELOW ground level nothin will change |
| 14:59 |
iqualfragile |
new mapgen? awsome! |
| 14:59 |
iqualfragile |
(is there some code already? |
| 14:59 |
iqualfragile |
) |
| 14:59 |
RealBadAngel |
https://github.com/kwolekr/minetest |
| 14:59 |
RealBadAngel |
you can test it out |
| 15:00 |
RealBadAngel |
some stuff works alredy, some not |
| 15:01 |
sapier |
is everything moved to lua a year ago moveing back to core atm? |
| 15:02 |
iqualfragile |
what are the improvements over the old mapgen? |
| 15:02 |
PilzAdam |
its modifyable by Lua |
| 15:02 |
thexyz |
sapier: why do you think so? |
| 15:02 |
PilzAdam |
(see minimal mapgen.lua) |
| 15:02 |
PilzAdam |
(or init.lua, dunno) |
| 15:02 |
sapier |
it's only my impression of last two weeks that's why I'm asking |
| 15:03 |
sapier |
and of course in that case I'd probably rewrite mobf in c++ ... would be much faster :) |
| 15:04 |
sapier |
although 1.9x series of mobf is quite performant ... except the spawners |
| 15:04 |
RealBadAngel |
IMHO you should. and make it fully configurable from Lua |
| 15:05 |
iqualfragile |
yeah, but only if its added to default |
| 15:05 |
RealBadAngel |
all time consuming and repetitive calulations done within the core |
| 15:06 |
RealBadAngel |
Lua just to config it |
| 15:06 |
sapier |
It's far to much work to do it at once if doing so this would be step by ste e.g. c++ify spawners first ... movement generators .. |
| 15:06 |
iqualfragile |
or: add a pathfinding-routine to the engine, that would be usefull |
| 15:06 |
sapier |
if you do require time consuming calculations for mobs you're doing something wrong ;-) |
| 15:06 |
RealBadAngel |
simple example, Lua needed 2-3 seconds on my box to spawn a big tree |
| 15:07 |
sapier |
yes pathfinding would be a use case for lua too |
| 15:07 |
RealBadAngel |
in c++ its nearly instant |
| 15:07 |
sapier |
you do handle thousands of nodes for a tree ... when does a mob require to touch that many nodes? |
| 15:07 |
RealBadAngel |
when i replaced default trees with L-system ones, i just played with them |
| 15:08 |
RealBadAngel |
with no lags |
| 15:08 |
|
marktraceur joined #minetest-dev |
| 15:08 |
RealBadAngel |
btw, technic from today on uses L-system tree for Rubber Tree |
| 15:08 |
sapier |
doing a c++ call from lua is a nightmare so switching to c++ for small calculations most likely will result in performance degrading instead of increasing |
| 15:09 |
RealBadAngel |
http://realbadangel.pl/rubber_trees.png |
| 15:09 |
RealBadAngel |
sapier, i can help you with that |
| 15:10 |
RealBadAngel |
ive added already some stuff to scriptapi.cpp |
| 15:10 |
sapier |
@RealBadAngel I'm skilled in c++ too, it's not a matter of skills it's a matter of decision what's worth to be in c++ and what ain't |
| 15:11 |
RealBadAngel |
time consuming -> c++ |
| 15:11 |
sapier |
ok so we need configurable spawners |
| 15:11 |
sapier |
that's by far most time consuming task |
| 15:12 |
sapier |
I've removed any abm based spawner from mobf and got from lag level "not playable" to "no lag at all" |
| 15:12 |
iqualfragile |
and its a question of overhead |
| 15:12 |
RealBadAngel |
ABM's are not workin right |
| 15:13 |
|
serengeor joined #minetest-dev |
| 15:13 |
RealBadAngel |
one badly wrote ABM can destroy whole system |
| 15:13 |
sapier |
but first https://github.com/celeron55/minetest/pull/383 should be reviewed and added :-) |
| 15:13 |
RealBadAngel |
in fact, is able to DISABLE ABM's |
| 15:14 |
RealBadAngel |
you can do a test, make an ABM and inside it infinite loop |
| 15:14 |
sapier |
abm's sometimes aren't way to do it ... e.g. spawn birds in air ... that abm is a performance killer |
| 15:15 |
sapier |
I've abms running < 3ms but for what I require them to do they need to be called far to often |
| 15:16 |
RealBadAngel |
make your own pseudo abm handler |
| 15:16 |
RealBadAngel |
based on dtime |
| 15:16 |
sapier |
I've found a solution capable for the moment but having a spawning mechanism to configure in core would be far better ;-) |
| 15:18 |
RealBadAngel |
c55 wrote somethin yesterday, lemme find it |
| 15:20 |
RealBadAngel |
http://pastebin.com/q7GaMPJG |
| 15:21 |
RealBadAngel |
ive cut a part ;) |
| 15:23 |
RealBadAngel |
http://irc.minetest.ru/minetest-dev/2013-01-01#i_2772669 |
| 15:23 |
sapier |
tztz ... |
| 15:23 |
RealBadAngel |
better read here |
| 15:24 |
sapier |
.. couple of hours to add mobs ... with respect to celeron that'd be very very simple mobs |
| 15:24 |
* PilzAdam |
points at simple mobs mod |
| 15:25 |
sapier |
as name tells it "simple" ... ;-) |
| 15:25 |
sapier |
btw simple as in copy n paste each mob ... i hate copy n paste |
| 15:25 |
RealBadAngel |
simple or not, i dont really what plain sprite has to do with creativity |
| 15:25 |
RealBadAngel |
*understand |
| 15:26 |
RealBadAngel |
easier to create, or what? |
| 15:27 |
sapier |
If ppl would have a look at doc they'd know how simple creating a mob in mof is ... it's even less work as socalled "simple mobs" |
| 15:27 |
RealBadAngel |
just make a fully workin implementation |
| 15:28 |
sapier |
yes there were performance issues ... because of spawning |
| 15:28 |
RealBadAngel |
and show it works |
| 15:28 |
sapier |
it's already done in lua ... and it'd be a blueprint for c++ implementation as its written like c++ code |
| 15:28 |
RealBadAngel |
so did i with trees |
| 15:29 |
sapier |
probably that c++ style is why others don't like mobf |
| 15:29 |
iqualfragile |
rotatable hitboxes would be usefull |
| 15:29 |
RealBadAngel |
Lua version was not usable, just a proof of concept |
| 15:29 |
sapier |
yea thats a big issue with mobs |
| 15:30 |
RealBadAngel |
i had even to rewrite in Lua some methods aviable in irrlicht core |
| 15:30 |
sapier |
mobf is usable I run it at 1 core 512MB ram @2.1Ghz without any lag |
| 15:30 |
sapier |
was lot's of work to find out where performance vanished but it's done |
| 15:30 |
RealBadAngel |
which was plain stupid |
| 15:31 |
sapier |
true ;-) |
| 15:31 |
sapier |
who is celeron56? :-) |
| 15:37 |
|
marktraceur joined #minetest-dev |
| 15:38 |
serengeor |
sapier, celeron55++ |
| 15:38 |
RealBadAngel |
new year, new celeron ;) |
| 15:39 |
sapier |
:-) hmm ok my client makes sapier to sapier1 at reconnect too ... probably it'd make it to sapier2 if i was sapier1 |
| 15:44 |
iqualfragile |
celeron55: do you live in oulu? |
| 15:48 |
sapier |
btw problem with rotating collisionboxes is missing collision handling for non axis aligned or non block shaped boxes |
| 15:49 |
iqualfragile |
hmm… i think another perlin-noise-map would be usefull: pressure |
| 15:49 |
iqualfragile |
(for caves and airstuff) |
| 15:50 |
sapier |
but pressure ain't a random value? |
| 15:54 |
iqualfragile |
no, its a perlin-value! |
| 15:54 |
iqualfragile |
& biomes need a skycolor or skycolorramp atribute |
| 15:54 |
sapier |
i thought perlin is just some sort of random like value |
| 15:55 |
iqualfragile |
it is, but its awsome, too |
| 15:55 |
iqualfragile |
what else would you make pressure dependent on? |
| 15:59 |
|
doserj joined #minetest-dev |
| 16:05 |
sapier |
hmm distance to non solid ground weighted by xz and y direction |
| 16:06 |
sapier |
asof xz distance being 20% if presure value while y is 80% |
| 16:06 |
sapier |
just a suggestion for numbers |
| 16:08 |
celeron55 |
iqualfragile: depends on why you ask |
| 16:08 |
iqualfragile |
i have met someone from there last summer |
| 16:08 |
iqualfragile |
& why is there a celeron56? |
| 16:10 |
sapier |
@celeron55 any chance to get this https://github.com/celeron55/minetest/pull/383 merged? If adding servermessage requires proctocol version change even for complatible changes I'll fix this asap. |
| 16:11 |
celeron55 |
sapier: i already commented that |
| 16:12 |
celeron55 |
08:57:39 < celeron55> i think formspecs should be just sent directly like PilzAdam noted |
| 16:12 |
celeron55 |
08:57:45 < celeron55> there's no reason not to |
| 16:12 |
celeron55 |
08:57:55 < celeron55> it will make a very simple implementation |
| 16:12 |
sapier |
I don't think so ... but I'll change either as I do need formspec support |
| 16:13 |
sapier |
you know this gonna result in lots of memory operations? |
| 16:22 |
|
rubenwardy joined #minetest-dev |
| 16:30 |
|
Calinou joined #minetest-dev |
| 16:44 |
|
sapier1 joined #minetest-dev |
| 16:47 |
|
sapier joined #minetest-dev |
| 16:47 |
|
vgdg joined #minetest-dev |
| 17:01 |
|
marktraceur joined #minetest-dev |
| 17:05 |
|
nyuszika7h joined #minetest-dev |
| 17:11 |
sapier |
another try: https://github.com/celeron55/minetest/pull/384 -> removed detached formspec support, updated protocol version |
| 17:13 |
|
marktraceur joined #minetest-dev |
| 17:14 |
celeron55 |
sapier: "showDetachedInv: couldn't find player" |
| 17:15 |
|
hmmmm joined #minetest-dev |
| 17:15 |
celeron55 |
also, you changed an error message in get_item_callback to be specific to detached inventories while it is a generic function |
| 17:16 |
celeron55 |
the std::string* thing is silly but it's indeed necessary because of the union |
| 17:17 |
celeron55 |
you should add a comment to it so it's clear |
| 17:18 |
sapier |
ok I changed that error message because it wasn't unique and you couldn't determine where it was originating from. I'll change the typo and rebase |
| 17:18 |
sapier |
but if you don't like it I change it back |
| 17:19 |
celeron55 |
change the three things i said |
| 17:19 |
celeron55 |
or, well, 1) change, 2) change back and 3) add |
| 17:19 |
sapier |
i do |
| 17:24 |
celeron55 |
the PROTOCOL_VERSION change probably behaves well enough now - when a 0.4.4 client connects to current server, it will work otherwise but it will receive a warning message in chat; all other cases work normally |
| 17:25 |
celeron55 |
(and, of course, in that case the formspec won't show up) |
| 17:25 |
celeron55 |
sapier: add a space after the comma in mminetest.show_formspec(playername,formspec) |
| 17:25 |
celeron55 |
-m |
| 17:26 |
|
marktraceur joined #minetest-dev |
| 17:26 |
sapier |
added .. true client still can connect to old servers I checked that |
| 17:33 |
celeron55 |
hmm |
| 17:34 |
celeron55 |
what happens if you show a formspec when one is already showing |
| 17:34 |
celeron55 |
it should be possible to update it, but that will do something... odd |
| 17:35 |
sapier |
hmm ... good question ... I'm gonna try what happens |
| 17:35 |
celeron55 |
game.cpp should somehow see that a FormspecFormSource exists, and update it there |
| 17:35 |
celeron55 |
also, don't use a string pointer in FormspecFormSource, you already have a memory leak in there because of it |
| 17:36 |
celeron55 |
(IFormSource exists exactly for that - to be able to update the formspec that is already showing up on screen) |
| 17:37 |
celeron55 |
i think you could add an std::string variable inside the_game and pass and store a reference to it in FormspecFormSource |
| 17:37 |
celeron55 |
so then you can... umm... |
| 17:37 |
celeron55 |
get more problems! |
| 17:37 |
sapier |
guiformspec is somehow complicated :-) |
| 17:38 |
sapier |
there are so many ways to get same thing ... |
| 17:39 |
celeron55 |
the FormspecFormSource needs to set the variable in the_game to "" when it is destructed, so then the code that launches a formspec with a FormspecFormSource can check that if it is "", then launch a new one, otherwise just change the variable (so that FormspecFormSource gets the updated value via the variable reference it has) |
| 17:39 |
sapier |
I don't see a memory leak by now where is it? |
| 17:39 |
celeron55 |
hmm, no, there isn't any |
| 17:39 |
celeron55 |
didn't see that you actually had a proper destructor in there 8) |
| 17:40 |
celeron55 |
did you understand what i said or do i need to do it myself? (not that big a task) |
| 17:41 |
sapier |
:-) there was a memory leak around this place in former pull request .. no I don't understand but I think I'll find out |
| 17:42 |
hmmmm |
just wondering, why isn't environment metadata loaded in ServerEnvironment's constructor? |
| 17:42 |
celeron55 |
the end result will be weird but will work very well |
| 17:43 |
|
rubenwardy joined #minetest-dev |
| 17:43 |
celeron55 |
hmmmm: where is it loaded? |
| 17:43 |
hmmmm |
after the object's been created, in the Server ctor |
| 17:43 |
hmmmm |
kind of struck me as odd |
| 17:44 |
celeron55 |
is there an example of a similar thing done in an other way somewhere |
| 17:44 |
celeron55 |
or why do you ask |
| 17:44 |
hmmmm |
well map meta is loaded in ServerMap::ServerMap, so you'd expect env meta to be loaded in ServerEnvironment::ServerEnvironment, that's all |
| 17:45 |
hmmmm |
it's not a problem |
| 17:45 |
hmmmm |
tbh what i have right now isn't a problem either, it just strikes me as being kludgy |
| 17:47 |
celeron55 |
i don't really know how that should be; altough i can see that as it currently is, the environment doesn't have to store a yet-another copy of the world location |
| 17:48 |
celeron55 |
these days i generally think serialization shouldn't be part of the object that is serialized, but it's completely backwards to how minetest is constructed 8) |
| 17:49 |
celeron55 |
what is more important is having a consistent way of doing it |
| 17:52 |
celeron55 |
the fact that things are dynamically loaded, saved and unloaded makes it hard to make reasonably structured code |
| 17:54 |
celeron55 |
there would need to be an abstracted backend for the storage of everything, which... well, i wonder if anyone has time and skill for designing anything like that |
| 17:55 |
celeron55 |
it's again one of those "oh hey, let's recode half of minetest for no visible benefit" thins |
| 17:55 |
celeron55 |
things* |
| 17:59 |
sapier |
yes but one of those maintenance things saving lots of work when summarizing all that small saves on future work |
| 18:00 |
celeron55 |
maybe, but a rewrite of everythin easily ends up being just an another kind of mess |
| 18:00 |
celeron55 |
+g |
| 18:00 |
celeron55 |
it needs to be done well too |
| 18:01 |
sapier |
yes if rewrite is done by someone not having experience from first write, outcome most likely won't be better at all |
| 18:02 |
|
rubenwardy left #minetest-dev |
| 18:02 |
sapier |
I'm testing what happens on update while formspec still shown prior pushing new version |
| 18:12 |
|
doserj joined #minetest-dev |
| 18:13 |
|
Taoki[laptop] joined #minetest-dev |
| 18:16 |
sapier |
@celeron ok I've checked it's updating formspec correctly if called while formspec shown. I hope I understood what you wanted me to do in the_game |
| 18:20 |
thexyz |
>sapier merged commit 5d18dc3 into celeron55:master from sapier:simple_luaformspec 10 minutes ago |
| 18:20 |
thexyz |
how? |
| 18:20 |
hmmmm |
things don't need a rewrite |
| 18:21 |
hmmmm |
it'll probably turn out down the line that your new abstraction didn't really make things much easier |
| 18:21 |
thexyz |
oh, wait, you merged 0 commits, seems legit |
| 18:22 |
hmmmm |
alright so the order of events i changed this to is: create BiomeDefManager, load biomes from lua, then ServerMap's ctor writes the MapgenParams which the EmergeManager takes as a parameter and creates the Mapgen objects with |
| 18:23 |
hmmmm |
indeed it's probably best that i don't create the BiomeDefManager along with the EmergeManager since they are separate entities, it just so happens that it's useful to have a biomedef associated with the emergemanager |
| 18:24 |
sapier |
@thexyz I don't know I updated my branch only |
| 18:37 |
celeron55 |
looks like github bugged somehow |
| 18:37 |
sapier |
hmm i'm rechecking if there's updated what I intended to update |
| 18:38 |
celeron55 |
your branch looks good otherwise, but you really should get rid of the heap-allocated std::string in there |
| 18:38 |
celeron55 |
it's totally unnecessary |
| 18:38 |
celeron55 |
just make it a non-pointer |
| 18:52 |
sapier |
ok ... changed and checked |
| 18:58 |
celeron55 |
sapier: pushed to c55/master |
| 18:59 |
celeron55 |
wait a second |
| 18:59 |
sapier |
whats wrong? |
| 18:59 |
celeron55 |
changed the commit message a bit 8) |
| 18:59 |
celeron55 |
now it's good |
| 18:59 |
sapier |
I see :) .. thx now I can releas my all new trader mob :-) |
| 19:04 |
celeron55 |
changed the version to 0.4.4-d1 so people have something to call it |
| 19:04 |
celeron55 |
(PROTOCOL_VERSIONs are kind of hard to remember...) |
| 19:06 |
sapier |
true :-) a marker is good in such cases |
| 19:13 |
|
TB|Vibe-X joined #minetest-dev |
| 19:13 |
|
doserj joined #minetest-dev |
| 19:51 |
sapier |
is there any chance to add a unique inventory id to invref? |
| 19:52 |
celeron55 |
unique in what context |
| 19:55 |
sapier |
create_detached_inventory returns a different invref as passed to callbacks |
| 19:56 |
celeron55 |
yes, invref is just a reference to a real inventory |
| 19:57 |
celeron55 |
so you need a way to compare invrefs to each other? |
| 19:57 |
celeron55 |
why |
| 19:58 |
sapier |
my trader creates a different detached inventory for any mob created |
| 19:58 |
sapier |
functions called on_move ... are same for everyone |
| 19:58 |
sapier |
so those functions need a way to decide which entity they are linked |
| 19:58 |
sapier |
atm I'm doing this by using a list |
| 19:59 |
sapier |
adding an item with a unique name |
| 19:59 |
sapier |
it works but it's a hack |
| 20:01 |
celeron55 |
hmm, so you essentially want server instance global ids... lua shouldn't see any ids though, because they aren't world-persistent; it should be able to compare the invrefs |
| 20:04 |
celeron55 |
what if there was InvRef:get_location() |
| 20:05 |
celeron55 |
that would return a similar thing that minetest.get_inventory takes as a parameter |
| 20:05 |
sapier |
detached_inventorys are already created by name probably this may be used? |
| 20:05 |
sapier |
invref->get_name() for example |
| 20:05 |
celeron55 |
minetest.get_inventory(location) -> InvRef |
| 20:05 |
celeron55 |
^ location = eg. {type="player", name="celeron55"} {type="node", pos={x=, y=, z=}} {type="detached", name="creative"} |
| 20:06 |
celeron55 |
i think InvRef:get_location() -> eg. {type="player", name="celeron55"} {type="node", pos={x=, y=, z=}} {type="detached", name="creative"} is the trivial solution |
| 20:07 |
sapier |
is it possible to compare those invrefs to those supplied to on_move ? |
| 20:07 |
celeron55 |
because that location is what an invref actually stores |
| 20:07 |
sapier |
InvRef:get_location() is good |
| 20:14 |
celeron55 |
i'll make that shortly |
| 20:26 |
|
bnd joined #minetest-dev |
| 20:33 |
celeron55 |
sapier: try this http://paste.dy.fi/u3N/plain |
| 20:45 |
sapier |
@celeron55 you're missing "method(InvRef, get_location)," but after adding it's working fine (at least for detached inventorys) |
| 20:48 |
celeron55 |
hmm, i guess i'll make it never return null but rather {type="undefined"} |
| 20:48 |
celeron55 |
easier to handle in scripts |
| 20:51 |
|
marktraceur joined #minetest-dev |
| 20:51 |
|
marktraceur joined #minetest-dev |
| 20:53 |
celeron55 |
it's there |
| 20:54 |
sapier |
thanks |
| 21:04 |
* PilzAdam |
points at 2 commits: https://github.com/PilzAdam/minetest/commits/random_stuff |
| 21:09 |
celeron55 |
why is damage_flash an s32 |
| 21:09 |
celeron55 |
it should be float |
| 21:10 |
PilzAdam |
why? |
| 21:10 |
celeron55 |
to not lose timing precision |
| 21:10 |
celeron55 |
for example, try to run the game now so that dtime is less than 10ms |
| 21:10 |
celeron55 |
the red will stay on the screen continuously |
| 21:11 |
PilzAdam |
ok |
| 21:14 |
celeron55 |
was there a patch somewhere that will make the camera tilt rather than flash something on the screen? |
| 21:16 |
PilzAdam |
fixed |
| 21:17 |
PilzAdam |
IIRC Jeija has a patch for that |
| 21:17 |
PilzAdam |
but it was buggy |
| 21:20 |
|
marktraceur joined #minetest-dev |
| 21:20 |
|
marktraceur joined #minetest-dev |
| 21:21 |
thexyz |
https://github.com/minetest/minetest/commit/9f02e3395e0df8896a65604fb1b8b79b2b7b9584 |
| 21:21 |
celeron55 |
can thexyz test those PilzAdam's things, i i'm going to sleep in a short time |
| 21:21 |
thexyz |
it doesn't work well when you're damaged continuously (like in lava) |
| 21:21 |
celeron55 |
-i |
| 21:25 |
PilzAdam |
mapgen_sapling doesnt exist so this change wont work |
| 21:27 |
PilzAdam |
fixed |
| 21:29 |
PilzAdam |
thexyz, could you review this 2 commits? |
| 21:30 |
thexyz |
sure |
| 21:38 |
thexyz |
PilzAdam: damage flash doesn't work perfect, some times screen blinks with red instead of slowly fading out (probably related to getting damaged multiple times) |
| 21:38 |
|
Jeija joined #minetest-dev |
| 21:39 |
|
Jeija joined #minetest-dev |
| 21:42 |
PilzAdam |
thexyz, repull |
| 21:43 |
PilzAdam |
I changed it so the damage_flash is decreased after drawing so negativ values cant be passed to the drawing method |
| 21:45 |
thexyz |
it'd be better for you to rebase after review and before pushing to main repo so I can easily see changes |
| 21:45 |
thexyz |
ok, testing this one |
| 21:47 |
thexyz |
seems fine |
| 21:53 |
|
doserj joined #minetest-dev |
| 23:02 |
|
rsiska joined #minetest-dev |
| 23:09 |
|
kaeza1 joined #minetest-dev |
| 23:16 |
|
sema4 joined #minetest-dev |
| 23:23 |
|
Jeija left #minetest-dev |
| 23:40 |
|
doserj joined #minetest-dev |
