| Time |
Nick |
Message |
| 00:02 |
|
SFENCE joined #minetest |
| 00:03 |
cheapie |
I have to wonder where this constant stream of kids (that act like they're about 8 years old) that join one specific server and go straight for celevator is coming from... |
| 00:04 |
cheapie |
Among older players there's mostly only interest from those who already showed interest in elevators beforehand, which isn't a whole lot (but is about what I expected)... but then there's this stream of kids for some reason. |
| 00:05 |
ireallyhateirc |
cheapie, Multicraft |
| 00:06 |
ireallyhateirc |
also maybe someone made a youtube video for your stuff without you knowing about it lol |
| 00:06 |
cheapie |
I've been watching for such a video (it wouldn't be the first time, someone did one for ltc4000e) - I did make one myself, but it only has ~500 views. |
| 00:07 |
cheapie |
Not sure what Multicraft has to do with it, Multicraft has been a persistent thorn in our sides over there for other reasons but I doubt it goes "join this one, it has elevators" |
| 00:09 |
ireallyhateirc |
it's not like they can break anything, can they? |
| 00:09 |
cheapie |
It doesn't break anything by existing, no, but it has a lot of broken features and causes all sorts of problems for them, then we get complained at about it. |
| 00:09 |
|
silverwolf73828 joined #minetest |
| 00:10 |
cheapie |
Seems like paramtype2 = "4dir" and [png don't work for most of them. |
| 00:11 |
cheapie |
celevator uses 4dir heavily, and while celevator doesn't use [png, another mod on the server (digiscreen) does, and tends to spew a ridiculous amount of errors on Multicraft. Works fine in MT. |
| 00:11 |
ireallyhateirc |
I mean kids |
| 00:12 |
ireallyhateirc |
they join, maybe are annoying, but if they can't destroy any nodes then it's fine I guess? |
| 00:12 |
cheapie |
The worst the kids usually do is act obnoxious in chat and grief a bit, nothing too terrible. |
| 00:13 |
cheapie |
On that server, at least near the spawn, we currently go for "protect your buildings, but any unprotected land is free to build on", so most of the node-related nonsense they do is just placing garbage all over and not so much breaking anything. It's easy enough to clean up, rollback recording is turned on. |
| 00:15 |
cheapie |
For a while I thought some of them were going crazy with placing celevator controllers and/or dispatchers everywhere as the ID numbers were up to something like 800 - turns out that while there's some of that, at least around 300 of them are actually legitimately working elevators... it's just popular, I guess. |
| 00:15 |
|
jistr joined #minetest |
| 00:19 |
|
SFENCE joined #minetest |
| 00:27 |
ireallyhateirc |
hmmm I'm now actually curious, does *Minecraft* have any mod that's comparable/better than yours? |
| 00:29 |
ireallyhateirc |
there probably are some, but at the end of the day they're probably proprietary together with the main game so ¯\_(ツ)_/¯ |
| 00:37 |
|
SFENCE joined #minetest |
| 00:52 |
cheapie |
ireallyhateirc: "The Other Game In Which You Mine and Craft™" has an "MTR" mod that....... well, it doesn't even really compare to celevator once you start digging into celevator's features, but from a basic user's point of view it's not too far off. |
| 00:53 |
cheapie |
It looks something like this: https://www.youtube.com/watch?v=jSKjYJnBQkI |
| 00:55 |
MTDiscord |
<damotrix> Yeah your mod had like 1000x more detail |
| 00:55 |
cheapie |
It does have support for rear doors, adjustable car size, and larger PIs, which celevator doesn't... but celevator has independent service, fire service, adjustable speed, inspection (car top and machine room), various controller status displays, group dispatching (I'm still proud of the algorithm behind that :P), destination-based dispatching, car call security, motor sounds, an animated hoist machine, remote monitoring, mesecons/digilines |
| 00:55 |
cheapie |
communication... |
| 00:56 |
cheapie |
Also you can surf the elevators in celevator :P |
| 00:57 |
|
SFENCE joined #minetest |
| 00:57 |
ireallyhateirc |
good to hear that, we need more stuff better than the other game has lol |
| 00:58 |
ireallyhateirc |
we don't use Java and the modding API actually exists, which is good :D |
| 00:59 |
cheapie |
AFAIK ltc4000e beats everything they have in the traffic signal control "market" too |
| 01:01 |
ireallyhateirc |
aaand we don't work for Microsoft in our free time |
| 01:02 |
|
SFENCE joined #minetest |
| 01:10 |
cheapie |
TBH I would kind of like to see some advancement in the elevator mods over there too - but I don't say that with the goal of furthering that game in general, but... just so I have more to compete with. |
| 01:10 |
|
ireallyhateirc2 joined #minetest |
| 01:11 |
MTDiscord |
<damotrix> Technically you can bring more people to MT if they don't step up their game sooooo |
| 01:11 |
|
sparky4 joined #minetest |
| 01:11 |
cheapie |
More different elevator mods in MT would work for this goal too :P |
| 01:12 |
MTDiscord |
<damotrix> Hehehehehehe fair X3 |
| 01:12 |
cheapie |
As it stands, I've been having to read actual real-life elevator controller manuals to find things I should pull into the game. |
| 01:13 |
MTDiscord |
<damotrix> From what I've seen, it's far beyond me. But it seems like an insane level of details and working parts |
| 01:13 |
cheapie |
There's also https://www.skyscrapersim.net/ (which is basically just entirely an elevator simulator game) but celevator is pulling off more detail than even /that/ in some areas (like that dispatching I mentioned). |
| 01:14 |
MTDiscord |
<damotrix> Oooooo |
| 01:15 |
cheapie |
Heck, if you were to take some real-life building with elevators from the 60s or 70s (maybe even 80s), rip out the dispatcher, and somehow make celevator's dispatcher code handle the hall calls... they might actually run noticeably *better*. |
| 01:16 |
cheapie |
(relay logic didn't dispatch all that great, neither did early solid-state stuff) |
| 01:16 |
|
ireallyhateirc2 joined #minetest |
| 01:17 |
cheapie |
In celevator it's similar to something you'd see IRL sometime around the late 80s through most of the 90s, but optimized slightly differently as things like energy efficiency aren't a concern in MT. |
| 01:20 |
MTDiscord |
<damotrix> Yeah huh, hmm |
| 01:22 |
ireallyhateirc2 |
is building elevators with your mod complex? I'm yet to try it, but I suck at building. |
| 01:22 |
cheapie |
It's not too terrible, installation instructions start on page 8 of the manual if you want to read through them: https://cheapiesystems.com/git/celevator/plain/docs/celevator_controller_manual.pdf |
| 01:24 |
cheapie |
As it mentions, most of the steps are optional - the minimum required to get a working elevator is the controller, drive, car, machine, and doors. You'll probably also want to add some call buttons and stuff unless you want to run it on independent all the time. |
| 01:29 |
ireallyhateirc2 |
ooh manual, great |
| 01:31 |
cheapie |
Not just any manual, a 61-page manual (that will probably get longer this weekend, I've added more stuff since then and need to update it) |
| 01:32 |
ireallyhateirc2 |
longer than my bachelor's paper |
| 01:34 |
MTDiscord |
<damotrix> Oooo and LMAO |
| 01:37 |
|
SFENCE joined #minetest |
| 01:38 |
|
sparky4 joined #minetest |
| 01:39 |
cheapie |
Random fun(?) fact: the controller and dispatcher textures when the doors are open are based on a specific real-life controller and a specific real-life dispatcher, but not from the same manufacturer as each other. |
| 01:47 |
|
cation joined #minetest |
| 01:56 |
|
SFENCE joined #minetest |
| 02:04 |
MTDiscord |
<damotrix> I thought you were gon mention half life 2 |
| 02:04 |
MTDiscord |
<damotrix> And ooh, not the same manufacturer? |
| 02:10 |
cheapie |
It's a rather loose resemblance, but still enough of one that someone who works with the things frequently might be able to recognize them - the celevator controller's inside textures are based on the Montgomery Miprom 21, while the dispatcher inside textures are based on an MCE IMC-series dispatcher. |
| 02:11 |
MTDiscord |
<damotrix> Ooooooh |
| 02:12 |
cheapie |
The behavior of the LEDs (the ones on the textures, not in the controller formspec) does differ a bit from the real thing - on the controller the animated LEDs have no significance or resemblance to the real thing, but the LEDs that turn on when the car is moving are vaguely similar to it. |
| 02:13 |
cheapie |
In the dispatcher, the animation does include MCE's famous scrolling LEDs (and yes, in the correct direction for a dispatcher :P) but that's it, none of the lights mean anything. |
| 02:15 |
MTDiscord |
<damotrix> Ohhh :o |
| 02:15 |
cheapie |
TBH I kind of like what MCE did with those lights back then - they'd scroll in one direction for a simplex car, in the other direction for a dispatcher, and back and forth (Knight Rider style) for a car in a group. If there was a fault or other special mode going on, they'd switch to flashing a number in binary that you could look up in the manual. |
| 02:15 |
cheapie |
(celevator doesn't do this, they just always keep scrolling) |
| 02:18 |
cheapie |
Here's a video inside one of the controllers that celevator's controller inside textures are based on: https://www.youtube.com/watch?v=0hNDbzjHKE0 |
| 02:20 |
cheapie |
And a similar dispatcher to what celevator's dispatcher textures were based on (note the stuff below the monitor+keyboard): https://www.youtube.com/watch?v=q9zvWsU-Ay4&t=312 |
| 02:20 |
MTDiscord |
<damotrix> Scrolling lights? |
| 02:21 |
|
SFENCE joined #minetest |
| 02:22 |
cheapie |
4:00 in that video has a view inside an MCE IMC-SCR controller, the lights I was talking about are visible on the smaller of the two white boxes on the left side of the cabinet. |
| 02:22 |
MTDiscord |
<damotrix> Ohh |
| 02:22 |
cheapie |
In that case it's a controller in a group, so the lights scroll back and forth instead of just in one direction. |
| 02:24 |
MTDiscord |
<damotrix> Ohhh I see. It kinda reminds me of an older thermostat with the yellowing. But I see what you mean, it's like, the light is pacing back and forth |
| 02:26 |
cheapie |
If there's a fault then it shows an error code in binary on those - like to take "Door Open Limit Failure" as an example, this is fault 83, so out of the 8 lights, the 1st, 7th, and 8th lights would be flashing while the rest are off. |
| 02:26 |
MTDiscord |
<damotrix> Oooh |
| 02:26 |
cheapie |
(10000011 = 0x83, then you look that number up in the manual) |
| 02:27 |
cheapie |
https://acim.nidec.com/elevators/-/media/elevators/mce/pdfs/legacy-control-manuals/imc-scr-rev-e8.ashx page 190 if you want the whole list |
| 02:28 |
MTDiscord |
<damotrix> Oh I see :o |
| 02:29 |
cheapie |
In the case of celevator, it has a screen (formspec), so... I just have it display faults on there. |
| 02:30 |
MTDiscord |
<damotrix> Yeah |
| 02:32 |
cheapie |
I do tend to use rather MCE-like terminology in a lot of it, part of that comes from reading this during the development: https://acim.nidec.com/elevators/-/media/elevators/mce/pdfs/icontrol-ac-august-08.ashx |
| 02:33 |
cheapie |
Compare page 281 of that manual to page 57 of mine... you can probably see where a lot of the formatting ideas came from. |
| 02:33 |
MTDiscord |
<damotrix> Oooo :o |
| 02:37 |
cheapie |
At least two of these messages ("Position Sync - Terminal" and "Position Sync - Floor") are identical between celevator and that specific real-life controller and mean effectively the same thing. |
| 02:38 |
MTDiscord |
<damotrix> Oh ok :o |
| 02:58 |
|
SFENCE joined #minetest |
| 03:23 |
|
amfl2 joined #minetest |
| 03:23 |
|
SFENCE joined #minetest |
| 03:41 |
|
SFENCE joined #minetest |
| 03:51 |
|
SFENCE_arch joined #minetest |
| 03:59 |
|
SFENCE joined #minetest |
| 03:59 |
|
bodiccea joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:15 |
|
SFENCE joined #minetest |
| 04:54 |
|
est31 joined #minetest |
| 05:01 |
|
Trifton_ joined #minetest |
| 05:02 |
|
SFENCE joined #minetest |
| 05:30 |
|
boingman joined #minetest |
| 05:54 |
|
cranez joined #minetest |
| 06:13 |
|
gregon joined #minetest |
| 06:18 |
|
liceDibrarian joined #minetest |
| 07:23 |
|
book` joined #minetest |
| 07:26 |
|
gregon joined #minetest |
| 07:48 |
|
MacroFaxSax joined #minetest |
| 07:51 |
|
Kimapr joined #minetest |
| 08:10 |
|
TomTom joined #minetest |
| 08:17 |
|
Talkless joined #minetest |
| 08:23 |
|
Glaedr joined #minetest |
| 09:15 |
|
gregon joined #minetest |
| 09:29 |
|
mrkubax10 joined #minetest |
| 09:56 |
|
cx384 joined #minetest |
| 10:03 |
|
gregon joined #minetest |
| 10:03 |
|
Guest21 joined #minetest |
| 10:03 |
|
YuGiOhJCJ joined #minetest |
| 10:17 |
|
Juri joined #minetest |
| 10:17 |
|
Niklp joined #minetest |
| 10:42 |
|
Desour joined #minetest |
| 10:47 |
|
SFENCE joined #minetest |
| 11:10 |
|
ireallyhateirc joined #minetest |
| 11:17 |
|
boingman joined #minetest |
| 11:21 |
|
SFENCE joined #minetest |
| 11:43 |
|
jaca122 joined #minetest |
| 11:49 |
|
mrkubax10 joined #minetest |
| 11:50 |
|
Thelie joined #minetest |
| 11:54 |
|
SFENCE joined #minetest |
| 12:00 |
|
simon816 joined #minetest |
| 12:14 |
|
SFENCE joined #minetest |
| 12:26 |
|
silverwolf73828 joined #minetest |
| 12:29 |
|
SFENCE joined #minetest |
| 12:35 |
|
silverwolf73828 joined #minetest |
| 12:47 |
|
SFENCE joined #minetest |
| 12:49 |
|
ball joined #minetest |
| 12:50 |
ball |
My son is about to try the lucky_block mod. |
| 12:51 |
ireallyhateirc |
good luck :) |
| 12:51 |
ball |
I would be playing Minetest myself but I have some software building. |
| 13:02 |
ball |
He likes the lucky blocks and super lucky blocks. |
| 13:05 |
|
SFENCE joined #minetest |
| 13:20 |
|
Thelie joined #minetest |
| 13:23 |
ball |
Now he's on to the dragons. |
| 13:26 |
MTDiscord |
<bastrabun> The Age of Discovery. Everyone has that in Minetest sooner or later 😉 |
| 13:27 |
ball |
Looks like he's feeding them rats. |
| 13:30 |
|
SFENCE joined #minetest |
| 13:49 |
|
SFENCE joined #minetest |
| 14:06 |
|
SFENCE joined #minetest |
| 14:26 |
|
SFENCE joined #minetest |
| 14:27 |
|
TomTom joined #minetest |
| 14:36 |
MTDiscord |
<damotrix> LMAOOOO age of discovery |
| 14:38 |
ball |
I must have passed the AoD because I just dug through mountains and built cottages every 1,024. |
| 14:38 |
* ball |
shrugs |
| 14:38 |
ball |
I find it relaxing. |
| 14:57 |
|
SFENCE joined #minetest |
| 15:00 |
|
SFENCE joined #minetest |
| 15:21 |
MTDiscord |
<warr1024> Documentation for minetest.compare_block_status is confusing or misleading: it seems like it's checking if a block's state is equal to the value specified, instead of greater than or equal, and it doesn't indicate that the enum choices there are ordered. |
| 15:22 |
MTDiscord |
<warr1024> i.e. it's not obvious that a block that's active must also be loaded, and actually confusing that a block that's loaded is apparently also emerging and uknown...? |
| 15:37 |
Krock |
https://i.imgflip.com/3te0a9.jpg |
| 15:37 |
|
gregon joined #minetest |
| 15:40 |
|
SFENCE joined #minetest |
| 15:42 |
|
SFENCE joined #minetest |
| 16:01 |
|
SFENCE joined #minetest |
| 16:04 |
|
SFENCE joined #minetest |
| 16:07 |
MTDiscord |
<warr1024> Is it worth making an issue for that? |
| 16:17 |
|
SFENCE joined #minetest |
| 16:17 |
|
gregon joined #minetest |
| 16:18 |
|
fluxionary joined #minetest |
| 16:26 |
Krock |
it might be worth opening a PR for that - either to correct the documentation or to deprecate the API if it turns out to be useless. |
| 16:27 |
|
ball left #minetest |
| 16:32 |
|
SFENCE joined #minetest |
| 16:33 |
MTDiscord |
<warr1024> It's actually incredibly important ... but the API itself is badly designed. |
| 16:33 |
MTDiscord |
<warr1024> Like, there's no way to find out which mapblocks are loaded or active or whatever, we have to guess and poll. |
| 16:34 |
ireallyhateirc |
I also found that part of API confusing |
| 16:34 |
ireallyhateirc |
also you give a pos, but it checks a mapblock? this needs to be clarified |
| 16:35 |
MTDiscord |
<warr1024> There is a certain amount of inconsistency between using block pos and node pos and they're not always explicit |
| 16:35 |
|
jaca122 joined #minetest |
| 16:35 |
MTDiscord |
<warr1024> in this case it takes a node pos |
| 16:35 |
|
gregon joined #minetest |
| 16:35 |
MTDiscord |
<warr1024> if the mapblock is active then the node is also active, so that's not a disconnect per se |
| 16:36 |
|
frostsnow joined #minetest |
| 16:36 |
MTDiscord |
<warr1024> it's just weird that some other APIs DO use blockpos instead of node pos. |
| 16:36 |
|
SFENCE joined #minetest |
| 16:36 |
MTDiscord |
<bastrabun> A bit more design and less on demand might be generally a good idea |
| 16:42 |
MTDiscord |
<warr1024> The existing API is good for certain use-cases. I was actually lucky I discovered it a few days ago because it turned out to be the only available solution to a real-world problem. |
| 16:43 |
MTDiscord |
<warr1024> I don't think it would be good to "replace" it, but it could be extended with some alternatives that make more sense for other use-cases. |
| 16:43 |
MTDiscord |
<warr1024> The only thing I could see really replaceing it would be an on_mapblock_state_change callback, really. |
| 16:52 |
|
gregon joined #minetest |
| 16:52 |
Krock |
huh? What API uses blockpos? VManips? |
| 17:00 |
MTDiscord |
<warr1024> emerge_area and send_mapblock |
| 17:01 |
Krock |
oh great -.- |
| 17:07 |
|
SFENCE joined #minetest |
| 17:17 |
|
SFENCE joined #minetest |
| 17:21 |
|
SFENCE joined #minetest |
| 17:30 |
|
TheCoffeMaker joined #minetest |
| 17:41 |
|
imi joined #minetest |
| 17:43 |
|
TheCoffeMaker_ joined #minetest |
| 17:47 |
|
SFENCE joined #minetest |
| 17:51 |
|
lemonzest joined #minetest |
| 17:58 |
|
SFENCE joined #minetest |
| 18:10 |
|
SFENCE joined #minetest |
| 18:56 |
|
Sokomine joined #minetest |
| 18:57 |
|
SFENCE joined #minetest |
| 19:06 |
|
Kimapr_ joined #minetest |
| 19:19 |
|
Sokomine joined #minetest |
| 20:03 |
|
Artea joined #minetest |
| 20:41 |
|
SFENCE joined #minetest |
| 21:07 |
|
boingman joined #minetest |
| 21:18 |
ireallyhateirc |
theoretically, which one has a bigger impact on performance: making a loop function with minetest.after(10, loop) with tail recursion or registering a global step and checking if 10s have passed? |
| 21:22 |
|
Fulgen joined #minetest |
| 21:29 |
MTDiscord |
<bastrabun> minetest.after eventually goes into a globalstep. A function every 10 seconds doesn't do much in comparison (except the function ofc). I'd rather ask: is that a continuous task that over the runtime of the server will be executed every 10 seconds (then rather globalstep) or is there a start and end, so that it can be terminated eventually (and later picked up again) - then minetest.after |
| 21:32 |
ireallyhateirc |
it basically checks every 10 seconds if there's anything to do, if there is something then it starts Voxel Manipulators |
| 21:39 |
|
illwieckz joined #minetest |
| 22:08 |
|
boingman joined #minetest |
| 22:11 |
MTDiscord |
<luatic> ireallyhateirc: Don't worry about that. Either solution is completely fine. |
| 22:11 |
MTDiscord |
<luatic> This is the kind of thing that's really negligible. |
| 22:13 |
MTDiscord |
<luatic> If you instead said, I want to register a million globalsteps, I'd start to think about it (and the answer would be to use minetest.after, since that leverages a heap internally). But for the couple statically registered globalsteps, it really doesn't matter at all. Thinking about it is just premature optimization. |
| 22:25 |
ireallyhateirc |
hmmm sounds good then |
| 22:33 |
|
panwolfram joined #minetest |
| 22:44 |
|
TheCoffeMaker joined #minetest |
| 22:48 |
|
bvm joined #minetest |
| 23:05 |
|
Eragon joined #minetest |
