jcramb

The point I was trying to make is that software being used on spacecraft is most likely going to be in machine code and not interpreted on the fly. In which case the program has been compiled, probably with efforts to optimise and reduce the size of the resulting binary. Due to this it is not realistic to have a byte limit on the source code, but rather it should be a byte limit on the machine code. You would only need the most very basic of parsers to achieve a simulation of this compared to just counting the byte size of the source file. Compared to what other mods are computing performance wise, there should be absolutely no reason why kOS should be technically limited regarding speed or RAM usage. At 100k or even 10MB (which is a ridiculous number of programs) it is extremely unlikely to be the mod responsible for ksp hitting the dreaded 3.5GB limit. That is more attributed to textures / models which take up far more space. Concerning performance, well kOS only runs 5 clock cycles a second which even if you considered an overhead of 100,000 actual cpu cycles to compute that one simulated cycle (a generous amount) then even on the very slowest of computers its only using 0.01% of the cpu. So in other words, any limitations on kOS are pretty much by design and not due to any feasible technical limitation on computing power / memory.

This mod just NUKED my entire GameData folder and i've lost the entire mod setup I had configured... so I am a little hesitant to trust it with my game now. Cool idea in theory though.

You need to write the code to execute the node, ie. lock steering to node and calculate the time required for the burn, then commence the burn half of that time before the node.

Hi all! I am new to the thread but am reading through the kOS source (its an awesome mod ) and will submit pull requests soon after to help with dev. Regarding program size limit I have the viewpoint that a fixed byte limit is not realistic for a number of reasons. The main one being that the byte limit should apply to a compiled program, not one written in an interpreted language. This would mean that the size limit would not penalise developers for using comments or more verbose code structures for clarity. Ideally, kOS should have an assembler but I understand that it is designed for the general ksp public. With a fixed limit it is also hard to show the advancement of technology in kOS. Ideally there would be multiple script control parts with a range of drive space / clock rate parameters. Then the low space, slower components could be a status symbol of hard mode early day automation, leading to the more advanced / accurate systems required for more complicated interplanetary trips. Steven's suggestion above sounds like a good interim idea though, counting tokens (but not comments) rather then byte size.