| Time |
Nick |
Message |
| 01:16 |
|
galex-713_ joined #minetest |
| 01:29 |
|
erlehmann_ joined #minetest |
| 01:37 |
|
ANAND joined #minetest |
| 01:53 |
|
nephele_ joined #minetest |
| 02:19 |
jonadab |
The most ridiculous thing about clouds: http://jonadab.jumpingcrab.com/pastebin/1160.png |
| 05:03 |
ssieb |
krock: What do you mean by "One executable cannot use more than one core"? That's the whole point of using threads. |
| 05:05 |
ssieb |
Well, not the *whole* point, but a big part. |
| 05:30 |
|
calcul0n joined #minetest |
| 05:37 |
freelikegnu |
i see nothing wrong with that cloud. Where I |
| 05:37 |
freelikegnu |
I'm from we call that fog |
| 05:38 |
comrad |
ground clouds! |
| 05:55 |
* theenemystando[m |
uploaded an image: screenshot_20200424_135405.png (680KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/OUSbWLFRaTooAfueSUMfimpa > |
| 05:56 |
theenemystando[m |
its pretty nice when it works though |
| 06:16 |
|
TomTom joined #minetest |
| 06:19 |
|
astro left #minetest |
| 06:25 |
|
Flabb joined #minetest |
| 06:30 |
|
calcul0n_ joined #minetest |
| 06:40 |
|
scr267 joined #minetest |
| 07:04 |
|
dabbill_ joined #minetest |
| 07:07 |
|
Kimapr joined #minetest |
| 07:22 |
|
karamel joined #minetest |
| 08:35 |
|
Hirato joined #minetest |
| 09:04 |
|
Beton joined #minetest |
| 09:29 |
texmex |
Please support #7284 ! freelikegnu, comrad, TheEnemyStando |
| 09:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/7284 -- Per-player customizable fog (thickness, color, ...) |
| 09:36 |
theenemystando[m |
yusf: per-player fog is pretty cool. how would this work with the ability of toggling fog though? |
| 09:44 |
texmex |
TheEnemyStando: Imo it would need to be ”authoritive” in that it would override the toggle. But that’s just me wanting to be able to create games where every player having the same conditions. Regardless i’d be happy with the feature in almost any shape. |
| 09:45 |
theenemystando[m |
same here, it'd would make something like blindness effect or underwater "fog" possible. |
| 09:46 |
theenemystando[m |
Too often I see the sky underwater, below the surface of the sea |
| 09:59 |
|
macc24 joined #minetest |
| 10:12 |
|
Nyarg joined #minetest |
| 10:14 |
Nyarg |
if I want to load into a frame (for exaple fformspec) custom avatar picture at runtime, what do I to do ? |
| 10:15 |
Nyarg |
load from harddisk of cource |
| 10:16 |
Nyarg |
*of course |
| 10:30 |
|
_Zaizen_ joined #minetest |
| 10:31 |
|
ShadowNinja joined #minetest |
| 10:32 |
|
proller joined #minetest |
| 10:35 |
ANAND |
The image has to be present in the mod's textures/ dir during server startup |
| 10:36 |
ANAND |
i.e. It's currently not possible to send media to the client at runtime |
| 10:42 |
|
Fixer joined #minetest |
| 10:49 |
|
ShadowNinja joined #minetest |
| 10:55 |
|
SwissalpS joined #minetest |
| 11:00 |
|
ShadowNinja joined #minetest |
| 11:00 |
|
ShadowNinja joined #minetest |
| 11:05 |
|
Nyarg joined #minetest |
| 11:10 |
Nyarg |
Ok. But if I want to load picture at local side working in offline mode ? |
| 11:26 |
|
testman joined #minetest |
| 11:32 |
|
galex-713 joined #minetest |
| 11:45 |
|
Nyarg joined #minetest |
| 11:50 |
|
jluc joined #minetest |
| 12:11 |
ANAND |
Same story |
| 12:11 |
ANAND |
Texture needs to be present in the mod's textures/ dir at startup |
| 12:18 |
|
oil_boi joined #minetest |
| 12:18 |
|
oil_boi_ joined #minetest |
| 12:25 |
|
nowhere_man joined #minetest |
| 12:36 |
|
yrungr left #minetest |
| 12:53 |
|
Flabb joined #minetest |
| 12:56 |
|
calcul0n joined #minetest |
| 12:59 |
|
macc24 joined #minetest |
| 13:18 |
|
DrFrankenstone joined #minetest |
| 13:19 |
|
Verticen joined #minetest |
| 13:22 |
|
mizux joined #minetest |
| 13:48 |
|
Taoki joined #minetest |
| 13:49 |
|
turtleman joined #minetest |
| 13:56 |
|
macc24 joined #minetest |
| 13:59 |
tf2ftw |
sofar, does mcactive still work? The link in the forum leads to 404 |
| 14:07 |
|
awell1 joined #minetest |
| 14:13 |
jonadab |
freelikegnu: fog isn't usually a thin stripe from waist level up to about nose level. |
| 14:13 |
jonadab |
In my experience. |
| 14:14 |
jonadab |
Also, in the real world, there isn't any one specific height that all the clouds are at, so there isn't any one specific altitude where you constantly can't function because of incessant fog. I mean, there *are* areas with constant fog, but it's for other reasons (warm water meeting cold air, usually). |
| 14:27 |
|
kamdard joined #minetest |
| 14:33 |
|
macc24 joined #minetest |
| 14:36 |
|
calcul0n joined #minetest |
| 15:05 |
|
awell joined #minetest |
| 15:28 |
|
Darcidride joined #minetest |
| 15:38 |
|
mazes_84 joined #minetest |
| 15:40 |
|
Copenhagen_Bram joined #minetest |
| 15:41 |
Copenhagen_Bram |
is it possible to open minetest with toki pona as the language? |
| 15:49 |
SwissalpS |
where is that spoken? |
| 15:51 |
|
Extex joined #minetest |
| 16:07 |
|
Extex joined #minetest |
| 16:07 |
|
nowhere_man joined #minetest |
| 16:15 |
|
oil_boi joined #minetest |
| 17:05 |
|
macc24 joined #minetest |
| 17:17 |
|
oil_boi joined #minetest |
| 17:33 |
cheapie |
So I found out why mesecons_mvps is so slow :P |
| 17:33 |
Krock |
you enabled it in your world. |
| 17:33 |
cheapie |
They're iterating over *every single entity on the entire server* to figure out which ones should be pushed/pulled, every time a piston/movestone is activated. |
| 17:34 |
Krock |
only getting nearby ones would make sense |
| 17:34 |
cheapie |
It would. |
| 17:34 |
Krock |
caching is not an option |
| 17:34 |
sfan5 |
still somewhat slow since get_objects_in_radius doesn't have an optimal implementation |
| 17:34 |
sfan5 |
but surely fast that doing everything in lua |
| 17:34 |
Krock |
well, it got better recently, although not noticeably |
| 17:35 |
sfan5 |
I imagine adding an option to disable entity pulling/pushing would also make sense |
| 17:35 |
cheapie |
On the server I was troubleshooting the slow performance on, it was taking about 150ms to execute a single piston push of one node... it's that bad. |
| 17:35 |
Krock |
how many entities does it check each time? |
| 17:35 |
cheapie |
All of them. |
| 17:35 |
Krock |
in numbers? |
| 17:36 |
cheapie |
At that moment, there were 3408. |
| 17:36 |
Krock |
hmm, that's surprising low for that time |
| 17:36 |
cheapie |
Mostly sign text and other such things that should never be moved anyway. |
| 17:37 |
Krock |
Could you please check the difference using a binary from https://github.com/minetest/minetest/commit/e8ac5a31 or newer? |
| 17:37 |
cheapie |
They're not using that function, that's the problem. |
| 17:37 |
Krock |
would be interesting to have a comparison for scaling |
| 17:37 |
Krock |
oh right stupid me |
| 17:38 |
cheapie |
They're using "for id, obj in pairs(minetest.object_refs) do"... |
| 17:38 |
Krock |
*angry looks* |
| 17:39 |
|
galex-713 joined #minetest |
| 17:41 |
Krock |
for _, obj in pairs(minetest.get_objects_inside_radius(pos, 2)) do |
| 17:41 |
cheapie |
Yes, that would be a lot more sane. |
| 17:42 |
Krock |
please check the difference. I'll push that change to the repo if it still works fine |
| 17:42 |
Krock |
although the range might need to be 3 to support the maximal collision box range |
| 17:42 |
cheapie |
I think it would have to check near each node in the stack, that's kind of a problem. |
| 17:43 |
cheapie |
I wish there was like a minetest.get_objects_inside_area(pos1,pos2) function, as that would be perfect. |
| 17:44 |
cheapie |
FWIW, I'd be 100% fine if only pistons/movestones themselves and not the pushed/pulled nodes could move entities. |
| 17:45 |
cheapie |
*except* for movestones with a vertical stack on top of them. |
| 17:45 |
Krock |
or only the head of the pushed node column/stack |
| 17:45 |
cheapie |
Yeah, "only the head" would work fine for my needs. |
| 17:46 |
Krock |
or radius = stacksize + 1 |
| 17:46 |
cheapie |
As long as large radiuses aren't super-slow, yeah. |
| 17:47 |
Krock |
this will include many more entities than needed but might already bring a speed ebefit |
| 17:59 |
cheapie |
Krock: OK, so I tried a simple one-line patch, changing the line you gave the angry look to be "for id, obj in pairs(minetest.get_objects_inside_radius(pos,#nodestack+1)) do" - or at least I think so anyway, it was a live patch on a running server via dofile()... anyway, pistons and such still seem to work properly as far as I can tell, and even though it had been kinda fast (8ms or so) since I did a /clearobjects it's more like 1ms now. |
| 18:00 |
Krock |
:< I hoped there could be a comparison of before/now |
| 18:01 |
cheapie |
Yes, 8ms before, 1ms now, both were after the /clearobjects which is why they're not up at like 100ms. |
| 18:02 |
cheapie |
Something I can do if you want - there's a machine I have on that server that normally becomes unbearably slow after the server has been running for a few hours - I can check back later and see if it's still fast. |
| 18:03 |
Krock |
only if that mvps performance causes its slowness |
| 18:03 |
cheapie |
That had been determined already, yes. |
| 18:04 |
cheapie |
As stuff starts slowing down, it's all mvps stuff that slows, and only mvps stuff. |
| 18:05 |
cheapie |
At the moment, that machine has already slowed down enough that there's a noticeable difference between the patched and original versions just from watching it. |
| 18:07 |
cheapie |
If I give the server another few hours for people to run around and cause more sign entities to be regenerated, the unpatched function will probably slow back down to making it unbearably slow and then I can test it vs. the patched one again at that point. |
| 18:08 |
|
Extex joined #minetest |
| 18:10 |
sfan5 |
doesn't signs_lib have a command to regenerate entities? |
| 18:10 |
cheapie |
Only in loaded mapblocks :/ |
| 18:12 |
cheapie |
OK, so I did some more running around to try to get the entity count back up some - a piston push of a single node is taking about 30-40ms without the patch and around 1ms with it. |
| 18:14 |
cheapie |
Testing with pushing 16 nodes, the unpatched version is taking about 20-30ms (don't ask me why it's faster than moving 1 node) and the patched version is hovering around 3-6ms. |
| 18:16 |
|
proller joined #minetest |
| 18:26 |
sofar |
tf2ftw: mcactive? what? |
| 18:35 |
|
calcul0n_ joined #minetest |
| 18:36 |
oil_boi |
doesn't signs_lib have a command to regenerate entities? Yes but it should happen automatically |
| 18:37 |
cheapie |
oil_boi: Yes, but only on load. |
| 18:38 |
oil_boi |
That is not good |
| 18:38 |
cheapie |
Why not? |
| 18:38 |
cheapie |
That's usually fairly standard practice for nodes that have entities that go with them to provide extra functionality - an LBM that checks if the entity is still there and creates it if not. |
| 18:39 |
oil_boi |
The player should not be able to tell when a sing is change data, or regenerating data, only to see when the sign is too far and for it to unload and then reload as they get closer |
| 18:39 |
cheapie |
So you want the engine to magically know that the sign is going to be loaded before it actually is? |
| 18:40 |
oil_boi |
No the mod should know how far the player is from the sign and then unload reload accordingly |
| 18:40 |
oil_boi |
Also if clearobjects is run it should auto regenerate |
| 18:41 |
oil_boi |
The sign should be semi sentient even if that sentience is calculated per individual client around the position |
| 18:41 |
cheapie |
There's no "someone ran /clearobjects" callback that I know of. |
| 18:41 |
nephele |
oil_boi, the server already sends entities only in a specific radius |
| 18:42 |
cheapie |
Anyway, signs_lib is from VanessaE, talk to her if you think it should work differently. |
| 18:42 |
oil_boi |
Yes but that's different from LBM, and cheapie I am making it work differently |
| 18:44 |
cheapie |
oil_boi: I'm still not really sure I understand what you want the sign to do, then. |
| 18:44 |
cheapie |
Are you saying the node should cease to exist too when the entity does? |
| 18:44 |
oil_boi |
But right now I am too busy being drunk and listening to Excision to do paste any code or explain what my commit changes are |
| 18:45 |
|
Fulgen joined #minetest |
| 18:46 |
cheapie |
Krock: How's this for a comparison? https://cheapiesystems.com/media/pistonspeedup.webm |
| 18:47 |
cheapie |
That's a hidden piston door using digilines pistons - it tries to run as fast as it can, with lots of interrupt(0) use. |
| 18:47 |
cheapie |
It's being demonstrated opening and closing first without and then with the patch. |
| 18:47 |
oil_boi |
Oh wait I had a moment of clarity, the client should use minetest.find_nodes_in_area and then tell the client to load them otherwise don't |
| 18:47 |
|
galex-713 joined #minetest |
| 18:47 |
Krock |
nice speed |
| 18:47 |
cheapie |
oil_boi: So... how big of an area would that be? |
| 18:48 |
oil_boi |
The client should have a variable from a clientside menu to decide default to 12 xyz |
| 18:48 |
cheapie |
"close enough to load the mapblock" isn't a suitable value for this? :P |
| 18:49 |
oil_boi |
That's why I haven't implemented that into crafter, the clientside menu is a think on it's own, and no it's not at all, imagine 100000+ signs with entities loaded into the server |
| 18:49 |
oil_boi |
I need to think about it more and take notes before I can create a better way |
| 18:49 |
Krock |
reduce level of detail over distance |
| 18:50 |
cheapie |
Krock: It seems to behave exactly the same as before except for the speed, though admittedly I'm not all that familiar with how it's supposed to act entity-wise. |
| 18:50 |
oil_boi |
No Krock that's not too good actually, the memory data will still be loaded into the client and it still needs to process it |
| 18:50 |
cheapie |
oil_boi: 100k signs? That would take an awful lot of players. |
| 18:50 |
oil_boi |
But if the client could be told by the server the radius that it needs to be loaded within a certain radius that would work insanely well |
| 18:51 |
oil_boi |
cheapie, you have to think 10,000 steps ahead or a mod will lag on a server |
| 18:51 |
cheapie |
VE-Creative doesn't lag :P |
| 18:51 |
cheapie |
And that has signs_lib with a ton of signs. |
| 18:51 |
Krock |
just overclock the CPU when mods get laggy |
| 18:51 |
Krock |
easy fix |
| 18:51 |
|
SwissalpS joined #minetest |
| 18:52 |
oil_boi |
That's because the entities don't calculate their movement and I've been on there and the client goes from 500-700 FPS to 10-54 when I enter an area with a lot of signs |
| 18:52 |
cheapie |
Easy fix for that too, get a better CPU and/or video card or turn your view range down :P |
| 18:52 |
Krock |
is each sign one entity, or is each letter an entity? |
| 18:52 |
cheapie |
Krock: Each sign. |
| 18:53 |
Krock |
... just us e[ combine |
| 18:53 |
Krock |
*use [combine |
| 18:53 |
cheapie |
...yes, that's more or less how it works. |
| 18:53 |
oil_boi |
Players only need to see what they read when it comes to signs otherwise it's wasted cpu because the amount of pixels your screen can actually render quickly degredates the farther you are from a sign |
| 18:53 |
Krock |
oh. "each sign". well, each sign can have one or multiple entities |
| 18:53 |
cheapie |
oil_boi: Then don't use signs_lib :P |
| 18:54 |
oil_boi |
cheapie, that's quite a cop out when it can be vastly improved with the experimental features |
| 18:54 |
cheapie |
I can't just magically figure out which sign a player probably wants to read. |
| 18:54 |
oil_boi |
That's why we need the client to download client mods auto when joining a server otherwise custom servers become an extreme mess |
| 18:54 |
Krock |
cheapie: telepathy connection through SSH |
| 18:54 |
cheapie |
...what does CSM have to do with that? |
| 18:54 |
oil_boi |
Oh you can cheapie, distance |
| 18:55 |
cheapie |
That's *what the view range setting is for* |
| 18:55 |
Krock |
or active_object_send_range_blocks |
| 18:55 |
oil_boi |
fuck it, when I sober up I'll address https://github.com/oilboi/Crafter/issues/7 |
| 18:55 |
oil_boi |
Yeah, that is insane to calculate that serverside |
| 18:55 |
cheapie |
Maybe when you sober up this'll make more sense. |
| 18:56 |
oil_boi |
Oh no, it's made sense for about 27 days, I just don't feel like implementing it because it's around 2700 lines of code |
| 18:56 |
Krock |
flashbacks to the time when /clearobjects deleted players as well |
| 18:57 |
cheapie |
Krock: Oh, not just /clearobjects, players used to just be deleted at random :P |
| 18:57 |
Krock |
due to entity overload in a mapblock yes |
| 18:57 |
Krock |
but these were separate issues |
| 18:58 |
Krock |
or when invalid param2 values caused a segfault in 0.4.7 :D |
| 18:58 |
cheapie |
Or when /rollback_check took over 10 minutes :P |
| 18:58 |
Krock |
right. rollback itself is still slow, though. |
| 18:59 |
cheapie |
Yeah, I found the problem causing that and mentioned it in #minetest-dev, but I don't really want to go submit a PR and have to deal with them over there. |
| 18:59 |
cheapie |
Basically back when I fixed /rollback_check it broke /rollback in the process. |
| 18:59 |
Krock |
depending on your last time there, a lot might have changed |
| 18:59 |
Krock |
ugh |
| 19:00 |
cheapie |
The fix is to create a second index in the rollback DB, on the "timestamp" column of the "actor" table. |
| 19:00 |
Krock |
then sort by timestamp |
| 19:01 |
cheapie |
There used to be one there, but I mistakenly removed it when fixing the other index problems. |
| 19:01 |
VanessaE |
what |
| 19:01 |
cheapie |
VanessaE: ? |
| 19:02 |
VanessaE |
what's needed with those sign entities is a way to fade them out |
| 19:02 |
VanessaE |
but that distance needs to be something the mod can specify per-entity |
| 19:02 |
cheapie |
VanessaE's rollback DBs have that second index created on them already, and they seem to be fast enough at both /rollback_check and /rollback now. |
| 19:02 |
VanessaE |
(big signs with big text are readable from farther away than small signs) |
| 19:05 |
cheapie |
VanessaE: I've put two files in VE-C's world directory at the moment - test-piston-fix.lua switches to that patched function in mesecons_mvps and undo-test-piston-fix.lua switches back to the original. You can dofile() them from in game to switch. |
| 19:05 |
cheapie |
At the moment, I have some command blocks down in my playground area, by the hidden piston door, that switch them as well. |
| 19:07 |
jas_ |
!server jastest |
| 19:07 |
MinetestBot |
jas_: jastest | jastest.duckdns.org | Clients: 0/15, 0/0 | Version: 5.3.0-dev / minetest | Ping: 135ms |
| 19:07 |
jas_ |
(gotta get to the switch to build) just added skins |
| 19:07 |
|
galex-713 joined #minetest |
| 19:07 |
jas_ |
hi |
| 19:09 |
Krock |
VanessaE: fading out is only an eye candy. Only skipping the render part helps |
| 19:09 |
MinetestBot |
[git] An0n3m0us -> minetest/minetest_game: Fix door model UV for open and close (#2372) 189d2d9 https://git.io/JfLX8 (2020-04-24T19:04:00Z) |
| 19:11 |
VanessaE |
Krock: yeah but if they begin to fade away say 5m before some set distance, and then unload entirely if they're past that distance..? |
| 19:11 |
Krock |
feasible. what about zoom, what about letter size? |
| 19:11 |
VanessaE |
not unlike how terrain works (when infinite view is turned off) |
| 19:12 |
Krock |
infinite view doesn't exist anyway |
| 19:12 |
VanessaE |
I mean "r" mode. |
| 19:12 |
Krock |
occluded mapblocks are never rendered, also false-positives |
| 19:13 |
VanessaE |
yeah but I'm referring to the dog distance for those. |
| 19:13 |
VanessaE |
merely for comparison |
| 19:13 |
MinetestBot |
[git] sfan5 -> minetest/minetest_game: Fix flammable item entities crashing (#2659) 33eb7ce https://git.io/JfLXo (2020-04-24T19:12:40Z) |
| 19:13 |
jas_ |
\o/ |
| 19:14 |
VanessaE |
beyond the fog threshold, the map block isn't even rendered at all. |
| 19:14 |
VanessaE |
entities ought to be able to do something similar. |
| 19:14 |
VanessaE |
letter size? that's why the mod needs to specify it per-entity. a wall sign with small text is readable up to about 8m away. big signs, more like 20m. |
| 19:16 |
VanessaE |
so with those small signs I might like to set a distance limit of, oh, let's say 15m. they'd begin to fade away (become translucent to the sign background) when you got say 10m away, and by the time you're 15m away, the entity has faded away entirely and so it can be unloaded by the client |
| 19:16 |
VanessaE |
that way you don't just see the text popping in and out of existence as you walk around. |
| 19:18 |
VanessaE |
er, s/dog/fog/ earlier ;P |
| 19:19 |
VanessaE |
or maybe I shouldn't say unloaded, but just stops being rendered |
| 19:19 |
Copenhagen_Bram |
<SwissalpS> where is that spoken? |
| 19:19 |
Copenhagen_Bram |
toki pona is spoken on the internet, I believe |
| 19:23 |
tf2ftw |
sofar, the MC to MT texture tool you have posted in the forum. The posts is pretty old and the link to the tool is dead. I ask because its a pinned forum post. |
| 19:25 |
|
scr267 joined #minetest |
| 19:26 |
VanessaE |
Krock: oh, as for zoom, since under my suggested scheme the entities would still be loaded and just not rendered when too far away, zooming in on a sign should just render the entity without the fade effect. |
| 19:26 |
VanessaE |
(and turn them on for signs that are out of normal range) |
| 19:27 |
|
blaise joined #minetest |
| 19:28 |
VanessaE |
(maybe multiply the distance limit, so signs that are far away than the cut-off, are fading out in the zoomed view, 3x farther away, or whatever the zoom level is) |
| 19:29 |
|
oil_boi joined #minetest |
| 19:30 |
Copenhagen_Bram |
so why doesn't minetest have stuff like toki pona and pirate speak and lolcat like minecraft does? |
| 19:31 |
VanessaE |
what would those even do? |
| 19:31 |
rubenwardy |
I think we have higher priorities than that |
| 19:34 |
ANAND |
^ |
| 19:35 |
VanessaE |
Copenhagen_Bram: that said, those sound like things that can be done with a mod |
| 19:43 |
Copenhagen_Bram |
VanessaE: They're languages |
| 19:44 |
Copenhagen_Bram |
well, the last two, sort of. The last two are basically humorous variations on English |
| 19:44 |
Copenhagen_Bram |
I wonder what the LANG= code would be for toki pona |
| 19:47 |
VanessaE |
yeah as I said, you could do it with a mod, translating chat messages one way or the other |
| 19:53 |
|
galex-713 joined #minetest |
| 20:11 |
|
mizux joined #minetest |
| 20:17 |
|
calcul0n joined #minetest |
| 20:17 |
Copenhagen_Bram |
Hmm |
| 20:22 |
cheapie |
Copenhagen_Bram: Fun fact, if the LANG thing uses the ISO 639-3 codes, there's one for Klingon ("tlh") |
| 20:22 |
|
fluxflux joined #minetest |
| 20:34 |
|
sagax joined #minetest |
| 20:47 |
|
Verticen joined #minetest |
| 20:56 |
|
sagax joined #minetest |
| 21:07 |
sofar |
tf2ftw: mcresconvert |
| 21:08 |
sofar |
https://github.com/minetest-tools/mcresconvert |
| 21:10 |
tf2ftw |
thanks |
| 21:13 |
|
jonadab joined #minetest |
| 21:35 |
|
FreeFull joined #minetest |
| 21:37 |
|
macc24 joined #minetest |
| 21:53 |
|
macc24 joined #minetest |
| 21:58 |
|
emacsomancer joined #minetest |
| 22:03 |
|
scott_ joined #minetest |
| 22:04 |
scott_ |
when starting a game with the "mobs" mod enabled, I'm getting the following error: 'mod "mobs" has unsatisfied dependencies: "default"' |
| 22:06 |
sfan5 |
where did you download this "mobs" mod? are you using minetest_game? |
| 22:10 |
scott_ |
sorry I'm playing Mineclone 2 and I downloaded it from the "content" tab in the in-game menu |
| 22:13 |
rschulman |
Is the `pos` in the call to `after_place_node` the position of the node that was placed or the player that placed it? |
| 22:13 |
sfan5 |
chances are it's not compatible with mineclone2 then |
| 22:13 |
sfan5 |
rschulman: the node obviously |
| 22:13 |
sfan5 |
you could easily retrieve the position of the placing player yourself |
| 22:14 |
rschulman |
That's what I figured, but calling `minetest.get_node_timer(pos)` is returning something of the type `userdata`, which I'm confused by. |
| 22:15 |
sfan5 |
it returns an object of this type: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L5792 |
| 22:18 |
rschulman |
Yeah, I know, that's what I'm expecting, but if I do `local node_to_start = minetest.get_node_timer(pos)` then `print(node_to_start)` I get `userdata: 0x40255f50` |
| 22:19 |
rschulman |
so I'm clearly using it wrong. :) |
| 22:20 |
scott_ |
thanks sfan5 |
| 22:23 |
|
turtleman joined #minetest |
| 22:25 |
sfan5 |
rschulman: that's expected behaviour though, the NodeTimerRef object can't be printed as a string |
| 22:27 |
rschulman |
Ok, I figured it out. I needed to call `node_to_start:set` with a colon, I was using a period. |
| 22:36 |
|
macc24 joined #minetest |
| 22:38 |
|
LazyJ joined #minetest |
| 22:43 |
nephele |
mineclone2 does not implement the default mod |
| 22:44 |
nephele |
either the mobs mod shoudl explicitly support it, or a compat layer may be used (i don't know of any though...) |
| 22:44 |
VanessaE |
it's up to mineclone2 to remain compatible with regular mods imho |
| 22:45 |
nephele |
There are no regular mods |
| 22:45 |
nephele |
and there is no guranteed api for which nodes are available or not |
| 22:45 |
VanessaE |
I mean mods written with minetest_game in mind. |
| 22:45 |
VanessaE |
don't split hairs :P |
| 22:45 |
VanessaE |
I mean, shit, 90% of all minetest mods depend on `default` |
| 22:45 |
nephele |
It's unreasonable to demand that mineclone2 implement mtg aswell as itself ;) |
| 22:46 |
VanessaE |
and actually, there is -- minetest.registered_items{} |
| 22:46 |
nephele |
That's not a compatibility layer, that's just a method one could use to implement one |
| 22:46 |
VanessaE |
yes... and? |
| 22:47 |
nephele |
So, you are incorrect in saying it is one? |
| 22:47 |
VanessaE |
I read "api" as "a feature of the modding api" |
| 22:47 |
VanessaE |
and that table is one. |
| 22:48 |
nephele |
I men that as in, there is no gurantee that default:wood is available in future mtg version |
| 22:48 |
nephele |
as in what mods can expect for crafting recipes, there is simply no gurantee currently for known good values |
| 22:48 |
VanessaE |
the probability of something basic like that being removed is basically 0 |
| 22:48 |
nephele |
groups could be somewhat portable but mtg doesn't implement them widely |
| 22:49 |
nephele |
What makes you say that? it's entirely possible that blocks get replaced with variants of the block, i.e that only pine_wood etc. exist |
| 22:49 |
sfan5 |
the bigger issue IMO aren't items or nodes but functions such as player_api or sfinv that are minetest_game specific |
| 22:50 |
nephele |
Crafting recipes hinge on node names |
| 22:50 |
nephele |
if you can't craft many node mods aren't usable for instance |
| 22:50 |
VanessaE |
mineclone's seeks to be different. I get that. but being SO different that you can't even have a "skeleton" `default` mod that consists of just aliases between its nodes and functions, and those of mtg? that's taking the concept too far. |
| 22:51 |
nephele |
You could implement a mod named "default" for mtg that registers aliases |
| 22:51 |
VanessaE |
no |
| 22:51 |
nephele |
but again, mtg is a moving target, maintaining this is non-trivial |
| 22:51 |
VanessaE |
you implement it for mineclone |
| 22:51 |
nephele |
I ment mineclone |
| 22:51 |
VanessaE |
mtg is not as much a moving target as you think... |
| 22:51 |
nephele |
sorry, i mistyled |
| 22:51 |
VanessaE |
when was the last time some node or sound was *removed* from mtg> |
| 22:51 |
nephele |
Sure it is, there is not a single api or node for which mtg provides any gurantees of existance |
| 22:52 |
VanessaE |
(I can only remember the poptart cat and that was years ago) |
| 22:52 |
VanessaE |
how long must something persist before you consider it stable? |
| 22:53 |
nephele |
code rot is not a sign of stability |
| 22:53 |
nephele |
and neither is acumilating code depth |
| 22:53 |
nephele |
If you want a stable api to target for mods, you need just that an actually defined api |
| 22:53 |
VanessaE |
*sigh* |
| 22:53 |
VanessaE |
you didn't answer the question |
| 22:53 |
|
Extex joined #minetest |
| 22:54 |
nephele |
I literally did |
| 22:54 |
VanessaE |
no, you didn't |
| 22:54 |
sfan5 |
there's no guarantee that mineclone must have a specific (or any) type of wood either |
| 22:54 |
nephele |
Yes i did |
| 22:54 |
VanessaE |
I asked for a time length |
| 22:54 |
sfan5 |
so how would you actually define a "stable" api? |
| 22:54 |
nephele |
And i told you that there is no time length that would ever make something stable |
| 22:54 |
nephele |
sfan5, write it down |
| 22:54 |
VanessaE |
so by that metric, NOTHING can be stable and the minetest modding API can't be relied on? |
| 22:55 |
nephele |
The modding api provides gurantees |
| 22:55 |
nephele |
I know what calls version 5.0.0 has, i can rely on them |
| 22:55 |
nephele |
I also know which calls are deprecated |
| 22:55 |
sfan5 |
so you write down "outer straw stairs" and by consequence every game that wants to be compatible needs to have straw, stairs, straw stairs and an outer variant of them? |
| 22:55 |
VanessaE |
oh, and, I'm looking right at your text, you did NOT say anything implying "no time length" |
| 22:56 |
nephele |
sfan5, any game that wants to be able to provide a craftin recipe involving outer straw stairs, yes |
| 22:56 |
nephele |
VanessaE, i literally did "code rot is not a sign of stability" |
| 22:56 |
VanessaE |
what has code rot to do with time required to consider something "stable" in the sense that you can rely on it being there? |
| 22:56 |
nephele |
someone not changing a component for any time is not an indicator of it beeing a stable or an endorsed api |
| 22:57 |
nephele |
Time has nothing to do with it |
| 22:57 |
VanessaE |
horseshit |
| 22:57 |
sfan5 |
nephele: right, then you have a "stable" API but just about everything is optional? |
| 22:57 |
VanessaE |
something is "stable" if it can be relied on to be there and to work as intended. |
| 22:57 |
nephele |
sfan5, no, the point of such a gurantee is to have, you know, a gurantee |
| 22:57 |
nephele |
same with posix, most systems implement it almost completely |
| 22:57 |
nephele |
and those that dont simply arent compatible |
| 22:58 |
nephele |
VanessaE, that has nothing to do with api compatibility |
| 22:58 |
VanessaE |
it has *everything* to do with it! |
| 22:58 |
nephele |
like the mod above that relied on mtg, while presumebly beeing perfectly adaptable to run on mineclone |
| 22:58 |
sfan5 |
but you just said a game would a game would only provide outer straw stairs if it wanted to be compatible, so doesn't that mean they are optional? |
| 22:58 |
VanessaE |
the engine modding API is stable. the minetest_game API is considered stable, too, as is its contents. |
| 22:59 |
VanessaE |
as are* |
| 22:59 |
nephele |
No it doesn't, if you for some reason think outer straw stairs are essential enough to define in this layer and a game does then not implement them it is incompatible |
| 22:59 |
VanessaE |
I'm pretty sure nearly every minetest modder would agree with me |
| 22:59 |
VanessaE |
(the 0.4.x/5.x.x break notwithstanding) |
| 22:59 |
sfan5 |
ok |
| 23:00 |
nephele |
MTG is not stable, there are no gurantees for anything |
| 23:00 |
nephele |
literally nothing i can rely on and just port over to mineclone2 as an api defintion mods can just use |
| 23:00 |
sfan5 |
then you end up with a "stable" api that is defined to contain exactly the nodes/items MTG has |
| 23:00 |
sfan5 |
...which is not very useful at all |
| 23:00 |
sfan5 |
since games that do not implement all of it are automatically "incompatible" |
| 23:00 |
nephele |
sfan5, It obviously would not contain the exact same nodes |
| 23:01 |
sfan5 |
no then where do you draw the line? |
| 23:01 |
nephele |
sfan5, crafting groups are extremely usefull for this |
| 23:01 |
nephele |
for instance a group:solid_fuel would already provide huge compaitbility |
| 23:02 |
nephele |
In a sense, the crafting api destinction for what type of crafting it is, like smelting, is exactly the kind of compat you could easily have over severall gamemodes |
| 23:02 |
|
GreenXenith joined #minetest |
| 23:02 |
sfan5 |
isn't that the intersection of (all nodes) and (items that have a fuel craft registered)? |
| 23:02 |
nephele |
it's kind of a shame that the number of crafting types is fixed |
| 23:03 |
nephele |
sfan5, I mean for instance too, most gamemodes have wood, so a crafting recipe involving wood could use a group for that crafting |
| 23:03 |
nephele |
it doesn't need to rely on the specific nodenames that are in mtg |
| 23:03 |
sfan5 |
yes |
| 23:03 |
GreenXenith |
You could just roll your own crafting system |
| 23:03 |
nephele |
but a compatible implementation can check a known good source of the crafting groups that are expected |
| 23:03 |
sfan5 |
doesn't that already work? I've seen several mods that use group:wood |
| 23:03 |
nephele |
sfan5, yes, but there is still no spec for it |
| 23:04 |
nephele |
if any other game wants basic compatibility with mtg they have to go dig around inn mtgs source |
| 23:04 |
|
proller joined #minetest |
| 23:04 |
nephele |
and that isn't really pleasent imo... |
| 23:04 |
sfan5 |
sounds like it should be documented in game_api.txt then |
| 23:04 |
nephele |
I don't have that file |
| 23:05 |
sfan5 |
https://github.com/minetest/minetest_game/blob/master/game_api.txt |
| 23:06 |
nephele |
That's full of mtg specific stuff, for a "base target" if you will it would make more sense to have it outside mtg and have mtg implement it |
| 23:07 |
sfan5 |
I didn't say that it is the base target you propose |
| 23:07 |
sfan5 |
just that this would be the place where MTG could document its node and item groups for easy cross-game compatibility |
| 23:07 |
nephele |
That is then again everyone chasing mtg |
| 23:07 |
nephele |
it's not really a base target |
| 23:08 |
sfan5 |
nobody said that? |
| 23:08 |
nephele |
You said it would be good to put in game_api.txt |
| 23:08 |
nephele |
I don't think it fits the goal to have more compatibiltiy anyhow |
| 23:08 |
|
argyle joined #minetest |
| 23:09 |
nephele |
Some names might make sense to take straight from mtg now, but if they are too specific they may not make any sense for other games anymore |
| 23:09 |
sfan5 |
I said that it would be good to put documentation on which groups MTG uses in game_api.txt |
| 23:09 |
nephele |
as an unrelated comment? |
| 23:09 |
nephele |
i guess |
| 23:10 |
sfan5 |
<nephele> sfan5, yes, but there is still no spec for it |
| 23:10 |
sfan5 |
<nephele> if any other game wants basic compatibility with mtg they have to go dig around inn mtgs source |
| 23:10 |
sfan5 |
??? |
| 23:10 |
nephele |
There is no baseline spec |
| 23:11 |
nephele |
You need to define which groups you can use, as a baseline, nobody is going to implement everything game_api.txt sais into their own subgame, that is too big a target |
| 23:11 |
VanessaE |
it almost sounds as if you want some of mtg's content moved to the engine and renamed/grouped in some generic, less-descript way? |
| 23:11 |
nephele |
No, it has no place in the engine |
| 23:11 |
nephele |
That statement makes me wonder though, whether you actually read anything i have written this far |
| 23:12 |
sfan5 |
nephele: my comment is entirely unrelated to your baseline spec propoal, but it is in direct response to you pointing out that MTG (specifically) has no documentation on its groups |
| 23:12 |
VanessaE |
I have, and you are being utterly unclear |
| 23:12 |
nephele |
moving files around wont help for compatibility, mod authors need a good target to shoot at, if it's too much trouble to use a common subset they just wont (as you can observe now), and game authors need a damn good description of what they are supposed to implement as a baseline |
| 23:13 |
VanessaE |
wtf is a "baseline spec"? wtf do you want mtg to "implement" such that another game could also "implement" in a compatible way? |
| 23:13 |
nephele |
"what the fuck do you want minetest game to implement such that another game could also implement in a compatible way" |
| 23:13 |
VanessaE |
I mean look... |
| 23:14 |
nephele |
could you rephrase this in english? |
| 23:14 |
sfan5 |
basic things such as: you have nodes made out of something {stone,wood,dirt,fluid}-like, items that are flammable/cookable, maybe generalized minerals? |
| 23:14 |
sfan5 |
I'd assume |
| 23:14 |
VanessaE |
mtg has stone, mineclone2 has stone (I assume). the two have a footstep sound. the two have, I dunno, sun and moon textures or something |
| 23:14 |
sfan5 |
that might still be too specific if you were to make a space game on a moon though |
| 23:14 |
nephele |
In some places the engine could absolutely provide some better apis for cross-gamemode compatibility, but it shouldn't implement anything of mtg |
| 23:15 |
nephele |
sfan5, at some point you gott to have a cutoff, there is only so much compatibility you can have before you need explicit support |
| 23:15 |
VanessaE |
so what's so wrong with using mtg's file/function/item names internally for those things? or alising them? |
| 23:15 |
VanessaE |
aliasing* |
| 23:15 |
nephele |
MTG is a moving target and has no api gurantees |
| 23:16 |
VanessaE |
Jesus fuck, man, MTG IS NOT A MOVING TARGET |
| 23:16 |
nephele |
Yes it is |
| 23:16 |
VanessaE |
then how come all of my mods work fine on it? |
| 23:16 |
nephele |
what? |
| 23:16 |
VanessaE |
some of my mods have code so old they'd still be able to run on 0.4.0 :P |
| 23:17 |
nephele |
so what? |
| 23:17 |
VanessaE |
(if not for the fact that I occasionally take advantage of new features as they become available) |
| 23:17 |
|
Tychocaine joined #minetest |
| 23:17 |
sfan5 |
nephele is correct that MTG has no stability guarantees, but in practice nothing (of significance?) has been removed EVER |
| 23:17 |
|
appguru joined #minetest |
| 23:17 |
VanessaE |
is that not the very definition of a stable API? that code written for the oldest version still works in the newest? |
| 23:17 |
nephele |
My game wont run on mt lower than 5.1.0, i deliberately broke compatibility, but that is beside the point |
| 23:17 |
sfan5 |
and if something were to be removed you'd likely meet resistance from the devs, their intention being to enforce this informal rule |
| 23:18 |
nephele |
I am not going to implement every fucking node in mtg, and especially not every random api call they have |
| 23:18 |
nephele |
I am perfectly willing to implement some crafting groups and some node aliases, sure, but not the entire fucking game |
| 23:18 |
sfan5 |
I don't think anyone is suggesting that |
| 23:18 |
appguru |
Backwards compatibility should be kept to some extend, but sometimes things need to change |
| 23:18 |
nephele |
and then having to catch up with every change |
| 23:18 |
VanessaE |
sfan5: yes, and I won't debate that particular point. but a lack of an official, sanctioned guarantee does not make the game API unstable or "moving target" |
| 23:18 |
appguru |
Are we talking about MTG? |
| 23:18 |
nephele |
Yes |
| 23:18 |
VanessaE |
appguru: no. |
| 23:18 |
sfan5 |
appguru: logs are in the topic |
| 23:19 |
nephele |
specifically corss-game compatibility where mods only work on mtg currently |
| 23:19 |
VanessaE |
appguru: we're talking about how mineclone2 isn't compatible with mods meant for minetest_game and somehow that's the mods' or mtg's fault. |
| 23:19 |
sfan5 |
VanessaE: it certainly is a moving target if you are aiming for (almost) full compatibility |
| 23:19 |
sfan5 |
I hope nobody does that, though |
| 23:19 |
nephele |
VanessaE, what?? |
| 23:19 |
nephele |
If that is your gist than you didn't understand anything i said |
| 23:19 |
VanessaE |
sfan5: I wouldn't think a game that aims to be a Minecraft clone would seek to keep up with mtg's content? |
| 23:19 |
appguru |
I always go for latest stability with my mods. |
| 23:20 |
appguru |
(each of my mods is meant to work with the latest version of other mods) |
| 23:20 |
sfan5 |
nephele: so why not take some basic nodes MTG has and add aliases to your game? do you fear that you'll have to keep changing them? |
| 23:20 |
VanessaE |
did I not suggest that like, an hour ago? |
| 23:20 |
VanessaE |
:P |
| 23:20 |
appguru |
that's a good point |
| 23:20 |
appguru |
you should probably make that configurable |
| 23:21 |
nephele |
sfan5, absolutely not |
| 23:21 |
appguru |
probably even using an additional mod, mtg_compat which can be enabled if desired |
| 23:21 |
nephele |
I am not digging through mtgs code and implementing support for some nodes at random and hoping that will give me compatibility |
| 23:21 |
nephele |
because it will not |
| 23:21 |
nephele |
i now have mods that are only 5 errors instead of 12, and nothing gained, still completely unuseable |
| 23:21 |
appguru |
you should always have the mods in mind you which your mods are meant to be compatible with |
| 23:22 |
nephele |
unless there is a baseline that mod authors can actually target when they wish to be cross-game compatible there is nothing to do |
| 23:22 |
nephele |
except for trying to implement mtg fully, which i am not willing to so |
| 23:22 |
appguru |
there is something to do |
| 23:22 |
appguru |
there are quite some API mods out there |
| 23:22 |
appguru |
those are your "baselines" |
| 23:22 |
appguru |
MTG's player_api is a good example |
| 23:22 |
nephele |
appguru, and again, nobody was talking about those |
| 23:22 |
GreenXenith |
Except when you have 4 API mods that all do the same thing |
| 23:23 |
sfan5 |
so you want a base specification of some set amount of nodes/items (that MTG also has), which when implemented guarantees that random mods will work with your game? |
| 23:23 |
appguru |
This does not belong into the engine though. |
| 23:23 |
sfan5 |
at least that's what I gather from the fact that you don't want partial support(?) |
| 23:23 |
VanessaE |
appguru: well at least I addressed that with things like basic_materials, signs_lib, biome_lib, ... :) |
| 23:24 |
appguru |
(y) |
| 23:24 |
nephele |
sfan5, Whether mtg now does or does not have nodes is pretty irrelevant, there should be some crafting groups that i can knowingly implement, against which mod authors can test and be reasonably sure that their mod will be somewhat compatible |
| 23:24 |
nephele |
a baseline, if you will.... |
| 23:24 |
appguru |
The engine already has too much game-specific stuff IMO. It should've been a generic voxel game engine. |
| 23:24 |
sfan5 |
I guarantee you many relevant mods will need feature XYZ that isn't in that "baseline" and you're back at square one with compatibility |
| 23:25 |
nephele |
At the moment, as a mod author, it's pretty damn impossible to make your mod compatible with most subgames unless you spend hours hunting for version specific nodes in each one and hope they line up |
| 23:25 |
nephele |
sfan5, so what? |
| 23:25 |
appguru |
depends on the mods you're making |
| 23:25 |
nephele |
I don't have to give a shit about mods that don't care about compatibility, they wont now and they wont then |
| 23:25 |
nephele |
appguru, Absolutely, Not beeing able to make my mod properly portable is the sole reason i made my mod into a gamemode |
| 23:25 |
appguru |
if those subgames using common libraries then there is no issue |
| 23:26 |
nephele |
ITS STILL NOT ABOUT LIBRARIES |
| 23:26 |
sfan5 |
I don't understand this |
| 23:26 |
VanessaE |
yet you expect some mods to deliberately be compatible with MC2? |
| 23:26 |
sfan5 |
when it's about implementing random nodes from MTG, you complain that mod compatibility won't be good enough so it's still unusable |
| 23:26 |
GreenXenith |
appguru, they are talking about items. Libraries cant help with items (generally). |
| 23:26 |
VanessaE |
what about the 47 bazillion other games out there? |
| 23:26 |
sfan5 |
when it's about features missing from a potential "baseline" specification, suddenly you don't have to care about mod compatibility |
| 23:27 |
nephele |
Yes |
| 23:27 |
nephele |
Mod authors can care aslong as they have something to target |
| 23:27 |
VanessaE |
THEY HAVE. |
| 23:27 |
nephele |
if they can't target anything they can't care |
| 23:27 |
nephele |
VanessaE, no they dont |
| 23:27 |
appguru |
Item compatibility? Not that hard. Aliases are one approach. |
| 23:27 |
VanessaE |
they have had something reasonable to target since 0.4.0 came out. |
| 23:27 |
VanessaE |
and that was ...8? years ago? |
| 23:27 |
appguru |
Others are restructuring your code to not work using itemnames but rather groups for example. |
| 23:27 |
GreenXenith |
appguru, read the logs please |
| 23:27 |
nephele |
VanessaE, and again, it's not about the mt api... |
| 23:27 |
GreenXenith |
this has already been discussed |
| 23:27 |
nephele |
appguru, ugh |
| 23:28 |
nephele |
It waas about item groups already |
| 23:28 |
sfan5 |
nephele: I believe what she means is that minetest_game has been a stable target since 0.4.0 |
| 23:28 |
nephele |
but again, no gurantee, nobody has written down, or knows what an expected subset of groups is |
| 23:28 |
VanessaE |
nephele: mt API != mtg API; so what IS it about? |
| 23:28 |
nephele |
VanessaE, Cross-gamemode compatibility of third-party mods ffs |
| 23:28 |
appguru |
we don't need business-level guarantees for a game :P |
| 23:28 |
VanessaE |
sfan5: indeed. |
| 23:28 |
VanessaE |
nephele: so I reiterate, |
| 23:29 |
nephele |
sfan5, minetest game is an irrelevant target because i can't implement it |
| 23:29 |
VanessaE |
[04-24 19:26] <VanessaE> yet you expect some mods to deliberately be compatible with MC2? |
| 23:29 |
VanessaE |
[04-24 19:26] <VanessaE> what about the 47 bazillion other games out there? |
| 23:29 |
appguru |
APIs change just like item names, and your mods will have to change as well |
| 23:29 |
appguru |
Deal with it |
| 23:29 |
nephele |
so it's unuseable a sa baseling |
| 23:29 |
sfan5 |
nobody is saying it's usable as baseline |
| 23:29 |
sfan5 |
or that you should implement 100% |
| 23:29 |
nephele |
Exactly, it isn't |
| 23:29 |
nephele |
appguru, are we speaking the same language? |
| 23:29 |
|
turtleman joined #minetest |
| 23:29 |
appguru |
> The engine already has too much game-specific stuff. |
| 23:30 |
sfan5 |
the reality is though if you implement the right subset of maybe 50 nodes/items, most mods will work just fine |
| 23:30 |
appguru |
oof |
| 23:30 |
nephele |
Okay...? |
| 23:30 |
VanessaE |
now I'm starting to get a little pissed off... |
| 23:30 |
appguru |
> are we speaking the same language? |
| 23:30 |
sfan5 |
the only problem with this is that there is no documentation on what to implement |
| 23:30 |
nephele |
good that we werent talking about the engine then |
| 23:30 |
appguru |
probably not |
| 23:30 |
nephele |
sfan5, yes... |
| 23:30 |
GreenXenith |
VE, you're always a little pissed off :) |
| 23:30 |
nephele |
what i have been saying for the last fucking hour |
| 23:30 |
appguru |
that was a copy & paste issue, for context |
| 23:30 |
appguru |
is that you want good standards? |
| 23:30 |
VanessaE |
GreenXenith: not always, you're thinking of Bruce Banner :P |
| 23:30 |
GreenXenith |
Fair 'nuff |
| 23:31 |
nephele |
sfan5, "the reality is though if you implement the right subset of maybe 50 nodes/items, most mods will work just fine" |
| 23:31 |
sfan5 |
nephele: what I gathered is that you specifically taking issue in there not being a baseline and that (anything with MTG) couldn't possibly work |
| 23:31 |
nephele |
That's not true, each game will implement a different subset |
| 23:31 |
sfan5 |
but it appears the last is not actually an issue |
| 23:31 |
appguru |
I agree with nephele that we need some more specifications |
| 23:31 |
VanessaE |
sfan5: it almost sounds like he wants some mtg stuff split off into an out-of-game mod? |
| 23:31 |
nephele |
without a sense of direction or guidance you won't attain any meaningfull compatibility |
| 23:31 |
sfan5 |
VanessaE: not split, just documented |
| 23:32 |
VanessaE |
sfan5: except he was talking about implementation as well, not just the API |
| 23:32 |
appguru |
good example is Wuzzy's #9606 - that thing focuses on HUD element z indexes, but we'd need similar conventions for item names |
| 23:32 |
VanessaE |
s/API/documentation of contents/ |
| 23:32 |
sfan5 |
¯\_(ツ)_/¯ |
| 23:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/9606 -- [discuss] Come up with a convention for HUD element z_index |
| 23:33 |
nephele |
VanessaE, of course i was talking about implementations! I am a literall gamemode author, i have opinions on this |
| 23:33 |
nephele |
and i think sticking my hand into mtg and implementing what bit me is not a good aproach |
| 23:33 |
appguru |
Only convention that I remember from the top of my head is that itemnames should always be `category_type` for meaningful sorting (like `sword_steel` instead of the intuitive `steel_sword`) |
| 23:33 |
GreenXenith |
Literal game author as opposed to .. a figurative one? :D |
| 23:33 |
sfan5 |
nephele: what one considers "meaningful compatibility" is up to the game author, it's true that a potential baseline has strictly better compatibility yet I think it's realistic to implement a subset of MTG to achieve good enough compatibility |
| 23:33 |
nephele |
GreenXenith, absolutely :D |
| 23:34 |
appguru |
what is a figurative game author supposed to be? |
| 23:34 |
nephele |
sfan5, again, no it isn't, each gamemode will pick a different subset, and as a mod author you still can't target anything meaningfull |
| 23:34 |
sfan5 |
well okay if you believe it isn't then it is not for you |
| 23:34 |
GreenXenith |
A figurative game author probably makes imaginary games :^) |
| 23:34 |
nephele |
sfan5, what is? implementing mtg compat? |
| 23:35 |
sfan5 |
"implement a subset of MTG to achieve good enough compatibility" < this |
| 23:35 |
nephele |
It won't work without a known subset |
| 23:35 |
appguru |
MTG does not belong into the engine |
| 23:35 |
nephele |
specifically picking a random subset won't work |
| 23:35 |
sfan5 |
depends on your definition of "work" |
| 23:35 |
sfan5 |
but evidently you believe that it can't work |
| 23:35 |
nephele |
appguru, yes, you said so before, and again, nobody is talking about the engine |
| 23:36 |
appguru |
but it seemed so, or where else do you expect this to be implemented if not in MTG? |
| 23:36 |
nephele |
sfan5, if you have a known set of nodes and crafting groups that games claim to implement any incompatibility resulting from this is a bug you can adress |
| 23:36 |
nephele |
if you just pick a random subset then the mod author is the one that has to test and add exceptions for every gamemode |
| 23:36 |
appguru |
On a side note: I think MTG should be reorganized, with each mod getting it's own repo & MTG effectively becoming a collection of submodules |
| 23:36 |
GreenXenith |
Hmm. appguru mentioned API mods and everyone said it wasnt relevant .. but one could create a compatibility-layer mod with a compiled index of multiple games' items all linked to categories that could be optionally used by mods that wish to have complete compat. |
| 23:36 |
nephele |
appguru, implement what? |
| 23:37 |
appguru |
A common item layer, also known as CLI. |
| 23:37 |
GreenXenith |
A Command Line Interface? Nono ;) |
| 23:37 |
nephele |
.... you know minetest has crafting groups...... riiight? |
| 23:37 |
appguru |
I do |
| 23:37 |
VanessaE |
so, again, split some of mtg into a separate, out-of-game mod that both it and MC2 would import and use. |
| 23:37 |
VanessaE |
that's clearly what you're asking for. |
| 23:37 |
nephele |
No that's stupid |
| 23:38 |
GreenXenith |
What is the usecase of all this discussion? |
| 23:38 |
appguru |
That isn't stupid at all |
| 23:38 |
nephele |
Yes it is |
| 23:38 |
nephele |
Mtg is gpl, i can't use that |
| 23:38 |
appguru |
VanessaE is totally right: common dependencies shouldn't be split off |
| 23:38 |
nephele |
I also fail to see what you have against documentation |
| 23:38 |
VanessaE |
how else do you expect to establish a baseline? |
| 23:38 |
appguru |
* should be |
| 23:38 |
sfan5 |
VanessaE: via a specification |
| 23:38 |
VanessaE |
sfan5: which has to be implemented.... in a mod. |
| 23:38 |
appguru |
yeah, like Wuzzy's issue: a convention written down in the docs |
| 23:38 |
nephele |
VanessaE, no it doesn't |
| 23:39 |
VanessaE |
and most of that implementation could easily come from mtg |
| 23:39 |
sfan5 |
no not that way |
| 23:39 |
GreenXenith |
What is being solved here? I saw MTG and MCL2 mentioned .. is nephele trying to make a mod that works with both without having to manually defined which items to depend on from each game? |
| 23:39 |
GreenXenith |
-d |
| 23:39 |
sfan5 |
you specify " 'default:stone' should be a solid, stone-like node " |
| 23:39 |
sfan5 |
MTG and MCL2 can (and should) both implement this in their own way |
| 23:39 |
VanessaE |
sfan5: well, what good is a specification if you don't *implement* it? |
| 23:40 |
nephele |
GreenXenith, I maintain a gamemode for minetest, i would like to implement atleast a subset so mod authors can target this subset to atleast have a fairly good compatibility across gammodes |
| 23:40 |
sfan5 |
with zero common properties other than what the specificiation say |
| 23:40 |
sfan5 |
you do not literally need the same stone node in both mtg and mcl2 |
| 23:40 |
appguru |
I'd say the fault is probably at the fault of the games which are not taking MTG as baseline |
| 23:40 |
VanessaE |
and if you implement it once, why not re-use that implementation wherever possible? |
| 23:40 |
nephele |
sfan5, something like that, i wouldn't pick the default: name though for obvious reasons |
| 23:40 |
appguru |
You should contact their authors and ask them to change item names |
| 23:40 |
appguru |
Or provide a compatibility layer |
| 23:40 |
sfan5 |
VanessaE: because not every game should be variant of MTG |
| 23:41 |
sfan5 |
that would be kinda boring |
| 23:41 |
GreenXenith |
Games should not be based on MTG at all |
| 23:41 |
nephele |
appguru, uhm, yeah no, i have no interest, whatsoever to follow mtgs idiotic naming conventions and implementing it |
| 23:41 |
appguru |
Nu |
| 23:41 |
VanessaE |
sfan5: sure, I get that, but it's still e.g. "default:stone"... |
| 23:41 |
appguru |
MTG's naming conventions aren't that idiotic |
| 23:41 |
GreenXenith |
Down with MTG conventions! |
| 23:41 |
appguru |
Problem is, everyone thinks the other's conventions are idiotic |
| 23:41 |
nephele |
VanessaE, it would likely be more like group:solid_stone or something |
| 23:41 |
appguru |
So in the end you have no baseline :') |
| 23:41 |
nephele |
or a different name |
| 23:41 |
appguru |
cracky? |
| 23:41 |
GreenXenith |
So what I said earlier: A single item compatibility layer can totally be used to accomplish this goal. |
| 23:42 |
appguru |
but coming back GreenXenith: MTG is a good base |
| 23:42 |
appguru |
you just have to use it properly |
| 23:42 |
VanessaE |
nephele: in other words, everything should be rewritten to never use an actual node/item name, but a group name. |
| 23:42 |
VanessaE |
(in recipes et al.) |
| 23:42 |
nephele |
VanessaE, not neccesarily? that was an example |
| 23:43 |
appguru |
if using MTG mods as submodules, everything is fine |
| 23:43 |
VanessaE |
well that's the only way your "specification" is ever gonna work in reality. |
| 23:43 |
nephele |
No |
| 23:43 |
nephele |
Crafting groups are not neccesary |
| 23:43 |
nephele |
you could use aliases just aswel |
| 23:43 |
GreenXenith |
I dont want my games touch MTG with a 39.5-foot pole |
| 23:43 |
appguru |
I'm just sort of annoyed by games just copy & pasting MTG, which will end up with a buggy version in a few years as they don't pull in updates and often make custom modifications which result in merge conflicts if they try to... |
| 23:43 |
GreenXenith |
to touch* |
| 23:43 |
VanessaE |
nephele: and I suggested aliases ages ago. |
| 23:44 |
appguru |
There are some games which clearly shouldn't touch MTG |
| 23:44 |
nephele |
VanessaE, okay...? |
| 23:44 |
nephele |
still has nothing to do with a baseline spec |
| 23:44 |
appguru |
Such as my Cellestial Game (and a 2nd one in the planning) |
| 23:44 |
VanessaE |
except aliases won't work eithe, because they still have to reference a single, specific node. |
| 23:44 |
VanessaE |
+r |
| 23:44 |
appguru |
nephele: write your spec, publish it, and see if it's approved |
| 23:44 |
nephele |
Where is the problem in that? |
| 23:44 |
nephele |
appguru, aproved by whom? |
| 23:44 |
appguru |
the modding community which will have to use it |
| 23:45 |
VanessaE |
so your back to your spec and '"default:stone" should be etc etc' as sfan5 put it |
| 23:45 |
appguru |
I'd say go to MT Forum if that wasn't 500ing |
| 23:45 |
appguru |
Else you'll end up with builtin mechanisms which are unsupported, and eventually people will be rolling their own anyways |
| 23:45 |
nephele |
VanessaE, yeah the spec would say "awesome:stone stone used for $blah", and then i can implement it in a mod called awesome aliasing names to my gamemodes specific node names |
| 23:45 |
appguru |
(unsupported as in, modders dislike) |
| 23:46 |
VanessaE |
nephele: ok, and what of all the mods out there that DON'T use this new spec you're wanting? |
| 23:46 |
nephele |
what of them? |
| 23:46 |
appguru |
death |
| 23:46 |
VanessaE |
they're still incompatible with MC2? |
| 23:46 |
nephele |
yeah, so? |
| 23:46 |
VanessaE |
so again, you're asking mod authors to make changes just so their mods work with MC2 |
| 23:47 |
VanessaE |
I mean literally, you're the only one asking for this |
| 23:47 |
nephele |
where did you read that? |
| 23:47 |
appguru |
I usually just go for MTG compat |
| 23:47 |
VanessaE |
for this spec* |
| 23:47 |
appguru |
mod authors will be afraid to change item names |
| 23:47 |
VanessaE |
[04-24 18:43] <nephele> mineclone2 does not implement the default mod |
| 23:47 |
VanessaE |
[04-24 18:44] <nephele> either the mobs mod shoudl explicitly support it, or a compat layer may be used (i don't know of any though...) |
| 23:47 |
nephele |
It's a tool for mod authors to target something that gives them a broad range of compatibility (within certain restrictions) |
| 23:47 |
VanessaE |
I read "it" as "MC2" in that comment. |
| 23:48 |
appguru |
nephele: are you suggesting we all go for MCL2 compat? |
| 23:48 |
nephele |
I think i am suggesting, that you fucking read my messages instead of making up bullshit |
| 23:48 |
VanessaE |
all right, that's enough of that. |
| 23:48 |
nephele |
VanessaE, that reffered to now anyhow, there is no spec |
| 23:49 |
VanessaE |
stand down, nephele |
| 23:49 |
GreenXenith |
I see no issue with rolling your own compat .. registering different recipes based on what mods are available is easy and viable |
| 23:49 |
nephele |
there is nothing for mineclone2 to implement, so either it implements default compat now, or one uses a compat layer |
| 23:49 |
appguru |
"shoudl explicitly support it", with it being MCL2, which is why my question |
| 23:49 |
nephele |
but again, i dont know of any compat layers |
| 23:49 |
appguru |
you could go and write one? |
| 23:49 |
nephele |
GreenXenith, the issue is still that it's extremely high effort to try and make a perfect mtg compat |
| 23:50 |
nephele |
a base spec would atleast give you a baseline |
| 23:50 |
appguru |
actually not |
| 23:50 |
nephele |
VanessaE, from where? |
| 23:50 |
appguru |
MTG compat is pretty easy |
| 23:50 |
nephele |
No it isn't |
| 23:50 |
appguru |
Item names of MTG are mostly straightforward |
| 23:50 |
appguru |
Same goes for the API |
| 23:50 |
nephele |
It's still a huge set |
| 23:50 |
VanessaE |
look, the bottom line is there are mods you obviously wish you could use under MC2, but which don't work with it. Either the mods have to be rewritten to add MC2 compat, or to use some "common" spec such as you propose. |
| 23:50 |
nephele |
Which you would have to map in it's entirety to another gamemode |
| 23:51 |
nephele |
sure? but the common spec doesn't exist currently |
| 23:51 |
VanessaE |
or MC2 has to be altered to offer enough compatibility that those mods work. |
| 23:51 |
GreenXenith |
Provided you have similar materials in each game (which most a lot do), it should be fairly low-effort |
| 23:51 |
VanessaE |
and I can almost guarantee you that asking the rest of us to make out mods work on MC2 won't fly. |
| 23:52 |
nephele |
VanessaE, it's an optional tool |
| 23:52 |
GreenXenith |
(I think a compat layer mod seems like a reasonable idea ...) |
| 23:52 |
nephele |
if you care about it you can use it |
| 23:52 |
VanessaE |
I know I won't bother on my mods, I have WAY too much code to change to make that happen. |
| 23:52 |
nephele |
if you don't care, develop for mtg and be happy |
| 23:52 |
LMD |
Games are different, so having such a "baseline spec" is not easy, and in general achieving consensus among modders |
| 23:53 |
nephele |
Well, it's not going to be a "baseline for all gamemodes in minetest" think |
| 23:53 |
GreenXenith |
If a compat layer existed, modders should either use it and not care about what it decides to do, or make their own item maps |
| 23:53 |
VanessaE |
so the only thing that's gonna happen in reality is if you or some of your partners-in-code fork those desirable mods, alter them, and then maintain them as the originals continue to evolve |
| 23:53 |
nephele |
GreenXenith, Having a specification gives game authors much less overhead to implement |
| 23:53 |
nephele |
and gives you a pretty good thing to point at |
| 23:53 |
VanessaE |
so then again you're back to the "moving target" you complain of |
| 23:53 |
nephele |
VanessaE, no, why? |
| 23:53 |
LMD |
if this continues I'll probably write a spec & implement relevant compatibility mappings |
| 23:53 |
nephele |
I don't require mods to work on all gamemodes |
| 23:54 |
nephele |
and most won't |
| 23:54 |
VanessaE |
but clearly there are some you DO want |
| 23:54 |
GreenXenith |
a compat layer would be extremely easy to write .. in fact, you could leave out the implementation and make a mod dedicated to providing just item mapping data |
| 23:54 |
nephele |
Yes, my mods |
| 23:54 |
nephele |
I want to offer them to be used on other gamemodes aswell |
| 23:55 |
LMD |
The real solution is to have stuff like recipes not inside the code but instead inside of configuration files |
| 23:55 |
VanessaE |
yet you complained that mobs_redo doesn't work |
| 23:55 |
nephele |
No i dind't |
| 23:55 |
LMD |
Mods can and should provide decent default configurations, but if those don't suffice, users can extend them |
| 23:55 |
nephele |
That was in reference to an earlier comment |
| 23:55 |
nephele |
I don't plan to use mobs redo |
| 23:55 |
nephele |
and i don't playe mineclone2 either |
| 23:55 |
VanessaE |
correction, scott_ complained. |
| 23:56 |
nephele |
I only attempted to explain why it was incompatible and a possible mitigation for that moement |
| 23:56 |
orbea |
nephele: so you basically want something like the POSIX spec, but for minetest? |
| 23:56 |
LMD |
Someone should probably write a spec |
| 23:56 |
nephele |
the discussion about a possible baseline spec came after that and is mostly unrelated, except that it is about compatibility |
| 23:56 |
VanessaE |
no matter how you choose to "mitigate" this, nephele, SOMEONE will have to rewrite a bunch of mod code, even if it's only you |
| 23:56 |
LMD |
true |
| 23:56 |
VanessaE |
and if only you are gonna use i, what's the point of this spec |
| 23:56 |
VanessaE |
it* |
| 23:57 |
nephele |
so :) i can spend my time how i wish |
| 23:57 |
nephele |
A spec allows other people to be compatibile without having to dig around in my code |
| 23:57 |
LMD |
the point of the spec would be that modders don't invent item names and groups as they wish, but instead use common groups & names specified in the spec |
| 23:57 |
VanessaE |
you know full well no one who maintains a big project is gonna bother with that. |
| 23:57 |
nephele |
it's way easier to read a doc outlining the expectations than trying to be compatible by copying implemnetations or even implemnetation bugs |
| 23:58 |
GreenXenith |
If you had an item map, you could automate rewriting >.> |
| 23:58 |
nephele |
No, that is your assumption |
| 23:59 |
LMD |
I suggest advanced alias methods |
| 23:59 |
VanessaE |
and it has a high probability of being right :P |
| 23:59 |
nephele |
No, that is your assumption :P |
| 23:59 |
LMD |
for example registering alias groups |
