Jump to content


Communeguy's Content

There have been 23 items by Communeguy (Search limited from 30-March 23)


By content type

See this member's

Sort by                Order  

#251062 [Help]tables as args/saving tables

Posted by Communeguy on 27 April 2016 - 02:59 PM in Ask a Pro

Oh, that's quite elegant. Thank you.



#251060 [Help]tables as args/saving tables

Posted by Communeguy on 27 April 2016 - 02:44 PM in Ask a Pro

Alright. This function might not be as easy to generalize as I thought. I'll just go the long way around and save each file manually.



#251057 [Help]tables as args/saving tables

Posted by Communeguy on 27 April 2016 - 01:38 PM in Ask a Pro

Hi there. I'm trying to create a function that would save all the tables argued to it (and do some other silly extravagances left unsaid for the purposes of this exercise). What I am envisioning is a function you would argue a table full of table-names to. It would then string each of those tables and save them to separate files. I intend to use this function frequently through the program I'm defining it for to save the program's active database to files for some stability during operation - basically any time the tables are changed.

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

My first thought - and granted I don't use Draconic Evolution - would be that the NBT structures for the books and the charms are dissimilar. I mean, a more precise explanation of how your modified code fails would be helpful.

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

Fair point... Turns out it does, at least for me, if anyone was curious.



#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

Just curious - does anyone know if this works with CC 1.74? I know it was written for 1.65, but I wonder how much that could really be broken by. Obviously this isn't SUPPORTED, but still...



#249218 Computer Controlled Door Using Time / Money System

Posted by Communeguy on 31 March 2016 - 04:11 AM in Ask a Pro

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.



#249216 Computer Controlled Door Using Time / Money System

Posted by Communeguy on 31 March 2016 - 03:15 AM in Ask a Pro

View PostLyqyd, on 31 March 2016 - 02: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()...



#249213 City Generating Script

Posted by Communeguy on 31 March 2016 - 02:28 AM in Command Programs

I like the idea of this very much. I was originally planning on putting in the "filler" buildings of my city using a buildcraft architect or similar. Now, I might do this, just to save the tedium of moving it around for each building manually and self-randomizing the blueprints.



#249212 Computer Controlled Door Using Time / Money System

Posted by Communeguy on 31 March 2016 - 02:09 AM in Ask a Pro

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:
  • 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

View PostBomb Bloke, on 30 March 2016 - 06:01 AM, said:

In general, there's nothing stopping one user from sitting down next to a given computer - assuming their character has physical access to it - and copying everything off it to a new computer. That new system, assuming it knows the ID of the old one, would then be able to mimic it pretty much perfectly.

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.
I'm sure there's flaws in this galore, but I am old and tired and I don't know what they are just yet.

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

I am now arriving at an impasse my flowcharts can't solve.

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

View PostDog, on 30 March 2016 - 01:32 AM, said:

View PostKingofGamesYami, on 30 March 2016 - 01:01 AM, said:

I'm unfamiliar with RFID, however I believe Dog created a system for it; you might look at that.
Actually, I haven't done anything for Immibis' Peripherals - not sure why, either...

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 knew there had to be a way to prevent replay attacks, I just couldn't think for the life of me how. Am I right in thinking I could salt the RFID-Hash with the rolling code to verify both "this is a valid signal" and "this person is trying to open the door"?

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

I'm building a city - as one does - and among the various structures in the city is a ReactorCraft reactor complex. While I'm building in single player, I intend to eventually move the map to a server once it's built, so securing the complex proper occurred to me. I was planning on doing this using Immibis's RFID system, but I need to make sure the system archetecture makes sense, which is why I am here.

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

Thanks. As it turns out, that was the problem - both in the park() function and in the unfunctioned if/else tree that proceeds it. After moving the definition of incoming elsewhere in the program and excising all other localizations the software now works fully as intended.



#229434 Unexpected Symbol

Posted by Communeguy on 08 August 2015 - 11:17 PM in Ask a Pro

I could be wrong - I don't have big reactors so I can't test it myself - but I believe the "-" on line 2 should be an underscore.

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

It's shooting off into space because, as I understand it, there's no upper bound in this code- it's going to move or dig up by the number of times you put in as the yLevel, less 1.

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

And that totally worked.

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

I knew it had to be something hopelessly basic like that. Thanks.



#229334 Unexpected behaviour of Bundled Cable

Posted by Communeguy on 08 August 2015 - 02:18 AM in Ask a Pro

Sorry to doublepost. There is a freshly-reworked version of the code, and while I think I've purged all the typos out of the program, it doesn't run correctly just yet.

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

As it turns out, I discovered using the printing method that it was wrongly triggering hold() when the signal blocks populated on world load. If you give the computer a swift kick and add a sleep before the os.pullEvent trigger it fixes it.

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

As it happens, I am working on a program which does what it needs to do by controlling redstone signals along bundled cable - code at the link.

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