Additionally, if an elevator is located such that there is a room or similar underneath the pit, such as an elevator that goes down to the lobby but then has an underground parking garage below it, the counterweight will often have its own set of safety gear and its own governor. This is to prevent the counterweight from crashing through the bottom of the pit and into the area below if the hoist ropes were to fail. Even though celevator doesn't (yet?) have counterweights, you can kind of simulate this by placing a second governor if you want... actually you can place as many governors per car as you want, and at one point I had something like 20 of them connected to the same car as an experiment. There also aren't any restrictions (in celevator) as to where you put them, meaning if you use one as a desk ornament or something, you can connect it to an elevator across town and it'll spin when that one moves.
In celevator, it's just for decoration. You can set a car number on it and it will spin when that car moves. It's relatively new, so it hasn't made it into a manual update just yet.
In real life, it's used to protect against overspeed. There's a separate rope/cable that runs in a loop between the governor at the top (for overhead traction installations like what celevator is meant for, it's usually just on the floor next to the machine) and an idler down at the bottom (in the pit). This rope is attached to the safety gear on the car, and in normal operation the governor moves freely, not doing much other than spinning the governor as the car moves.
However, if the car moves too fast (only downwards on older installations, either direction on many newer ones), a switch in the governor opens (electrical trip). This switch is in the safety circuit along with things like the door locks, stop buttons, etc., and causes an emergency stop. If a rope brake is installed, it will possibly apply too. If the car continues to accelerate, for example if the hoist ropes have all failed or if the brakes are not working for some reason, the governor locks up (mechanical trip) and prevents the governor rope from moving. This pulls on the safety gear on the car, causing it to apply. In its most basic form, this is just a metal wedge that gets pulled in between the car and the guide rails and jams it in place. Higher-speed elevators have more elaborate systems to prevent the deceleration from being so strong as to cause injury.
The "home floors" idea that I'd like to implement sometime is something that's occasionally used on these in real life, especially in places like office buildings and hotels. The idea is that in those kinds of buildings, everyone really just has one floor they ever go to (the one they work on, the one their hotel room is on, etc.), and there might be some need to prevent them from going to other floors. So what gets done is that things are configured such that everyone arriving at the elevators has to authenticate somehow (often a keycard), and in doing so their floor is also automatically selected.
For example, if you worked on the 37th floor of such a building, when you arrived at the elevators in the morning, the DBD kiosk would just say something like "please tap card on reader". It might also offer a few floor selections like a cafeteria and parking or something, but that's it. But then when you tap your keycard on the reader, it would not only unlock floor 37 for you, but automatically select it too. It might go something like "please tap card on reader" -> tap -> "please use elevator C to floor 37"
This is my most recent (major) mod, yes - and if you like it that much, reviews are always appreciated :D
I do have a few other mods that focus on technology from real life, ltc4000e probably being the other big one but that one is really showing its age by now. I have plenty of ideas I want to put into a successor to that one if I ever get around to that. I also did a fire alarm mod a few years ago, never uploaded it here as it's admittedly kind of low quality, but someone else did fork it recently and uploaded their fork. I haven't tried said fork, but it sounds like it's still pretty similar to mine.
The various special modes in celevator mostly follow the applicable codes in the US (where I'm from), mostly ASME A17.1. This means you can probably find explanations of them elsewhere online and most of the information will apply to here too. Just in case though, I typed up a short version of what they do here - had to link to a text file as otherwise I'd have to split this whole thing into three comments.
As far as an improved DBD kiosk goes - I'd like to make the layout editable and add support for things like restricting access to certain floors from it, or even having the ability to have "home floors" for certain players where it just automatically selects the appropriate floor for them.
(split into a second reply because of the character limit)
My interest in Luanti modding kind of comes and goes over time, right now it's a bit on the lower side so I haven't been doing all that much. When it comes back (most likely in a few months) I'd like to work on the following, in no particular order:
Better DBD kiosk
Gearless hoist machine (the geared one is a bit silly at high speeds)
Techage integration (for communication, much like the current mesecons support - not for power)
More car designs
More door types (center-opening being the big one)
More operation modes (occupant evacuation, seismic, medical emergency, etc.)
Roller guides on the car
Better organization of controller parameters
Assorted refactoring
And some other feature ideas that would be nice but I may or may not do, as I'm not sure if they'd be worth the (rather high) effort:
If you use the DBD kiosk (the one where it says something like "Please use elevator A") then it will always send the one that was assigned. If you use the normal call buttons (the ones with up and down buttons) and connect them to a specific elevator by entering the controller ID, they will also always call that specific one.
However, if you use the normal call buttons (up/down buttons) and connect them to a dispatcher that itself is connected to multiple cars, it will try to pick whichever car can respond soonest. This may or may not be the closest one. If the situation changes (for example, the originally selected car goes out of service or has several more calls entered) it may change to a different car as appropriate. You can watch this happen on the dispatcher's display.
The reason there are directional lanterns and position indicators in that screenshot is for realism - where I live IRL, the following are required:
When a car arrives, a visual indication of which direction it is going (fulfilled by the lantern)
When a car arrives, an audible indication of which direction it is going, in the form of a single signal for up and a double signal for down (fulfulled by the bell built into the lantern)
For buildings over a certain height, an indication, on at least the main floor, of the current location of each car (fulfilled by the position indicators)
Oh, were you already using DBD? Never mind about the reassignment thing then, I thought you were using the standard call buttons (it only applies to those).
I might add lanterns with letters on them someday, but it's not very high on my priority list. Often I use the labels from display_modpack to label the cars.
Typically I arrange things something like in this screenshot when using DBD.
I'll experiment a bit more with the motor stuff sometime and see if I can reproduce that issue.
Can you elaborate on the "placed incorrectly" part? As far as I'm aware, as long as it was able to find the car (shows coordinates) it should work to move the car anywhere from where the car was placed up to just below the motor.
As far as an indicator of which car is coming - the main thing making that a bit problematic is that the dispatcher is able to reassign calls to other cars if needed, for example if a car becomes available that could answer the call much sooner or if the initially selected car goes out of service for whatever reason. It should be possible, provided you have mesecons installed, to drive an indicator lamp using some of the mesecons output modules (using the "up/down call exists at landing" options). However, it's possible, especially during heavy traffic, that you may see it light on multiple different cars as conditions change before one finally arrives.
There is however one feature (perhaps a bit subtle) that's meant to help people get to the right elevator before it arrives - if you use the directional lanterns, they light a few seconds before the car actually arrives when it's answering a hall call. Specifically, they light when the car has "committed" to stopping at that specific floor and is beginning to slow down for it.
You can also use destination-based dispatching, see page 27 of the manual. If you use this, people are directed to a specific car when the call is placed, and will not be reassigned to a different one. The algorithms for this aren't as optimized as for conventional hall calls yet (I need to work on that more sometime) but for most in-game traffic patterns it works acceptably.
I think I know what issue you probably ran into, and it's actually one I had seen before but I was waiting to have some more substantial changes ready before releasing again. I went ahead and released it now anyway, the game should offer it to you as an update within the next day or so.
If the node replacement tool is available on the server then you can most likely use this to replace the rest of the nodes with something you can dig. Otherwise, WorldEdit (you might have to contact staff on the server in question) should be able to get rid of it. If you can find out what caused it to disappear and/or a way to reproduce the issue, I'd appreciate hearing about it.
I'll have to see about adding some capability for it to detect and resolve this issue on its own in the future.
Hopefully these will answer your questions, in order:
You do need to place the controller and drive somewhere, yes, but there's no need to have them be in any particular spot relative to the elevator. On one server I frequently play on, one player commonly builds "machine room-less" installations where the hoist machine is at the top of the shaft and the controller and drive are located in a closet somewhere.
You do need to set up the floor table when setting up the controller, but the rest of the parameters can be left at defaults and it'll work. It'll just be a bit on the slow side (1m/s) and fire recall will possibly send it to the wrong floor if you use that feature.
Placing the controller and drive in a basement is fine. Only the hoist machine needs to be above the car.
I took a closer look today and what you wrote is reasonably close to what I was probably going to do anyway, so I just merged it with a few minor tweaks. Thanks!
Yeah, I should probably improve the crafting sometime. Admittedly it's been a low priority, as most people who use this mod are doing so in creative mode. In survival mode I tend to recommend shacknetisp's "Realtime Elevator" mod.
basic_materials isn't listed as a dependency in mod.conf since it's not needed for the mod to load, and if it is present there's no need for it to be loaded first. Admittedly I could probably stand to document its usage in crafting recipes better, but I still wish mod.conf allowed for the "recommends" field I suggested a while back.
The current crafting recipes are really intended for use in MTG and Dreambuilder - this is more or less what the mod is for in the first place, I have no interest in playing non-MTG-family games and very little in supporting them - but I may at some point split the recipes into three groups and auto-select which one based on installed game, something like this:
MTG: default only (for nodes that don't already require mesecons/digilines), no usage of xcompat or basic_materials
Dreambuilder (or other MTG-family game with basic_materials available): current recipes, uses basic_materials
Other: basic_materials + xcompat
This is pretty low on my priority list so I can't make any guarantees as to if or when it'll happen.
I do just want to mention, for anyone who reads the full review within the next few days and wonders where the metal cars and doors are at - they're available via Git now, but I'm giving them a few days to make sure I get all the bugs worked out (they seem pretty good so far though) before they get into a ContentDB release. It should be relatively soon now.
Enter the main egress landing number into the "Main Egress Landing" field and the alternate recall landing number into the "Alternate Recall Landing" field
Click "Save"
"Main Egress Landing" refers to the floor with the main exit from the building. This is the floor that will have a star on its car button and is also the floor that the elevator will return to during most forms of fire recall. Typically this is the lobby.
"Alternate Recall Landing" refers to the floor the elevator will return to if it receives a signal requesting alternate floor recall, for example if a mesecons input module is activated in response to smoke being detected on the main egress landing. In most cases this is the floor above the main egress landing, but some building designs warrant other choices - for example, the travelnet exchange near the spawn on VE-Creative has a second exit (a tunnel to another building) on level P2, so P2 was selected as the alternate recall landing.
Both of these expect a landing number, much like the call buttons and other fixtures. For example, if your floors are numbered "SB, B, L, 2, 3, 4, 5" and you want the car to recall to floor L during fire recall, the correct "Main Egress Landing" setting would be 3.
Height is the height of the floor (from its floor level to the floor level of the next floor), not the position. Try entering 10 as the height of floor 1.
The height numbers are the distance from the floor to the one below, which is always positive. For example, if you have one floor at a Y value of -400 and the next one up is at -390, you would enter 10 as the height of the lower floor. If you want the floor numbers to count in the other direction, you can rename the floors to whatever you want, but they're always entered in order from bottom to top.
I just tried it at a negative Y position (I'm assuming this is what you mean - the message says negative Z but then gives a position with negative Y) and it seems to be working fine. What's it doing/not doing for you?
On its own, this mod doesn't do much - you get a mediocre LCD that can display a bit of text, two sensors that hardly anyone seems to ever use, and some blue wires (the digilines themselves). But once you get some other mods that work with this, that's when the fun starts...
Mesecons Luacontrollers (and similar mods, like mooncontroller) are the use that's initially most obvious. Connect two or more of them with digilines, and now you can pass arbitrary data back and forth between them. Now you can use multiple Luacontrollers working together to get more I/O pins, have two machines that run independently but also communicate with each other, or even just simplify wiring.
But then there are the peripherals (digistuff, LED Marquee, digiterms, Nixie Tubes...) - add some of those and now you can wire up a Luacontroller to just about anything you want. Just run digilines over to where you want it and place a button, sensor, piston, text or graphical display, touchscreen, light, or whatever, and now your Luacontroller can control an entire machine, moving parts and all, with just one wire.
By now, I've built hundreds of electronic devices using digilines, some of which have upwards of 1000 lines of code in the Luacontroller and over 100 digilines devices connected. Even at this scale the wiring was still practical - try doing that with just mesecons.
I do have an elevator mod of my own that does some similar things (celevator), you're welcome to take some ideas for fixes from that if you want. I do think there's still a place for this Real Elevators mod to exist despite that - it's almost like a "light" version of it.
For the particular points you've mentioned, the way I've dealt with them, or how I suggest fixing them:
Crashing on shutdown: I assume what's going on is that it's trying to save an entity itself to mod storage or something. The mechanism I've found to work best is to use the static_save=false property on the entities, so that when they unload they just disappear. Then I can just save data about where they were supposed to be at, and spawn new ones when the game starts again. No need to try to find the old ones again, they're just gone.
Door animations: I've found this to work best/smoothest by setting velocity instead of position. If you have the velocity follow half of a sine wave, this tends to be rather visually appealing for doors, much more so than a constant speed.
Call queuing: Going in the order of closest calls is probably good enough. Selective collective (separate up and down hall buttons) would be a nice boost for realism, if you want that.
Falling through upon arrival: The easiest solution I've found for this is to just teleport the player to slightly above the floor right after the elevator stops. In the particular case of celevator there's a bit more logic to it than that (celevator has cars larger than one node and allows riding on top) and I also teleport the player twice, about half a second apart, just in case they still fall through the first time.
I think this mod manages a pretty good balance of realism vs. practicality for use in a survival environment. It's rather straightforward to set up (just place elevators where you want, connect them with shafts, and put a motor on top) and yet doesn't feel too overpowered.
For creative use it's a little more lacking - it still works fine, it's just less realistic than creative builds tend to usually go for.
Something I would like to see is smoother motion - the sudden start/stop can be rather disorientating, and the doors just switch between open and closed with no animation. It's something you get used to after a while, but sometimes when you're in an unfamiliar building, a ride on one of these can turn into just a few seconds of having no idea what's going on, then suddenly ending up on a different floor.
This is certainly an interesting attempt at an elevator mod - it tries much harder to be realistic than any of the others that were available at the time, and generally succeeds at that (the smooth motion is especially nice, and I haven't seen the animated hoist ropes in any other elevator mod yet).
Unfortunately there are a few issues that prevent it from being much use:
Shutting down the server with an elevator built results in a crash
Trying to ride up results in falling through upon arrival
Lots of debugging spam in the chat when anything happens
Queue system is a bit unrealistic - it serves calls in the order the buttons were pressed, instead of as it arrives at each floor
Despite all that, it's still a fun mod to play with in singleplayer sometimes.
I'm not personally maintaining it any more, but the mt-mods fork is being maintained, and I would suggest using that one instead unless you need the advanced touchscreen: https://github.com/mt-mods/digistuff
I did try contacting rubenwardy about having my listing replaced with one for theirs (with it being provided as an "update" for users of mine) somewhat recently and never received a response. I had previously declined an offer for this setup a few years ago, but circumstances have changed since then and it's now something I would like to see happen.
What do you mean? If you're talking about digilines channels (like for the traffic lights) then there's nothing to create, you just set the traffic lights to whatever digilines channel you want, connect them to some other device, and have that device send messages on that channel.
This is a quirk of unifieddyes that I haven't found a good way to work around - for some reason unknown to me, white is palette entry 240 and not 0. I could try making a custom palette, but unifieddyes is.... not pleasant to work with and I don't really want to do that again.
I do remember poking at it a while back and finding that it was actually in tenths of a second for some reason - that was ages ago though, so it may have been fixed by now for all I know.
I can't seem to replicate the NIC issue here - your code results in "test" being sent on "led3" just like it should.
Are you perhaps running this on an excessively slow connection that results in the timeout (I think 500ms) being hit?
This is a Lua script I've been using for this myself: https://gist.github.com/cheapie/e4edc2ea274750c235c984d972703803
Runs outside of the game, requires lua-imlib2, and takes one argument (the path to an image file). It'll then spew two things - the image in table format (as a digiscreen would need) and in the "packed" format for the "loadpacked" command of digistuff's GPU.
Do make sure you scale the image to whatever size you want ahead of time - it won't try to do that for you, and will process whatever resolution the input is whether that's what you want or not.
(continued from above)
Additionally, if an elevator is located such that there is a room or similar underneath the pit, such as an elevator that goes down to the lobby but then has an underground parking garage below it, the counterweight will often have its own set of safety gear and its own governor. This is to prevent the counterweight from crashing through the bottom of the pit and into the area below if the hoist ropes were to fail. Even though celevator doesn't (yet?) have counterweights, you can kind of simulate this by placing a second governor if you want... actually you can place as many governors per car as you want, and at one point I had something like 20 of them connected to the same car as an experiment. There also aren't any restrictions (in celevator) as to where you put them, meaning if you use one as a desk ornament or something, you can connect it to an elevator across town and it'll spin when that one moves.
In celevator, it's just for decoration. You can set a car number on it and it will spin when that car moves. It's relatively new, so it hasn't made it into a manual update just yet.
In real life, it's used to protect against overspeed. There's a separate rope/cable that runs in a loop between the governor at the top (for overhead traction installations like what celevator is meant for, it's usually just on the floor next to the machine) and an idler down at the bottom (in the pit). This rope is attached to the safety gear on the car, and in normal operation the governor moves freely, not doing much other than spinning the governor as the car moves.
However, if the car moves too fast (only downwards on older installations, either direction on many newer ones), a switch in the governor opens (electrical trip). This switch is in the safety circuit along with things like the door locks, stop buttons, etc., and causes an emergency stop. If a rope brake is installed, it will possibly apply too. If the car continues to accelerate, for example if the hoist ropes have all failed or if the brakes are not working for some reason, the governor locks up (mechanical trip) and prevents the governor rope from moving. This pulls on the safety gear on the car, causing it to apply. In its most basic form, this is just a metal wedge that gets pulled in between the car and the guide rails and jams it in place. Higher-speed elevators have more elaborate systems to prevent the deceleration from being so strong as to cause injury.
(continued below because of the character limit)
The "home floors" idea that I'd like to implement sometime is something that's occasionally used on these in real life, especially in places like office buildings and hotels. The idea is that in those kinds of buildings, everyone really just has one floor they ever go to (the one they work on, the one their hotel room is on, etc.), and there might be some need to prevent them from going to other floors. So what gets done is that things are configured such that everyone arriving at the elevators has to authenticate somehow (often a keycard), and in doing so their floor is also automatically selected.
For example, if you worked on the 37th floor of such a building, when you arrived at the elevators in the morning, the DBD kiosk would just say something like "please tap card on reader". It might also offer a few floor selections like a cafeteria and parking or something, but that's it. But then when you tap your keycard on the reader, it would not only unlock floor 37 for you, but automatically select it too. It might go something like "please tap card on reader" -> tap -> "please use elevator C to floor 37"
This is my most recent (major) mod, yes - and if you like it that much, reviews are always appreciated :D
I do have a few other mods that focus on technology from real life, ltc4000e probably being the other big one but that one is really showing its age by now. I have plenty of ideas I want to put into a successor to that one if I ever get around to that. I also did a fire alarm mod a few years ago, never uploaded it here as it's admittedly kind of low quality, but someone else did fork it recently and uploaded their fork. I haven't tried said fork, but it sounds like it's still pretty similar to mine.
The various special modes in celevator mostly follow the applicable codes in the US (where I'm from), mostly ASME A17.1. This means you can probably find explanations of them elsewhere online and most of the information will apply to here too. Just in case though, I typed up a short version of what they do here - had to link to a text file as otherwise I'd have to split this whole thing into three comments.
As far as an improved DBD kiosk goes - I'd like to make the layout editable and add support for things like restricting access to certain floors from it, or even having the ability to have "home floors" for certain players where it just automatically selects the appropriate floor for them.
(split into a second reply because of the character limit)
My interest in Luanti modding kind of comes and goes over time, right now it's a bit on the lower side so I haven't been doing all that much. When it comes back (most likely in a few months) I'd like to work on the following, in no particular order:
And some other feature ideas that would be nice but I may or may not do, as I'm not sure if they'd be worth the (rather high) effort:
If you use the DBD kiosk (the one where it says something like "Please use elevator A") then it will always send the one that was assigned. If you use the normal call buttons (the ones with up and down buttons) and connect them to a specific elevator by entering the controller ID, they will also always call that specific one.
However, if you use the normal call buttons (up/down buttons) and connect them to a dispatcher that itself is connected to multiple cars, it will try to pick whichever car can respond soonest. This may or may not be the closest one. If the situation changes (for example, the originally selected car goes out of service or has several more calls entered) it may change to a different car as appropriate. You can watch this happen on the dispatcher's display.
The reason there are directional lanterns and position indicators in that screenshot is for realism - where I live IRL, the following are required:
Oh, were you already using DBD? Never mind about the reassignment thing then, I thought you were using the standard call buttons (it only applies to those).
I might add lanterns with letters on them someday, but it's not very high on my priority list. Often I use the labels from display_modpack to label the cars.
Typically I arrange things something like in this screenshot when using DBD.
I'll experiment a bit more with the motor stuff sometime and see if I can reproduce that issue.
Can you elaborate on the "placed incorrectly" part? As far as I'm aware, as long as it was able to find the car (shows coordinates) it should work to move the car anywhere from where the car was placed up to just below the motor.
As far as an indicator of which car is coming - the main thing making that a bit problematic is that the dispatcher is able to reassign calls to other cars if needed, for example if a car becomes available that could answer the call much sooner or if the initially selected car goes out of service for whatever reason. It should be possible, provided you have mesecons installed, to drive an indicator lamp using some of the mesecons output modules (using the "up/down call exists at landing" options). However, it's possible, especially during heavy traffic, that you may see it light on multiple different cars as conditions change before one finally arrives.
There is however one feature (perhaps a bit subtle) that's meant to help people get to the right elevator before it arrives - if you use the directional lanterns, they light a few seconds before the car actually arrives when it's answering a hall call. Specifically, they light when the car has "committed" to stopping at that specific floor and is beginning to slow down for it.
You can also use destination-based dispatching, see page 27 of the manual. If you use this, people are directed to a specific car when the call is placed, and will not be reassigned to a different one. The algorithms for this aren't as optimized as for conventional hall calls yet (I need to work on that more sometime) but for most in-game traffic patterns it works acceptably.
I think I know what issue you probably ran into, and it's actually one I had seen before but I was waiting to have some more substantial changes ready before releasing again. I went ahead and released it now anyway, the game should offer it to you as an update within the next day or so.
If the node replacement tool is available on the server then you can most likely use this to replace the rest of the nodes with something you can dig. Otherwise, WorldEdit (you might have to contact staff on the server in question) should be able to get rid of it. If you can find out what caused it to disappear and/or a way to reproduce the issue, I'd appreciate hearing about it.
I'll have to see about adding some capability for it to detect and resolve this issue on its own in the future.
Hopefully these will answer your questions, in order:
You do need to place the controller and drive somewhere, yes, but there's no need to have them be in any particular spot relative to the elevator. On one server I frequently play on, one player commonly builds "machine room-less" installations where the hoist machine is at the top of the shaft and the controller and drive are located in a closet somewhere.
You do need to set up the floor table when setting up the controller, but the rest of the parameters can be left at defaults and it'll work. It'll just be a bit on the slow side (1m/s) and fire recall will possibly send it to the wrong floor if you use that feature.
Placing the controller and drive in a basement is fine. Only the hoist machine needs to be above the car.
Direct video link (same video as the listing) is here: https://www.youtube.com/watch?v=oKm2epe0AzU
I took a closer look today and what you wrote is reasonably close to what I was probably going to do anyway, so I just merged it with a few minor tweaks. Thanks!
Yeah, I should probably improve the crafting sometime. Admittedly it's been a low priority, as most people who use this mod are doing so in creative mode. In survival mode I tend to recommend shacknetisp's "Realtime Elevator" mod.
basic_materials isn't listed as a dependency in mod.conf since it's not needed for the mod to load, and if it is present there's no need for it to be loaded first. Admittedly I could probably stand to document its usage in crafting recipes better, but I still wish mod.conf allowed for the "recommends" field I suggested a while back.
The current crafting recipes are really intended for use in MTG and Dreambuilder - this is more or less what the mod is for in the first place, I have no interest in playing non-MTG-family games and very little in supporting them - but I may at some point split the recipes into three groups and auto-select which one based on installed game, something like this:
This is pretty low on my priority list so I can't make any guarantees as to if or when it'll happen.
I do just want to mention, for anyone who reads the full review within the next few days and wonders where the metal cars and doors are at - they're available via Git now, but I'm giving them a few days to make sure I get all the bugs worked out (they seem pretty good so far though) before they get into a ContentDB release. It should be relatively soon now.
This is detailed in the manual on page 35.
The short version:
"Main Egress Landing" refers to the floor with the main exit from the building. This is the floor that will have a star on its car button and is also the floor that the elevator will return to during most forms of fire recall. Typically this is the lobby.
"Alternate Recall Landing" refers to the floor the elevator will return to if it receives a signal requesting alternate floor recall, for example if a mesecons input module is activated in response to smoke being detected on the main egress landing. In most cases this is the floor above the main egress landing, but some building designs warrant other choices - for example, the travelnet exchange near the spawn on VE-Creative has a second exit (a tunnel to another building) on level P2, so P2 was selected as the alternate recall landing.
Both of these expect a landing number, much like the call buttons and other fixtures. For example, if your floors are numbered "SB, B, L, 2, 3, 4, 5" and you want the car to recall to floor L during fire recall, the correct "Main Egress Landing" setting would be 3.
Height is the height of the floor (from its floor level to the floor level of the next floor), not the position. Try entering 10 as the height of floor 1.
This usually means that the heights are set wrong in the floor table. Can you share a screenshot of how you have the floor table set up?
The height numbers are the distance from the floor to the one below, which is always positive. For example, if you have one floor at a Y value of -400 and the next one up is at -390, you would enter 10 as the height of the lower floor. If you want the floor numbers to count in the other direction, you can rename the floors to whatever you want, but they're always entered in order from bottom to top.
I just tried it at a negative Y position (I'm assuming this is what you mean - the message says negative Z but then gives a position with negative Y) and it seems to be working fine. What's it doing/not doing for you?
On its own, this mod doesn't do much - you get a mediocre LCD that can display a bit of text, two sensors that hardly anyone seems to ever use, and some blue wires (the digilines themselves). But once you get some other mods that work with this, that's when the fun starts...
Mesecons Luacontrollers (and similar mods, like mooncontroller) are the use that's initially most obvious. Connect two or more of them with digilines, and now you can pass arbitrary data back and forth between them. Now you can use multiple Luacontrollers working together to get more I/O pins, have two machines that run independently but also communicate with each other, or even just simplify wiring.
But then there are the peripherals (digistuff, LED Marquee, digiterms, Nixie Tubes...) - add some of those and now you can wire up a Luacontroller to just about anything you want. Just run digilines over to where you want it and place a button, sensor, piston, text or graphical display, touchscreen, light, or whatever, and now your Luacontroller can control an entire machine, moving parts and all, with just one wire.
By now, I've built hundreds of electronic devices using digilines, some of which have upwards of 1000 lines of code in the Luacontroller and over 100 digilines devices connected. Even at this scale the wiring was still practical - try doing that with just mesecons.
I do have an elevator mod of my own that does some similar things (celevator), you're welcome to take some ideas for fixes from that if you want. I do think there's still a place for this Real Elevators mod to exist despite that - it's almost like a "light" version of it.
For the particular points you've mentioned, the way I've dealt with them, or how I suggest fixing them:
I think this mod manages a pretty good balance of realism vs. practicality for use in a survival environment. It's rather straightforward to set up (just place elevators where you want, connect them with shafts, and put a motor on top) and yet doesn't feel too overpowered.
For creative use it's a little more lacking - it still works fine, it's just less realistic than creative builds tend to usually go for.
Something I would like to see is smoother motion - the sudden start/stop can be rather disorientating, and the doors just switch between open and closed with no animation. It's something you get used to after a while, but sometimes when you're in an unfamiliar building, a ride on one of these can turn into just a few seconds of having no idea what's going on, then suddenly ending up on a different floor.
This is certainly an interesting attempt at an elevator mod - it tries much harder to be realistic than any of the others that were available at the time, and generally succeeds at that (the smooth motion is especially nice, and I haven't seen the animated hoist ropes in any other elevator mod yet).
Unfortunately there are a few issues that prevent it from being much use:
Despite all that, it's still a fun mod to play with in singleplayer sometimes.
I'm not personally maintaining it any more, but the mt-mods fork is being maintained, and I would suggest using that one instead unless you need the advanced touchscreen: https://github.com/mt-mods/digistuff
I did try contacting rubenwardy about having my listing replaced with one for theirs (with it being provided as an "update" for users of mine) somewhat recently and never received a response. I had previously declined an offer for this setup a few years ago, but circumstances have changed since then and it's now something I would like to see happen.
What do you mean? If you're talking about digilines channels (like for the traffic lights) then there's nothing to create, you just set the traffic lights to whatever digilines channel you want, connect them to some other device, and have that device send messages on that channel.
This is a quirk of unifieddyes that I haven't found a good way to work around - for some reason unknown to me, white is palette entry 240 and not 0. I could try making a custom palette, but unifieddyes is.... not pleasant to work with and I don't really want to do that again.
I do remember poking at it a while back and finding that it was actually in tenths of a second for some reason - that was ages ago though, so it may have been fixed by now for all I know.
I can't seem to replicate the NIC issue here - your code results in "test" being sent on "led3" just like it should.
Are you perhaps running this on an excessively slow connection that results in the timeout (I think 500ms) being hit?
This is a Lua script I've been using for this myself: https://gist.github.com/cheapie/e4edc2ea274750c235c984d972703803
Runs outside of the game, requires lua-imlib2, and takes one argument (the path to an image file). It'll then spew two things - the image in table format (as a digiscreen would need) and in the "packed" format for the "loadpacked" command of digistuff's GPU.
Do make sure you scale the image to whatever size you want ahead of time - it won't try to do that for you, and will process whatever resolution the input is whether that's what you want or not.