137 replies to this topic

[Dlcruz129]

OminousPenguin, on 23 March 2013 - 04:12 PM, said:

People have this notion that necroing an old thread is inherently bad. That is rubbish.

Except for the fact that its not allowed on these forums.

[SyberSmoke]

Dlcruz129, on 29 May 2013 - 08:29 PM, said:

OminousPenguin, on 23 March 2013 - 04:12 PM, said:

People have this notion that necroing an old thread is inherently bad. That is rubbish.

Except for the fact that its not allowed on these forums.

Since the developer and OP of the thread has been active in the thread since the threads resurrection. In fact it's resurrection has caused the developer to pick it back up. So...yeah...get over it.

OminousPenguin, on 29 May 2013 - 06:59 PM, said:

I keep refactoring it trying to make it smaller and more efficient. I should probably just finish it and leave the optimisation until afterwards.

I'll let you know as soon at there's something to test.

It would be a good idea to release something for commentary and testing. :-)

[Leo Verto]

Dlcruz129, on 29 May 2013 - 08:29 PM, said:

OminousPenguin, on 23 March 2013 - 04:12 PM, said:

People have this notion that necroing an old thread is inherently bad. That is rubbish.

Except for the fact that its not allowed on these forums.

Necroing is only bad when someone picks up a totally dead discussion thread, Penguin is totally right.

[Cranium]

I looked over this topic. There is no necro. Carry on.

[OminousPenguin]

Earlier today I hoped to have the program ready for beta testing by this evening but it's not quite there yet. Aiming for tomorrow!

All that remains to be done before I release the beta is controlling the actual elevator, the pastebin thing, and I need to add a section to the setup wizard for choosing the position and colours of the bundled red stone wire.

This initial release is limited by the range of the wireless modem. - Any floors outside of floor X's range will not find out about floor X.
In a subsequent update, floors in-between will pass on details of X so all floors will find out about all other floors.

Also there is no facility for having multiple different elevators within range of each other. You'll be able to work around this by manually specifying a different channel number in the file.

Edit: ok... tomorrow! more needed doing than I thought.

[SyberSmoke]

You may get me interested in playing again. :-)

[OminousPenguin]

Ok. Beta release of version 2 is here!

See original post for details.

Let me know how you get on!

If you want me to come on your server and help set it up, PM me the address and what time you'll be online (including time zone! I'm in GMT)

[OminousPenguin]

Update 2.0b -> 2.0.1b

The four variables bundleSide , elevatorWire, detetctorWire and boardingWire now work.
In 2.0b the colours were still hardcoded where they were actually used. Oops.

Setup program remains unchanged so you can just run the setup program again, or use pastebin get iJWyUQVr elevator-main.lua (You will need to delete your old elevator-main.lua first)

[basdxz]

Would this work with RedNet wire from MFR? And could it be made to run from one comp with touch screen monitors with CC rednet cables?

[SyberSmoke]

basdxz, on 07 June 2013 - 07:01 PM, said:

Would this work with RedNet wire from MFR? And could it be made to run from one comp with touch screen monitors with CC rednet cables?

It working with rednet wire would depend on ComputerCraft supporting that specific mod. You would have to check the API's for that. As for the touch screens and such...patience. He has just spent a good amount of time reworking his original code. He is interested in added features, but for now it looks fairly bare bones.

[basdxz]

SyberSmoke, on 07 June 2013 - 08:49 PM, said:

basdxz, on 07 June 2013 - 07:01 PM, said:

Would this work with RedNet wire from MFR? And could it be made to run from one comp with touch screen monitors with CC rednet cables?

It working with rednet wire would depend on ComputerCraft supporting that specific mod. You would have to check the API's for that. As for the touch screens and such...patience. He has just spent a good amount of time reworking his original code. He is interested in added features, but for now it looks fairly bare bones.

The current CC is MFR Rednet cable compatible while redpower is still 1.4.7 and not 1.5.2. Could this be made to work with MFR rednet cables?

[OminousPenguin]

basdxz, on 07 June 2013 - 07:01 PM, said:

Would this work with RedNet wire from MFR?

Yes, as of CC 1.53 the bundledCable API works with MFR's cables. I have just tested this and it works as expected:

basdxz, on 07 June 2013 - 07:01 PM, said:

And could it be made to run from one comp with touch screen monitors with CC rednet cables?

Touch screens are definitely on the todo list.

Running it from one computer would essentially be a completely different program... Monitors must be adjacent to a computer so you couldn't have one computer with a monitor on each floor. You'd have to travel back to that one computer to choose your destination.
Why did you want it to run from one computer? What sort of use-case are you imagining?

[hpnisse]

Quote

Running it from one computer would essentially be a completely different program... Monitors must be adjacent to a computer so you couldn't have one computer with a monitor on each floor. You'd have to travel back to that one computer to choose your destination.
Why did you want it to run from one computer? What sort of use-case are you imagining?

You don´t need to have the monitors adjacent to a computer anymore, in the 1.5 update they added peripheralCable (aka. "Networking Cables" with "Wired Modems".
So you can have the monitor or in this case monitors connected by wire. Multiple monitors (or other peripherals) can be on one network cable and it will only take one side on the computer!

[OminousPenguin]

hpnisse, on 08 June 2013 - 11:51 AM, said:

You don´t need to have the monitors adjacent to a computer anymore, in the 1.5 update they added peripheralCable (aka. "Networking Cables" with "Wired Modems".
So you can have the monitor or in this case monitors connected by wire. Multiple monitors (or other peripherals) can be on one network cable and it will only take one side on the computer!

Ok. I'll do some tests.
What sort of setup do you envisage? Why do you want the floors connected by cables? It looks like that would be more expensive and also require a lot more user interaction to set up - they'd need to specify which monitor was on which floor, unless all the monitors have identical display which doesn't seem very efficient.

Maybe I'm missing something but I don't see how this would be a good idea.

[basdxz]

OminousPenguin, on 08 June 2013 - 03:38 PM, said:

hpnisse, on 08 June 2013 - 11:51 AM, said:

You don´t need to have the monitors adjacent to a computer anymore, in the 1.5 update they added peripheralCable (aka. "Networking Cables" with "Wired Modems".
So you can have the monitor or in this case monitors connected by wire. Multiple monitors (or other peripherals) can be on one network cable and it will only take one side on the computer!

Ok. I'll do some tests.
What sort of setup do you envisage?

I would want a monitor on every floor acting like a computer does here but pressing one button is silmpler and faster than a few. Also should work with pick-up rails >: D

[OminousPenguin]

basdxz, on 08 June 2013 - 03:54 PM, said:

I would want a monitor on every floor acting like a computer does here but pressing one button is silmpler and faster than a few. Also should work with pick-up rails >: D

As has already been said, touch monitors are planned, but why do you want one computer, and a load of cable instead of simply a computer on each floor with it's own monitor?

Regarding pick-up rails, you can simply place one between the boarding rail and the detector. That's nothing to do with the program - You can have whatever rail configuration you like.

[OminousPenguin]

Update 2.0.1b -> 2.0.2b

• Fixed bug with GPS options.

Setup program changed so to update use pastebin get VYwxa3su setup then run setup. (You will need to delete your old files first)
No need to update if you don't use any of the GPS options.

[SyberSmoke]

I would like to suggest a key feature. The ability to call an elevator from another location. May be it could be just at the top of the list as "Call Elevator" That way some one can use it with out having to climb to it. :-)

Actually I was wondering...what is the reason for the detector? I ask because each floor should only have two states: Has Cart, Does not have cart. If some one went to a floor, that floor should be "Has Cart". While all other floors should be "Does not have cart". So what is there to detect?

This would also make things easier for the user because the computer that has the cart would be able to send that cart to another floor (Full Menu). While all the other floors would only present one option, Call Elevator.

Now this would present an issue if the elevator cart gets broken, the person would need to track down what floor and replace the cart. But in this case there could also be something of a debug where the player could place a cart on any floor and use a command...say "find lost cart" and the system will send it to the lowest floor and register the cart in that position.

Any way as you can see I FINALLY got back in the mood to monkey with my tower...and I am enjoying the elevator even though I can not call the cart to me. I am glad that the elevator rail is also a ladder.

[OminousPenguin]

SyberSmoke, on 17 June 2013 - 05:55 PM, said:

I would like to suggest a key feature. The ability to call an elevator from another location. May be it could be just at the top of the list as "Call Elevator" That way some one can use it with out having to climb to it. :-)

I'll add a 'Call Elevator' button to the next update. I always just carry a cart around with me and take it off the track at my destination. That way you avoid other players colliding with unmanned carts.

SyberSmoke, on 17 June 2013 - 05:55 PM, said:

Actually I was wondering...what is the reason for the detector? I ask because each floor should only have two states: Has Cart, Does not have cart. If some one went to a floor, that floor should be "Has Cart". While all other floors should be "Does not have cart". So what is there to detect?

This would also make things easier for the user because the computer that has the cart would be able to send that cart to another floor (Full Menu). While all the other floors would only present one option, Call Elevator.

Now this would present an issue if the elevator cart gets broken, the person would need to track down what floor and replace the cart. But in this case there could also be something of a debug where the player could place a cart on any floor and use a command...say "find lost cart" and the system will send it to the lowest floor and register the cart in that position.

Programmers don't like to assume stuff. The detector is so it knows when to stop powering the elevator and free up the system. Just powering the elevator for a certain amount of time is clumsy. If you're going up 10 meters it'll take a few seconds. If you're going up 100 meters it'll take longer.
I would work out the speed and do it exactly, but there is no way to know how far the cart has to go to actually get to the elevator track. (Unless it asks the user, but I don't want to increase the setup complexity)

Unfortunately I have not found a way to have a boarding rail on top of a detector so a computer can not know if there is a cart present. We could have a detector on the side of the track, but that would be ugly.

[SyberSmoke]

Well right now I do not know what happened. But I think the system lost track of the elevator. I try to send it some where and well it does not go and the power gets locked on. So a "Find Cart" command may also be a good idea. Just pulses the passenger rail across the system and send to to bottom floor.