| Time |
Nick |
Message |
| 00:00 |
Cylus |
I don't want to be the cause of any new engine hackery. If someone else does that, it's not my fault and not my problem. |
| 00:01 |
VanessaE |
well if done right, it wouldn't be what one could rightfully call "hackery" |
| 00:01 |
VanessaE |
lava and fire DO need to propagate the responsible party |
| 00:01 |
VanessaE |
(water too) |
| 00:01 |
Cylus |
What about a new node property? <node def>.not_removable_by_nonplayers = true? We'd need a better property name, but you get the idea. |
| 00:02 |
VanessaE |
<def>.nonplayer_diggable = false (defaults to nil = true) |
| 00:02 |
Cylus |
What about lava flow caused by lava spawning with air under it? It could light TNT as well. Geting liquids to keep this data doesn't fix the whole issue. |
| 00:03 |
VanessaE |
it doesn't fix the entire issue no, but if lava can set something else alight, then that something must surely be able to pick up the player info from that light-up event |
| 00:04 |
VanessaE |
it's like setting up a lava flow that, 50 nodes down a hill sets a forest on fire, which sets off a line of gunpowder that sets off TNT |
| 00:04 |
Cylus |
Also, the player reference thing. Even if the liquid stores the player name, it would also need to store the player reference across restarts. |
| 00:04 |
VanessaE |
the player who dumped that lava gets propagated to every lava, fire, and burning gunpowder node as each one moves/is set alight. |
| 00:05 |
Cylus |
That sounds like a good start. |
| 00:06 |
VanessaE |
and if the lava has no player info, it's either old lava or it's naturally spawned, in which case defer to the person who placed the gunpowder or TNT when it gets lit by that lava, or the person who struck it with a torch if that event comes first |
| 00:06 |
Cylus |
There's still the case of mapgen-spawned everything: both the explosive and the igniter are placed by mapgen, posibly by a mod. Who knows what people will code, we need to not cause crashes for no reason. |
| 00:06 |
VanessaE |
see above :) |
| 00:06 |
Cylus |
No information. Mapgen placed the lava and the TNT. |
| 00:07 |
VanessaE |
that's why the "responsibility" has to be propagated inside the engine, where a mod can't touch it. |
| 00:07 |
VanessaE |
mapgen-placed lava and TNT? no player responsibility, therefore no protection will help. |
| 00:07 |
VanessaE |
just blow it up and disregard any complaints. |
| 00:07 |
Cylus |
Okay, got it. That should work well then. |
| 00:07 |
kahrl |
what if someone explodes TNT which explodes some nodes which causes some lava to reflow which sets off a forest fire which ignites gunpowder which sets off TNT? |
| 00:07 |
blaise |
why is tnt being generated if it's a man made item? |
| 00:08 |
VanessaE |
kahrl: same deal. responsibility follows the fire. |
| 00:08 |
VanessaE |
kahrl: in other words, if it can explode or burn, a responsibility key needs to follow it as it moves/burns |
| 00:08 |
Cylus |
blaise: Because some people add weird mods to spawn weird things. We can't let that crash the game just because we don't expect it. |
| 00:08 |
kahrl |
VanessaE: where is the responsibility propagated when TNT removes nodes? (which then causes the second lava to reflow) |
| 00:09 |
blaise |
indeed. |
| 00:09 |
VanessaE |
kahrl: propagate it into the lava that filled the empty spaces. |
| 00:09 |
VanessaE |
e.g. into the air that was created. |
| 00:09 |
VanessaE |
if you can't do that, well, I guess that's one corner case that this idea can't protect against |
| 00:09 |
kahrl |
that's some heavy air :P |
| 00:10 |
Cylus |
So the first step is set up a C++ countability handler. Is that about right, VanessaE? |
| 00:10 |
kahrl |
but anyway, I'm not sure the node metadata system can handle that much data per mapblock |
| 00:10 |
kahrl |
and it isn't designed for that |
| 00:10 |
VanessaE |
kahrl: it's not designed for it, but it has to happen if something like TNT is ever going to have any future on multiplayer servers. |
| 00:11 |
VanessaE |
kahrl: besides, all you really need to send along with the node is a player name, not the whole object - the object could be merely referenced by name once somewhere in the mapblock |
| 00:11 |
blaise |
VanessaE: do we have to worry about explosive decompression yet? |
| 00:11 |
VanessaE |
blaise: eh, I doubt it :P |
| 00:11 |
kahrl |
why not simply prevent TNT from blowing up protected nodes at all? |
| 00:12 |
VanessaE |
kahrl: because <nodedef>.can_dig needs a player object. |
| 00:12 |
VanessaE |
and protection needs a player name |
| 00:12 |
VanessaE |
and if you can't blow up your own stuff...you have a problem |
| 00:13 |
kahrl |
I haven't read the whole discussion, but why can't those functions be changed? |
| 00:13 |
VanessaE |
which functions? |
| 00:13 |
VanessaE |
you mean can_dig et al? |
| 00:13 |
kahrl |
yeah |
| 00:14 |
VanessaE |
[08-27 19:38] <Cylus> Wait, no, I was right. Because <node def>.can_dig() is defined by the node, old mods might not expect strings, but new mods might pass them in anyway. |
| 00:14 |
Cylus |
Also as PilzAdam said, <node def>.can_dig() may be set to always return true. You can't rely on it's existence to mean there is a chance the node can't be dug. |
| 00:14 |
VanessaE |
(where "string" might be a plain old player name, my idea from earlier) |
| 00:14 |
Cylus |
Right. |
| 00:14 |
kahrl |
eh, so fix those old mods? |
| 00:14 |
VanessaE |
kahrl: we don't have the manpower to do that. |
| 00:15 |
kahrl |
are there really that many mods that use can_dig? and is that usually more than a one-liner? |
| 00:15 |
Cylus |
kahrl: I'd love to say that, but that's the "break backwards compatibility" idea stated earlier that won't fly. |
| 00:15 |
VanessaE |
kahrl: every mod that has a locked something or other in it yeah |
| 00:15 |
|
NakedFury joined #minetest-dev |
| 00:16 |
VanessaE |
no idea how much code it would take to fix. maybe a couple of lines apiece, but the problem is the sheer number of nodes and getting new versions of said mods into the server owners' hands |
| 00:16 |
VanessaE |
kahrl: even getting mods fixed where the author is here, active, and willing to accept updates can sometimes be a challenge. |
| 00:16 |
kahrl |
but you should be aware that our liquid update is not the fastest in the world, to say the least |
| 00:17 |
kahrl |
can you imagine it checking the metadata of each node? |
| 00:17 |
VanessaE |
kahrl: that's the understatement of the decade ;) |
| 00:17 |
VanessaE |
besides, you already have to read the node from the map to find out whether you can spread it further, don't you? |
| 00:18 |
Cylus |
Why is TNT even in the game if it's not production-ready, anyway? |
| 00:18 |
VanessaE |
(in the case of say, a single water source on flat ground) |
| 00:18 |
kahrl |
yeah, but that's constant access time (once you read the mapblock) |
| 00:18 |
kahrl |
an index into an array |
| 00:18 |
VanessaE |
(insert spherical, frictionless object in a vacuum example here) |
| 00:18 |
VanessaE |
how much extra data would it take to add that property to a water/lava node? |
| 00:19 |
VanessaE |
Cylus: I've been wondering the same - especially since it wasn't even ShadowNinja's much faster version to begin with |
| 00:19 |
kahrl |
20 bytes, unless we introduce numeric player IDs |
| 00:19 |
kahrl |
and you would have to add that to every node, not only liquid nodes |
| 00:19 |
VanessaE |
kahrl: so 24 bytes versus 4. No way to flag a node as "contains extra data that isn't metadata" ? |
| 00:20 |
kahrl |
nope |
| 00:20 |
VanessaE |
and if it does hold metadata? |
| 00:20 |
kahrl |
that would ruin the entire "index into an array" thing |
| 00:20 |
kahrl |
well, that could be done, but you still need to lookup the metadata |
| 00:20 |
VanessaE |
well sure |
| 00:21 |
VanessaE |
but for the sake of argument, how much data would it take? |
| 00:21 |
kahrl |
a "has metadata" flag? 1 bit |
| 00:21 |
VanessaE |
20 bytes for the player, 4 for the node def, and some overhead for the metadata container? |
| 00:22 |
VanessaE |
I mean in the case of the map format we use now |
| 00:22 |
VanessaE |
rather than hypothetically |
| 00:22 |
VanessaE |
if I just randomly stored a field "player" with a value "kahrl" let's say |
| 00:23 |
kahrl |
oh, I don't remember all the details of the serialization format |
| 00:23 |
VanessaE |
a couple dozen bytes per node, I suppose? |
| 00:24 |
kahrl |
we could even assume, for the sake of argument, that storage size is not the problem |
| 00:24 |
kahrl |
the problem is access time during liquid update |
| 00:24 |
VanessaE |
yeah |
| 00:24 |
VanessaE |
but these are accesses that should be on the order of microseconds at most |
| 00:25 |
VanessaE |
so I wonder if we're worrying about the wrong part of the problem? |
| 00:25 |
kahrl |
well |
| 00:25 |
kahrl |
one access might be like that |
| 00:25 |
kahrl |
now imagine someone pouring out a water bucket on top of a hill |
| 00:26 |
VanessaE |
that's an operation that's already gonna soak up a ton of CPU without reading meta |
| 00:26 |
kahrl |
and you want to make it take 10-100x as much time? |
| 00:27 |
VanessaE |
well I was thinking that's the sort of operation that's sitting in the milliseconds-per-node range, from my own experience. that's why I figured a few tens of microseconds per node wouldn't even matter here. |
| 00:28 |
kahrl |
well, if someone implements it, I'd be glad to test |
| 00:29 |
VanessaE |
with something like water, accountability isn't too critical, but with lava is kinda is :) |
| 00:35 |
|
ImQ009 joined #minetest-dev |
| 00:36 |
kahrl |
btw, didn't someone at some point write some code to make liquids not spread on unloaded blocks |
| 00:37 |
kahrl |
who was that? |
| 00:37 |
Cylus |
Wow, that would be a nice feature. |
| 00:42 |
|
darkrose joined #minetest-dev |
| 00:43 |
VanessaE |
kahrl: possibly so, but I don't remember seeing that |
| 00:52 |
|
Miner_48er joined #minetest-dev |
| 01:04 |
blaise |
some random dude dumped a bucket of lava out in his house which was elevated pretty high |
| 01:04 |
blaise |
then tried to extinguish it with a bucket of water |
| 01:04 |
blaise |
my server didn't actually crash, but it sure did slow stuff down for a bit |
| 01:05 |
VanessaE |
I yelled quite loudly when lava cooling was added to the game |
| 01:06 |
VanessaE |
and PA responded by adding functions i could hook into the default ABM with. frankly I'd rather it be ripped out entirely |
| 01:07 |
cg72 |
lol |
| 01:08 |
VanessaE |
I mean for G*d sakes the default cooling ABM has chance 1, interval 1 |
| 01:08 |
VanessaE |
https://github.com/minetest/minetest_game/blob/master/mods/default/functions.lua#L181 |
| 01:21 |
* VanessaE |
tunes it a bit in dreambuilder. |
| 01:23 |
cg72 |
VanessaE i got that long ago 3sec and 8 chance |
| 01:23 |
cg72 |
works greast |
| 01:23 |
VanessaE |
5 and 15 here. |
| 01:23 |
cg72 |
lol |
| 01:23 |
cg72 |
vanessa see my trees? |
| 01:23 |
VanessaE |
which trees? |
| 01:27 |
cg72 |
http://i.imgur.com/o68SYqc.png |
| 01:28 |
VanessaE |
nice |
| 01:29 |
cg72 |
they are taller and rounded but apple trees are short lol |
| 01:30 |
VanessaE |
cool |
| 01:30 |
VanessaE |
ok, bbl. |
| 01:30 |
VanessaE |
cooking. |
| 01:30 |
cg72 |
i want some |
| 01:48 |
VanessaE |
back |
| 01:49 |
* VanessaE |
offers cg72 a hamburger. |
| 01:49 |
cg72 |
id be happy sitting in a corner crying my self to death rn thanks :\ |
| 02:45 |
blaise |
._. |
| 03:03 |
|
CraigyDavi`` joined #minetest-dev |
| 03:04 |
|
cg72 left #minetest-dev |
| 05:10 |
|
CraigyDavi joined #minetest-dev |
| 05:45 |
|
Hunterz joined #minetest-dev |
| 06:13 |
|
Anchakor_ joined #minetest-dev |
| 06:14 |
|
alexxss joined #minetest-dev |
| 06:30 |
|
Jordach joined #minetest-dev |
| 06:36 |
|
Zeno` joined #minetest-dev |
| 07:20 |
Zeno` |
Would anybody care to review: https://github.com/minetest/minetest/pull/1583 |
| 07:23 |
Zeno` |
I tried to squash :( |
| 07:23 |
Zeno` |
and it sort of is |
| 07:43 |
|
jin_xi joined #minetest-dev |
| 08:03 |
|
casimir joined #minetest-dev |
| 08:50 |
|
Megaf joined #minetest-dev |
| 08:55 |
Megaf |
Hi all |
| 08:56 |
Megaf |
I got info on the client crash when loging in a server, https://github.com/minetest/minetest/issues/1512#issuecomment-53689806 |
| 08:56 |
Megaf |
^ Zeno` ^ ShadowNinja |
| 09:05 |
Megaf |
and by the way, any work done on multithreading? |
| 09:14 |
|
CaIinou joined #minetest-dev |
| 09:16 |
|
Amaz joined #minetest-dev |
| 09:23 |
|
proller joined #minetest-dev |
| 09:25 |
|
ImQ009 joined #minetest-dev |
| 10:32 |
|
jp_ joined #minetest-dev |
| 11:07 |
|
Amaz joined #minetest-dev |
| 11:27 |
|
jp_ joined #minetest-dev |
| 12:07 |
|
cg72 joined #minetest-dev |
| 12:38 |
|
rubenwardy joined #minetest-dev |
| 12:45 |
|
kahrl joined #minetest-dev |
| 12:56 |
|
jp_ left #minetest-dev |
| 12:58 |
|
casimir joined #minetest-dev |
| 13:05 |
|
jin_xi joined #minetest-dev |
| 13:24 |
|
Amaz joined #minetest-dev |
| 14:16 |
|
Cylus joined #minetest-dev |
| 14:18 |
|
hmmmm joined #minetest-dev |
| 14:20 |
|
VanessaE joined #minetest-dev |
| 14:28 |
|
Hunterz joined #minetest-dev |
| 14:28 |
|
Hunterz left #minetest-dev |
| 14:51 |
|
Jordach joined #minetest-dev |
| 14:51 |
|
92AAAP61M joined #minetest-dev |
| 14:51 |
|
Jordach joined #minetest-dev |
| 15:01 |
|
Calinou joined #minetest-dev |
| 15:05 |
|
PilzAdam joined #minetest-dev |
| 15:18 |
|
NakedFury joined #minetest-dev |
| 15:19 |
PilzAdam |
is there any reason to not revert https://github.com/minetest/minetest/commit/7993696fc4b59354974059e1f8d6b3063d316411 ? |
| 15:19 |
PilzAdam |
VanessaE? |
| 15:19 |
VanessaE |
yeah, it's broken for me too |
| 15:20 |
VanessaE |
wait for sapier though, maybe he meant to rename the image file also. |
| 15:21 |
PilzAdam |
https://github.com/minetest/minetest/issues/1564#issuecomment-53729815 hmmmm.... seems like debian needs it? |
| 15:22 |
PilzAdam |
is there any documentation on the format? |
| 15:31 |
|
cg72 joined #minetest-dev |
| 15:32 |
cg72 |
is there any reason i cant set all the main menus background as 1 image??? i have "background.png" in the textures/base/pack |
| 15:37 |
cg72 |
well more code rewriting lol |
| 15:44 |
|
proller joined #minetest-dev |
| 15:47 |
|
cg72 joined #minetest-dev |
| 16:17 |
|
zat joined #minetest-dev |
| 16:24 |
|
OldCoder joined #minetest-dev |
| 16:29 |
ShadowNinja |
Thoughts on https://github.com/minetest/minetest/pull/1439 or is it good to merge? |
| 16:30 |
ShadowNinja |
PilzAdam: A proper fix might be `mv minetest-icon.* minetest.\1` |
| 16:30 |
ShadowNinja |
That might work on all distros. |
| 16:43 |
|
jp joined #minetest-dev |
| 16:44 |
|
jp left #minetest-dev |
| 16:44 |
cg72 |
/home/cg72/.minetest/textures/base/pack/ isnt a dir so why does the check ~= nil return true? |
| 16:47 |
VanessaE |
ShadowNinja: 1439 is a very good idea indeed, though there's a conundrum to it.. |
| 16:48 |
VanessaE |
it's natural to use Q and E to switch items (as that's how I always did it in FPS's) but dammit, those controls are already bound to "drop" and "descend/use" :) |
| 16:48 |
cg72 |
the numbers 1-10 select the box also |
| 16:49 |
cg72 |
1= first item 8= last |
| 16:50 |
VanessaE |
yep. |
| 16:50 |
cg72 |
thats the fastest way why add mor keys to press on accident? |
| 16:58 |
VanessaE |
bbl |
| 17:13 |
cg72 |
https://github.com/minetest/minetest/pull/1584 |
| 17:13 |
cg72 |
now the minetest header is there in all tabe when no texturepack is there |
| 17:27 |
|
Hunterz joined #minetest-dev |
| 17:46 |
|
Megaf joined #minetest-dev |
| 17:48 |
|
sapier joined #minetest-dev |
| 17:50 |
|
khonkhortisan joined #minetest-dev |
| 17:51 |
sapier |
Well ShadowNinja if ppl tell me it's broken I fix it, if they lie to me I can't do anything about that, except of telling sorry and next time not merging things from ppl lieing to me ;-) |
| 17:53 |
|
OldCoder joined #minetest-dev |
| 18:53 |
|
nore joined #minetest-dev |
| 19:04 |
|
proller joined #minetest-dev |
| 19:05 |
|
troller joined #minetest-dev |
| 19:19 |
|
nore joined #minetest-dev |
| 19:29 |
|
Jordach joined #minetest-dev |
| 20:07 |
|
Miner_48er joined #minetest-dev |
| 20:31 |
|
alexxs joined #minetest-dev |
| 20:35 |
|
nore joined #minetest-dev |
| 20:45 |
RealBadAngel |
sapier, here? |
| 20:47 |
sapier |
yes RealBadAngel |
| 20:47 |
RealBadAngel |
http://i.imgur.com/5hGuOUq.png |
| 20:47 |
RealBadAngel |
you know whats that? |
| 20:47 |
sapier |
looks like some transparency issue |
| 20:48 |
RealBadAngel |
no, its a feature you have added to main menu lately |
| 20:48 |
sapier |
oh burningvideo :-) |
| 20:48 |
RealBadAngel |
actually its software |
| 20:48 |
sapier |
software? how did you get it run? |
| 20:48 |
RealBadAngel |
but burningsvideo isnt much better |
| 20:49 |
sapier |
I know those drivers are quite limited |
| 20:49 |
RealBadAngel |
just selected it and run the game |
| 20:49 |
RealBadAngel |
point is, those drivers should not be aviable at all |
| 20:49 |
RealBadAngel |
theyre not able even to display main menu correctly |
| 20:49 |
sapier |
and? bugs like those are partial our fault too |
| 20:50 |
RealBadAngel |
unusable drivers should not be selectable at all |
| 20:50 |
sapier |
who are we telling users what driver to use? they're different for macos windows android whatever. do you wanna maintain the list? |
| 20:50 |
sapier |
they are not unusable |
| 20:50 |
RealBadAngel |
no big deal, 3 drivers |
| 20:51 |
sapier |
nope |
| 20:51 |
sapier |
it's already 6 drivers by now |
| 20:51 |
RealBadAngel |
i mean opengl, d3d and android |
| 20:51 |
sapier |
directx8 directx9 opengl ogles2 ogles3 software burningvideo (don't know how macos is called, maybe opengl too) |
| 20:52 |
sapier |
and by the way some of those issues are result of minetest not doing proper checks too |
| 20:53 |
sapier |
forgot ogles |
| 20:53 |
kahrl |
a driver with buggy frustum clipping is minetest's fault? |
| 20:53 |
sapier |
nope but e.g. the invalid item images |
| 20:53 |
RealBadAngel |
i dont like this menu option at all |
| 20:54 |
sapier |
for what reason? because it shows how incomplete we do feature checking prior using them? |
| 20:55 |
sapier |
if I did know about those issues beeing visible in other drivers too I would've done some of the android hacks more generic |
| 20:55 |
RealBadAngel |
first of all, software and burningsvideo drivers have to be removed from list of aviable ones |
| 20:56 |
RealBadAngel |
they will never be usable |
| 20:56 |
sapier |
no they haven't because it's just adding additional maintenance |
| 20:56 |
sapier |
the function provides a list of drivers irrlicht provides |
| 20:57 |
sapier |
case irrlicht fixes those issues they will work, I don't even know if they may work better e.g. on windows or macos |
| 20:57 |
RealBadAngel |
are you kidding? |
| 20:57 |
sapier |
noone is forced to choose those drivers |
| 20:58 |
RealBadAngel |
its a game, users will do that |
| 20:58 |
RealBadAngel |
and then you will have to complain why the game is fucked up like that |
| 20:58 |
RealBadAngel |
http://i.imgur.com/5hGuOUq.png |
| 20:58 |
sapier |
if you don't like the dropdown remove it but don't add a crazy "I don't like something therefore I filter some wrong thing" feature to a generic driver function |
| 20:59 |
troller |
software usable but too slow |
| 20:59 |
sapier |
and please do hardcode the setting too as users always could choose those drivers |
| 20:59 |
RealBadAngel |
troller, usable? rotfl |
| 21:00 |
|
iqualfragile joined #minetest-dev |
| 21:00 |
sapier |
imho we should first fix all issues we can fix and there are a lot ... then we can decide if it's still necessary to remove the dropdown |
| 21:00 |
RealBadAngel |
dancing geometry, jumping planes 1-2fps |
| 21:00 |
RealBadAngel |
youre drunk guys? |
| 21:00 |
troller |
buy faster PC |
| 21:00 |
sapier |
especially on android for example choosing between ogles ogles2 and (soon ogles3) will have a major impact and we can't decide this on our own |
| 21:01 |
kahrl |
I get 30 FPS with software |
| 21:01 |
sapier |
because we just don't know what's faster on this particular device |
| 21:01 |
sapier |
I get exactly 0 fps because it crashes immediatly |
| 21:01 |
sapier |
irrlicht 1.7 |
| 21:02 |
sapier |
case you have 1.8 kahrl that could be proove irrlicht guys improve it too |
| 21:02 |
troller |
why not irrlicht 1.1 |
| 21:02 |
kahrl |
yeah, 1.8 |
| 21:02 |
sapier |
because there's no supportde distribution using irrlicht 1.1 troll ;-) |
| 21:03 |
sapier |
for burningvideo transparency works even on 1.7 |
| 21:05 |
sapier |
btw folllowing logic "remove everything that may fuck up graphic" we'd have to remove shaders too, because there's no way to decide which opengl cards support them or not |
| 21:05 |
sapier |
well unless maintaining a database of course |
| 21:07 |
sapier |
but still this is only my opinion so if you guys don't like it feel free to remove it ... but then I will always bug you for providing a equal good mechanism for android users ;-P |
| 21:08 |
sapier |
and no I will not maintain a driver list specific for each device I'm already annoyed about the graphics chip ist for android hacks |
| 21:09 |
|
Evolykane joined #minetest-dev |
| 21:13 |
kahrl |
I agree that filtering in get_video_drivers is wrong, but why not filter in tab_settings.lua? |
| 21:14 |
sapier |
and then add same hack which is there for android right now but for all supported architectures? It just because of settings menu is to small. It's supposed to get subtabs soon then this hack could be removed. |
| 21:15 |
kahrl |
which hack? |
| 21:15 |
sapier |
You'd have to add at least Windows, Android, Linux/Macos ... and I'd not even be sure this is correct because there might me android devices out there supporting full opengl soon |
| 21:15 |
sapier |
there's a check for ANDROID somewhere |
| 21:16 |
kahrl |
I'm only talking about removing software and burningsvideo from the dropdown |
| 21:16 |
kahrl |
which can be done platform-independent |
| 21:16 |
sapier |
and why? |
| 21:16 |
kahrl |
because what RBA said |
| 21:17 |
sapier |
because it's broken for him? seems to work way better for others? |
| 21:17 |
kahrl |
if anyone really wants to use them, there's still a happy minetest.conf waiting to be edited |
| 21:17 |
sapier |
I still don't understand why removing somthing because of beeing broken for someone |
| 21:17 |
kahrl |
who is software working well for? |
| 21:17 |
sapier |
someone without a 3d graphics card maybe? ;-) |
| 21:18 |
sapier |
e.g. a vm |
| 21:18 |
kahrl |
those should still have mesa software opengl |
| 21:18 |
sapier |
mesa on windows? |
| 21:18 |
kahrl |
idk about windows |
| 21:18 |
kahrl |
who runs games in a windows vm anyway? |
| 21:19 |
sapier |
ppl testing it for example |
| 21:19 |
kahrl |
they can use minetest.conf |
| 21:19 |
sapier |
yes but following this logic we can remove the whole settings tab, everyone can use minetest.conf |
| 21:20 |
sapier |
and I guess trying to fix those issues will find some serious bugs we still have in minetest too |
| 21:20 |
kahrl |
the point is to reduce support effort |
| 21:21 |
kahrl |
so we don't have people opening issues when minetest doesn't start anymore, after they have chosen a driver they know nothing about |
| 21:21 |
sapier |
to me it feels like "running away from bugs" |
| 21:21 |
kahrl |
bugs that would be closed as wontfix because they are irrlicht bugs |
| 21:22 |
sapier |
at least that issue could be fixed |
| 21:22 |
sapier |
we could make minetest switch to default driver on error |
| 21:22 |
sapier |
but that'd require another maintained list |
| 21:22 |
kahrl |
not really, we already have a default driver |
| 21:23 |
kahrl |
it's opengl |
| 21:23 |
sapier |
I don't think so, burningsvideo for example has issues with non npot2 textures, something some android doesn't handle correct too |
| 21:23 |
sapier |
well then you're gonna break android |
| 21:23 |
sapier |
switching to opengl will result on permanent error there |
| 21:24 |
sapier |
unless you have android x86 where even now may already be opengl graphics chips |
| 21:24 |
kahrl |
well then use those hacks for android that already exist (don't they?) |
| 21:24 |
* VanessaE |
is back. |
| 21:24 |
sapier |
I want to get rid of them as soon as possible (or implement them in a more generic way) not make them standard |
| 21:25 |
sapier |
well I could try what happens if I enable them for "burningsvideo" ... give me some minutes |
| 21:30 |
RealBadAngel |
sapier, in case you havent noticed not working shaders do not make screen red any longer |
| 21:31 |
RealBadAngel |
so not working shader just does nothing |
| 21:32 |
sapier |
nice ... so we have about 2 years to fix the software rendering prior having to remove it? *smile* |
| 21:35 |
RealBadAngel |
we shall focus on drivers we know that we will be using, not all exotic ones around there |
| 21:35 |
RealBadAngel |
fact that irrlicht have some modes doesnt imply mt has to use them |
| 21:35 |
sapier |
ok I don't have to look for the texture scaling issue in burningsvideo as it's already fixed in irrlicht 1.8 kahrl you should already have correct texture sizes there |
| 21:35 |
sapier |
and you pretend to know what "we" use? |
| 21:36 |
sapier |
I'd sometimes be glad about a working software renderer because some other applications already did grab all supported opengl instances |
| 21:36 |
RealBadAngel |
we are makin a game, not another part of dexters laboratory |
| 21:36 |
sapier |
don't know what nvidia did within their driver |
| 21:36 |
RealBadAngel |
software and burning will never be useable by us |
| 21:37 |
sapier |
30 fps? |
| 21:37 |
RealBadAngel |
software, well, may be useable |
| 21:37 |
sapier |
some ppl having 3d cards have less |
| 21:37 |
RealBadAngel |
to display fancy window with warning :P |
| 21:37 |
kahrl |
30 fps, but extremely ugly and nausea inducing |
| 21:38 |
sapier |
software or burningsvideo? |
| 21:38 |
kahrl |
software |
| 21:38 |
RealBadAngel |
both are weird, in different ways |
| 21:38 |
sapier |
try burningsvideo even irrlicht guys tell it's way more advanced |
| 21:38 |
kahrl |
burningsvideo is better, but there's still terrible flicker all over the skybox and clouds |
| 21:38 |
kahrl |
and it's 10 fps |
| 21:39 |
kahrl |
well, and transparency doesn't seem to be working for me (on the apples and torches) |
| 21:39 |
RealBadAngel |
instead of software or burning better to focus on proper d3d handling |
| 21:39 |
sapier |
well I do care as much about d3d as you do about software so lets just remove that too ;-P |
| 21:40 |
RealBadAngel |
at some point i will just translate shaders |
| 21:40 |
sapier |
and no I'm not serious, I just wanted to show that a feature irrelevant for someone can be quite relevant for someone else |
| 21:41 |
RealBadAngel |
still, having highly experimental, partially working features in main menu options is just asking for troubles imho |
| 21:41 |
RealBadAngel |
howgh |
| 21:41 |
sapier |
btw no the npot2 fix doesn't help for burningsvideo as it's implemented irrlicht as of 1.8 only |
| 21:42 |
sapier |
we did have highly experimental partly working features in there for years ... while it's been yours you didn't have issues with it ;-) |
| 21:43 |
sapier |
what about removing them for release builds only? |
| 21:44 |
sapier |
a mechanism for hiding experimental settings could be helpfull for other things too so this would at least be something of more then single use |
| 21:45 |
|
ImQ009 joined #minetest-dev |
| 21:45 |
RealBadAngel |
so make experimental tab for them |
| 21:46 |
RealBadAngel |
this will prevent messing up layout in tabs |
| 21:46 |
sapier |
what's that gonna help? do you wanna tell windows users switching from d3d to opengl is experimental? |
| 21:47 |
VanessaE |
tell them that Windows is experimental ;-) |
| 21:47 |
sapier |
or android users from ogles to ogles2 (well right now ogles2 is really experimental, yet that branch evolves quite fast) not sure if it's still gonna be once we release next version |
| 21:47 |
RealBadAngel |
lol |
| 21:49 |
sapier |
imho driver selection should be there. if there's only one driver in it ok then noone can choose on that platform |
| 21:49 |
sapier |
but it's gonna be linux and macos only |
| 21:50 |
Calinou |
?! only one driver on these OSes |
| 21:50 |
Calinou |
Windows is where you can use both D3D and OpenGL |
| 21:50 |
Calinou |
but D3D sucks |
| 21:50 |
Calinou |
should be dropped from Minetest entirely |
| 21:51 |
sapier |
you can even choose d3d8 and d3d9 there |
| 21:51 |
sapier |
see next one not caring about d3d too ;-) |
| 21:53 |
VanessaE |
don't offer drivers that can't possibly be used on a particular platform :) |
| 21:54 |
VanessaE |
that much is a definite |
| 21:54 |
sapier |
they can be used |
| 21:54 |
VanessaE |
directX on linux? |
| 21:54 |
sapier |
wine? |
| 21:54 |
VanessaE |
directX ON LINUX |
| 21:54 |
hmmmm |
you can use directx on linux |
| 21:54 |
VanessaE |
as in linux HOST |
| 21:54 |
VanessaE |
not guest |
| 21:54 |
hmmmm |
gallium3d |
| 21:54 |
VanessaE |
wat? |
| 21:54 |
sapier |
last time I tried wine did run on linux |
| 21:54 |
VanessaE |
wine is not linux, wine is wine |
| 21:55 |
hmmmm |
sapier, what vanessae is saying is that minetest running on wine for all intents is minetest running on windows |
| 21:55 |
sapier |
maybe you got too much wine vanessae ;-) |
| 21:55 |
VanessaE |
I'm talking on the bare OD., |
| 21:55 |
VanessaE |
OS* |
| 21:55 |
VanessaE |
hmmmm: exactly. |
| 21:55 |
hmmmm |
but minetest compiled for a target like linux or freebsd on the other hand doesn't have d3d support necessarily |
| 21:55 |
hmmmm |
although like i said, that may change sometime in the future !! :) |
| 21:55 |
sapier |
hmmmm I know what she means but I didn't ever tell about providing d3d on linux too |
| 21:56 |
sapier |
it wont happen anyway as the feature reads the supported driver list from irrlicht |
| 21:56 |
hmmmm |
vanessae is saying that you should hide the option for d3d if compiled for linux |
| 21:56 |
VanessaE |
sapier: I was merely providing an example, and indeed my build doesn't even offer windows-specific drivers anyway |
| 21:57 |
VanessaE |
hmmmm: and people might put chevy engines in their fords ;) |
| 21:57 |
VanessaE |
(oh wait, they do that :P ) |
| 21:57 |
hmmmm |
you can do that with enough welding |
| 21:57 |
hmmmm |
--; |
| 21:57 |
VanessaE |
lol |
| 21:57 |
sapier |
hmmmm as I said I don't need to hide it as it's not told to be supported by irrlicht |
| 21:57 |
hmmmm |
so it's an irrlicht problem |
| 21:58 |
sapier |
if there would be shown direct3d on linux yes it'd be an irrlicht problem but at least for me it's not shown |
| 21:58 |
VanessaE |
I just said it's not being shown for me, but that was just an *example*, jeez |
| 21:58 |
VanessaE |
do not take it literally :P |
| 21:59 |
sapier |
what this discussion is about irrlicht telling to support software and burningsvideo too ... those are most times way less perfect then opengl or even direct3d |
| 21:59 |
sapier |
in worst case irrlicht is even wrong, for example on my pc software just crashes |
| 21:59 |
VanessaE |
if those are pure software renderers, wouldn't they be identical from one platform to another? |
| 22:00 |
sapier |
but on the other hand we couln't tell for sure some opengl driver doesn't crash on windows |
| 22:01 |
sapier |
obviously not, that crash happening for me looks like a timing issue |
| 22:02 |
VanessaE |
I meant the rendered result. |
| 22:02 |
sapier |
result should be identical ... at least in theory |
| 22:02 |
VanessaE |
then don't use them at all. |
| 22:02 |
VanessaE |
by definition, they're broken |
| 22:02 |
sapier |
if they did use memcpy or things like that there may be different implementataions resulting in different effects |
| 22:03 |
sapier |
or different display colorspaces |
| 22:03 |
|
EvergreenTree joined #minetest-dev |
| 22:03 |
RealBadAngel |
sapier, that reminds me of an issue reported |
| 22:03 |
VanessaE |
sapier: there has to be a threshold above which you decide "you know what, this is way too unpredictable to use" |
| 22:03 |
RealBadAngel |
if you select not workin one you wont be able to change it back |
| 22:04 |
sapier |
RealBadAngel: that's gonna happen if you select opengl on a broken opengl driver too |
| 22:04 |
VanessaE |
(at least as far as what you present to an average Joe Sixpack) |
| 22:04 |
RealBadAngel |
some1 already reported it in the channel |
| 22:04 |
sapier |
same thing will happen if you start minetest with broken opengl driver |
| 22:04 |
RealBadAngel |
so then use software as fallback |
| 22:04 |
RealBadAngel |
only reasonable usage for it |
| 22:05 |
sapier |
software should work on any platform even android so you could be right about that one yes |
| 22:05 |
RealBadAngel |
but only for main menu |
| 22:05 |
sapier |
unless there's a bug in it but that's normal risk |
| 22:05 |
RealBadAngel |
not game in any case |
| 22:05 |
sapier |
everyone can change it once it started |
| 22:06 |
sapier |
using different engines for different parts by default will result in duplicating test cases/error cases for standard usecase |
| 22:08 |
sapier |
what about same thing windows uses "popup safe mode" ;-) |
| 22:08 |
VanessaE |
sapier: didn't I suggest that a week ago? :) |
| 22:09 |
sapier |
"you did select software/burningsvideo these modes are not using hardware acceleration go to "settings"-tab and change it ... add a checkbox "don't bug me again" to this dialog so ppl can disable this message |
| 22:09 |
sapier |
popup on starting minetest vanessae not on selecting it |
| 22:10 |
sapier |
this way we could handle the fallback situation too |
| 22:11 |
sapier |
first thing minetest will do is setting a flag in settings, that flag is reset once menu is started successfull. if it crashes due to driver error next time we will find that flag and can switch to ... hmm I'd suggest burningsvideo |
| 22:12 |
sapier |
btw I've got 16 fps on burningsvideo and irrlicht 1.8 ... more then a lot of android devices with hardware rendering |
| 22:17 |
sapier |
I think apple textures not beeing transparent our fault as the images in mainmenu are transparent |
| 22:19 |
sapier |
lol |
| 22:19 |
sapier |
disable shaders and you get full transparency |
| 22:20 |
sapier |
RealBadAngel: didn't you tell shaders don't do anything if they're not supported? ;-) |
| 22:24 |
RealBadAngel |
they shouldnt |
| 22:24 |
RealBadAngel |
at least final color blend is removed from them |
| 22:24 |
RealBadAngel |
and is done by the engine only |
| 22:25 |
sapier |
well still disabling shaders on burningsvideo results in transparency beeing fine |
| 22:25 |
RealBadAngel |
that maybe because irrlicht materials are combined |
| 22:25 |
sapier |
possible |
| 22:26 |
RealBadAngel |
i should add there a flag for success on compiling shaders, if false then not build new one material |
| 22:26 |
sapier |
and the skybox flickering ... I'm not quite sure but skybox code looks to me like drawing all at same coordinates. In cases like that floating point rounding precision may cause them to intersect ... not sure if same thing couldn't happen on other drivers too |
| 22:27 |
RealBadAngel |
shaders can fail because of many reasons, such flag is good idea |
| 22:27 |
sapier |
do you compile through irrlicht or directly? |
| 22:29 |
|
EvergreenTree joined #minetest-dev |
| 22:31 |
sapier |
ok software rendering is still quite ugly in 1.8.1 |
| 22:32 |
RealBadAngel |
irrlicht compiles them |
| 22:32 |
sapier |
hopefully they return a correct error code ;-) |
| 22:32 |
sapier |
http://imgur.com/0CBST2S,T81hhkS |
| 22:32 |
RealBadAngel |
they should |
| 22:33 |
sapier |
burningsvideo and opengl are optically different but imho both are fine ... and at least to me even burningsvideo is playable ... and I've got a quite old machine |
| 22:33 |
VanessaE |
sapier: ew, you use filtering with 16px mode? :) |
| 22:33 |
sapier |
nope everything disablerd |
| 22:33 |
VanessaE |
first image looks like tri- or bi-linear filtering |
| 22:34 |
sapier |
first is burningsvideo guess they're scaling algorithm has same effect |
| 22:35 |
sapier |
I wonder what happens if I try to use burningsvideo in 3d mode |
| 22:36 |
sapier |
lol |
| 22:37 |
VanessaE |
3d as in shutter/LCD glasses? :) |
| 22:37 |
sapier |
guess noone ever tried 3d mode on irrlicht 1.8 |
| 22:38 |
sapier |
I had to flip one of the images because irrlicht did flip it on copy ... seems they fixed that bug on 1.8 ... now the fixed image for 1.7 is flipped again ... looks like some ifdef to add |
| 22:39 |
sapier |
nope 3d as in polarization glasses |
| 22:42 |
VanessaE |
same diff |
| 22:42 |
VanessaE |
polarized, anaglyph, shutter...whatever method you choose :) |
| 22:43 |
sapier |
yet I don't know if shutter support works |
| 22:43 |
kahrl |
haha that's trippy |
| 22:43 |
RealBadAngel |
sapier, ok, such flag is a piece of cake, even i dont have to add any extra field for it, will just use current id system, shader_id = 0 will mean no shader for this material |
| 22:43 |
sapier |
ok |
| 22:54 |
sapier |
https://gist.github.com/sapier/c685006eb8a3864709a3 anyone against merging this? |
| 22:56 |
sapier |
well as obviously noone uses that feature by now I'm gonna push it after having it tested myself ;-) |
| 22:59 |
RealBadAngel |
interlaced mode? what for? |
| 22:59 |
sapier |
those who use id know it ;-) |
| 22:59 |
sapier |
oh wait ... noone uses it :-) |
| 23:00 |
|
^v joined #minetest-dev |
| 23:01 |
RealBadAngel |
hehe |
| 23:01 |
sapier |
well we do support almost all available stereomodes, but I guess stereo isn't that common by now |
| 23:02 |
sapier |
real vr devices are missing by now :-) |
| 23:02 |
sapier |
but I don't even think about providing a setting too choose the 3d mode as you'll complain about it breaking view again ;-) |
| 23:03 |
sapier |
we support anaglyph/topbottom/sidebyside and interlaced |
| 23:06 |
sapier |
so if someone has a 3d tv she/he will most likely find a mode to work on it |
| 23:06 |
sapier |
3d on burningsvideo :-) ... not very fluid :) |
| 23:07 |
kahrl |
is the second screen in topbottom/sidebyside mode meant to not update its size when the window is resized? |
| 23:08 |
sapier |
I don't think so |
| 23:09 |
sapier |
funny I get 6 screens in sidebyside mode ... guess there's another bug in it |
| 23:10 |
sapier |
wonder if it's some other thing "fixed" in irrlicht 1.8 |
| 23:10 |
kahrl |
same here, but only after I maximize the window after it starts small |
| 23:11 |
sapier |
irrlicht 1.8? |
| 23:12 |
kahrl |
yes |
| 23:12 |
sapier |
ok I'm gonna check with irrlicht 1.7 ... I guess this is another ifdef irrlicht version issue |
| 23:13 |
sapier |
our official version is irrlicht 1.8 right? |
| 23:14 |
kahrl |
I don't know, is there an official version? |
| 23:14 |
sapier |
that one on minetest.net ;-) |
| 23:14 |
kahrl |
1.8.1 I think |
| 23:15 |
sapier |
so practically any 3d mode was broken and noone did notice ;-) |
| 23:15 |
kahrl |
according to buildwin32.sh and buildwin64.sh |
| 23:15 |
sapier |
maybe anaglyph did work |
| 23:15 |
kahrl |
anaglyph seems fine |
| 23:15 |
RealBadAngel |
im on 1.7 all the time |
| 23:16 |
sapier |
nope sidebyside is broken on 1.7 too |
| 23:16 |
sapier |
so at least there no ifdef is required |
| 23:16 |
sapier |
I'm gonna fix it soon |
| 23:19 |
sapier |
uarg ... silly bug |
| 23:25 |
sapier |
grrr formspecs are broken on 3d mode too ... but that one is for tomorrow |
| 23:26 |
|
Inocudom joined #minetest-dev |
| 23:27 |
* VanessaE |
wonders where a formspec ends up in 3d mode :) |
| 23:27 |
Inocudom |
This is a very serious bug that I fell victim too: https://forum.minetest.net/viewtopic.php?f=6&t=10014 |
| 23:28 |
sapier |
does it happen on sqlite too? |
| 23:29 |
Inocudom |
I encountered the issue on servers mostly. |
| 23:29 |
Inocudom |
Even with client_unload_unused_data_timeout = 180 in my config file, it can still happen. |
| 23:30 |
Inocudom |
How can I tell what map format a server is using? Which ones use sqlite? |
| 23:31 |
sapier |
I'm not sure if I do understand the issue correctly |
| 23:31 |
sapier |
those chunks are only missing on client? |
| 23:31 |
VanessaE |
I'm confused too. |
| 23:32 |
VanessaE |
wait. |
| 23:32 |
Sokomine |
inocudom: if it's not your own, you can't tell. else: take a look in the world-folder. if a file map.sqlite is present -> sqlite3. if a map.db/ folder is present, then it's probably leveldb |
| 23:32 |
sapier |
because I'm quite sure mapblocks are sent repeatedly |
| 23:32 |
VanessaE |
Inocudom: got worldedit handy? |
| 23:32 |
RealBadAngel |
sapier, btw https://www.youtube.com/watch?v=g1RzmQynCPA |
| 23:32 |
VanessaE |
Inocudom: //inspect and then punch at the "blank" area please |
| 23:32 |
RealBadAngel |
^^ toggling one bit and use special tiles instead of tiles |
| 23:32 |
Inocudom |
It seems to be an issue where if I load too many chunks on a map during a play session, the game studders and temporarily freezes. Gets longer each time too. |
| 23:32 |
VanessaE |
RealBadAngel: wait please, off topci |
| 23:33 |
RealBadAngel |
yup, i know ;) |
| 23:33 |
sapier |
https://gist.github.com/sapier/434731e2842881f4ad31 fix for broken window resizing |
| 23:34 |
VanessaE |
Inocudom: please do //inspect and then punch at the "empty" area. Is it CONTENT_IGNORE by chance? Can you actually *point* at the blank spaces? If you walk to the blank space, can you place e.g. a torch and then the land immediately adjacent to the torch appears? |
| 23:34 |
Inocudom |
The missing chunks issue, as far as I know, is only in Freeminer, unless that too was encountered by some in Minetest. |
| 23:35 |
sapier |
RealBadAngel: what exactly is this supposed to show? |
| 23:35 |
Inocudom |
I can't walk into those blank spaces, and the map where I saw those empty spaces was a leveldb map in Freeminer. Mapgen v5 too, though that might not be relevant. |
| 23:35 |
VanessaE |
mapgenv5? VERY relevent. |
| 23:35 |
VanessaE |
minetest does not have mapgen v5. |
| 23:35 |
VanessaE |
only freeminer has that. |
| 23:36 |
Inocudom |
Can't even point at anything in those spaces. They act like unloaded chunks/void areas. |
| 23:36 |
RealBadAngel |
sapier, thats example usage of special_tiles and a single bit that toggles between tiles and special_tiles |
| 23:36 |
VanessaE |
Inocudom: can you place a torch into the blank area? |
| 23:36 |
sapier |
I'm not sure if this is a good example as I don't really see a usecase for it ;-) except of maybe fake blocks ;-) |
| 23:37 |
Inocudom |
But the chunks not loading issue that I encountered in Freeminer is not the only issue. There is also the temporary freezing when I load too many chunks on a map during a play session. |
| 23:37 |
sapier |
I'm pushing the 3d mode fix |
| 23:37 |
RealBadAngel |
furnaces, machines, mesecon wires? |
| 23:37 |
VanessaE |
sapier: furnaces, mesecons, anything with an "on" and "off" texture/node |
| 23:37 |
RealBadAngel |
single def instead of inactive/active defs |
| 23:37 |
sapier |
yes but those aren't changed directly by player? |
| 23:37 |
VanessaE |
Inocudom: if this is mapgen version five, then it's not a minetest issue, as minetest doesn't have v5. |
| 23:38 |
Inocudom |
The number of chunks required to do it is lower than what would normally cause bad_allocation. Again, client_unload_unused_data_timeout = 180 does not get rid of the issue. |
| 23:38 |
VanessaE |
sapier: that's the point though - fewer node defs. for larger mods, it can cut the numebr of nodes by dozens or even hundreds. |
| 23:38 |
VanessaE |
number* |
| 23:38 |
RealBadAngel |
in case of climbable mesecon wires its about 500 node defs |
| 23:38 |
sapier |
well ... only if you don't care about stable clients till 0.4.11 is released |
| 23:39 |
VanessaE |
sapier: wouldn't be the first time that's happened :P |
| 23:39 |
sapier |
true VanessaE you really never care about stable versions ... but complain about broken dev ;-P |
| 23:40 |
RealBadAngel |
sapier, we do already have full featured special_tiles here |
| 23:40 |
RealBadAngel |
i made it same sized as regular tiles |
| 23:40 |
sapier |
I know that's why I don't veto, yet those usecases you guys tell me sound like adding some sort of subnode definition |
| 23:41 |
RealBadAngel |
not really |
| 23:41 |
sapier |
effectively addin another dimension to our node definition mechanism |
| 23:41 |
RealBadAngel |
yes |
| 23:42 |
VanessaE |
sapier: I don't complain about broken dev unless it remains broken for a long time or in the face of code that's *right there waiting to merge* to fix bugs :) |
| 23:42 |
sapier |
basicaly you could replace all nodes by a single one ... with special tiles for everything |
| 23:42 |
RealBadAngel |
effecting in less complicated code, less nodedefs, faster switching |
| 23:42 |
sapier |
and all mods using it have to check nodename AND subnodetype |
| 23:42 |
RealBadAngel |
switch is done realtime, while drawing |
| 23:42 |
RealBadAngel |
no they dont have to |
| 23:42 |
sapier |
if ppl use it that way they have |
| 23:42 |
RealBadAngel |
its a general feature |
| 23:43 |
RealBadAngel |
aviable for all the drawtypes excluding liquids |
| 23:43 |
sapier |
I'm brave and predict modders will use special tiles to implement completely different things and next time they will make they're mods do different things dependent on subnode type |
| 23:44 |
sapier |
e.g. a node crop ... subtype wheat corn, pumpkin |
| 23:44 |
RealBadAngel |
ofc, we cannot predict what modders will make with it |
| 23:44 |
RealBadAngel |
abuse as usual ;) |
| 23:45 |
RealBadAngel |
but keep in mind im modder too, i know why im adding this for |
| 23:45 |
VanessaE |
well to be fair, sapier, if you were to use this feature for e.g. mesecons, you would, by definition have to do something different depending on the state of this special tiles setting - e.g. a wire being "off" isn't going to be propagating a signal to a receptor. |
| 23:45 |
sapier |
you make it easy the way you show it to them ... result will be mods getting way more complicated as nodename isn't gonna be enough to know what's there |
| 23:46 |
sapier |
I'm fair, I just tell this is not making code more simple but just shifts complexity to another location |
| 23:46 |
sapier |
maybe even increases overall complexity |
| 23:47 |
sapier |
as both, drawing code as well as each mod has to check the subtype to know what's going on |
| 23:48 |
VanessaE |
sapier: but it also allows modders to cut down the total number of node definitions. remember, we do have a (rather high) limit and the more we define, the longer the game takes to start. |
| 23:48 |
VanessaE |
better to define 5000 with special tiles than 10000 without them |
| 23:48 |
sapier |
yes you cut down number of node definitions at cost of size of each node definition ... so where's the actual benefit? |
| 23:49 |
VanessaE |
startup time? less resources used at the client? |
| 23:49 |
sapier |
in worst case you'll have a couple of kb for a single node definition |
| 23:49 |
sapier |
same thing has to be parsed |
| 23:49 |
sapier |
it's not less it's just packaged different |
| 23:50 |
sapier |
did anyone check what happens if a single node def doesn't fit into a packet? |
| 23:50 |
sapier |
hopefully we don't care about it :) |
| 23:51 |
sapier |
hmm we send mb of data so it's quite likey we wont ever hit that limit |
| 23:51 |
VanessaE |
if a node ever hits 1MB in size, we have a much bigger problem to deal with :P |
| 23:52 |
sapier |
still I don't see the real benefit except of reducing the count of nodes, at cost of mod complexity |
| 23:53 |
VanessaE |
seems like `node.name == foo and node.param2 > 128` is enough |
| 23:53 |
VanessaE |
that's hardly what I'd call "complex" |
| 23:53 |
VanessaE |
assuming RBA is still using the msb of param2 |
| 23:53 |
Sokomine |
may this new feature perhaps be useful for changes of dirt nodes and leaves through the seasons? the 4seasons mod was a lot of fun but also caused high load for a server |
| 23:53 |
RealBadAngel |
sapier, well its not really sub definition |
| 23:53 |
sapier |
it is |
| 23:54 |
RealBadAngel |
you may think it is, while it isnt |
| 23:54 |
sapier |
as vanessae already mentioned she's gonna use it for active as well as non active mesecon wires |
| 23:54 |
RealBadAngel |
yes, and im going to simplify all the machines thx to it |
| 23:54 |
VanessaE |
sapier: you just have to change how you think of finding a node - stop looking for it purely by name. look for the name of the generic node and then check its param2 for its on/off state |
| 23:55 |
RealBadAngel |
def stays the same, its not altered |
| 23:55 |
sapier |
what you tell is increasing complexity by 100% |
| 23:55 |
RealBadAngel |
so node wont become some other one |
| 23:56 |
RealBadAngel |
treating it as another node (sub) is not understanding the mechanism |
| 23:56 |
VanessaE |
the only caveat I can see is if you had two separate ABMs for two related nodes (an "on" and "off" state for something, maybe furnaces). Those would need a single ABM with a one-line check to see which one you're dealing with |
| 23:56 |
sapier |
obviously powered wires and non powered wires have a difference, it's just implicitly coded in the new subtype ... thus a relevant detail about the node isn't even part of nodedef |
| 23:56 |
RealBadAngel |
im repeating subtype is completely wrong word here |
| 23:56 |
sapier |
no it ain't |
| 23:57 |
RealBadAngel |
node wont become something another with it |
| 23:57 |
sapier |
you don't like it but it's exactly this |
| 23:57 |
RealBadAngel |
in any way |
| 23:57 |
* VanessaE |
wanders off to do something where she won't be half-ignored :-/ |
| 23:58 |
sapier |
just to stay at that special case vanessae mentioned if some mod wants to interact to mesecons node it HAS TO check nodename as well as subtype AND has to know the meaning of that subtype |
| 23:58 |
RealBadAngel |
VanessaE, param2 MSB is your on/off flag for mesecons to spread the signal |
| 23:58 |
sapier |
and those subtypes aren't even speaking names but just numbers |
| 23:58 |
RealBadAngel |
and at the very same time way to represent it graphically |
| 23:58 |
RealBadAngel |
tread msb = 0 as "off" |
| 23:58 |
VanessaE |
sapier: incorrect. mesecons has an API for that. you never interact directly with the wires. |
| 23:59 |
RealBadAngel |
*treat |
| 23:59 |
sapier |
ok so moreblocks will add a node "moreblocks:block" and provide a api "moreblocks.getNode(pos) |
| 23:59 |
VanessaE |
sapier: from the standpoint of a mod interacting with mesecons, nothing will change. same is true of a mod interacting with pipeworks. we have APIs to handle that stuff |
