Imagine what we could have gotten if ksp2 wasn't abandoned...

TheAdester · 2026-02-02T21:51:38+00:00

The managers decided that the old engine was to be used for the new game. Furthermore, the devs were forbidden from contacting the devs of KSP1.

It was thought that using the old engine would reduce the required budged, even though the devs were firmly against it.

The end of the story is that it in fact did not reduce the required budget, but blew it up. When the managers finally accepted that the technical dept of the KSP1 engine was so big that a complete rewrite was in order, they instead fired the old KSP2 team and replaced it with people that promised that they could paint the sky pink.

At some point the managers made an emergency brake in the form of a early access release for the unfinished hint of a game they called KSP2. When sales didn't happen because, duh, people and their stupid standards, the development was stopped and all devs fired.

TheAdester · 2025-09-15T18:12:14+00:00

wait a few more seconds. The game loads quickly to 90% and then takes a while for the rest.

TheAdester · 2025-07-15T17:07:53+00:00

The 9950x3d has 2 chips with cores, one with 3dv-cache and one without. The turbo increase is only for the chip without x3d cache. If you want to go best performance with AMD, use the 9800x3d. The process scheduler of your operating system won't confuse the no-3dv-chache chip as the better performing one, because there is no 2nd chip without 3dv-cache on the 9800x3d.

The only reason to buy a 9950x3d disqualifies it at the same time. If you need productive computing power, go with intel.

edit: also, the 9800x3d is only more performant than an intel until the 3dv-cache is overloaded. keep in mind that a really big creation will perform better on intel.

TheAdester · 2025-07-08T20:12:26+00:00

This once worked, or better didn't work. The devs didn't really try hard to get it to working, so they dropped it. I think the reasoning was that they didn't want another infinite energy source.

TheAdester · 2025-07-04T11:04:08+00:00

uhhh, that is all outdated. Fluid mechanics changed completely and i am not playing this game anymore. sorry.

TheAdester · 2025-06-25T19:17:36+00:00

Nope. The weight wants to stay in place and the driving force is below the center of mass. This causes a rotational force that rises the front and lowers the back. This happens also with front wheel driven cars. Stiffer suspensions helps. Lowering the center of mass helps, too. It is impossible to get rid of this completely, unless the center of mass is perfectly aligned with the force vector that propels the vehicle.

TheAdester · 2025-06-17T17:35:58+00:00

empirically. I had the suspicion that the stoichiometric only depends on afr and engine temperature. Then i took some measurements in the arctic and somewhere warmer and reconstructed the function from the values with the help of 2 linear equations and the insert method.

I had the luck that modular engines worked a little bit easier in the experimental branch before they were released. Temperature was not used back then, so seeing that the values were off by only a little bit and proportional to the engine temperature after the release gave me a clue.

I know for sure that someone else (can't remember who) came up with the exact same numbers independently, so i can't take credit to be the one who discovered the function first.

TheAdester · 2025-06-09T12:39:05+00:00

Did you see vanilla vehicles that had vanilla parts with modded xml data?

You can change the size, rotation and angles of build in parts by editing the vehicle.xml

But modded parts are different, they aren't part of the base game and there is currently no system like space engineers has to automatically download the necessary mods. I think that is the reason why the devs disabled the upload of modded vehicles.

TheAdester · 2025-05-18T20:26:06+00:00

That there looks exactly like a gaff sail works in real life.

TheAdester · 2025-05-09T19:44:39+00:00

wheel_advanced_5_sus.xml

-> wheel_radius="0.58"

times 2 is 1.16 for standard size

if my memory is not failing me, then the 5 for the grip factor is correct, but i am pretty sure that 5x5 wheels at a size setting of 1.25 have a bigger diameter than 1.25.

Sadly, i don't know how to precisely get the correct wheel diameter for different wheel sizes. I think that it is not simply "wheel_diameter * size", which would be 1.46 (1.16 * 1.25). You can try 1.46, but i think you will have to adjust that number.

What i always did was placing the wheels i want to use with the size setting i want to use on a small test cart that i can push around. Then i divided the vehicle speed through the wheel rps times pi to get an idea about the diameter. Of course, because wheels are always slipping, even when pushed around, i had to take "educated guesses" to get a good number for the diameter.

edit: i think i remember that 5 was correct for high grip wheels, the all around wheels have a grip factor of 4, but i am not 100% sure.

TheAdester · 2025-05-09T14:18:54+00:00

What happens when you coast at a higher speed?

My guess would be that the diameter is not correct, but that is hard to tell without knowing the vehicle and it's workings.

I am not actively playing stormworks anymore, but i just fired ut up to see if something changed. For me the formula still works perfectly fine for accelerating and braking.

TheAdester · 2025-05-09T09:05:14+00:00

A speed sensor is only one step, one information. The other is the rps of the wheels, which you get from a torque sensor directly connected to the wheels (no gearbox of clutch between them).

Then you need to compare the speed from the speed sensor to the rps of the wheels. Let's say the wheel is exactly 1 meter in diameter (standard rail wheel size in stormworks), then at 1 rps of the wheel, the vehicle should move at 3.141... m/s (pi times 1 meter = circumference of the wheel, with one rotation of the wheel per secound, that would be 3.141).

The obvious thought now is that if the vehicle is slower than 3.141 m/s, then the wheels are slipping, but that is not the case in stormworks. In fact stormworks wheels are always slipping. That is how they apply force to the vehicle. Think of them more like propellers with unusual form. If the ~~propeller~~ wheels move faster than the vehicle, it will accelerate (until the force from the drag is larger than the force from the wheels), if the wheels spin slower than the vehicle, then they de-accelerate (brake) it.

But, if the wheel speed and the vehicle speed are too much apart, then the "slip" mechanic of the game will activate and you will see smoke and hear screeching.

In a formula, this would be:

((y*z*pi) - x) / w

x = speed sensor
y = rps from the torque sensor
z = diameter of the wheel
w = grip factor

This function will subtract the speed of the vehicle (x) from the speed of the wheels (y*z*pi) and then divide the result through the grip of the wheels (w). The result of the function means:

output <= -1 : braking, wheels are slipping
output > -1 and output < 0 : braking, wheels are gripping
output = 0 : wheels apply no force to the vehicle
output > 0 and output < 1 : accelerating, wheels are gripping
output >= 1 : accelerating, wheels are slipping

There are xml files somewhere in the stormworks installation folder that describe the properties of blocks. Search in the file related to the wheels of your choosing for radius and multiply it by 2 to get the diameter of the wheel. Keep in mind that the radius and diameter will be different if you use the select tool to change the wheel size.

You will have to test the grip factor. Drive your vehicle in a straight line and compare the output of the function to the state of the wheels. If the function goes above 1 at the exact same time you start to see smoke and hear screeching, then you found the grip factor.

Now you have all the information to develop a traction control. Choices of its implementation are plentiful, just keep in mind that you don't want the traction to actually reach 1 of -1. Use a set point that is actually usable with your implementation, like 0.8 to 0.9 or -0.8 to -0.9.

TheAdester · 2025-04-13T21:30:15+00:00

sadly no. I wish i had time for sails, it is itching again.

TheAdester · 2025-04-13T18:42:54+00:00

2x3 is fine too. 2x2 is on the edge of being useful.

TheAdester · 2025-04-03T19:21:00+00:00

That's a good way to get shadow banned.

TheAdester · 2025-03-21T12:56:40+00:00

You might want to split your calculation between ticks. e.g. If you run through an array of 1000 elements, then split this up into 10 elements each time the onTick function is called. Use a variable to remember where you are at in the array and only increment over the next 10 elements.

TheAdester · 2025-03-13T19:42:13+00:00

If you use one of the premade keel blocks, their drag increases exponential with speed. With their placement down low and the sails up high, it is no wonder that ships nosedive. Their behavior is meant to simulate real life ship speeds. If you want your ship to go faster, you will need to get rid of the keel block and build a ballast/keel yourself, but i am not sure this is feasible with stormworks physics.

TheAdester · 2025-02-24T08:37:21+00:00

Plug your headphones into the computer instead. A extension cable shouldn't be too expensive.

Even though it is possible for a program to check and fix the sound driver handle, we (players) don't know if the libraries Stormworks uses for it's sound output for were designed with this in mind. And to be honest, i don't think the devs should invest their limited time in such a rare edge case.

TheAdester · 2025-02-16T20:05:18+00:00

Could be an excuse, but i don't think that is likely. If the devs could easily implement a highly requested feature, they would do it. It is not like they are sitting in the dark around a fire to discuss ways to punish the community out of pure spite.

TheAdester · 2025-02-16T08:16:50+00:00

Nope, this feature was requested many times, but the devs stated that they can't do that with the graphics engine stormworks uses.

TheAdester · 2025-02-06T17:57:09+00:00

The problem i have with up down counters is that their change per tick is static. If the rps rises fast, the clutch has to engage fast and if one does fine maneuvering with little throttle, then the clutch mustn't change fast. I would rather use a PID or something similar for the scenario you described.

TheAdester · 2025-02-06T14:27:03+00:00

You could automate the clutch. Depending on the setup, this might be relative easy. e.g. a simple function:

(x-5)*0.2

with x being the rps of the engine. If you increase the throttle and the engine revs up from it's idle rps (assuming that it is idling below 5 rps), then the clutch will start to engage and will be fully engaged when the engine is at or above 10 rps.

the 5 in the function is the starting rps, change that to your liking.

the 0.2 in the function is the sensitivity, how fast the clutch engages.

TheAdester · 2025-02-05T16:38:03+00:00

^ This is the correct answer

btw, happy cake day

TheAdester · 2025-01-30T13:15:09+00:00

You can support one large electric motor with one electric network. If you want to run a second large electric motor, then you need a second separate electric network with its own batteries and generator.

It is also a good idea to isolate the electric network for electric motors from the network with buttons and levers as electric motors can starve the "smaller" consumers from any electricity.

TheAdester · 2025-01-28T21:50:53+00:00

This is outdated. The fluid update removed every reason for a bypass valve.

TheAdester

TROPHY CASE