HB Stratos

We are literally trying to build a computer within the stock game. That is the purpose of this thread. That there is some code here stems from the fact that we do not fancy clicking 500 times for one KAL, only for KSP to not save it lol.

As the title says, I am trying to write a MM Patch that reduces the drag of the panel variant of the stock Flags. Their drag is simply ridiculous, almost rivalling a parachute. I have a patch that can successfully address all Flag Configs, but I cannot figure out how to affect the drag cube of the panel flags. They are part variants of the Flag of course, but their configs do not specify a change in drag cube, yet the behavior in game between a thin flag (no drag) and a panel flag (a lot of drag) is wildly different. Here's my MM patch. It works in that all requested changes are applied, but none of them actually change the drag behavior of the flags. How do I fix this? //@PART[flagPart*] { @maximum_drag = 0.01 @MODULE[ModulePartVariants] { @useMultipleDragCubes = true @VARIANT[*Panel] { @sizeGroup = nonStructural @attachRules = 0,1,0,0,1 } } }

Good solution for the issue of there not being able to be two dictionaries of the same name. Just makes it a little harder to make code to traverse through it. With dicts you can just do craft["parts"]["probe_core"]["Resource Electric Charge"]["Amount"] = 200 or similar tricks. You'd need a helper function to do it this readably with lists

These are craft files, not configs. By definition anything is stock that loads and functions in a completely unmodded game. And modifying craft files does load in any install of ksp just fine, so while this may be 'cheating' for a career playthrough, I see it as completely fair game to modify externally Having someone familiar with the game and how it works would be very helpful. Or even decompiled source code as it exists for minecraft. But that may not be possible here, I know how to mod parts, but not code sadly. Looks pretty good already! I tried to avoid lists, but kinda failed with that. How did you manage to make named lists?

I had assumed that they likely use the unity transform.Find() function, which would allow path traverse with e.g. spotlight_08/Lamp/spotlight, but it doesn't appear to work. With said path traverse ./Lamp should equal Lamp, but only the latter actually works. So I am not entirely sure which function behind the scenes is evaluating this https://nodachisoft.com/common/en/article/en000181/ https://docs.unity3d.com/ScriptReference/Transform.Find.html

I can't fully explain everything, but you can read up on the basics of what you can do with KAls on my kerbalX posts: https://kerbalx.com/HB_Stratos/Analog-Subtraction , https://kerbalx.com/HB_Stratos/Smoothed-State-Follower @Nazalassa by the way in my research of craft files I discovered something: Look at that movementTransformName... You can enter any transform there. So far I have gotten it to work with model, light_08 and spotlight. The first two make the entire spotlight move including it's base, while the last one only makes the light move without even moving the lamp (It's the spotlight you can pitch and yaw around). I am currently trying to find out which unity function they are using to parse that string, and then try to do path traverse so I can modify parts outside of the current part to move around. Would you have any ideas how any of this could work? MODULE { name = ModuleLight isEnabled = True isOn = True uiWriteLock = False disableColorPicker = False lightR = 0.875 lightG = 0.875 lightB = 0.875 castLight = True movementTransformName = Lamp isBlinking = False rotationAngle = 0 pitchAngle = -22 blinkRate = 1 stagingEnabled = True EVENTS {

Axis group "sensors" aren't really sensors. They are more like a keyboard, player input. Also because axis groups only respond to player input, and sadly don't respond to SAS and the like. If they did we'd have a real-world sensor right there. Also worth noting is that the update rate for Axis groups affecting a KAL appears to be different to that of a KAL updating another KAL, which leads to a flickering input if a KAL and an Axis group affect another KAL simultaneously. That sort of tick rate flickering is what I was theorizing that it could be used for some sort of sensor, though I don't know how yet. Another thing, there's this section in the KALs craft file: I wonder whether it would be possible to hack this somehow so that e.g. the position of a sensor would affect the play position of a KAL. sounds near impossible... but maaaaybe..

I have done some research on sensors. as far as I know I invented the impact sensor, and make some torpedos with explosion triggers with that. But actual sensors that are more than single use have this far proven to be near impossible. I haven't found a way yet to have something - anything in the environment influence the play position of a KAL. Some theories that come to mind would be that we have proven that breaking links is detectable, so maybe breaking a docking port and redocking would be resettable, but I doubt the KAL would gain the curves it lost back. So I guess we need to look deeper, perhaps abuse changing tick rates or KAL update rates somehow. I don't know how yet, but that's the best I can think of so far. All my other sensors have been using purely mechanical systems. for example my full auto spoilers don't need a single KAL to function.

Super cool stuff, love to see it. I think by now we have proven that a full computer is possible, and I'm excited to see how far we can go. I in the meantime have made progress on the parser. It still is very janky, in desperate need of a re-write. It will break on stuff like the panther engine where one engine with two same moduleEngines exist, but otherwise it appears to be working, if very ugly (unused code, unreadable code, outdated comments, etc) . Since it is so heavily WIP I will not throw it on github yet, but if you're interested in using it already and maybe helping me fix stuff, here it is:

Absolutely awesome work! I don't have much time rn, university exam season and all. but this is actually proving to be feasible. I was always wondering how a full loop of KALs would work. Usually there's the problem that a KAL cannot be disabled as when you set a KALs position from another KAL it skips around, never playing action groups. But in this case we can just have one single KAL that does actually play with a play speed above zero, essentially acting as our clock. And that one would be the only one allowed to use action groups to set a KAL playing or not for the bus to work. If that's not an option, the slightly messy workaround of having one KAL set the play speed of another KAL which is set to loop and will click an action group if play speed is increased would also work. A word of caution though, when playing with complex KAL mechanics on my 1k part concorde I have run into the issue of larger time skips causing issues with the averaging skipping around more. If we end up running into lag we may need to clock down the CPU beyond what the physics tick rate dropping would already do to ensure reliable function. Also, we cannot use axis groups as input, at least not without major filtering. Even when set to playing axis grouped KAL appear to be updating on a different clock cycle, therefore making the averaged output of that KAL and another one flutter between a real average and the value of the non-axis KAL. By the way, is your adder compatible with negative numbers with my method of just treating the middle of the play positon space as zero?

Yeah that's the plan.. sadly Sensors (except for a single use collision sensor) are outside the range of possibility for now, so a PID controller would not be possible not because it can't be coded with KALs, but because we don't have any real world data we can use as input

Yes, we are looking at making a computer out of KALs. if you want to look at the basic writeups I did of the underlying things we can do with KALs, look here: https://kerbalx.com/HB_Stratos/Analog-Subtraction , https://kerbalx.com/HB_Stratos/Smoothed-State-Follower also @Nazalassa I am currently writing a parser for .craft files in python that will output nested dictionaries similar what the python json.loads() does. Might be of use to combine with your script once it's done, then you don't have to copy-paste into craft files anymore.

Analog calculations will be fast and very KAL efficient, but as with real analog computers compounding errors will become a problem. This will be an issue for OP Codes and precise integer ops, but should be fine for most general purpose calculations. After all, this only runs on floats, and well floats even outside of KALs have their limits on precision. For OP Codes though we will need to have a stairstepped KAL to rule out any reading errors, cause if you're .1 off it doesn't matter much, but if you do ADD instead of POP STACK that will become a major issue.

KSP Community Fixes has already introduced multiple additional action groups for e.g Autostrutt on/off. Would it ever be considered to add something like being able to use servos as "sensors" by being able to assign a KAL's play position to the movement of a servo through the use of an axis group? (aka each servo spawns an axis group similar to how e.g. the pitch axis group works). This feels like it would just make so much sense to have, and would imo fit in line with the other additions of making things more automatable with action groups.

I don't think it is a major behavioral change to just make it behave as expected. A part copied from another part that was already placed is supposed to inherit all properties and settings from said previous part. How would it break mods that a copied part retains fuel flow being disabled if the same thing would be achieved by copying the part and re-disabling it manually? If your fear illegal states it could be implemented to only apply to parts where the player can toggle whether the fuel stored in it should be able to flow or not. But to even be able to reach an illegal state the part that was copied has to have been in an illegal state itself. If you fear for issues it could be disabled by default, but I feel the QOL improvement would be significant. I frequently build big craft and disable fuel tanks that are purely cosmetic to save on lag in the fuel flow calculation and to make the fuel counter show proper percentages. And it is very annoying to have to fix it every time after I copy something. And I often miss tanks as I expect tanks I copy to retain their settings, and not just loose one particular one while all others are retained. Actually thinking about the argument above, that parts should retain all properties of the part they were copied from, fairings should also retain their X-Sections when copied with alt-click. It would be immensely helpful for shaping plane fuselages from many fairings and I think it also makes sense. Currently you have to detach the fairing and leave it floating in the hangar, then ctrl-z to revert while keeping the detached fairing around. This seems like an annoying hack for what should just be a feature. Especially since some things about fairings like to break when using ctrl-z (colliders liked to just disappear or become solid inside especially in older versions) it would be nice to just copy fairings with their shells. And I don't think that would break anything else.

Hey Everyone! I believe I have found a bug that is caused by Waterfall (but also separately by RealPlume). I didn't want to copy paste, so here's a separate forum topic for it. Could any Devs have a look at this?

Hey Everyone! I believe I have found a bug that is caused by RealPlume (but also separately by Waterfall). I didn't want to copy paste, so here's a separate forum topic for it. Could any Devs have a look at this?

I'm posting this as a separate Topic as it separately applies to two different mods I tested, and I don't want to copy-paste the same issue twice when it may have the same root cause. The Issue: When Loading a Stock Craft into a KSP Game with EITHER Waterfall or Realplume loaded, Engine Enable/Disable Action Groups get lost. How it should be: how it ends up with either RealPlume or Waterfall: Probable Cause (guess) The issue does not appear to lie in the configs directly, doing a grep over all of the mod folders of Realplume and Waterfall with their respecive configs I could find no line that explicitly edits the Action groups or completely deletes ModuleEngines. They however all rename ModuleEngines to ModuleEnginesFX. This leads me to suspect that in that renaming KSP does not know how to handle a craft with such a module in place as it isn't the ModuleEngines it expected, and therefore it seems to miss every setting within the ModuleEngines that was not at default, or at least action groups. (I did not have the time to test for thrust limiters too.) I'd be curious to hear from the devs of the respective mods about what could be causing this and how it could be fixed, as I am not familiar with KSP modding in terms of C#, and only know a little bit about Module Manager patching. It would be cool to see this fixed, because this breaks functionality of vessels that are otherwise considered fully stock in their craft file and should work in an unmodded game. Investigation: (what lead me to my above conclusion)

I have a minor bug report that might be fixable. It has annoyed me a few times while e.g. building submarines that need a lot of ore in them: When copying a fuel tank with alt-click, the fuel flow enabled button is reset to on, no matter what state it was in previously. , would that be fixable with mods?

Class 1 Entry, 1318m It certainly stretches how much one should use the offset too, but at four parts and this height such measures are necessary

Entry for class 2, 26102m

Just pitching in to say maybe please don't fix this, or at least make it toggelable. I found a cool exploit using these to make a craft that has absolutely zero drag. it just falls through the atmosphere as if there was none

Entry for Class 3, 75635m

Some beautiful shots showing off the heatblur on real planes, and also the reason why I really want the blur to be worldspace. Just look at these trails left behind the planes, it just looks so cool. And it is possible to tell if an engine is on even if one can't look at it from the back. Some notes on the heat blur visible here: the blur behavior is interesting, expanding almost directly behind the engine then expanding way slower until it fades out way behind the plane. there's quite a lot of blurring and less distortion going on, presumably because of the velocity of the exhaust blurring things in camera. the interaction of the heatblur plume with the ground on pitch-up One can also see low pressure vapor clouds above the wings of the F-16 in high g maneuvers, any chance that we will see something like that in KSP2? Also on a similar note, any chance of wingtip vortices like this: First of all, more heatblur. Second of all, look at the wintip vortices forming, and their shadows on the ground. Such an interesting phenomena, though in ksp it brings the challenge of finding out where the wing tips are and when they should cause these vortices, given that a player can create a vessel of any shape and throw it at the physics simulation.

it really depends on what you want to do. Modders will somehow bodge a way in even if you don't provide one. But you can make it significantly easier. This can be through easily accessible modding API things, good documentation of said API, or even going as far as making a graphical in-game tool every somewhat knowledgeable player can use. The best compromise would probably be finding a way to publish your internal tools for creating these plumes. Like this a new editor doesn't have to be written and we get as much power as the devs themselves.