Craft Part Module/Parser

[O-Doc]

Hi All,

I've been thinking about writing some KSP modules for a few months now but, could not come up with a cool idea which had not already been done. Yeah, there's the alien invasion strategy game idea, think X-COM meets Kethane. But, that's a bit too much for a first mod.

So, I'm settling for something which I don't think has been done yet which very much aligns with my programming expertise. I'm a web developer and I use/debug/write parsers of tree structures for a living. I simply can't find one for KSP craft files.

Now, I could go on about how I spend most of my KSP time in the build interface and all the improvements I could make with modules built on the parser. However, first things first. Because I don't know a fraction of the inner guts of KSP and Unity like most devs here, I'm looking for input into the API.

Here's the basic concept of what I propose.

Layer One

Basic tree parser which would have a similar approach to reading and navigating the craft files as the DOM(Document Object Model) library. Construct the tree using a set of nodes with different nodes being either a craft, attribute, child object, etc. I would like to architect this with performance in mind.

I don't know how Squad reads crafts files but, I'm sure they haven't implemented anything like layer two.

Layer Two

Create an API wrapper using a builder pattern similar to the Sizzle Engine(CSS selectors) which jQuery uses. This would allow more on-the-fly programming for modules and if the performance of layer one is good then that could be used widely in-flight.

There's basically three pieces to this puzzle.

1. Definition of the craft file(if none exists create it as part of this project)
   
2. Definition of the programmatic tree structure for the craft file parser
   
3. Definition of the builder API(part selector engine) for mod developers
   

Like jQuery, this could be extended to a number of basic manipulations and event handling. That's something to consider for the future. Any input into this idea is most appreciated. Be gentle. I'm a complete noob at KSP modding and my expertise in Unity3D is basic at best.

The module concept?

Oh yeah. Have a new tab for the building interface with the craft tree structure in it. The craft is translucent in the editor with the selected part or, tree branch, as a solid part. In the interface have all the part/branch manipulation options available, such as, tweakables. Additional features may include having hooks for specific programming attached to that craft part. After the API is built the possibilities would be endless.

[O-Doc]

I'll take the liberty of using this space to insert API notes/rules and provide news/updates.

[Crater]

Are you thinking about this as an in-game tool, or separate app?

I ask because, if you're planning for something in-game, then you most likely don't want to work with craft files, but with the in-memory vessel objects that KSP is using to represent the already loaded and parsed vessel, which would mean that you'd need more of a tree walker than a parser, and I think from what you're saying, layer one is already implemented within the game, and you could get straight on to layer two?

[O-Doc]

The core would be a C# library for use ingame and external tool development.

Layer one would do two things, parse a craft file and parse the data from an ingame craft object. Judging from the files and the ingame performance, data handling is all flat and very basic. The idea would be to create a tree structure as a reference point(part of the builder pattern) and then, as part of layer two, create a new flat memory structure which would do a better job at accessing and manipulating the game objects.

It seems that the game object data access increases memory and processing requirements exponentially. I have a pretty clear architecture in mind to make that resource issue linear, using a psuedo hash table lookup routine that never recursively iterates through a loop. Rather, it would seeks to deduct value sets from the entire hash table instead of pathing through references and attribute comparisons to assemble the results.

[O-Doc]

...which would mean that you'd need more of a tree walker than a parser, and I think from what you're saying, layer one is already implemented within the game...

Other than Vessel.rootpart and Part.children what other tree walking options are available? The current API that I'm aware of seems less than, say, optimised.

[Crater]

I'm not disagreeing with what you're trying to achieve, I was just trying to point out that there is no craft file to read for a loaded vessel. While you are in the game, the only possible source for information about a craft is the in-memory game object. This is periodcally flushed to the persistence file (which is similar in layout to a .craft, but not quite the same), but your information source, which you will have to work from for any in-game operations will have to be walking the current tree and building your optimized data structures, not parsing .craft files.

[Faark]

I've read your posts multiple times but are still note sure what you are trying to re-invent. Who and how exactly would someone benefit from it? (Except you, since *something* would work in a way thats more familiar to yourself).

- You can't change part cfg's, VAB/SPH's craft files, or save games (.sfs's) without loosing compatibility.

- You can't improve ingame performance without re-recreating the game and it is good enough anyway.

- Load and save processes could be speed up a lot, but again thats barely sth a moder can do.

- You could invent a new way to build & load stock-compatible part modules, but i don't think that would be used a lot since thats not really a problem in KSP (though it does miss documentation, i have to admit).

[O-Doc]

I'm not disagreeing with what you're trying to achieve, I was just trying to point out that there is no craft file to read for a loaded vessel. While you are in the game, the only possible source for information about a craft is the in-memory game object. This is periodcally flushed to the persistence file (which is similar in layout to a .craft, but not quite the same), but your information source, which you will have to work from for any in-game operations will have to be walking the current tree and building your optimized data structures, not parsing .craft files.

Yes, that's my understanding too. The idea would be to know how to get to the part/s I'm looking for on the game object. For example, if I want to get all parts with a toggle module attached to a fuel tank and it is set to down position, I have to look up all the PartModules and cross reference them to the Parts. Expensive operation looping through recursive loops. Also, alot of programming each time you have to find something and call an event it it/them. Easier just to have a call findPart("name.FT400 > module.Toggle[position=down]").doSomething();

I've read your posts multiple times but are still note sure what you are trying to re-invent. Who and how exactly would someone benefit from it? (Except you, since *something* would work in a way thats more familiar to yourself).

- You can't change part cfg's, VAB/SPH's craft files, or save games (.sfs's) without loosing compatibility.

- You can't improve ingame performance without re-recreating the game and it is good enough anyway.

- Load and save processes could be speed up a lot, but again thats barely sth a moder can do.

- You could invent a new way to build & load stock-compatible part modules, but i don't think that would be used a lot since thats not really a problem in KSP (though it does miss documentation, i have to admit).

Agreed. I'm not looking to save craft files, just parse the file for external tools such as delta-v calculators. The idea is to parse the craft object ingame as well to perform operations defined on the fly. EG; change hotkey 2 to release all drogue chutes. The module idea comes from certain re-occurring frustrations that exist for me in the builder interface which could easily be solved with object manipulation on a side panel rather than having to click the object itself.

I spent yesterday right-clicking on objects over and over again both in the editor and ingame and not getting the properties menu up. It would have been a godsend to do something simple like command my vessel "extend all parts that can extend". Easy to do with both a find and command text box with something like this: "module.Extend", "position=extend"

Cheers for the questions.

[Faark]

For example, if I want to get all parts with a toggle module attached to a fuel tank and it is set to down position, I have to look up all the PartModules and cross reference them to the Parts. Expensive operation looping through recursive loops. Also, alot of programming each time you have to find something and call an event it it/them. Easier just to have a call findPart("name.FT400 > module.Toggle[position=down]").doSomething();

The c# code that does that could look like this:

foreach(var module in FlightGlobals.ActiveVessel.Parts
    .Where(part=>part.name=="FT400")
    .Select(part=>part.FindModulesImplementing<ModuleToggle>().FirstOrDefault())
    .Where(toggleModule=>module!=null && toggleModule.position == TogglePositions.Down))
{
    module.doSomething();
}

It is ofc a lot longer, since C# is a general purpose language, but shouldn't have notable performance issues. Running code like that on large vessels a bazillion times per frame wouldn't be a great idea, ofc, but i don't see a good way to improve that.

A nice ingame UI to do stuff could definitively be an improvement. I personally would prefer sth that would be easy to use and doesn't make me think about syntax or stuff like that. Guess it would just be something like a more powerful and more user friendly action group manager that can be used in flight as well.

There were/are a few action group managers, but their screens never looked user-friendly enough for me to give one of them a try.

[O-Doc]

Thanks for the code. That's very useful. The purpose of a syntax would mostly be about programmatically navigating a ship's parts on the fly. Given the state of the official wiki I'm not even sure how useful it would be to other module developer's needs. I can see a ton of uses for something like this.