Was seemingly getting odd effects when building, so did a bit of testing. Testing rig is about as balanced as I could make it. First pics are just one small thruster pointed in different directions out on the edge but in the middle. Next a couple thrusters, then on to testing what they do when out at a far corner. *The Stats pages show how many thrusters; couldn't always get a clear shot of all the thrusters. Thursters are color coded so their force direction matches the Red/Blue/Grn of the axis' shown when CoM is active. Also hopped in & out of the drivers seat each time to ensure updated turn rates. Note I did add a bit more framework mid-way through. The natural colored carbon fiber blocks along the edges. Pics are numbered in upper left corner. Part I find odd is when thruster/s are out at a far corner. Torque is greatly reduced. Seeming to show that if a ships front back left right thrusters are noticibly above or below the CoM plane, rotation is impacted. Sry for all the pics but they're the best way to show things.
I noticed that effect during the building of one of my SV's, I just made sure to have as many thrusters in the center plane as possible.
It's easier to quantify in one plane ... they are using the moment arm from thruster to CM to calculate a metric of control authority so that the longer the moment arm the greater rotational force it creates. Watch Spacedock do the once over on the Razorback 50 seconds in for a nice visual of a ship using small thrusters on a long moment arm to turn a ship fast. It's doing the right thing as far as that's concerned however there are some things you would expect to see that don't happen. I threw this together to see what you were talking about... ... I can shut off all engines but the two pointed aft and using the arrow keys I can spin quickly in a circle. If I shut off the one on the left I can only spin right. But in either case the ship doesn't move forward as you would expect it to given that the only thrusters pushing on the ship are pointed straight behind me and there is nothing countering that force. If I have a single engine on the end of the arm enabled and press W it goes straight forward so no rotational torque gets applied. Likewise moment arm calculations of the mass distribution don't seem to impact the CG the way you would expect. The long arm of hardened steel blocks out front should move the CM proportionally further forward with each additional block to reflect the impact of the length of the arm- a 1Kg weight on the end of a 10M arm should move the CG the same distance as a 10Kg weight on the end of a 1M arm. The upside of this is that you can get great control authority in terms of degrees/second with small thrusters at the end of a long arm and you don't need to worry about thrust offset putting you in a spin if you loose one.
The differences between picture #2 & #6 is the part that I can't make sense of. And I can't tell if it's intentional or accidental. In #2 the thruster is on/in the CoM plane. In #6 it's been raised above that plane by 7 blocks. Result of higher placement is significant reduction in turning force; from 37 deg/s to 2 deg/s. -- I get why they seperated 'straight line movement' from 'turning movement' (your 2 rear thrusters allowing Yaw without moving ship forward). Irrational, but allows for spinning in place for landing and such. (without requiring counter-balancing thrusters; so it supports the, 'only need one forward thruster to 'fly' a ship' bit) Your second part of that, only having 1 of the rear thrusters active, resulting in not being able to spin in both directions, that isn't what pic #2 shows. It has 37 deg/s on the 'strong' side, but still provides 7 deg/s in the other direction... Should clarify and say I _didn't_ actually try turning the test ship. So it could be that while it shows 7 deg/s, it may not have actually been able to turn in that direction. Flight test is needed --- Thanks a bunch for that link, -very- cool!
damn, i think i was playing a survival space craft game... not a flying simulator spaceship simulator... lol
I gave up trying to understand the system. It's too full of bugs to be able to tell the difference between bug and working as intended.
Yeah, this is what I get for saying "but the physics IS laughable" six months back when we were flying around in Elenor's house from The Good Place as a CV ... it's the same reason you should never share hints on how to avoid base attacks and other "exploits" around here. I'd bet money they watch spanj's vids to prioritize which holes to plug in the colander. "You can't use elevators!!! What! Cheeky! Who said you could use the stairs!" Oh ... I see what you mean. That is counter intuitive. I had to make my ship on a two block keel to get the CG right on the line vs. in the middle of a single block keel (where I saw the same bias to the edge you describe) but once I did that turning an engine off made the turn that way torque drop to zero.
If that was true, then a good amount of suggestions that fit the following would get adopted rapidly: - lazy or no coding involved - impervious to exploits - reduces strain on computers (servers ++) - simple change of values make big play differences - reduce game complexity to promote higher sales - auto-balancing system - lots of assets variety with minimal developer input/ work - more fun, less grind, happier playerbase (proven ++) ... and surely others of the same kind. But what we are often witnessing doesn't fit with that "idea". Not going further to avoid harsh words...
I like the game and try not to get too worked up on stuff that goes differently than I'd prefer since the guys doing the work know more about the implications of what suggested changes might imply to their code base. That doesn't mean I wouldn't jump ship if they went to fee based subscriptions or another vendor released a "better" product (by my definition of course!) but right now Empyrion is still (by far) the best value in my Steam account based on the hours of my life I've frittered away. Love you guys! Today's "yeah, that's still a thing" are these three pics .. the first after joining our 11.1.1 local server game and being greeted by a creepy (dead after I shot it and floating in mid-air for a reason that shows up later), the second on a reset to initial state by jumping out and in (better- but not there yet), and third on a reset to initial state by jumping out and in (third time's the charm). Laugh or cry? Camus says laugh. We're all hanging out in this bar for a reason. I find the console commands "gm", "sbp", "im", and "h" do a yeoman's job at getting past rage quitting when I don't agree with the unexpected outcome of various implementation choices on the part of the lead developer. PS: Want to avoid base attacks in single player? Set it public. I leave a base like this on every planet my never attacked CV parks at, even if I can't count on the base actually being there when I join. PPS: What's the bug that actually needs fixing, players being able to avoid base attacks or bases not spawning completely?
This post looks very good, but a little hard to follow.... Would love to see a YouTube vid showing the results of the testing!
One thing to keep in mind when doing tests like this is that the moment of inertia will change as you change the CoM by adding and removing thrusters, and could explain at least some of the odd behavior that you're seeing (not that there might not be some weirdness anyway). I'd recommend putting a thruster in every location that can have a thruster and disabling all but the one you're testing.
If I'm following correctly, the further the vertical distance, the lower the rotational force. That would make sense if Eleon is calculating a single rotation vector around the centre of mass and then projecting that circle onto the various 2D planes. *edit* Nope. My hypothesis is wrong. I'll leave it spoiled for posterity. The size of the plate would change since the total distance is changing so the acceleration should vary a bit, but not what you're seeing. Spoiler Put a dot on a table and place a plate centred on it. The distance from the dot to the edge of the plate is the rotational force when the thruster is on the same plane as the centre of mass. Now tilt the plate by raising one corner 45 degrees, but keep the plate centred on the dot. That's the shape of the rotation vector is the thruster is up off the plane of the centre of mass. Note how much closer the edge of the plate is to the dot if you drop straight down from the edge of the plate. That's the new rotational force. The rest of the force should go to help pitch/yaw.
Jinx! I was just trying that. In these two pics the first shows an on state thruster in the yaw plane giving 14 deg/sec and deactivating that one and activating the one that's directly above it yields 14 deg/sec yaw and 14.6 deg/sec pitch (the "new" moment arm) .. guessing the additional 0.6 in pitch is coming from the +half-block of height above the yaw plane since the "keel" of the test platform is 1x2 vs 2x2. So the issue appears to go away if the mass distribution doesn't change and all you do is light the engine under test-
There's something wrong with the yaw torque, as it shouldn't change when you change between those two thrusters (because the perpendicular moment arm doesn't change).
It didn't, yaw reads +14 deg/sec in both .. the only change was the addition of pitch moment but I think they have the rate in the wrong text widget- it's displays 14.6 in pitch as acceleration and a zero in the rate. I misread it when I typed above.
I was referring to the yaw torque, which is different between the two cases. The angular speeds are meaningless for debug purposes because it's entirely unclear how they're being calculated; probably there's some kind of angular-acceleration-limited nonsense going on . . .
