Biggest issue for me right now is that there's no way to put in a direct ^ or |n in DWAINE. Otherwise you'd theoretically be able to write scripts down on paper and scan them into the mainframe system; right now any |n on paper turns into a literal newline after scanning so it's a bit silly.
I'm curious how you set up remote telescience, though. It's late but I can't figure out how you'd get the wireless net talking to the wired one.
Zadeon: I'm with Zamujasa on open discussion. Sure. Some things I'll hold back unless I see somebody working hard on it. Like lockers, or remote telsci. That might change with this thread, I guess. It depends on the reaction from the other nerds. I'm Manne Love in game if you wanna hit me up. I'm generally just playing the sax and looking for neat hats to wear anyways, so I find making people nerds teaching people enjoyable. I also lurk #goonstation just to figure out who is teaching poor HeadSurgeon all of these horrible things.
That being said, most of the people in this thread are far more competent at this stuff than I am.
Though if you are working on something that is unique and you want to keep it a surprise, then ye, you can PM me. If people worked on stuff like the critter farm in a thread that I saw, then it wouldn't have had the impact it did.
Zamujasa: Yeah. I want remote scripting. I remember trying it a good while ago and giving up after a couple days due to headaches. I haven't really tried again due to that.
As for remote telsci, you can push it from a wifi comp to a signalbuilder to a powernet comp. Or am I wrong? I know I set up a remote signaler to toggle a portal the other day just to see if I remembered correctly.
Zadeon Wrote:So how do you trigger remote signalers again with components?
RSDs send a packet when activated that activates other RSDs on the same freq with the same code. It looks something similar to "command=ACTIVATE&code=30" -- I forget the actual packet, but it's easy enough to figure out. Just hook up a wifi component to a soundsynth component and set the wifi component to whatever freq yer using with the RSD. Then activate the RSD. If you did it right, you should hear the packet from the soundsynth. You could also just use the packet sniffer from the ND cart. That's more accessible, anyways.
Once you have your packet, well, it's pretty easy to understand. I'm guessing you just need to know is how to send it. For that you need a wifi component, a signal builder, and for the sake of explanation let's say a pressure switch. Hook the pressure switch to the signal builder (the send option), and the signal builder to the wifi (the send option). Make sure to toggle the wifi as mentioned earlier, and also set it to the freq of the rsd you wanna activate. Then plug in your packet as the starting string in the signal builder. With this setup, the rsd will go off when somebody walks over the pressure switch.
Most people would use this setup to for hellfoams or bombs. I use it for autohonkers. Honk. Actually -- most of the time I just set up the autohonkers to a CU. Autoautohonking. Honk. Honk. Honk. Honk. Honk. "OH GOD IT'S HAPPENING!!"
NOTE: The signal builder might be excessive. You could try just changing the pressure switch's 'send signal' to the packet you wanna send and then link it directly into the wifi comp. I remember setting up honkers that way. I also remember calling the shuttle with just a button and a powernet comp. It's just that I've lately had some trouble with this method not liking ampersands. *shrug
Zadeon Wrote:Is it possible to do loops of any kind? You keep mentioning autohonkers and what do you mean by that? Just signals to rsd+bikehorn combos?
I just noticed how much I've mentioned honking. It must be the hunger. The problem is they get picked up and tossed for some strange reason.
And yes. It's a very simple thing. RSD+Bikehorn, then using a fun trigger. Just using an RSD to set them off is boring. Something like having them honk every time someone enters sec is more fun. Or you could just set the CU to repeat them nonstop.
Getting an endless loop can happen one of two ways. Well, I think there's only two ways. The first is the set up gravaccs to send something like a locker back and forth in a way that it hits a pressure sensor on the return trip, thus starting the process over again. This has more style, but is unreliable and less efficient. The second method is to use a control unit.
I wrote a step by step for setting up a repeating signal with the CU a while back:
Vitatroll Wrote:To use it to que actions is the only thing I remember right now. A few months ago I remember being able to do more, but I lost my research, which happens because I'm a dumbass and title my docs vaguely.
The basics on the CU:
Examine Info Wrote:Control Unit:
This is Control Unit.
* Instructions: Word size in this setup is one byte, one nibble is the instruction and the other is the operand. In that order. A0 is opcode A operand 0.
* 0 and F are NOPs
* 1 (LD) loads an input value into the accumulator, RR. Input 0 is !RR.
* 2 (LDC) acts like 1, but with the complement of the input
* 3 (AND) sets RR to the logical AND of RR and the input.
* 4 (ANDC) sets RR to the logical AND of RR and the complement of the input
* 5 (OR) sets RR to the logical OR of RR and the input
* 6 (ORC) sets RR to the logical OR of RR and the complement of the input
* 7 (XNOR) essentially equates RR and the input, with RR set to the result of the test.
* 8 (STO) store RR in either a RAM addess (High 8 bits) or one of 8 outputs (Low 8 bits).
* 9 (STOC) store complement of RR in the same was as STO.
* A (IEN) sets IEN to the input. IEN is Input ENable.
* B (OEN) sets OEN to the input. OEN is Output ENable.
* C (JMP) will adjust the program counter by up to 32 addresses, forward or backward from the current instruction. Arguments 8+ will subtract 7 and then jump 4x that value forward, less than that will jump back 4x (that value + 1)
* D (RTN) skip next instruction. For some reason.
* E (SKZ) skip next instruction if RR is zero.
Output signals have the value "PIN:VALUE" i.e "2:1" to output true on pin 2. You can filter this with OR gate triggers, ok.
Example program: "30A0B01181" Will AND RR with 0 on the first iteration (As IEN is zero) and AND it with !RR on subsequent loops (Both set it to zero), load !RR (1) into IEN and OEN, then load input 1 and send it to output 1. This will repeat without end.
Step by step for a repeating signal:
Wrench CU into place.
Right-Click with multitool in hand and Set ROM to b080.
Click-Drag CU onto another to set what it's signal does. Let's say we hooked it up to a speaker component.
Right-Click with multitool and select Activate.
Done.
Now you'll see that the speaker component will be repeatedly outputting 0:0. The CU's signals are key value pairs in the form of OUTPUT:RR.
What b080 does:
b0 sets OEN(b) to input 0, which is !RR. RR starts at 0, so NOT(!) RR is the opposite. This means that b0 sets OEN to 1 and enables the CU's ability to send signals.
80 send the value of RR, which is currently 0, to output 0. That's why the signal shows up as 0:0.
The CU reaches the end of the instruction set, then repeats the instructions, and this continues until it has been disabled.
If you want to increase the time between pulses you can add 00s to the end of b080 and it will delay the next pulse. Or you can just hook the output into a delay component.
More complex things can be built using the logic gates and key-value pairs. Says the person who's tripping on toggle components, anyways.
You probably knew all of this. Might help somebody, though.
I've had a few people come to me for doorchanics. Unfortunately I've been busier than usual in game, so I couldn't help. Zamujasa has already listed everything you need to know on his wiki, so this feels redundant for me. Still, it's good to be discussed here since it's a nice introduction to packets.
The basics you need to know:
- All normal doors send and receive packets over the wireless network on frequency 141.1, which I will call 1411 from now on.
- Doors can receive commands from any distance, but they only send reports within an 11x11 square centered on the reporting door. This is true no matter what method used.
- Wireless packets can be created, sent, and received through a few methods. Mechcomp and PDAs are the most relevant, so I'll keep it to those only.
- PDAs need to have an Network Diagnostics Cart, or the equivalent of.
- MechComps machines will need a wifi component to send and receive wireless packets. Theoretically you could use other methods if you figured out a way to remotely create files in the mainframe.
What door the packets look like:
If you Packet Sniff a door when it's opened manually you will see that the door sends out a report. The report looks like this:
Doors send these packets twice when you open a door manually. This is only a report, though. It isn't used to operate the door. This, however, IS useful for automation using MechComps. It's also a way to get the door address without a screwdriver or ping roulette. The parts explained:
- sender is the doors address
- timestamp is the timestamp
- user_id is the name on the ID Card used to access the door
- door_status is the status of the door after the action. This is wonky. If you open a door it automatically closes after a while. Even if the door is actually closed. With no action after you open a door it will produce one report with 'open' and another with 'closed'. If you close the door after you open it, then the second report will be 'open' even though the door doesn't open. If you open a door with packets, then close it with your hands, then you'll get a single 'closed' report.
- lock_status is the status of the lock during/after the action.
- command is the command given to the door. There are 6 command I know about. They are:
- - lock
- - unlock
- - open
- - close
- - secure_open (Bolts a door open, even if it was closed and locked)
- - secure_close (Bolts a door closed, even if it was open and locked)
- address_1 is the address of the door. You can get the address by packet sniffing, pinging, or by using a screwdriver and checking it's access panel.
- sender is the address of the device used to send the packet.
Remote Door Control with PDAs:
Using a PDA with the equivalent of a Network Diagnostic Cart, start off by using your PDA's File Browser to access the Packet Sender. Once in the Packet Sender you press (add new) and add your key:value pairs. Key in the first popup. Value in the second popup. You only need two KVPs to use a door remotely: command:commandhere and address_1:dooraddresshere -- next, you set the Packet Sender's frequency to 1411 and press send. It's that easy.
Remote Door Control with MechComps:
The packet is the same. The way you enter it is different. You need at least three things. A Signal Builder Component, a Wifi Component, and a trigger to send the signal. Let's use a Pressure Sensor Component. First for the hookups: Pressure Sensor to the Signal Builder (send), then the Signal Builder to the Wifi (send). Then toggle both of the wifi's options (don't forget!). Then enter the packet into the signal builder, separating the key:value pairs with ampersands. It should look like this:
command=commandhere&address_1=dooraddresshere
Then just walk over the pressure sensor and watch the door obey your command.
Those are the basics down.Now how do I make all of the doors on the station bolt open??
You don't.
Err.. well, it IS possible, but also highly impractical. Regardless, please don't try this as a nontater. One method is to:
Set up a machine at your base that splits the door address from every ping response on 1412 and then sends that data into a selection component. Then set up two wifi components set to relay packets from 1411 to 1412. Then you set up the wifi comps at any place you want doors to open within a 11x11 range, and ping with an ND cart. Then you take up your wifi comps and do that for every 11x11 space you want to doors to open in aaaaaaaaaaa!! Or you can enter them manually from the ping results aaaaaaaaaaaaaaaaa!! Once you're done you can then just set up a signal builder to repeatedly open up all doors one at a time with the help of a control unit and a delay component. It doesn't help that the selection component usually gets duplicates which can be a pain to get rid of. Also, it doesn't work with welded doors obviously.
There are other options, but the best option is to subvert the silicons and make THEM bolt all doors open. Which they tend to love doing, anyways.
I want to piss everybody off with yet ANOTHER tollbooth!
Wow! You really ARE a Mechanic!!
First off: Door-based tollbooths are inferior to teleporter tollbooths. Sure, they don't have as much style, but they're more likely to work while automated. Second: I won't give you the parts. Just some things that have been done.
Primal: Simple, but one of my favorites. Have one button that will secure_open a door and another that will secure_close it. You are the gatekeeper, and money is your keymaster. You could also have one button that opens and closes the door quickly with the help of a relay component. Not as primal though. Really this only works at mechanics, and is pretty much one way unless you rig up a table and a hole in the wall, or a pipe system that mails yer stuff to you.
I only accept cash: Payment Component to machine that will secure_open and secure_close a door quickly. No refunds for being a slow poke! Just make sure that the payment component is on the door tile (or in a wall north or south of it) so they can get their refund if they missed it. Or don't if yer a jerk. Though if you do that you might wanna build a pipe system that autoflushes all excess credits to you! Ha-HA! Though you'd probably still wanna set that up in a wall so you don't get any unwanted visitors. They can be quite rude, I say.
Tickets please!: Set up the toll with a thermal printer and a paper scanner. Either sell the tickets directly or have them work with a payment component. Like all automatic systems this can be set up anywhere. It does work better if you don't have the scanner eat the paper, though.
Hands up!: Hand scanner with a selection component used to verify purchase. The meat of it need a hand scanner, a selection component, two relays and a signal checker. The selection component needs a list of names or fingerprints, and in that list you need a null value for non-clubmembers. A 0 will do it. The connections go like this:
- Scanner to selection component (select item) and relay1
- Relay1 to selection component (send item) and relay2
- Relay2, which has signal changing toggled and send signal set to 0, to selection component (select item)
- Selection component to signal checker
- Signal checker, which has an inverted trigger string set to 0, to the rest of your machine
aaand you're done, more or less. A bit more complicated, eh? Then again, it's late (early, actually), so I could be over complicating things due to yawning.
Some general tips:
- Give sec a cut of the action. Or a free pass if you can't manage the credits. They love to play along. Also goes a long way to make sure the tolls are respected.
- Armory doors make wonderful toll stops. Super easy to get if you bring sec in on your game.
- Give heads a free pass. They'll enjoy laughing at other people and will usually support the tolls.
- Give people a way around; just make sure it's a long way. This way they're more likely to just go around instead of destroying your machinations.
- Talk. If you just sit in silence you're gonna get mobbed eventually. Conversation makes this more fun for all parties, even if some of those parties are want to mob you.
- Beware the Clown. No, I'm serious.
Okay so the 'open all doors' thing sounds like hell, is there a compromise?
Ah, why yes. Yes there is. It's just situational. It also has it's glitches due to the way door reports work. Please don't use the secure_open version of this unless you're a tater.
You need at least: Four wifi components, a splitter component, and a signal builder component. Prep the wifis by toggling the toggles and setting them to 1411. Set up the splitter comp, the signal builder comp, and two wifi comps in your home base. Connect them like this:
- wifi1 to splitter
- splitter, which has it's trigger set to sender, to signal builder (add + send)
- signal builder, which has it's starting string set to command=open&address_1=, to wifi2 (send)
Next, go to any place you want be able to access with an 11x11 square and place a wifi4 there and wifi3 beside it. Hook wifi3 to wifi4, and now walk into any door within an 11x11 square of wifi4. What?? Huzzah!! How 'bout that? I mean it's still fairly impractical, but hey, doors kiss your ass now! Neat, eh?
Doors are great, but I'm looking for something else...
Try secure lockers: Frequency 1431, packet is address_1=lockeraddress&command=lock/unlock&pass=commandauthcode -- Great, now I've gone and pissed off all of the 20 people who know that! Oh well.
Sorry. As far as I know locked crates need a card. I've pinged all frequencies and haven't gotten anything. Locked safes and pass crates need to be figured out as well. Eh. *fart
Now, get to work. I expect to be horribly inconvenienced in new and exciting ways! Don't disappoint. (Like I just did with the mess, typos and errors. I'm too tired to proofread. )
I'd just like to give a friendly reminder that, if you play an AI, your PDA has packet sniffing and sending modules, as well as a station-wide range. Comes in handy for doing more esoteric rogue business, like helping your traitor buddy bust open the armory lockers. It also, I believe, lets you open/close doors even if the AI control wire got snipped, though I haven't tested that out quite yet.
Somepotato Wrote:Not sure if it was wise to show how to unlock locked lockers as that was kept secret because of how OP it can be
It's not really that powerful from a tater side of things. It's far better to get an emag or an HoS. The real possible problem comes from sec breaking in every round. Honestly, I resolved that if remote locker access gets taken out because of that post, then I would have rather not had it in anyways. I made a show of it, but I'm perfectly fine with those 20 people being pissed at me.
Telsci-stuff is a tad different. It requires no access and no daring. (Well, access helps) It's also fairly easy. People have everything they need to get started in this thread. Mainly, zamujasa's wikipage. It's real useful all the way around, and can lead to some unique contraptions from creative people who don't beat a dead horse because they can. It'd be a real loss to see it gone.
BaneOfGiygas: Nah. AI control wire cuts remote access off. Probably a good thing, as it's the only real countermeasure against the AI and packet hippies.
Huh, 143.1 has private lockers too? Can you ping those? My notes on the wiki just had it full of that mystery patrolling thing.
As a side note, the AI PDA might have infinite range (but then don't all PDAs?), but you're still only going to get replies if you're in range of the device. I spent an entire round as AI pinging every single frequency on max range and got a lot less than I was hoping for :downs:
I kind of wish the pinging functionality had a "signal strength" thing too so you could get a guesstimate of how far away from the signal you were. Would make for some fun marco polo-style hunting. Imagine using the ping tool to find people's PDAs like a low-tech pinpointer...
)
