Computer Controlled Door Using Time / Money System

Hello everyone.

I want to make a couple programs (on a couple different computers) that do the following:

Computer/Program 1:

• Find the in-game date & time.
• Print said date & time onto a piece of paper.
• (Player takes and holds onto paper)
• Entry door opens

Computer/Program 2:

• (Player inserts paper into some sort of reader (whether in ComputerCraft or an addon))
• Computer reads previously printed date/time and calculates a price based on how much time has passed since the paper was printed
• (player inserts certain items as 'currency')
• Computer verifies correct currency is inserted
• exit door opens

If all that confuses you, think of it this way:

You enter your local airport's parking garage and have to pull a ticket from a machine to get in and park.
When you go to exit, you have to put that same ticket into another machine which reads it and displays a price which you have to pay to get out.

That is basically what I am trying to have happen with this idea. Anyone know how I would do this?

This is where things could get surprisingly complicated.

That I know of, computers can't natively call the in-game time, but that's okay because you don't really need it. You only need the time elapsed as this network would have to understand it. If you really like project sprawl, you could create a computer in a chunkloaded chunk and leash it to an ender modem to provide a sort of global/multiversal time standard, but that wanders into the realm of needless complexity (or, as us horologists call them, "complications".)

One way to do this without additional mods would be to replace your paper tickets with computercraft's floppy disks. A better way to do this would be to use Immibis' RFID cards from his peripherals add-on to CC, since the RFID cards are single-write only. Unfortunately, they also write slow, but there's ways around that.

I picture a flow something like this:

1. When the chunk you're considering installing this on loads, three computers individually load the entry client, exit client, and time server applications. These computers are networked - doesn't matter exactly how for this stage in planning. Here you can get really overcomplicated by adding all sorts of verification steps to make sure all the computers are legit, or you can skip that to get basic functionality.
2. When a person Alice enters your paygated area (IE, when they arrive at the parking garage), they press a button or are otherwise detected by the Enterance Client. EnClient gets the current system time from the time server and encodes this to an RFID card however the hell you like. This takes about 30 seconds. A disk would be instant, but again, you could rewrite the disk whenever you want with access to a naked interface and a basic understanding of how CC works.
3. Alice does whatever she's doing and decides to leave. She arrives wherever the exit interface is. The RFID reader automagically reads the card from the inventory, getting the time code of entry.
4. It then requests the current time code from the server, and gets the difference.
5. However your charge/pricing system works goes here.
6. Computer waits for payment <- this might require some kind of extra peripheral unless chests count as peripherals and you can check for specific block/itemids. I'm not as up on this and someone else might be better equipped to address it.
7. Exit Client, upon receiving payment, lets you out.

Current in-game day and time are available via the os API, as os.day() and os.time().

Lyqyd, on 31 March 2016 - 03:56 AM said:

Current in-game day and time are available via the os API, as os.day() and os.time().

Well, now I look stupid. I wonder what I was thinking of. World time maybe. I should see if there's a UTC api…

As far as the currency system goes, best bet is probably to use a set-up with two chests. One placed where the user can get at it, and one the owner can get at, with a turtle between them. The turtle, as part of the payments process, will automatically empty out the chest, report to the exit point computer the item types and counts removed, and then place those items into the owner chest for you to retrieve later.

It is left as an exercise to the op to code these functions, but a principle component would be, I think, the function turtle.getItemDetail()…

This seems to be going where I need it to, however, in the interest of full disclosure, I am not very good with coding. When supplied with an API and simple instructions (such as touchpoint), I can handle things, but when it's a concept that I have never worked with before and have no basis on even where to start, I am terrible :/

My advice in that regard is almost the opposite of what I would think common sense would be - make the problem smaller. What you really need is two programs - one for the exit system and one for the entry system. Now you just need the flows. I'm giving flows assuming you use os.clock() instead of day() and time() for simplicty's sake. The flaw here is that both computers have to come up at the same time and stay loaded the whole time the player is in the area. This is easy with chunk loaders.

The program flow for the entry system should, on boot:
1. Wrap the Disk Drive/RFID/Other Media Writer it Needs
2. Display a message indicating it is ready (optional)
3. Wait for an arrival prompt (redstone signal, keystroke, etc)
4. Get the current timestamp
5. Write that timestamp to its media.
6. Loop back to waiting for an arrival prompt.

The program for the exit should:
1. Assign various configuration variables (optional but recommended. Rather than hard-coding prices somewhere halfway down the code, having an hourly/minutely/per-second rate up near the top is convenient to you).
2. Wrap the Drive/RFID Reader/Whatever and Turtle as peripherals.
3. Wait to read media on the reader.
4. Take the time stamp from the reader and validate it is a time stamp. (optional but recommended, especially if you are using whatever kind of media for other reasons as well)
5. Determine the difference between the present time and the time-on-card.
6. Convert that time difference to a number of days/hours/minutes that you calculated your rate for. (os.clock() returns uptime in seconds. The game-time functions return even less conveniently.)
7. Calculate the rate.
8. Prompt the user with the rate and to pay in exact change, then press any key to continue.
9. Get the turtle to take items out the payment basket.
10. Find out what those items are by calling the turtle api as a peripheral.
11. Check that it is the right kind of item.
12. Check that it is the current kind of item.
13. If the wrong item or amount, put it back in the basket.
14. Prompt the user to double-check the amount. Continue 13-14 until the right amount of the right item is achieved.
15. Move the item from the turtle to the owner's chest.
16. Wait for the next ticket input.

These are simplified of course, perhaps overly so, but once you have a flow you can write pseudocode, and then it's just a matter of finding the right functions. Or hard-coding them yourself. Bear in mind though, any one of these steps could be a single line of code. Or they could be thirty. I don't know, I haven't written the program to do this yet. Having said that, building programs in this way offers the possibility that you will remember how to solve one trivial problem x and the next time you find a similar problem y, you might remember your original solution and work from that.

Some users on the forum undoubtedly consider such processes as these two program flows trivial, but they're right around the skill level I'm at, which isn't that far off the ground.

For the record, if you do use the global times from os.day and os.time, you need to do a little more work converting them to formats you can compare easily and multiply your rates by, but, you get rid of the syncronization issues and no longer need to keep the computers loaded all the time. To me, that'd be worthwhile, but if you build bases that don't sprawl much, that might be more work than it's worth. Food for thought.

Good luck! Post any code snippets you come up with. I'd be happy to help, and could probably use the experience.