/tg/Station 13

Put it here, don't be rude

also, if your feedback is one sentence I'll fucking delete it I swear to god.

Copying from PR:

- no feedback when clicking button (should be a balloon alert + possibly a light sound)
- not obvious you need multitool to connect (should be in examine)
- not obvious how to put cell in (attempting to click on shell with circuit inside should either put the cell in or tell you to take it out)
- component printer should have balloon alert when printing also put it in random positions
- admin should be able to look inside a shell
- voice sensors should not trigger themselves
- RAM component output is `any`, so it's not obvious how to output it to other nodes. If possible, it should be typed like typecheck

- no component to check if string contains string

- Circuit multitool is not clear at all what it does. Why do I need to mark things? Aslo, if I want to interact with an inbuilt circuit (like the buttons or the drone move), I need a normal multi instead of the circuit multi, why?

- Light circuit's brightness and RGB colors is uncapped so you can give it a billion brightness, or turn it into a flashdark

- Metastation's circuit lab has a toolbox you can't reach
- Tramstation's circuit lab has a toolbox you can't reach, it's unpowered roundstart, it's not even defined as an area, the APC is the APC FOR SPACE, there's no intercoms, firelocks, fire extinguishers, camera. It's not good.

- I managed to make a circuit that automatically translates any uncommon that's spoken, and a circuit that yells when someone said 'fuck' in plaintext
- I couldn't seem to figure out a way to count up via the RAM component
- Whenever I tried to direct an entity -> to string, in person it gave me the entities name but over comms it only said "entity".
- I also had issues getting the get species to work from a voice message.
- I wish there was a way to search for a string in a string, or disregard punctuation
- Is there a way to check for if something is in a list, or a way to build a list? I didn't get to try, but i'd like to see if there's a way to supply a list of words to check instead of just one string.

My first creations:

[1] Feedback in general seems very poor - there doesnt seem to be any way to figure out what's going on or why interacting in any given way doesn't work. Took me like 20 minutes of faffing about to even realise how the coloured connection dots worked at all, and I still have no clue what all the rules for it are

[2] Removing a circuit board from a device has a runechat message (that vanishes so fast it can't even be fully read, let alone be an indicator) but no actual chat log message. For step-by-step technical procedures like this that's very annoying.

[3] It's unclear how you interact with a shell on your circuitboard. The weird scanner didn't do anything even when I put it in as a "Marked" input so I guess it's not that. Again just, really unclear what anything does which I feel lets down the core idea that it should be easy to dabble in.

After a quick discussion in the discord, people would appreciate this being mapped into charlie station when the thing is full merged, so people can try circuits as a ghost role.

This is pretty great so far, but It seems that some of the cores don't work properly. I tried to replicate a loop that was in a drone. It would repeat whatever it heard, but it seemed to not work when I tried to use it on a server. This could just be due to my faulty coding, but goddamn that loop simple.

I will try to be simple, but if any of this is confusing, please ask me to elaborate.

- There are many missing parts! I will not go too in depth because I assume they are WIP, but as an easy example, the Index circuit is currently useless because it takes a list input but there is no other circuit that can provide or even use a list. There are other obvious things like string -> int conversions, or literally any way for the circuitry to sense its surroundings (like for example, making a bot that moves around avoid getting stuck on walls). I appreciate what is currently there but it needs a lot more functionality before being pushed to live, or else players will not understand why any of it exists in the first place.

- It is unclear if there is an upper limit to the number of components you can apply to a single integrated circuit. Either this limit needs to be communicated or, if there is no limit, one should probably be added for reasons that are hopefully obvious.

- Concatenation circuit does not have a trigger input; I suspect this may be the case for other circuits though admittedly I have not checked them all. Instead, it seems to passively concatenate and delay the whole circuit in the process. This is a major step down from the old "pulse in to trigger a concatenate, then have a pulse out for post-concatenation."

- You cannot wire the output of circuits into their own inputs, which breaks things like plugging an "x + 1" circuit into itself so you can increment by 1 each cycle, or concatenators that self-refer so you can continuously build up a string.

- You CAN wire two concatenators into each other, but because they do not use "pulse in to trigger concatenate/pulse out for post-concatenation" and instead run automatically when they receive input, this causes a seemingly infinite loop that at some point stops for reasons I cannot explain due to lack of ingame feedback. Again, the root of this issue is a lack of pulse inputs/outputs.

- You cannot seem to see the buffer of a circuit or change it. For example, if you concatenate two strings "A" and "B" to make string "AB", the output buffer of that concatenator circuit will apparently just have "AB" in it for all time and there's no way to see it or clear it. (Actually you might be able to clear it by running some different inputs and I broke this by wiring two concatenators together, but you should still be able to see the buffer.)

- Delay circuits are needed where it often does not make intuitive sense for them to be placed. Again this seems to be the result of a lack of "pulse in to trigger" and "pulse out post-function" wires like with the concatenation circuit. For example:
-- A voice sensor that places its Speaker value into a "To String" circuit. The To String sends to a "String Contains" circuit where it is checked against a manually entered string. The voice sensor's On Speech Sensed output pulse is wired into that same "String Contains" input pulse circuit. If the String Contains outputs a True pulse, the robot will speak "TRUE" out loud.
-- A plain english form of the above: A robot that will say "TRUE" only when Joe Schmoe speaks to it, and is silent for anyone else.
-- This robot DOES NOT WORK because the "To String" and "String Contains" circuits are ran at the same time, when the "String Contains" should wait on the "To String" before running because it needs the string input from it. A delay must be placed between the voice sensor and the "String Contains" circuit in order to fix it, but in the old system, you would instead just wire the voice sensor's pulse out to a pulse-in trigger on the "To String." Instead with the new system, the "To String" is ran apparently automatically as soon as it receives input, which is bad bad bad. More than anything I would call this counter intuitive. Delays like these should be a part of the natural flow of the pulses of the circuit and not made by bulky, clunky delay circuits.

- Delays are not well communicated. A "To String" circuit automatically runs when it receives input (it should use pulses and not be automatic!!!! but that's beside this point), but it causes the circuit to delay before moving on to actually use that string. Delay it for how long, you ask? Who knows? It is anyone's guess. A simple UI element, like a number under the name of the circuit on the wiring interface, would fix this.

- The examine text for an Integrated Circuit should indicate that you can unscrew the battery.

- Manual input like buttons probably shouldn't be linked to the shell type, but I'm actually not sure about this because if more shells are added in the future it might not be a problem.

- In summary, most of these issues are caused by certain circuits being ran automatically when they receive any input (for example Concatenate, To String). If you gave those circuits "pulse in to trigger" and "pulse out when done" nodes, it would fix a LOT of problems.

- To end on a positive note, the new UI is insanely well done. Really brilliant job, works seamlessly and so far has been lag free.

Sorry to doublepost but I forgot to include:

- Power consumption is not communicated well, much like delays

- You can apparently have multiple processes running on the same device an unlimited number of times, delays and all, which can cause some serious fuckery. In this clip, I had pushed a button on my circuit a great number of times earlier, believing that it did not work. What it was actually doing was silently running dozens of processes where it looped between concatenators for almost a full minute before unloading all the outputs one after another. This probably shouldn't happen, or at least those processes shouldn't have been silent.

This was about the most complex circuit i've attempted (a verbal voting system that disables itself after a while, tallies the votes, and displays who won). I was close to accomplishing it but I didn't really get what I wanted in the end. First I tried sending in a signal to the loop entrance using a XOR but there's no XOR in the logic gates yet (I assume more advanced logic gates are later). Then I tried a second signal to toggle it off when it's done but I didn't solve it before the round ended. Ultimately it sorta worked but a lotta things felt like they were missing, like a lot of connections were made unnecessarily complicated due to limitations.

(don't criticize my shitty circuitry pls, the picture was after I tried a buncha random shit to make it work so it's not the idealized product)

- Incrementing a variable is complicated and annoying
- RESETING a variable seems to be impossible
- There's no way to flat out reset a circuit to initial state?

Ultimately I think it's really cool but right now it's just kinda very wonky and limiting in many ways.

- Also, voice activators probably shouldn't trigger on circuits themselves. Spam is really easy even by mistake.

ram should really be accessible remotely without a wire connection like how you can access variables in UE4, the amount of wires crossing in Melbert's picture remind me of how messy blueprints can get if you dont use that functionality.

edit: to clarify:


have ram function the same as the vars do in this image, you can either get them or set them. (but setting still resulting in a get output after the change)

Qustinnus wrote:ram should really be accessible remotely without a wire connection like how you can access variables in UE4, the amount of wires crossing in Melbert's picture remind me of how messy blueprints can get if you dont use that functionality.

edit: to clarify:


have ram function the same as the vars do in this image, you can either get them or set them. (but setting still resulting in a get output after the change)

I'm unlikely to implement this functionality in the MVP for integrated circuits, but it is definitely something that can be done for the future.

Waltermeldron wrote:

Qustinnus wrote:ram should really be accessible remotely without a wire connection like how you can access variables in UE4, the amount of wires crossing in Melbert's picture remind me of how messy blueprints can get if you dont use that functionality.

edit: to clarify:


have ram function the same as the vars do in this image, you can either get them or set them. (but setting still resulting in a get output after the change)

I'm unlikely to implement this functionality in the MVP for integrated circuits, but it is definitely something that can be done for the future.

Sure. Good work so far.

It needs a guide, but once I picked up the tips and tricks of it all it's a lot of fun!

Looking forward to more.

Would really like to see more string manipulation, string splitting, word replacement, etc.

Circuits are really good I love them.

Is the tg code different from bees? And if so how much different? Because I saw a damn PAI inside of a circuit integrated buggy.

Someone made a racism machine. If you walked around it it would shout racial expletives if you were a lizard, moth, cat girl or plasma man. It was fucking hilarious and this was a good idea.
More features if possible

Jonathan Gupta wrote:Is the tg code different from bees? And if so how much different? Because I saw a damn PAI inside of a circuit integrated buggy.

It's a completely new system in every way--one of the non-goals in the design doc was being directly comparable.

legoscape wrote:Someone made a racism machine. If you walked around it it would shout racial expletives if you were a lizard, moth, cat girl or plasma man. It was fucking hilarious and this was a good idea.
More features if possible

This is the feature we've been dreaming of. With the automation of racism, assistants are no longer needed on the station.

So I did mess a lot with circuitry since the testmerge phase and I do have a lot to feedback.

First of all I think circuitry really serve it's purpose. It gives science a thing to do, it's not a "paste the same program every round" thing like it is in other codebases and you also feel rewarded when you succeed building a good and efficient program. It has also a big plus, it gives a new breath to old cool things like signaling devices and others attachements.

You can do simple programs like a translator or do unnecessarily complex things like a rock paper scissor game. You can make practical things brig lockdown protocols or fun stuff like a bot that moves randomly and yells at you when it hears the F-word.

I already had memorable moments with wiremod, especially with a contraption of my own, the RPS-o-tron, an automatic rock paper scissor game:



With my positive feedback comes some suggestions I'd like to see implemented compenent wise:
- Being able to have multiple signal inputs or having a component that combines multiple signals inputs into one (You can already do that by using radio signals but well, it's a bypass)
- A string module that just returns a string you preset in the code (useful for concatenation)
- A module that returns GPS coordinates (two outputs X and Y )
- A module that sends X signals, X being a number that you input (Result) or preset. The only issue that I've experienced with wiremod was the AND gate bug but watermelon patched it rather quickly.
Maybe power consumption could use some little tweaks because when you make an efficient program with no clocks you never have to recharge the board's power cell.

Anyway, big thank to Watermelon and the others c*ders that worked on this, keep up the good work !

Just tried circuits and posted on coding feedback.
I am hugely enthusiastic for the potential, even as is it only work in progress. In my opinion new components should focus on ways to interact with physical and digital worlds : allow deep interactions with electronics (machines and consoles, via usb at least) and with the station in a physical manner (components to pre programme path for drones, opening doors, scanning area to interact with specified targets, construct/deconstruct simole things ..)

The potential is really huge to make a sandbox inside a sandbox and reward patient scientists who want to either help station or terrorize it (or just prank crew).
Circuits could be the best adding to TG in months, if not years, but it requires many more components

It would be great to have a component that could fit in a tablet to remote control precisely a drone/bot to give it directions, allow it to plug electronics and interact with them as could be done physically

I really do like that you went with the connectable nodes for this, it requires no coding knowledge, it's more fun to use and it is fairly simple to grasp how it works. While I personally think that the entire printable components chain is a bit too obstructive, it does work well enough that you can still get your goals done.

While I was testing this out, I noticed a few things that gave me troubles:

- The window does not open up correctly for me, when I open up the component printer, the window cuts off important interactable sections, as shown here: The initial window for the circuit is also very small, while it is possible to enlarge both windows, it would be more userfriendly if there was either a maximize button at the top, or if the window opened up larger to begin with.
- For some reason, the clock speed remained the same, no matter the number I've put in. I can understand that you would want to limit the speed for the server sake, but surely you'd allow it to slow down?
- Even though lists and indexes are accetable inputs, I could not find a way to create either with the components available

Here are some suggestions that would make me happy to see implemented next:

- I'd love to have more sensors available for use to create more complex programs, for example a way to measure distance to build some sort of navigation
- I love using the nodes, would it be possible to also allow for a drag and drop style of connecting nodes? What I mean by that is that you click an input / output and drag it over another one. This would make interaction with the node system smoother and more precise.
- Speaking of, can you implement a zoom out of the window by using a keyboard button + scrollwheel combination, and scrolling up and down with the mouse wheel itself?
- It would be great if components were prevented from being moved when you move around by pressing down the mouse wheel
- If you continue to use components as they are, it would be neat if upon installation, they were dropped into a sidebar from which you can drag and drop them into the actual circuit, that would make additions to large circuits more pleasant

This is my initial feedback, I will continue testing this feature in the future. I am looking forward to the next improvements, and I really do enjoy what we were given already!


With warm regards
-BONERMASTER