HB Stratos

This is very awesome! Sorry, I've gotten kinda swamped up in other projects, but this is still awesome to see, even if I don't play too much KSP at the moment. There's a lot of potential here.

about 5000kb, so 5mb? The biggest craft on KerbalX is currently ~15mb (https://kerbalx.com/HolidayTheLeek/Aqua-sama) so I think we should be good. It will just take ages to load. I think KALs also run on update(), not on fixedUpdate(), which is to say they run with every frame you see on screen, not every physics frame. This can actually cause issues with using axis groups as input as they update with fixedUpdate(). See this bug report I wrote for KSPCF: https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/129 Other than that, cool to see you still working on this. I haven't really checked in here much as I am working on finishing my concorde when I play ksp, and on university when I don't.

Looks awesome! I definitely need this tool now, to figure out what the heck might be broken in a craft file I am dealing with. Is it somehow possible to make it draw a craft tree where it displays which part is attached to what and with what means it is attached?

That is absolutely awesome! Great job! I really have to look into writing scripts for your interface. something like a fairing smoother that just adds more sections for example. Or a single click add negative amount of ore to part to make it lighter (while ideally having precautions to avoid negative weight parts), A search would also be awesome, especially one that also allows ingame part names, not file names. So many ideas.

I don't have much time rn, but I'm glad to see your progress! Looks really good, absolutely solid work! for a simple program registers and rom might be enough. Ram though, yeah your method might be the only one available so far. Optimizing the amount of KALs for R/W or perhaps multiplexing may be an idea.

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?