Concept 1

Let's face it, large things are cool, they usually have a lot of time dedicated towards their complexity (most of the time), they have greater potential (in a lot of cases this will mean more guns, wheels, or thrusters), and they usually have a lot of neat mechanics to them.

However, in the trailmakers community there is a problem, it's the complexity limit.
This complexity limit is sometimes annoying as 1. You can only make an educated guess on when you will reach that limit, and 2. It feels a bit too low if I'm being honest (our complaining likely won't help us change that).

Luckily however we've gotten two recent additions that are game changers, these are the magnets and the anchor pieces. These are rather self explanatory but my god are they a miracle.
These parts help us attach builds that can work in unison... but then there's that roadblock, sadly, one seat can not control other creations as well

That's where my idea comes in.
My idea uses the following blocks for one seat to be able to control other sister builds:

Pistons
Distance Sensors
Suspension
And Possibly Magnets.

How would it work? It's simple

Two builds are attached, one has a set of pistons and/or magnets, the other has suspension separating tow distance sensors which trigger when the suspension is compressed. The pistons on the control centre of the two builds will push down on the sensor and trigger the output of the sensors (tips will be included at the end), what you could also do is substitute the pistons for some magnets, magnets will provide instantaneous force on the suspension as the piston design first needs to extend, the magnets design in my opinion is better for steering as it provides more instant force, the drawback to the magnet design is that it's heavier, more complex, and runs the risk of the sensors actually triggering without proper user input (part of tips).

Due to this design using logic you can lead the input into other means of logic (examples being a walking motion for a leg, multi-cannon firing intervals, mechanical motor (specific), and more).

This could honestly be a game changer as the only limit to the combined build size, is in fact your computer, why? Well because I have a low end computer that struggles with one max size creation, now imagine 5 on a decent computer that you regret buying as all you're doing is playing indie games which don't require too much performance (sorry, just a bit of comedy, don't be offended please). This means that with some heavy thinking, numerous builds, and a currently burning PC, you could hypothetically make a functioning computer which is instant bragging rights... that is, if people don't call you a nerd.

My request for any community builders out there (Don't hate me please):

8 leg walker with enough firepower to scare the United States Military.

*TIPS FOR CBIS(Cross Build Input System)*

1. When using piston design make sure to have suspension at high stiffness to avoid Dry Firing upon sudden movements.
2. When using the piston design make sure to tune the sensors to be in just the right spot to fire, if not you either run the risk of Dry Firing when the trigger is too lenient, or if too strict you receive more input lag.
3. No matter what design you use you will always have some input lag
4. if using magnets, make sure to have the suspension be softer than the piston counterpart, too much stiffness and/or damping will either receive more input lag or not even fire due to the magnets not having enough power.
5. All you will really need is 1-4 pistons and 4-8 suspension pieces. More than the recommendation will maker the system heavy and larger.
6. If using a Downward Push System make sure to account for the forces of inertia when the build comes to a halt after a fall (higher stiffness/dampening)
7. if using a Forward Push/Backward Push System, follow the recommendation from tip 6.


*JARGON FOR CBIS(Cross Build Input System)*

"Dry Fire" : when sensors trigger without direct player input
"[Insert Direction] Push System" : Direction of the male component
"Male Component" : the part in the system that applies force to trigger the sensors
"Female Component" : the part of which is compressed to trigger gates.

*Examples Of Uses For CBIS(Cross Build Input System)*
1. Multi Segmented Walkers. The reason why is to be able to spread weight over a larger area with more legs making it more durable as some legs CAN be missing (to communicate the leg being destroyed to the logic used I recommend having permanently activated logic leading to an AND gate which basically means that if every gate is intact it will say to the system "hey, I'm still functional, continue walking". If you want better results you could use a more complex logic system with each sensor in the leg individually affecting the circuit to say "hey, I'm ok, keep doing what you're doing" or if some are destroyed "hey, I've taken hits and not as functional as before, make sure to account for this when walking". That system is more complex and will require a lot of thinking.)
2. Making A Computer (Please don't kill your computer, make sure to reserve as much computing power possible to attempt this)
3. Repairable Builds. Multiple small parts attached by magnets which an be dropped and replaced if needed. Examples would include Multi Wheeled creations in which every wheel component has it's own drive, and armour plating.

------------------------------------------------------------------------------------------------------------------------
Concept 2

Cars and Planes, both rather amazing marvels of engineering, one can fly, one can be driven on land for a lower cost. Notice how I didn't state that cars can fly, that's one thing they can't do. However, in trailmakers it's much easier to make flying vehicles out of anything, including a tank (aka extremely heavy armoured car). These in the community are called transformers, one purpose to another in a small amount of time, yet we can shrink that time by being smart on the transformation phase.

What you will need for this system is the following

Helicopter Engine (V1 for Servo, Either For Hinges)
Possibly Steering Hinges (x4)
-Any 1x1x1 Pipes (Varied, Minimum Of 4)
Possibly Rotating Servo
-Any 2x1x1 Structure Blocks (x8)
-Any 2x2x1 Structure Block
Wings (Small Or Large, Varied)


How Would It Work?

Wings convert forwards motion into lift, the more forwards speed it has the more lift it has therefore allowing flight. However, Helicopter engines alone are powerful, but sometimes isn't fast enough, here we can get help from hinges or servos to, during takeoff, extend the wings outwards, this extension creates extra speed, however this comes at the cost of initial lift as the spinning of the helicopter engine isn't fully utilised as the wings will be folded inwards therefore meaning upon input there will be slight lag. The lag experienced though will be followed up with extra lift as both the steering hinges/servos and helicopter engines will provide speed, this extra lift begins when the extension of the wings surpasses 50% extension.

This system does have a few benefits, all of them include smaller dimensions than keeping the wings outwards at all times, if a creation is just light enough to get off the ground but gains height at a slow rate then this method would give it a burst of lift getting it out of a dangerous situation faster.

*TIPS FOR "SPEED TAKEOFF DEPLOYMENT METHOD"*

1. If hinges are used just be weary that they can still be moved without input (given a decent amount of force).
2. If a servo is used I would highly recommend building the servo so that everything is retracted upon initial spawning, you could however substitute this with a logic sequence given the blades need additional folding to be considered compact.
3. Smaller and lighter transformers may not benefit from this as the time it takes to extend may be too great (using a traditional helicopter system may be able to takeoff faster due to the delay period not being a factor, this concept is mainly for heavier creations).
------------------------------------------------------------------------------------------------------------------------
*NOTABLE FEEDBACK*



------------------------------------------------------------------------------------------------------------------------
*WILL BE UPDATED*

+++ = New (Added Concept)
++ = Added (Added section)
+ = Added To (Added onto attached section)
- = Removed (Removed Information from attached section)
-- = Deleted (Deleted section)
--- = Scrapped (Deleted Concept)
-+ = Edited

Update Log 1: ++ "Examples Of Uses For CBIS(Cross Build Input System)" section 1-3.
Update Log 2A: -+ post Topic to "Advanced Component Concepts".
Update Log 2B: ++ Update Log Key Chart
Update Log 2C: -+ everything in order to carry through with update 2A.
Update Log 2D: ++ "Notable Feedback" section.
Update Log 2E: +++ "Speed Takeoff Deployment Method" Concept (Unfinished).
Update Log 3A: + "Speed Takeoff Deployment Method" Concept (Finished).
Update Log $A: -+ "Examples Of Uses For CBIS(Cross Build Input System)" section 1.