| Time |
Nick |
Message |
| 00:01 |
VanessaE |
[07-15 20:00] <VanessaE> wtf is force-loading that block [at map coordinates 0,0,0]? |
| 00:01 |
VanessaE |
[07-15 20:00] <cheapie> It appears that when you first join a server, the client "thinks" you're at 0,0,0 until the server tells it otherwise. |
| 00:01 |
VanessaE |
is this true?> |
| 00:01 |
VanessaE |
[07-15 20:01] <cheapie> The client, meanwhile, is requesting mapblocks for that area. |
| 00:01 |
VanessaE |
[07-15 20:01] <cheapie> When I join servers, especially slow ones, I can see my position start at 0,0,0 and then change to the correct value. |
| 00:01 |
VanessaE |
can someone confirm this so I can perhaps stop chasing this wild goose? |
| 00:01 |
cheapie |
(I have debug mode set to always enabled in my minetest.conf) |
| 00:02 |
VanessaE |
(other than the client doesn't so much request, as the server just sends; there is no mechanism for the client to explicitly request a mapblock) |
| 00:02 |
cheapie |
Oh, OK. |
| 00:03 |
VanessaE |
yeah maybe that is it, because now I'm not seeing those blocks when I first join, so they aren't force-loaded for mw |
| 00:03 |
VanessaE |
me* |
| 00:03 |
VanessaE |
whew. that's a relief |
| 00:06 |
|
AnotherBrick joined #minetest-dev |
| 02:02 |
|
CraigyDavi` joined #minetest-dev |
| 02:15 |
|
cheapie joined #minetest-dev |
| 02:28 |
|
CraigyDavi`` joined #minetest-dev |
| 03:19 |
|
VargaD joined #minetest-dev |
| 04:36 |
|
CraigyDavi joined #minetest-dev |
| 04:41 |
|
Eater4 joined #minetest-dev |
| 05:31 |
|
CraigyDavi` joined #minetest-dev |
| 05:36 |
|
RealBadAngel joined #minetest-dev |
| 05:36 |
|
Zeno` joined #minetest-dev |
| 05:39 |
RealBadAngel |
hi |
| 05:40 |
RealBadAngel |
ShadowNinja, here? |
| 05:41 |
|
Hunterz joined #minetest-dev |
| 06:03 |
|
grrk-bzzt joined #minetest-dev |
| 06:05 |
|
Jordach joined #minetest-dev |
| 06:05 |
|
Jordach joined #minetest-dev |
| 06:14 |
|
LemonLake joined #minetest-dev |
| 06:29 |
Zeno` |
RealBadAngel, I made a mistake |
| 06:30 |
Zeno` |
RealBadAngel, https://github.com/minetest/minetest/issues/1469 |
| 06:31 |
Zeno` |
The random seed not being provided and therefore (probably) being 0+14002 is "sort of an issue" still though |
| 06:31 |
Zeno` |
It seems that VE would like a random seed if one is not explicitly provided |
| 06:33 |
Zeno` |
Also, not providing random_level will cause a crash (dunno if this is a bug or not though) |
| 06:34 |
Zeno` |
Since it crashes every time I guess the "bug" could be viewed as kind of like a compiler error. I don't know what you guys deem appropriate for something like that though. |
| 06:48 |
|
Garmine joined #minetest-dev |
| 07:09 |
RealBadAngel |
Zeno`, sorry i havent had a chance to check the code |
| 07:10 |
RealBadAngel |
i will analyze it later today |
| 07:11 |
Zeno` |
RealBadAngel, no rush. I actually think it's ok as-is, but the mod people I've spoken to disagree (regarding the seed). |
| 07:12 |
Zeno` |
I guess the question is "if a seed is not explicitly provided should a random or constant be assigned" |
| 07:12 |
Zeno` |
And there are good arguments on both sides of the coin |
| 07:13 |
RealBadAngel |
before PA forced me to use seeds i tried to make the code as random as possible |
| 07:13 |
|
CraigyDavi joined #minetest-dev |
| 07:14 |
Zeno` |
well, at the moment there is no seed unless one is specified from Lua. I guess the confusion stems from the API docs because it "seems" unimportant |
| 07:14 |
RealBadAngel |
thats why for example tree models are using so many "twists" |
| 07:14 |
Zeno` |
I think either side of the argument could be supported... tough decision |
| 07:15 |
Zeno` |
What does the Lua interface give the seed value if it's undefined? Is it 0? |
| 07:15 |
RealBadAngel |
idk |
| 07:15 |
Zeno` |
I guess I can look that up later |
| 07:16 |
RealBadAngel |
mt is too complex project for one person to know everything |
| 07:17 |
Zeno` |
yeah of course, just thought you may know though (it's a Lua question btw... as in embedded Lua, not really MT-related) |
| 07:19 |
Zeno` |
https://github.com/minetest/minetest/blob/master/src/script/lua_api/l_env.cpp#L760 |
| 07:19 |
Zeno` |
that is the line I think everyone is talking about |
| 07:20 |
Zeno` |
the "field" that none of the mods seem to set |
| 07:20 |
|
CraigyDavi` joined #minetest-dev |
| 07:20 |
Zeno` |
anyway, in your hands :p ;) |
| 07:33 |
Zeno` |
probably -1 from a preliminary perusal |
| 07:35 |
|
CraigyDavi joined #minetest-dev |
| 07:41 |
Zeno` |
scrap that, it /might/ be undefined |
| 07:42 |
Zeno` |
i.e. c_converter.cpp does not set *result if lua_isnumber() returns 0 |
| 07:47 |
|
Calinou joined #minetest-dev |
| 08:01 |
|
Krock joined #minetest-dev |
| 08:01 |
|
CraigyDavi` joined #minetest-dev |
| 08:20 |
|
cheapie joined #minetest-dev |
| 08:33 |
|
cheapie joined #minetest-dev |
| 08:35 |
|
CraigyDavi joined #minetest-dev |
| 08:36 |
|
smoke_fumus joined #minetest-dev |
| 08:54 |
|
Calinou joined #minetest-dev |
| 09:44 |
|
proller joined #minetest-dev |
| 09:48 |
|
hax404 joined #minetest-dev |
| 10:05 |
|
PenguinDad joined #minetest-dev |
| 10:14 |
|
sapier joined #minetest-dev |
| 10:59 |
|
proller joined #minetest-dev |
| 11:19 |
Krock |
ShadowNinja, could you check this one https://github.com/SmallJoker/minetest/commit/e2a40d6feed256be2645fd07ebc387bc11ced6fc for correctness? |
| 11:23 |
proller |
unsapierizing code 8-) |
| 11:34 |
sapier |
more fixing code I refused to fix becase by someone who promised to do it years ago didn't |
| 11:35 |
sapier |
same as sfan5 not having added speaking color names as he promised about a year ago |
| 11:35 |
proller |
s/years/ year/ |
| 11:35 |
proller |
s/didn't/done half year ago/ |
| 11:36 |
|
Jordach joined #minetest-dev |
| 11:37 |
sfan5 |
sapier: I did not promise adding color names |
| 11:37 |
sapier |
hmm not sure if it's a problem or an additional feature but this code would cause ANY element sent to be transfered to lua not those we support only |
| 11:48 |
sapier |
well that's been my requiremen to agree to that commit at all |
| 11:48 |
sapier |
I know ppl forget things like that ... therefore I'll not agree to things "to be done later" ... learned my lesson |
| 11:50 |
Zeno` |
two questions: const char *str = it.memberName(); <---- will that (pointer) remain in scope, OR does lua_pushstring() make a "deep copy" of the string? |
| 11:52 |
Zeno` |
it.membername() is quite different to a string constant which the removed code uses |
| 11:52 |
Zeno` |
depending on how lua_pushstring() works it may, or may not, be an issue |
| 11:52 |
sfan5 |
http://pgl.yoyo.org/luai/i/lua_pushstring |
| 11:52 |
sfan5 |
>Lua makes (or reuses) an internal copy of the given string, [...] |
| 11:53 |
Zeno` |
If it were me I'd look further then |
| 11:55 |
Zeno` |
it.memberName() obviously returns a pointer to a string, but is that (pointer) guaranteed to stay valid? |
| 11:55 |
Zeno` |
the removed code uses string literals so they /are/ guarenteed to remain valid |
| 11:57 |
sfan5 |
Zeno`: depends on the 'it' class |
| 11:57 |
Zeno` |
sfan5, of course |
| 11:58 |
Zeno` |
can the behaviour or implementation of the 'it' class be guaranteed? |
| 11:58 |
sfan5 |
if 'it' belongs to the C++ std lib it has docs, otherwise look into the src for 'it' |
| 11:59 |
|
ImQ009 joined #minetest-dev |
| 12:00 |
Zeno` |
You misunderstand what I am saying. The "long way" has semantics that CANNOT change because they are clearly defined by the C++ Std. The much nicer and shorter way relies on things that are not (necessarily) in the standard and required look elsewhere |
| 12:01 |
Zeno` |
require* |
| 12:01 |
Zeno` |
If I have to look elsewhere then it's dangerous code and maybe this is why PE did it that way in the first place |
| 12:02 |
Zeno` |
or why he wanted it that way... I don't know the history |
| 12:03 |
Zeno` |
In either case one way is ambiguous and the other way never ambiguous |
| 12:03 |
Zeno` |
I know which way I'd choose |
| 12:06 |
sapier |
don't use non standard behaviour not guaranteed to be there for other os/compiler/compiler version if there's a way to do it standard conforming |
| 12:07 |
sapier |
as always someone other having already done this wrong in our code doesn't justify to do it wrong again ;-) |
| 12:10 |
Zeno` |
well, that's what I just said |
| 12:10 |
sapier |
ok why didn't you say it more clear? ;-) |
| 12:11 |
Zeno` |
Well, because I had to start looking at all sorts of other stuff outside of the standard |
| 12:11 |
Zeno` |
and then gave up |
| 12:12 |
Zeno` |
I mean... Krock's code is much, much nicer |
| 12:12 |
Zeno` |
but I have to look at crap not in the standard |
| 12:12 |
Zeno` |
so *shrug*. I don't care... not my code |
| 12:14 |
sapier |
sorry don't understand what you're trying to hint at (hopfully he reads log) |
| 12:21 |
|
Megaf joined #minetest-dev |
| 12:22 |
|
kaeza joined #minetest-dev |
| 12:27 |
|
Jordach joined #minetest-dev |
| 12:30 |
|
rubenwardy joined #minetest-dev |
| 12:37 |
|
swaaws joined #minetest-dev |
| 12:55 |
sapier |
I'd like to merge some pull requests, any comments: https://github.com/minetest/minetest/pull/1391 https://github.com/minetest/minetest/pull/1457 https://github.com/minetest/minetest/pull/1475 and https://github.com/minetest/minetest/pull/1491 |
| 12:56 |
sfan5 |
sapier: +-------------------------------------------------------------------------------- |
| 12:56 |
sfan5 |
what are those for |
| 12:56 |
sapier |
where? |
| 12:56 |
sapier |
oh... to separate functions opticaly |
| 12:57 |
sfan5 |
1391 looks good |
| 13:01 |
sapier |
ok merging |
| 13:04 |
|
diemartin joined #minetest-dev |
| 13:13 |
|
Krock joined #minetest-dev |
| 13:23 |
|
hmmmm joined #minetest-dev |
| 14:02 |
|
CraigyDavi joined #minetest-dev |
| 14:03 |
|
PilzAdam joined #minetest-dev |
| 14:25 |
|
LemonLake joined #minetest-dev |
| 14:44 |
|
rubenwardy joined #minetest-dev |
| 15:00 |
kaeza |
https://github.com/minetest/minetest/issues/1493 |
| 15:06 |
|
Calinou joined #minetest-dev |
| 15:29 |
|
Exio joined #minetest-dev |
| 15:36 |
|
swaaws joined #minetest-dev |
| 15:36 |
Calinou |
# To reduce lag, block transfers are slowed down when a player is building something. |
| 15:36 |
Calinou |
# This determines how long they are slowed down after placing or removing a node. |
| 15:36 |
Calinou |
#full_block_send_enable_min_time_from_building = 2.0 |
| 15:37 |
Calinou |
is this relevant in current versions? doesn't this cause all block sends to be slowed down a lot when there are lots of players on a server, since they're all building or digging? |
| 15:37 |
Calinou |
(we have client-side block placement prediction since long time ago) |
| 15:37 |
Calinou |
this setting was introduced in early 2011 |
| 15:38 |
VanessaE |
I should think that setting would be useless now |
| 15:40 |
Calinou |
then it should be reduced or disabled by default |
| 15:44 |
celeron55 |
it's per-client |
| 15:45 |
celeron55 |
and yes, you really do want that to be there; it helps on shitty connections |
| 15:45 |
sapier |
if it's not there in worst case you send a full block update per placed node |
| 15:46 |
celeron55 |
actually, i'm not perfectly sure how that interacts with the channel priorization now |
| 15:46 |
celeron55 |
that could make it less relevant to some extent |
| 15:46 |
sapier |
I don't think so |
| 15:47 |
sapier |
for what I understood this touches block sending only, as all blocks are transmitted on same channel I don't know how side effects could happen |
| 15:48 |
sapier |
unless you did add this to slow down block sending in favor of interaction |
| 15:48 |
Calinou |
thanks for the info |
| 15:51 |
Calinou |
is disabling mud flow in mapgenv6 much faster? is it really required to have mud flow in the first place? |
| 15:52 |
Calinou |
it seems like it's slow, the nodes are placed after generation (sometimes players can even see that) |
| 15:52 |
VanessaE |
Calinou: wasn't that added to cover up those every-80-nodes trenches? |
| 15:54 |
Krock |
trenches? perlin noise doesn't generate trenches when it touches a "border" |
| 15:54 |
VanessaE |
Krock: no, but some mapgen bug many moons ago did. |
| 15:55 |
Calinou |
I'll try generating a world without mudflow |
| 15:55 |
Krock |
ah. |
| 15:55 |
VanessaE |
I'm sure I'm wrong, as usual. |
| 15:56 |
* Krock |
doesn't know minetest history thet good |
| 15:56 |
Calinou |
I don't seem to have trenches and it looks like it's quite fast |
| 15:57 |
Krock |
so, let's remove mudflow from mgv6? :3 |
| 15:57 |
celeron55 |
the mud flow is there because it makes a more interesting and natural end result |
| 15:57 |
VanessaE |
so I guess those are long since fixed :) |
| 15:58 |
Krock |
celeron55, well, what exactly does it do? |
| 15:58 |
Calinou |
how fast is it? |
| 15:58 |
celeron55 |
iirc it moves dirt and sand down hills |
| 15:58 |
sapier |
mudflow does postprocess map to smooth sharp edges |
| 15:58 |
Krock |
ah, nice feature |
| 15:58 |
celeron55 |
so that if there is a hole in the base rock, it flows there, and if there is a spike, it falls off of it |
| 15:59 |
Calinou |
the flag is nomudflow, right? |
| 16:03 |
|
Hunterz joined #minetest-dev |
| 16:05 |
|
grrk-bzzt joined #minetest-dev |
| 16:05 |
|
rubenwardy joined #minetest-dev |
| 16:06 |
kaeza |
<kaeza> fun fact: field[] elements are bottom-aligned ;_; |
| 16:06 |
kaeza |
<kaeza> so height is practically useless |
| 16:07 |
kaeza |
well, height for an element which is *always* one line does not make sense |
| 16:16 |
sapier |
yes that's a incosistency we can't fix |
| 16:23 |
|
us`0gb joined #minetest-dev |
| 16:27 |
ShadowNinja |
Krock: This is what I mean: http://pastebin.ubuntu.com/7804219/ |
| 16:28 |
Krock |
ShadowNinja, I thought I already tried this and got a convert error |
| 16:28 |
sapier |
independent of how this is done do we really want to pass everything received unseen to lua? |
| 16:29 |
Krock |
why not, sapier? |
| 16:29 |
ShadowNinja |
^ It it much cleaner, more extendable, and doesn't involve hardcoding it. |
| 16:29 |
ShadowNinja |
is* |
| 16:30 |
sapier |
true but removes a check therefore increases risk of exploiting possible bugs |
| 16:30 |
Krock |
well then, ShadowNinja, gonna take your codes and override mine |
| 16:31 |
sapier |
and to me server list is not considered to be trustworthy ... it's remote |
| 16:32 |
ShadowNinja |
Krock: Oh, that last parameter is an undex for a null value. You'll have to put something on the stack for that. |
| 16:32 |
ShadowNinja |
sapier: Removes what check? |
| 16:33 |
|
rubenwardy left #minetest-dev |
| 16:33 |
Krock |
"You'll have to put something on the stack for that." -> too complicated words... |
| 16:33 |
RealBadAngel |
so guys, what about https://github.com/minetest/minetest/pull/1487 ? |
| 16:33 |
|
rubenwardy joined #minetest-dev |
| 16:34 |
ShadowNinja |
Krock: Just something like "lua_pushnil(L); int nullindex = lua_gettop(L);" |
| 16:34 |
|
us`0gb joined #minetest-dev |
| 16:34 |
ShadowNinja |
Krock: You'll also have to pop it from the stach with lua_remove(L, nullindex); |
| 16:34 |
VanessaE |
RealBadAngel: did you sort out the fencepost normalmap rotation glitch |
| 16:34 |
VanessaE |
? |
| 16:35 |
ShadowNinja |
Make sure to push that before lua_newtable(). |
| 16:35 |
Krock |
k |
| 16:35 |
RealBadAngel |
VanessaE, fences are subject for another pull, problem with them are because they used dirty hack |
| 16:36 |
VanessaE |
RealBadAngel: imho this can't be pushed without fixing that, because this pull will break those normalmaps, introducing a regression. |
| 16:36 |
|
zat joined #minetest-dev |
| 16:37 |
RealBadAngel |
those things shouldnt be combined in one pull |
| 16:37 |
Krock |
ShadowNinja, so you mean something like this? http://pastebin.com/DyMGD0EW |
| 16:38 |
Krock |
eh. forgot lua_remove |
| 16:38 |
RealBadAngel |
i would rather fix fences BEFORE mapblock mesh get merged |
| 16:40 |
VanessaE |
fix that bug and some 180 MB of texture memory needed by HDX 512 gets freed (think coloredwoods mod - all those fences it defines) :) |
| 16:41 |
VanessaE |
(89 colors of fences, plus normals for each texture) |
| 16:41 |
Calinou |
you should use dynamic fence previews for coloredwood fences, VanessaE, like in minetest_next |
| 16:41 |
Calinou |
if not done already |
| 16:41 |
VanessaE |
Calinou: actually in Dreambuilder I use Sokomine's colormachine |
| 16:41 |
ShadowNinja |
Krock: Yes, but not on pastebin.com. ;-) |
| 16:41 |
* Krock |
headdesks |
| 16:42 |
Krock |
paste = pasta = yummy |
| 16:42 |
Krock |
eh. |
| 16:42 |
Krock |
not that |
| 16:47 |
VanessaE |
Calinou: and actually, I don't really like the way _next does it |
| 16:48 |
Calinou |
it avoids repetition |
| 16:48 |
Calinou |
you can edit how it's done (the overlay) |
| 16:48 |
VanessaE |
using image overlays requires that the overlay be the same size as the texture |
| 16:48 |
Calinou |
use a larger overlay for HD packs? |
| 16:48 |
VanessaE |
exactly. |
| 16:50 |
VanessaE |
though using a single overlay image at 512px is about half the storage of the ~100 distinct inventory images being used now, it doesn't allow me to use a photo rendering of a fence as the item |
| 16:50 |
|
Calinou joined #minetest-dev |
| 16:50 |
VanessaE |
gotta run, bbl. |
| 16:51 |
Krock |
ShadowNinja, so you meant this? (edited and added lua_remove) http://pastebin.com/DyMGD0EW |
| 16:52 |
Krock |
it's an interesting Lua "API" in this minetest core |
| 16:53 |
ShadowNinja |
Krock: Um, you might not want to remove the null before you use it. ;-) Move the remove call to after the loop, and if the first line's indented it looks good. |
| 16:54 |
Krock |
that's a copy&paste fail |
| 16:55 |
ShadowNinja |
Minetest uses Lua's C API without wrappers or anything. I find http://pgl.yoyo.org/luai/i/about helpfull often. |
| 16:55 |
* Krock |
gives ShadowNinja a huge cookie |
| 16:56 |
Krock |
updated codes, uploaded. |
| 16:57 |
|
swaawsios joined #minetest-dev |
| 16:58 |
ShadowNinja |
Krock: Tested and works? |
| 16:58 |
Krock |
wait 15 miutes and I'll tell you |
| 16:59 |
Krock |
no.might take 20 minutes |
| 17:02 |
sapier |
ShadowNinja "remove the check" as of passing any data from any server as long as it's lua |
| 17:02 |
sapier |
-lua+json |
| 17:02 |
sapier |
just change serverlist url, fetch serverlist, change back ... |
| 17:03 |
ShadowNinja |
sapier: Could you reword that? |
| 17:03 |
sapier |
of course if you download serverlist that way remove the serverlist and add a "download_json_url()" function |
| 17:04 |
|
us`0gb joined #minetest-dev |
| 17:04 |
sapier |
it's equivalent |
| 17:04 |
ShadowNinja |
Do you mean that now it will accept any JSON value instead of just serverlist-like data? |
| 17:05 |
ShadowNinja |
sapier: Just use download_file() and parse_json(). But that function works on the local list too. |
| 17:05 |
sapier |
I think so |
| 17:05 |
ShadowNinja |
sapier: Well, the user is expected to set serverlist_url to the url of a server list. |
| 17:06 |
ShadowNinja |
That doesn't seem like an unreasonable expectation. |
| 17:06 |
sapier |
if you do it that way any mainmenu mod could do too ... but that's not the point what I don't like is passing ANY data instead of data we know about |
| 17:09 |
sapier |
it's good practice to catch invalid data as soon as possible now we pass them to lua and let lua decide |
| 17:13 |
sapier |
any comments on this one https://github.com/minetest/minetest/pull/1475? |
| 17:20 |
|
swaawsios joined #minetest-dev |
| 17:21 |
|
SoniEx2 joined #minetest-dev |
| 17:22 |
Krock |
ShadowNinja, works. but the "empty favourites entries"-bug which is caused by this, is still present |
| 17:24 |
RealBadAngel |
https://github.com/RealBadAngel/minetest/commit/99b0b8dde2f32272fa898fffe40df2147c31ba60 |
| 17:24 |
RealBadAngel |
that fixes fences issue |
| 17:26 |
RealBadAngel |
i dont know why github tries to combine that patch and mapblock_mesh updates into one commit |
| 17:26 |
RealBadAngel |
can i push that directly? |
| 17:36 |
ShadowNinja |
sapier: https://forum.minetest.net/viewtopic.php?f=6&t=9765 |
| 17:37 |
ShadowNinja |
Krock: Um, so it doesn't work? It doesn't show the serverlist? |
| 17:38 |
Krock |
ShadowNinja, it works but the favourite servers have the bug where they have no name (image on pull request) |
| 17:38 |
ShadowNinja |
sapier: Lua can do same basic sanity checks. JSON can't store functions or anything of the like, so it isn't unsafe, it just might throw an error or crash if it hets invalid data. |
| 17:43 |
sapier |
ShadowNinja: it's not about can or can't its about propagating invalid data to more locations where they could cause harm in case of bugs |
| 17:44 |
sapier |
And I know about the githash isssue ;-) |
| 17:44 |
sapier |
oh I didn't know about the parallel build issue ... strange |
| 18:03 |
|
CraigyDavi` joined #minetest-dev |
| 18:05 |
RealBadAngel |
guys? any objections about fences fix? |
| 18:07 |
ShadowNinja |
RealBadAngel: Looks good, provided it works. But change the // ^[transformR90 comment to // Place the texture the right way around the posts or something like that. |
| 18:08 |
RealBadAngel |
ok, will change the description |
| 18:09 |
RealBadAngel |
and ofc it works, theres built-in rotation system for tiles which rotates vertices |
| 18:09 |
RealBadAngel |
i made it for 6dfacedit |
| 18:09 |
RealBadAngel |
6dfacedir |
| 18:10 |
sapier |
talking about fences, there once was a patch which made fences connect to solid blocks does someone remember it? |
| 18:10 |
|
cheapie joined #minetest-dev |
| 18:11 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L102 |
| 18:11 |
RealBadAngel |
so no need to use any texture transformations in the engine |
| 18:11 |
ShadowNinja |
No, but doesn't sound like it'll take more than a few lines of code to recreate it. |
| 18:11 |
ShadowNinja |
sapier: ^ |
| 18:12 |
ShadowNinja |
RealBadAngel: Um, why is that indented so much? |
| 18:14 |
RealBadAngel |
ShadowNinja, my code that speeds up mapblock mesh doesnt allow realtime texture modifications. all is fetched at startup |
| 18:15 |
ShadowNinja |
RealBadAngel: Oh, that might be an issue. Is it still allowed for entities? If not my nuke mod, and sfan5's, will break. |
| 18:16 |
ShadowNinja |
RealBadAngel: But change that indentation to 1 tab like it should be. :-) |
| 18:16 |
RealBadAngel |
there shouldnt be any issue with any kind of mods |
| 18:17 |
sapier |
hmm we shoud start clapping peoples fingers if they use spaces for indention :-) |
| 18:17 |
RealBadAngel |
ShadowNinja, ofc you can try mods in question with the patch |
| 18:18 |
RealBadAngel |
https://github.com/minetest/minetest/pull/1487 |
| 18:19 |
RealBadAngel |
anyway its not about entities, just nodes |
| 18:20 |
sapier |
can someone explain to me why furnace animation doesn't work? |
| 18:20 |
RealBadAngel |
it reads on startup all node definitions, prepares textures, assign shaders, get normal textures, animation frames etc |
| 18:20 |
RealBadAngel |
sapier it does work for me |
| 18:23 |
sapier |
ok it doesn't work if you burn leaves only |
| 18:23 |
sapier |
guess there's some bug iwth low quality material |
| 18:25 |
Calinou |
the texture is still stretched on part of the fences :( |
| 18:25 |
sapier |
you're working in that area RealBadAngel could you have a look? |
| 18:25 |
RealBadAngel |
Calinou, youre talkin bout fences patch? |
| 18:26 |
RealBadAngel |
you wont notice any difference, it does exactly the same rotations, but just not using illegal hack |
| 18:26 |
sapier |
did I mention I merged fixes for bugs with a cumulative age of about 3 years today? ;-) |
| 18:26 |
Calinou |
https://cdn.mediacru.sh/gin7sSgg8PPm.jpg |
| 18:27 |
Calinou |
happens with any textures |
| 18:27 |
sapier |
as RealBadAngel said that's same as before |
| 18:28 |
ShadowNinja |
sapier: No, not spaces, there are three tabs there where only one should be. |
| 18:28 |
sapier |
ok I just mentioned because I stumbled over a location where this happened today |
| 18:29 |
RealBadAngel |
Calinou, idk if the current look is wrong |
| 18:30 |
Calinou |
it pretty much is |
| 18:30 |
Calinou |
only half of the fences look correct |
| 18:32 |
RealBadAngel |
try to define then how it should look, i can change it then |
| 18:34 |
sapier |
well for wood the effect is quite good |
| 18:48 |
|
diemartin joined #minetest-dev |
| 18:53 |
|
paramat joined #minetest-dev |
| 18:56 |
|
crazyR joined #minetest-dev |
| 18:57 |
paramat |
Calinou, Krock, the option to disable mudflow was added by hmmmmm on my request to fix https://github.com/minetest/minetest/issues/1077 i doubt it's much faster when disabled |
| 18:58 |
Calinou |
disabled by default in Carbone now, on new worlds |
| 18:58 |
Calinou |
looks OK to me |
| 18:58 |
Calinou |
I don't have these trenches |
| 18:58 |
Krock |
paramat, that's weird.. normally, there shouldn't be any problems with perlin noise |
| 18:59 |
VanessaE |
paramat: ah, so for once I WAS right? O_O |
| 18:59 |
paramat |
see https://forum.minetest.net/viewtopic.php?p=124043#p124043 |
| 18:59 |
* Krock |
gives VanessaE a cookie |
| 18:59 |
* VanessaE |
falls over from the shock |
| 18:59 |
paramat |
yep :) |
| 19:00 |
Krock |
o.o paramat joined IRC! Let's celebrate |
| 19:00 |
* VanessaE |
tosses the cookie in OldCoder's kitten food box (someone's gotta keep his kitten pile fed) |
| 19:01 |
* sfan5 |
gives VanessaE a kitten |
| 19:01 |
* Krock |
points at /topic |
| 19:01 |
VanessaE |
dammit sfan5... |
| 19:01 |
* VanessaE |
puts the kitten in OldCoder's pile. |
| 19:01 |
* sfan5 |
ignores Krock |
| 19:01 |
VanessaE |
paramat: I still can't help but wonder what the original cause was of those trenches |
| 19:03 |
paramat |
VanessaE, apparently they were in very early (pre-paramat) versions of Minetest? |
| 19:03 |
VanessaE |
paramat: well yeah :P |
| 19:07 |
|
cg72 joined #minetest-dev |
| 19:09 |
|
cg72 joined #minetest-dev |
| 19:09 |
|
cg72 left #minetest-dev |
| 19:09 |
sapier |
I've seen them not that long ago |
| 19:09 |
sapier |
well actually I saw opposit |
| 19:12 |
paramat |
so disabling mudflow is necessary when lowering terrain by mod in mgv6, for example in my 2 mgv6 flattening mods and in my island and archipelago mods |
| 19:18 |
|
Miner_48er joined #minetest-dev |
| 19:23 |
|
cg72 joined #minetest-dev |
| 19:24 |
|
proller joined #minetest-dev |
| 19:24 |
|
cg72 left #minetest-dev |
| 19:33 |
|
VanessaE joined #minetest-dev |
| 19:35 |
VanessaE |
sapier: that velocity/position prediction patch (#1489)... Zefram_Fysh has tested it with success. what's your feeling on merging it? |
| 19:36 |
Zefram_Fysh |
I came to some interesting realisations about it while making pipeworks use it |
| 19:37 |
Zefram_Fysh |
there are multiple uses for this velocity prediction feature, and they conflict when the engine only permits one prediction |
| 19:37 |
Zefram_Fysh |
ideally I'd like to be able to give the client a prediction for visual purposes that's different from what the engine is computing with |
| 19:38 |
Zefram_Fysh |
with pipeworks I really wanted to use prediction just to make the animation cleaner, but I was forced to also change some of the internal computation, which now sees items stopped just as the player does |
| 19:40 |
|
us`0gb joined #minetest-dev |
| 19:40 |
|
OldCoder joined #minetest-dev |
| 19:40 |
Zefram_Fysh |
also, there are two distinct ways I could use prediction to improve animation. I could predict the next segment of motion, to make the transition appear smooth; this is applicable both visually and in computation |
| 19:41 |
Zefram_Fysh |
the other use of prediction is to predict that the entity will stop when it reaches the place where the server needs to work out the next segment of motion: this is just to avoid showing the player wildly extrapolated motion that would never really happen |
| 19:42 |
Zefram_Fysh |
with the present velocity prediction feature, I have to choose one use of prediction or the other. I chose the latter as being more important |
| 19:43 |
Zefram_Fysh |
but it would be nice to be able to make two segments of prediction, so that I can get both the smooth transition when there's sufficiently low lag *and* the fallback of stopping when we run out of reasonably predictable motion |
| 19:44 |
Zefram_Fysh |
that's akin to the advantage of triple-buffered graphics over double-buffered |
| 19:45 |
Zefram_Fysh |
to be clear, those are proposed enhancements, not prerequisites for velocity prediction to be useful. the single-segment velocity prediction is useful as it is, and most welcome |
| 19:47 |
Krock |
ok. |
| 19:50 |
|
paramat left #minetest-dev |
| 19:52 |
sapier |
VanessaE: I haven't got any core developers oppinion upon it so I won't merge it as it's a major impact on gameplay |
| 19:53 |
VanessaE |
what impact do you expect it to have, assuming it's not being used? |
| 19:53 |
sapier |
I never assume something isn't used |
| 19:53 |
VanessaE |
s/it's/the extra feature/ |
| 19:53 |
sapier |
ppl use everything even worst features |
| 19:53 |
VanessaE |
true :) |
| 19:54 |
sapier |
and I still have no use for it in mobf as it's way of doing it is exactly oposite how mobf generates movement |
| 19:55 |
sapier |
and even if I did find a way to use it ... sounds strange ... I couldn't do that as mobf has to work with stable |
| 19:56 |
Zefram_Fysh |
it's *initially* unused, surely? and so should be safe to merge |
| 19:57 |
Zefram_Fysh |
it's also easy to use in a backcompatible way. the extra parameters are ignored by the older engine |
| 19:57 |
sapier |
it's not about bugs but about sideeffects I haven't thought about |
| 19:58 |
sapier |
why don't you just bother some other core dev to check, that's most easy way to get it merged ;-P |
| 19:58 |
VanessaE |
sapier: because you know how it is here :P |
| 19:58 |
sapier |
well I wont merge it without ok from someone really having checked it |
| 20:21 |
|
alexxss joined #minetest-dev |
| 20:22 |
|
ImQ009 joined #minetest-dev |
| 20:27 |
|
unnamed joined #minetest-dev |
| 20:34 |
|
werwerwer joined #minetest-dev |
| 20:39 |
|
alexxss joined #minetest-dev |
| 20:48 |
|
unnamed joined #minetest-dev |
| 21:00 |
|
crazyR joined #minetest-dev |
| 21:15 |
|
rmilan joined #minetest-dev |
| 21:23 |
|
Miner_48er joined #minetest-dev |
| 21:26 |
|
Jordach joined #minetest-dev |
| 21:28 |
sapier |
ShadowNinja: could you have a look at "Error in error handling" bug? that one is quite annoying |
| 22:07 |
|
Taoki joined #minetest-dev |
| 22:16 |
|
Exio joined #minetest-dev |
| 22:19 |
|
us`0gb joined #minetest-dev |
| 22:31 |
|
Taoki_1 joined #minetest-dev |
| 22:35 |
|
Taoki joined #minetest-dev |
| 22:41 |
|
Taoki joined #minetest-dev |
| 22:43 |
|
sapier left #minetest-dev |
| 22:47 |
|
khonkhortisan joined #minetest-dev |
| 22:48 |
|
swaaws joined #minetest-dev |
| 22:48 |
|
Gethiox joined #minetest-dev |
| 23:00 |
|
Zeno` joined #minetest-dev |
| 23:11 |
|
Jordach joined #minetest-dev |
| 23:22 |
|
diemartin joined #minetest-dev |
| 23:59 |
|
khonkhortisan joined #minetest-dev |
