[Plugin] [0.22] OrbitalConstruction Redux 4.2.1 fork

[attosecond]

So I decided to tackle a couple of annoying issues with OrbitalConstruction, and I need some testers. If you try this out, please do let me know how it works for you. Changes made:

1) Streamlined spacedock identification and vessel mass calculation. Spacedock identification is now automatic--no more "scan for docks" button to click. Spacedocks that don't have enough RocketParts to build the dry mass (hull) of the vessel are not listed.

2) Updated the method for checking RocketParts availability. Previously, two docked vessels with warehouses (only one of which has a spacedock) could not both contribute their RocketParts during a construction event. Only the parts in the warehouse originally attached to the spacedock's vessel were detected and available. This limitation is now gone--multiple docked warehouses can act as one giant warehouse.

3) The assembly is now named OrbitalConstruction.dll instead of KerbalTestOne.dll.

4) Kerbals are automatically removed from a vessel before it is built at the spacedock. It just doesn't make sense to have Kerbals being built along with their craft.

5) Swiped the GUI (with a few tweaks) from Extraplanetary Launchpads, including the logic to require specific resources for building a vessel. The days of building fuel, monopropellant, etc out of RocketParts are gone. If you don't have the resources at your dock, don't worry! You can always build with empty tanks and send up some fuel (or whatever you're missing) later.

Anyone who wants to test this is welcome to try: download the dll here. Make sure you delete or rename KerbalTestOne.dll from your GameData\OrbitalConstruction Redux\Plugins folder, and then put the new dll in its place.

License: I'm following Interfect's lead on this one--this is public and free.

Source code available here: https://github.com/attosecond/OrbitalConstruction

I'll also update the Parts to 0.22 career mode compatibility at some point soon.

Source code at

Cheers,

attosecond

Edited October 31, 2013 by attosecond
major update available

[rottielover]

I'll grab the dll, not sure how much I can help, but I'll try

[Chaosratt]

If I may, you should speak with the Extraplanetary Launchpads guys. They've got a rather slick build interface rather than the teleport trick OC does. They might be able to assist you. I recall seeing in their thread a while back someone made up a DLL that tried to port this interface over to OC, but had little luck with OC's original dev in getting it implemented.

[attosecond]

That's an excellent suggestion, and right where I was heading. My plan is to try and clean up OC as much as I can w.r.t. stability and then leave it alone. What I really want to work on is a space-based version of the EL launch pad, and as soon as I feel like I've gotten this OC itch out of my system I'll do just that. Sure wish I knew how to use this Blender thing I just downloaded...

[attosecond]

I managed to clear up one of the nagging issues--with the old code if you had a large persistence file with lots of parts in it, the scan for spacedocks took forever. Also, in 0.22 it sometimes didn't come back with any results, even though I had two spacedocks floating around out there. As best I can tell, this behavior occurred because the scan function actually loaded each vessel in the FlightGlobals structure, checked over the parts, and then allowed them to unload automatically due to the large distance from the active vessel. The debug log seemed to indicate that my KAS-enabled ships on the Mun didn't like loading up, having the physics start, and unloading again in such rapid succession, and somehow the scan for spacedocks aborted when it got to these vessels.

I fixed the problem by doing the scan using the ProtoPartSnapshot class, which allows me to scan all vessels without loading a single one. Now my spacedocks show up every time I scan, without fail, and the scan is completed in a fraction of a second. A big improvement!

Now, the spacedock disintegrating if you switch to it using ][ after the new ship is teleported up is still an issue, and so far I can't figure out why it's happening. The Hyperedit code is a real joy to read...

I've put up a new version of OrbitalConstruction.dll with my dock scan fix. Please use this when testing, thanks! I also committed the code changes for this fix to Github.

[frizzank]

If I leave a ship on the launch pad with clamps, and switch to it from the runway, sometimes my ships explode. It may be a bug with KSP placing the ship and then moving it to the correct position, thats a guess but there it is.

[attosecond]

If I leave a ship on the launch pad with clamps, and switch to it from the runway, sometimes my ships explode. It may be a bug with KSP placing the ship and then moving it to the correct position, thats a guess but there it is.

Hmmm... I can't seem to replicate this, with or without a SpaceBuilt identifier on the ship sitting on the pad. How often does this happen? Can you send me .craft files for the vessels involved?

[attosecond]

The disintegrating spacedock bug has been fixed. A poorly placed Vessel.Unload() statement was to blame (my mistake). The source has been updated on Github and a new, faster, hopefully bug-free version is available for testing on Mediafire.

[bac9]

Nice work!

A small idea, though: is it possible to alter the logic of the vessel spawn in the orbit, creating them not in an arbitrary place away from the station, but on a certain transform contained in the space dock part?

This way, you can make a very fancy space dock part model (something like installations from Star Trek with empty space in the middle), in the middle of which your spaceships will naturally appear. Let me illustrate.

Think of a part like that as of something like a roof-less VAB where your craft will appear.

To avoid collisions with too small dock parts, additional check can be implemented: a part can not only include a spawn transform, but also a trigger collider that's used in a check against the dimensions of the craft. If the check is passed, craft is allowed to spawn, if not, well, make a smaller one or use a bigger dock.

[attosecond]

Working on this at this very moment, but it'll take a bit of time. When it's all said and done the final plugin will resemble Exoplanetary Launchpads more than Orbital Construction, both in form and function. I'm working on a final update to OC before I abandon it and start fresh. The last OC update will be to replace the GUI with a ExLaunchpads -style interface to require specific resources for construction. Once this is done, I'll start in on Orbital Manufacturing, the OC successor that will (hopefully) have user-specified vessel spawn location, no need for separate docks/identifier parts (GUI fires up from the dock vessel), and some nice whiz-bang dock parts to choose from. The last is a bit of an issue, since I know zip about modelling. I'll most likely have to recruit outside help to get the models made in anything under a few years.

[bac9]

Working on this at this very moment, but it'll take a bit of time. When it's all said and done the final plugin will resemble Exoplanetary Launchpads more than Orbital Construction, both in form and function. I'm working on a final update to OC before I abandon it and start fresh. The last OC update will be to replace the GUI with a ExLaunchpads -style interface to require specific resources for construction. Once this is done, I'll start in on Orbital Manufacturing, the OC successor that will (hopefully) have user-specified vessel spawn location, no need for separate docks/identifier parts (GUI fires up from the dock vessel), and some nice whiz-bang dock parts to choose from. The last is a bit of an issue, since I know zip about modelling. I'll most likely have to recruit outside help to get the models made in anything under a few years.

I can look into the modeling, shouldn't be too hard. It's not that big of a part set, I guess (containers, storage, differently sized assembly enclosures ranging from small 2.5m wide workshops to something like half a VAB).

Not sure how to handle large orbital docks though, as making one huge part you need to bring into orbit feels a bit cheaty. How about an implementation that supports not just one part, but multiple ones you should connect together in a certain way? Let's say there is a modestly sized core module, but it checks whether it has certain auxiliary parts connected to it if you want it to work. Component parts of the dock piece can have the docking port modules with a certain unique designation, and can be shaped in a way which prevents them from being docked from an unintended angle (kinda like ports on the PC), so it will be hard to assemble the whole thing in a wrong or cheaty way too (like slapping the parts randomly around some station).

Of course, you can assemble it in the editor and launch it together, if you can manage to build a vehicle capable of lifting the ridiculous full weight in one go (and if you don't play with FAR where lifting something shaped like that is not the brightest idea), but it would be fun to make preparations an interesting exercise in docking and delivery of various payloads.

Another, implementation of this would be to have core parts of a different radius which have some initial space they are certified to build within, and which you can expand in length by docking the additional modular pieces to the front of them. That's more simple to implement too, I guess. Attach a piece, get +20m to allowed length on the bounding box check.

Edited October 30, 2013 by bac9

[Railgunner2160]

Damn!! I can't speak for attosecond, but that would make the most badass Orbital Construction mod EVER!!!! Your work on the KSC & the B9 Aerospace pack is top notch, if you were the one to make models for this it would be epic!!!!

[attosecond]

I can look into the modeling, shouldn't be too hard. It's not that big of a part set, I guess (containers, storage, differently sized assembly enclosures ranging from small 2.5m wide workshops to something like half a VAB).

Not sure how to handle large orbital docks though, as making one huge part you need to bring into orbit feels a bit cheaty. How about an implementation that supports not just one part, but multiple ones you should connect together in a certain way? Let's say there is a modestly sized core module, but it checks whether it has certain auxiliary parts connected to it if you want it to work. Component parts of the dock piece can have the docking port modules with a certain unique designation, and can be shaped in a way which prevents them from being docked from an unintended angle (kinda like ports on the PC), so it will be hard to assemble the whole thing in a wrong or cheaty way too (like slapping the parts randomly around some station).

Of course, you can assemble it in the editor and launch it together, if you can manage to build a vehicle capable of lifting the ridiculous full weight in one go (and if you don't play with FAR where lifting something shaped like that is not the brightest idea), but it would be fun to make preparations an interesting exercise in docking and delivery of various payloads.

Another, implementation of this would be to have core parts of a different radius which have some initial space they are certified to build within, and which you can expand in length by docking the additional modular pieces to the front of them. That's more simple to implement too, I guess. Attach a piece, get +20m to allowed length on the bounding box check.

Both good ideas; I guess the best place to start would be with the simplest and work our way up. My thoughts on the simplest way to get going is to create two classes of manufacturing plant: a starter part that can be launched (with effort, of course, it should still be enormous, say 5m dia x 12m long in its launch configuration) into orbit and which will only be capable of constructing parts for the large modular manufacturing center. No general-purpose construction will be allowed with the smaller dock. I also had an idea for the longer-term, and I'm not really sure if it can be done, but it's fun to think about: a procedural orbital dock. DYJ's code for the procedural wings is not too complex (could use more comments, but then so could mine). For this system, we could add a "Grow Dock" button to the context menu, and provided enough resources are available the dock would expand itself to the next size up. Come to think of it, procedural parts aren't even needed here: just a set of different sized dock parts, only the smallest of which is launch-able. Click "grow," and the dock will replace itself with the next available size. The largest size, of course, can still be expanded using additional pieces a la your ideas, above.

My starting point will be to take ExLaunchpad's interface and rework the build/launch code to incorporate the appropriate transform to build a set distance from the dock (say, 5m) in the correct orientation (VAB craft are easy, SPH not so simple). I'll then tackle the trigger collider, and finally work on logic for a modular system. Before any of this, I want to get my current OC update polished off (another day or two, depending on free time). I'll set up a repository for the project and send you a link. Can't wait to get this working!

[bac9]

Sounds good, it's reasonable to start with just one type. Regarding the implementation, though, I don't think it's a good idea to hardcode the position as something like "5m from the dock" - just require an empty game object to be present in the part from which the coords and rotation are used for spawning the craft (let's say, with Z as up).

Great idea about making it possible to perform upgrades right through the initial dock, although I think that takes out the fun and challenge of lifting and docking them. Easier to implement, though.

As about VAB/SPH crafts, there should be zero difference between them as both are using identical axis as "up" in their craft formats, if I recall correctly. Only thing unique to aircraft is the use of bound colliders for the landing gear which should be irrelevant in space as there is no runway to fall onto.

Edited October 30, 2013 by bac9

[attosecond]

The trouble with SPH craft (and some stranger VAB craft I've built) is that "up" is not necessarily the same as the pointy end, if there even is a pointy end. Some logic is needed to determine how to best orient the craft within the dock. Grabbing orbit info from a fixed empty game object sounds deceptively simple. Let's see what happens when I code it...

[sharpspoonful]

I can look into the modeling, shouldn't be too hard. It's not that big of a part set, I guess (containers, storage, differently sized assembly enclosures ranging from small 2.5m wide workshops to something like half a VAB).

Not sure how to handle large orbital docks though, as making one huge part you need to bring into orbit feels a bit cheaty. How about an implementation that supports not just one part, but multiple ones you should connect together in a certain way? Let's say there is a modestly sized core module, but it checks whether it has certain auxiliary parts connected to it if you want it to work. Component parts of the dock piece can have the docking port modules with a certain unique designation, and can be shaped in a way which prevents them from being docked from an unintended angle (kinda like ports on the PC), so it will be hard to assemble the whole thing in a wrong or cheaty way too (like slapping the parts randomly around some station).

Of course, you can assemble it in the editor and launch it together, if you can manage to build a vehicle capable of lifting the ridiculous full weight in one go (and if you don't play with FAR where lifting something shaped like that is not the brightest idea), but it would be fun to make preparations an interesting exercise in docking and delivery of various payloads.

<img snip!>

Another, implementation of this would be to have core parts of a different radius which have some initial space they are certified to build within, and which you can expand in length by docking the additional modular pieces to the front of them. That's more simple to implement too, I guess. Attach a piece, get +20m to allowed length on the bounding box check.

<img snip!>

While excellent suggestions, the second idea constrains you to size limitations. What if I want to build something outside of three meters wide or five meters in height? Then neither of those structures would work. Or I want to fabricate a station in-situ? Then this becomes an issue. Why not something along the lines of starting with a functional core, but to build larger ships you need to shuttle Spare Parts to orbital dry dock to expand it? That way, you have to build that and man it and maintain it before you can build monstrosities, and it falls inline with how the mod has worked in the past.

The trouble with SPH craft (and some stranger VAB craft I've built) is that "up" is not necessarily the same as the pointy end, if there even is a pointy end. Some logic is needed to determine how to best orient the craft within the dock. Grabbing orbit info from a fixed empty game object sounds deceptively simple. Let's see what happens when I code it...

To solve this, why not add a indicator part to tell the OD which end is forward?

Edited October 30, 2013 by sharpspoonful

[bac9]

While excellent suggestions, the second idea constrains you to size limitations. What if I want to build something outside of three meters wide or five meters in height? Then neither of those structures would work. Or I want to fabricate a station in-situ? Then this becomes an issue.

Not really, you just have a core part defining the allowed radius from the central axis and subsequent attachments that increase the allowed length of a craft. Last assembly core diameter can be quite roomy, so I don't see any issues with large crafts here.

Why not something along the lines of starting with a functional core, but to build larger ships you need to shuttle Spare Parts to orbital dry dock to expand it? That way, you have to build that and man it and maintain it before you can build monstrosities, and it falls inline with how the mod has worked in the past.

As I've said above, making a dock one single part that can be upgraded with the parts is the easiest implementation, but it's not very beneficial to the game. There already isn't much to do in the game, so reducing space dock management to delivering completely identical part containers countless times, just like with ship components, is not a very interesting solution. It's best when a system in the game delivers some varied and interesting challenges, which, in this case, would be do design, launch and dock the payloads with the space station components of varied shape and size, - that will occupy the players nicely, making a large operational orbital dock a very satisfying achievement in itself.

Speaking of which, I don't think spacecraft construction should be necessarily done with just one resource. Artificially inflating the micromanagement by introducing several faceless types of resources like metal and ceramics is unnecessary, but there are several logical improvements that can be done there: for example, all crafts assembled in the orbit should start with no fuel (and should remove appropriate amount of fuel from the dock to fill them, if the dock has fuel tanks attached) and no crew, which will serve as another interesting opportunity to build service ships like crew delivery vehicles (like efficient spaceplanes) and fuel tankers.

Essentially, orbital construction is the opportunity to give players lots of interesting activities and reasons to design cool crafts - it shouldn't be HyperEdit in a disguise.

Edited October 30, 2013 by bac9

[attosecond]

Speaking of which, I don't think spacecraft construction can be necessarily done with just one resource. There are several logical improvements that can be done there: for example, all crafts assembled in the orbit should start with no fuel (or should remove appropriate amount of fuel from the dock, if it has the fuel storage) and no crew, which will serve as another interesting opportunity to build service ships like crew delivery vehicles (like efficient spaceplanes) and fuel tankers.

This is the reason I'm starting with the ExLaunchpads interface, since it does just that--all pumpable resources must be present in the dock vessel in order for the new vessel to be built. You can choose how much of each resource to include in the build, if you don't happen to have enough. All non-pumpable items (usually just the dry mass, unless someone's using some strange mod) are built from RocketParts. The update to OC that I'm banging out right now includes this functionality and strips the vessel of any Kerbals, since it doesn't make sense to have Kerbals built along with their vessel.

[bac9]

Ha, great to hear it's in there so soon. )

[Ryugi]

I'm stalking this mod with great interest.

I like to run a technologically advanced, but largely ignorant of their system due to past conflicts, Space Program, and this sort of thing is right up my alley since I already use Orbital Construction to rid myself of some laggy crash issues with launches since I run a lower-end system.

The fact that B9 is poking around and dropping sketches only makes me more excited.

[sumghai]

I'll definitely be watching this thread closely, especially as the Karmony Warehouse Module I design is specifically used for holding supplies used in orbital drydocks.

I also have a Kirs Docking Module that could be used as the starting point for the drydock "core" bac9 described - obviously, there will need to be some models for the expanding bounding box.

[attosecond]

Back to what this thread is about, I've finished my final changes to OC. Please give it a whirl and let me know if you have any issues. Here's the download: http://www./?yxu2kirmdmeyedf.

I'm updating my original post to list changes/improvements.

[Blaylock1988]

Back to what this thread is about, I've finished my final changes to OC. Please give it a whirl and let me know if you have any issues. Here's the download: http://www./?yxu2kirmdmeyedf.

I'm updating my original post to list changes/improvements.

Oh this looks fantastic!

[attosecond]

The new OC is released: http://forum.kerbalspaceprogram.com/threads/56140-0-22-Orbital-Construction-Re-Redux. Time to move on to the Orbital Manufacturing we've been discussing.