- ComputerCraft | Programmable Computers for Minecraft
- → Communeguy's Content
Communeguy's Content
There have been 23 items by Communeguy (Search limited from 30-March 23)
#251062 [Help]tables as args/saving tables
Posted by Communeguy on 27 April 2016 - 02:59 PM in Ask a Pro
#251060 [Help]tables as args/saving tables
Posted by Communeguy on 27 April 2016 - 02:44 PM in Ask a Pro
#251057 [Help]tables as args/saving tables
Posted by Communeguy on 27 April 2016 - 01:38 PM in Ask a Pro
I've gone as far as defining a table full of the other tables, and I can make the code walk through those tables and deserialize them 1 by 1, but I can't figure out how to also use those tables NAMES for the filename argument. Am I attacking the problem wrong?
#249360 Computercraft Dailer System for Draconic Evolution Portals?
Posted by Communeguy on 03 April 2016 - 02:52 AM in Ask a Pro
More relevantly, though, the code is still behaving as though it is talking to mystcraft books. You've changed some display features to the string Charm of Dislocation but you've done nothing to address actual functions such as "book.mystbook.destination"
Either way, beyond these vague ideas of where the fault might be, this kind of program is outside my usual area of expertise (checking hidden values on blocks to control other functions as in my ReactorCraft controller) and you'd be better served with someone else's help.
#249251 [MC 1.7.10] [CC 1.65] Immibis's Peripherals
Posted by Communeguy on 31 March 2016 - 10:47 PM in Peripherals and Turtle Upgrades
#249243 [MC 1.7.10] [CC 1.65] Immibis's Peripherals
Posted by Communeguy on 31 March 2016 - 09:50 PM in Peripherals and Turtle Upgrades
#249218 Computer Controlled Door Using Time / Money System
Posted by Communeguy on 31 March 2016 - 04:11 AM in Ask a Pro
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.
#249216 Computer Controlled Door Using Time / Money System
Posted by Communeguy on 31 March 2016 - 03:15 AM in Ask a Pro
Lyqyd, on 31 March 2016 - 02:56 AM, said:
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()...
#249213 City Generating Script
Posted by Communeguy on 31 March 2016 - 02:28 AM in Command Programs
#249212 Computer Controlled Door Using Time / Money System
Posted by Communeguy on 31 March 2016 - 02:09 AM in Ask a Pro
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:
- 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.
- 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.
- 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.
- It then requests the current time code from the server, and gets the difference.
- However your charge/pricing system works goes here.
- 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.
- Exit Client, upon receiving payment, lets you out.
#249210 Stab at a Keysystem
Posted by Communeguy on 31 March 2016 - 01:42 AM in Ask a Pro
Bomb Bloke, on 30 March 2016 - 06:01 AM, said:
This is glossing over a few details (there are some checks you can put in to attempt to prevent this, and these can in turn be coded around by your attacker, and so on), but the winner boils down to whether it's you or your attacker who has the most free time to kill.
Assuming you prevent such access, a rolling code is really all you need. So long as no one gets their hands on the key used to generate the code sequence, you're all good. Your server knows the codes are coming from the client because only the client has the correct key.
If you're going to be one of the OPs on this server, then you have the option of using Command Computers. These can only be accessed by OPs in creative mode - you can hook up external buttons or a monitor or something to allow other users to interact with the scripts you run on them, but they otherwise can't play with the things.
Without using those, you still have the option of warded blocks and so on from other mods.
Thanks Bomb Bloke - I think you're right, using certs would be a waste of time, both in terms of complexity and reproducability.
Before I go even more prematurely Grey coding this, I just want to make sure the following process makes sense. Note that I only describe the "open the door" process here. Note that there's no step to prevent from sending the RFID data to the wrong server - someone's not going to use my client code to copy the extant RFIDs. They're going to build some elegant five-line copy thing to just keep copying to RFID cards and then try the products until they work. This is the problem with single-factor authentication. I'm also not sure this really counts as a "rolling code", since I can't figure out how to make one work for multiple "keys" in a network, but lets try.
- A given client detects the RFID signal and records the RFID data to memory. This gets zero'd eventually.
- The client takes the [bleh] hash of its own ComputerID variable.
- The client uses hashComputerID as the symmetric encryption key for a message to the target server, containing it's programmed Door ID variable.
- The server knows the hashes for all valid (pre-authorized) doors. It tries them all in sequence and verifies that the transmitted doorID and the expected DoorID are the same. DoorID is a configuration variable and NOT the computer ID.
- REGARDLESS OF SUCCESS: The server sends a go-ahead code. It then disregards all further communications for 30 seconds if it failed to authenticate. This is done so that the client itself is not notified if it failed to transmit. This code is single-use, which is important.
- The client, upon receipt of the message from the server, hashes that to a standard bitsize and again uses it as an encryption key.
- The client hashes the RFID data and transmits that, encrypted using the above key.
- The server compares the recieved-and-decrypted hashRFIDData to a table of known hashes and authorization levels, possibly indexed by user (for logging purposes? Later feature?)
- The server makes sure that the clearance level is sufficient for the door it believes it is talking to.
- If successful, the computer sends a pass message TRUE, using the same sequential key. If not, it sends false.
- On reciept of "true", door opens, on the receipt of false, it doesn't.
- Client clears its RFID Data variable, possibly by writing a random value to it.
- GOTO1.
ETA: In fact, this doesn't even roll properly from the client side, making the server vulnerable to replay attacks. One possible solution would be to do something like use hash(compID * return of os.time()) with adequate imprecision.
#249153 Stab at a Keysystem
Posted by Communeguy on 30 March 2016 - 03:49 AM in Ask a Pro
For obvious reasons, it's important to verify both that the client (that is, the door) and the server are who they say they are. You would think this would be as easy as setting a couple name variables and asking for them upon an exchange, but that's easily spoofed. Do I need to do something similar to RSA signature creation where I *insert overcomplicated explanation of how signatures work here*, and the server says "Yup, that's a valid client" and the client says "Yep, that's the server I want"? Is that spoofed easily? Is there a more elegant solution? I am thinking of something similar to a certificate, but I can't think of how to do it without some secret or another being stored on the client side.
#249148 Stab at a Keysystem
Posted by Communeguy on 30 March 2016 - 01:59 AM in Ask a Pro
Dog, on 30 March 2016 - 01:32 AM, said:
KingofGamesYami, on 30 March 2016 - 01:01 AM, said:
FWIW, I did find 2 RFID programs for Immibis' Peripherals here and here for reference.
Thanks for these!
#249145 Stab at a Keysystem
Posted by Communeguy on 30 March 2016 - 01:32 AM in Ask a Pro
I mean, really, the only points of access into the network (apart from the admin terminal) are all buried, and the admin terminal itself is behind locks. If we're at the part where people are breaking blocks to get into the network, they could just knock down walls in the facility and take stuff that way.
Thanks though. I'll factor this sort of thing into my thinking.
#249142 Stab at a Keysystem
Posted by Communeguy on 30 March 2016 - 12:15 AM in Ask a Pro
Originally, I intended to simply have an RFID reader at the complex gate to let you in or out. This is kind of a second layer of security already, since reaching the gate means having the right Rail Ticket, but that's neither here nor there, and ultimately you could walk. It occurred to me later, while planning, that different parts of the facility should be more or less accessable.
Eventually, I boiled this down to a credential system with three levels 1-3, with 1 being an admin with (basically) root access, 2 being complete access, and 3 being access to only reactor control (I know that sounds weird, but it's less dangerous to let people turn the damn thing on or off than it is to let them at any of the machinery or fuel directly).
What I envision is this:
-1. RFID-sensing Door Lock
--Reads Nearby RFID
--Sends the hash of the RFID code to the Server
--Waits to be told to open the door or not
--Loops
-2. Admin Terminal
--Authenticates an Admin (somehow - against the server?)
--Sends messages to the server to add/remove users or update their clearances
--Can request the (encrypted and replacement) RFID code for a given user and print it to an RFID Card
-3. The ServerTM
--Holds UserID, RFID Hashes, and Level
--Also holds DoorID and Level
--Receives hash of inputted RFID and Door ID
--Checks if RFID hash has Level <= the Door ID's level
--Sends the Open Signal. Or Doesn't.
--Updates the DB when told to by the admin terminal
--Regenerates a new RFID code for a given user on request and sends it to the admin terminal to write, probably encrypted
Vulnerabilities Are:
-If network is tapped and sniffed you could get the hash of RFIDs, but you shouldn't be able to reverse that.
-You MIGHT be able to get the admin credential, unless that's hashed too.
-If you pulsed open signals on a network tap you could theoretically force a door to open by standing near it with ANY RFID card.
-There's absolutely nothing to suggest that an RFID card can't be copied, but I can't think of a good second factor for this system
Apparent Strengths:
--Passwords are not Sent in the Plain
--Passwords are not stored in the plain
--Doesn't need users to remember anything apart from bringing their keys with them
--Keys can be invalidated if lost or privelages are abused.
--Server means that one operation removes, adds, or updates a user for the whole facility, instead of walking around to update individual doors.
Anyone see any vulnerabilities or fixes? I intend to build the code myself, but I've never had to secure a system at all, and I rarely network. I don't intend do do my own crypto - various hash codes in LUA already exist. If the code works, I will probably reuse it in multiple complexes/buildings throughout the city.
Thanks for input, Sorry to bore;
--CG
#229439 Unexpected behaviour of Bundled Cable
Posted by Communeguy on 09 August 2015 - 12:15 AM in Ask a Pro
#229434 Unexpected Symbol
Posted by Communeguy on 08 August 2015 - 11:17 PM in Ask a Pro
with bios error codes the second number is the line in the code throwing the error. From there you can see what that line would be dependant on to diagnose the error, if you can't find the error right in that code.
#229421 Im doing something wrong and I dont know what
Posted by Communeguy on 08 August 2015 - 08:41 PM in Ask a Pro
My interpretation anyway. Your mileage may vary, because I don't mess with turtles much.
Maybe someone can tell me I'm wrong, but that's what the compiler in my head is trying to do with this.
ETA": If you post the full code to pastebin I can try plugging it into a turtle and see if I can find the bad line. In spite of how often I have to come for help on this board, I can at least usually find the broken thing, even if I can't actually fix it.
ETA2: Yeah, tonumber() is probably the ticket. So derp. I don't usually deal with waiting for user input much, either.
#229416 Unexpected behaviour of Bundled Cable
Posted by Communeguy on 08 August 2015 - 06:35 PM in Ask a Pro
I am now down to what I believe to be the final bug - after squashing a few typos and bad calls, I've gotten as far as identifying the code responsible - my locally-defined park() function:
local function park() -- where's the train going? if sig1() == true then p1 = incoming local bypass = false elseif sig2() == true then p2 = incoming local bypass = false elseif sig3() == true then p3 = incoming local bypass = false elseif sig4() == true then p4 = incoming local bypass = false else local bypass = true end
"incoming" sets correctly - I have it print immediately for debugging.
However, after park executes, when the program loops back around to the print block (line 125 onward), the variable for wherever the train was sent (determined by park()) has become nil.
Anyone know why I borked something as simple as an if/else tree?
#229343 Unexpected behaviour of Bundled Cable
Posted by Communeguy on 08 August 2015 - 03:50 AM in Ask a Pro
#229334 Unexpected behaviour of Bundled Cable
Posted by Communeguy on 08 August 2015 - 02:18 AM in Ask a Pro
Code from pastebin here.
The problematic areas are the local functions checkDepartures() and switch() which don't seem to operate as intended. I think there's a commonality there, probably in the functions they're dependant on.
checkDepartures SHOULD change the state of any empty platforms the program is watching to "Vacant" if I coded it right, but clearly I didn't, as when the variables it alters later print, they print as the default state ("Unknown").
Likewise, switch() should turn a number of redstone bundled wire outputs on, but likewise doesn't.
They both have a dependancy in any of 4 "sig functions", which are thus defined:
local function segExample() rs.testBundledInput(rSide, relevant colour) end
I feel as though I must be missing some fundamental piece of information that everybody else knows but I've genuinely hit wits end on this.
#229312 Unexpected behaviour of Bundled Cable
Posted by Communeguy on 07 August 2015 - 09:12 PM in Ask a Pro
Now to tackle the rest of the functionality problems. A full rewrite seems to be in order
#229263 Unexpected behaviour of Bundled Cable
Posted by Communeguy on 07 August 2015 - 02:54 PM in Ask a Pro
I am having a peculiar problem where one of the cables (yellow on the left side) energizes unexpectedly when the program initializes. This is in fact the opposite of what should be happening (everything on the left should be shut off at the start), so I'm wondering how in the hell I went wrong.
The bundles on the left side and the right side are the not the same colour of bundle from Project:Red, though I do "re use" colours on the left side and the right side. Every other call to the various wires works as expected, except this one. Unfortunately this one happens to be a critical function.
ETA: Minecraft 1.7.10, ComputerCraft 1.65, ProjectRed 4.5.15.75
- ComputerCraft | Programmable Computers for Minecraft
- → Communeguy's Content