Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
How complex a chip is depends entirely on what you want it to do. However, as a rule of thumb, the more complex it is the more specific use it has and thus the more unlikely it is for a block with that exact functionality to be added. Additionally, the point of the game is making things yourself with the tools provided, which is why if it can already be achieved it has a low chance of being added
Basic math operations of addition/subtraction/multiplication on output values are already a thing. Powers/roots/trigonometry functions would be very rarely used (specially when you consider that the input can only be on the [-1, 1] range), and output value storage can already be achieved with just 2 blocks
Wheel speed/torque can be achieved by reading the speed of the vehicle or the power with which you are activating the engines. Spring stretch/compression can be read with distance sensors. Hinge angle can be read from the power with which you are activating them. Those blocks aren't sensors, so it doesn't make much sense for them to send an output (and that output would have to have a true/false value attached, making it make even less sense as you now have to define which state is active and which is inactive)
How about getting proprioception data for a compliant robot arm to detect when it's colliding with something and where the the collision is happening?
Adjust the speed of the wheels on a self-balancing vehicle with a PID system to keep it stable, accounting for when it's carrying additional weight picked with an electromagnet?
Modulate pistons on a car with active suspension?
Distance sensors. I don't see how analog outputs can help with that at all, since 2 objects are either colliding or not, there is no in between state
Same circuit as for the first case
Analog input just changes the speed of pistons, so you wouldn't get much more control with them. The method will still be distance sensors to measure the distance to the ground
For the compliant robot arm; are you sugesting coating the whole surface of the arm with distance sensors, and wiring a complicated logic system to calculate the directions of all those depth "pixels", doing the trig and comparing the dozen sensors with logic gates?
The suspension also has a similar issue as the self-balancing, bang-bang allows for no nuance...
For self balancing, you can use the same circuit. It's just a matter of choosing what should be activated (and on which direction if necessary) whenever the sensors detect the creation is tilted on a given direction
Yes and no. Yes, you would need to coat the whole surface with distance sensors, and analog outputs isn't going to change that. However, you wouldn't need any circuit than at most a couple OR gates to combine the sensors on some areas. Where the collision is is given directly by which sensor was activated. Since analog signals can only contain a single number in the range [-1, 1], you can't compress the position of the signal on a single output (as a single number isn't enough to describe a position in a 2d surface)
Again, analog output wouldn't change anything there as analog inputs just determine the speed of pistons. They don't determine their length
Using an x86 chip to simulate logic gates to simulate an x86 chip seems like madness. I just want a nice scripting language like lua.
To keep with the "brick" mentality and maintain controller compatibility, perhaps the scripting interface could be something based on/inspired Google's Blockly programming system, where code can be "written" using just the mouse by dragging commands, variables etc, and placing them on the "connectors" of previously added blocks, in a visual structure that's pretty much equivalent to code in text editor with very fancy formatting. I'm trying it on the site right now, and looks like by default it might not let you edit the raw code text directly, but that doesn't sound like it would be a big challenge for developers to add; I'm not sure if there's already a way to convert raw code into the block structure though, so there's a chance editing the code directly might be a one-way thing unless a reconversion function is implemented.
Oh, looks like they mention another similar project, called PencilCode, which has a editor component called Droplet that can be used independently, which does allow back and forth conversion between blocks and text.
https://steamcommunity.com/sharedfiles/filedetails/?id=2790650774
You don't really need to simulate a full computer for anything (unless your goal is specifically designing a full computer). The most commonly used circuits outside of logic focused builds use less than 10-15 gates at most, with ~2-5 being the average. For circuits as simple as that, logic gates are much easier to use for people who don't know programming already (which is the vast majority of the players) as their behaviour is much simpler and thus easier to learn than a full programming language. Additionally, a full programming language would still have to be limited by the way inputs/outputs work for it to be compatible with other blocks (it can only have a single output which is always sent to all connected blocks, inputs/outputs must be on the [-1, 1] range, and it can't differentiate between inputs), which greatly limits what it could do
you can manually rotate the platforms with w/s, which is why there are 2 sets of servos on each side. The first set can be controlled manually to tilt the platforms, while the second set is controlled automatically by the sensors themselves. In practice, you don't have the first set (since it's used for testing) and the second set can be replaced by whatever you want to use to stabilize it (usually heli engines due to the high rotation force they can apply as well as how fast they can change the direction of that rotation, i just used servos since you originally asked to stabilize it with mechanical connections). If you look at the gif i posted, you can see that i was activating the first set of servos for most of the time (you can see the base of the second set was being rotated), so the sensors where actively counteracting the rotation applied by the first set of servos. If you disable the sensors and repeat that, the platforms won't stay horizontal/parallel to the ground
That behavior is only partially related to the stabilization. It's true that one part comes from the wobbliness of the stabilization (which can be reduced by a lot by tinkering with the values), however most comes from the fact that that was a test bed and not something you would implement directly on a creation. Particularly, you wouldn't have the first set of servos as they are only used for testing purposes as i have already explained, and those are the main cause of the problem. Basically that design has 2 mechanical blocks directly attached to eachother, which means the total mass between the mechanical blocks is pretty much 0kg. Meanwhile, attached to the second mechanical block there are ~20kg. Mechanical blocks which hold a lot more weight than their base has are known to cause issues, leading to them spontaneously wobblying a lot. In this case, the second set of servos is holding ~20kg while having pretty much 0kg on their base, which is why you can see that issue happening. If you add a 30kg weight between the servos, most of the issue dissappears and you are left again with just the wobblying from the stabilization
and what did you expect by doing that? That's not how you are supposed to use it, you shouldn't even be using both stabilization methods at once (i just put them on the same blueprint to share it more easily, but as i had already said each half of the build is independant and stabilized to different positions). You didn't modify anything while changing what needed to be stabilized. If you wanted the middle to be stabilized, then you need to only use a single pair of sensors, attach them to the seat and connect them to the sensors on both sides. Additionally, for the system to be able to mechanically work, you need to add weight to the legs/attach them to the ground with anchor pins, since otherwise whenever the servos are activated they will rotate the legs as they are easier to rotate than the seat. After you do that, it works flawlessly again