[1.1.2] Orbital Utility Vehicle v1.2.4

[linuxgurugamer]

What would you think about the following idea for nuclear engines in general, and specifically for this mod:

1. Nukes generate heat which is dispersed by the propellant as it is propelled out
2. The amount of heat generated is equal to the amount of thrust in units
3. Each unit of heat requires X seconds of a lower thrust level to disperse the excess heat.  The lower thrust level has to be within 10% of the current thrust level
4. If an engine is shut down when the amount of units of heat is >10% of the max possible units of heat, the engine will start to get hotter (out-of-control nuclear reaction), at a rate of 1 unit of heat per second.
5. If an engine gets too hot, it explodes.

Example, assuming that X above = 1:

1. Engine is capable of 30 units of thrust.
2. Engine has been brought up to full throttle, engine now has 30 units of heat
3. Reduce throttle by 10%, leave it there for 3 seconds, engine now has 27 units of heat.
4. Reduce another 10%, to 80%, leave it there for 3 seconds, engine now has 24 units of heat
5. etc.

And, pulling in from the quoted section below, a tug would need to have a way to kill thrust without shutting down the engine

6 minutes ago, DStaal said:

How much cooling would depend on the size of the nuclear core, and it's temperature.  Those would have direct relationships to the max thrust of the engine (the reason for my flippant comment - if max thrust isn't keeping your core at a stable temp, your core is to large for the rest of your engine), and to the ISP of the engine, respectively.  Ideal shutdown would be to damp the core and reduce flow as Starwaster commented of course - but especially for a tug you might want the ability to crash-shutdown the engine or to keep it warm and ready to thrust on a moment's notice.  (And on a full dirty engine you might just dump the core on shutdown - leaving you to only have to deal with cooling the housing.)

All that said - take a look at how NFE handles this, as it (and Kerbal Atomics) have an implementation of it already - though it's notoriously prone to issues with the KSP heat system.

You necro'd me, but tell me what you think about what I wrote

Edited June 19, 2019 by linuxgurugamer

[Starwaster]

17 minutes ago, linuxgurugamer said:

What would you think about the following idea for nuclear engines in general, and specifically for this mod:

1. Nukes generate heat which is dispersed by the propellant as it is propelled out
2. The amount of heat generated is equal to the amount of thrust in units
3. Each unit of heat requires X seconds of a lower thrust level to disperse the excess heat.  The lower thrust level has to be within 10% of the current thrust level
4. If an engine is shut down when the amount of units of heat is >10% of the max possible units of heat, the engine will start to get hotter (out-of-control nuclear reaction), at a rate of 1 unit of heat per second.
5. If an engine gets too hot, it explodes.

 

I think maybe you're complicating parts of this for yourself more than they need to be.

Yes you can assume that generated heat is removed but all you really need is to consider the net result and use the stock engine module to produce the net amount of heat. I would pick an actual design to use as a model, maybe a scaled down Pewee 2. From that you can find the thermal output of the reactor and its operating temperature while at thrust. (for engines of this size something like the 67 kN LUNOX engines would be comparable)

It probably wouldn't explode outright if it overheated as you describe but it would at worst crack the core rendering the engine inoperable. (take that with the caveat there must be some circumstance under which NTR could explode since they simulated just such an explosion with Kiwi-TNT - one of the early nuclear rockets that they rigged to explode out in the desert)

[DStaal]

The part that sticks out to me is the 'cool down this way or it heats further' - I would think in most cases (especially for an engine) you could damp the reactor pretty quickly, so it wouldn't *generate* more heat.  (Though it would be very hot at that point.)  Depending on the design, you may be able to extract the heat without using propellant, and even without proper cooling what you'd have is a normal meltdown - which on it's own wouldn't cause an explosion.  (Though it would cause catastrophic damage to the engine, making it unusable.)  The obvious worst-case safety mechanism for an atomic rocket engine is just to expel the nuclear core - the shell of the engine is still there, but you're not going to be doing any more burns.   Though maybe Kerbals prefer things that blow up.     You probably could shut down the propellant flow with the engine was still quite hot without danger of meltdown as well (almost certainly by 50%) - though what that heat would do to the *rest* of your ship which isn't designed to handle high temperatures isn't likely to be nice.

Though I'll admit I'm feeling a need to re-read the Atomic Rockets page on this...

http://www.projectrho.com/public_html/rocket/enginelist2.php#id--Nuclear_Thermal--Solid_Core

[linuxgurugamer]

11 minutes ago, DStaal said:

Though I'll admit I'm feeling a need to re-read the Atomic Rockets page on this...

http://www.projectrho.com/public_html/rocket/enginelist2.php#id--Nuclear_Thermal--Solid_Core

Yup, I had just finished reading that again.

I can agree with the damp down quickly, my thought was going to continue to use propellant to do the remaining cooldown.

[DStaal]

5 minutes ago, linuxgurugamer said:

I can agree with the damp down quickly, my thought was going to continue to use propellant to do the remaining cooldown. 

Which makes sense in a mass-efficiency way, but is locking yourself into one design paradigm, and I'm not sure the core would heat up to explosion if you didn't.  (Depending on design of the core, of course.)

Basically, the main advantage of that is that you don't need radiators on your ship, and you were already doing a thrust burn anyway.  You lose some ISP, but you aren't carrying dead weight which you only need for short periods.

On the other hand if you do need the radiators for something else - say you have a nuclear power plant for EC, or you're delivering a mining rig that will need suitable radiators as well - then the long cooldown is just making your burn calculation harder.  (And *much* harder in KSP, as none of the tools help with it.)

[linuxgurugamer]

I'm open to suggestions (and I will look at NFE this evening).

Essentially, I want the engines to be powerful for short periods of time, but not usable for long durations.  Not sure if this is possible at all, the other ideas I was thinking of were either a timer (autoshutdown after x seconds), or heat buildup to the point of explosions.  But the heat buildup doesn't make sense as described above, and an arbitrary timer needs to have some reason for it to require a shutdown.

[DStaal]

Most of that NFE can do, actually.  The one thing is the not usable for long durations - if you have the cooling, it would work even for long durations.  In a surface-based tug I could see putting in an engine you couldn't use full-out for long, knowing you'll want the short bursts of power - but I don't really see how that would work with a nuclear space engine.  Thrust is based on propellant/coolant flow, not the size of the reactor.

Hmm.  One idea: A low-ISP high-thrust mode that could be switched to.  If you need power for something in particular, you can dump more propellant in, but you can't heat it as effectively then.  If you really wanted to, that could over-cool the reactor and have it shut down the engine after a time period until it could heat up again. 

[LordMacragge]

32 minutes ago, linuxgurugamer said:

I'm open to suggestions (and I will look at NFE this evening).

Essentially, I want the engines to be powerful for short periods of time, but not usable for long durations.  Not sure if this is possible at all, the other ideas I was thinking of were either a timer (autoshutdown after x seconds), or heat buildup to the point of explosions.  But the heat buildup doesn't make sense as described above, and an arbitrary timer needs to have some reason for it to require a shutdown.

Make it so that it needs cooling.

[Starwaster]

21 minutes ago, DStaal said:

Most of that NFE can do, actually.  The one thing is the not usable for long durations - if you have the cooling, it would work even for long durations.  In a surface-based tug I could see putting in an engine you couldn't use full-out for long, knowing you'll want the short bursts of power - but I don't really see how that would work with a nuclear space engine.  Thrust is based on propellant/coolant flow, not the size of the reactor.

But it is based on the size of the reactor because greater propellant mass flow means you'll need more thermal output to heat up the propellant to the desired temperature which means a larger reactor.

• 7.5 klbf = 33.4 (rounded)
• 15 klbf = 66.7 kN
• 25 klbf = 111.1 kN

Edited June 19, 2019 by Starwaster

[DStaal]

5 minutes ago, Starwaster said:

But it is based on the size of the reactor because greater propellant mass flow means you'll need more thermal output to heat up the propellant to the desired temperature which means a larger reactor. 

Which means that the size of the reactor is based (indirectly) on the thrust, not that the the thrust is based on the size of the reactor.    (And really it's more coupled to the ISP - you could always expel cold propellant if you want.)

[Starwaster]

lol ok whatever then. 

[linuxgurugamer]

1 hour ago, LordMacragge said:

Make it so that it needs cooling.

Please read the discussion to understand the issues.  

 

2 hours ago, linuxgurugamer said:

an arbitrary timer needs to have some reason for it to require a shutdown.

This was my problem ^^^

1 hour ago, DStaal said:

Hmm.  One idea: A low-ISP high-thrust mode that could be switched to.  If you need power for something in particular, you can dump more propellant in, but you can't heat it as effectively then.  If you really wanted to, that could over-cool the reactor and have it shut down the engine after a time period until it could heat up again

and I think you just provided a reason for the shutdown!

[BaelRathLian]

10 hours ago, linuxgurugamer said:

 

 

Ummm, it's a tug, like a tugboat.  It doesn't need more power, just like a real tugboat doesn't need to be able to cross the ocean.  I don't think it needs to be tweakable.

The engines are reasonably powered for their size.  If you want to move more, add more engines

and, my thought is that the tug is only meant to be used for short periods of time, not for long burns, especially not long burns at full power.

 

I would assume they are solid core, and yes, the propellant would cool the core, but what if the core is  hotter than the propellant can cool?

 

  When I said tweakable I was talking about the SIZE of each part.  Larger or smaller etc.  Using the tweak anything mod.  As for the Tug boat analogy  Have you ever seen in person a tug boat?  I have.  You would not believe what those little boats can do.  I have seen just 2 of them push an aircraft carrier.  So being able to get back into orbit with this mod should not be a problem for the engines even if it is a slow climb. 

[linuxgurugamer]

31 minutes ago, BaelRathLian said:

  When I said tweakable I was talking about the SIZE of each part.  Larger or smaller etc.  Using the tweak anything mod.  As for the Tug boat analogy  Have you ever seen in person a tug boat?  I have.  You would not believe what those little boats can do.  I have seen just 2 of them push an aircraft carrier.  So being able to get back into orbit with this mod should not be a problem for the engines even if it is a slow climb. 

I understand, and I disagree.  Anything bigger than this isn't a tug, it's a complete vessel.

Think about your example of tug boats and an aircraft carrier.  The tugs aren't too much larger than those used for smaller things.  You don't need a lot of umph for a tug.

And, while a tug can tow an aircraft carrier, it is extremely slow;  I wouldn't expect a space tug to have orbital capability

Edited June 20, 2019 by linuxgurugamer

[zer0Kerbal]

12 hours ago, DStaal said:

Most of that NFE can do, actually.  The one thing is the not usable for long durations - if you have the cooling, it would work even for long durations.  In a surface-based tug I could see putting in an engine you couldn't use full-out for long, knowing you'll want the short bursts of power - but I don't really see how that would work with a nuclear space engine.  Thrust is based on propellant/coolant flow, not the size of the reactor.

Hmm.  One idea: A low-ISP high-thrust mode that could be switched to.  If you need power for something in particular, you can dump more propellant in, but you can't heat it as effectively then.  If you really wanted to, that could over-cool the reactor and have it shut down the engine after a time period until it could heat up again. 

 

10 hours ago, linuxgurugamer said:

Please read the discussion to understand the issues.  

 

This was my problem ^^^

and I think you just provided a reason for the shutdown!

afterburner - or different naval (and cavalry) approach - the old diesel subs (and all diesels) - when they needed extra oomph (WWII and so) the engineers would cut the diesel with whiskey (thin it out), and on land they would add napalm or even dissolved explosives. gave them 10-30 extra hp, but cut their MTBF in half, and sometimes just melted them.

Also remember, these are multimode engines, so when the LF runs out - it has MP to run on, and or to cool them down.

6 hours ago, linuxgurugamer said:

I understand, and I disagree.  Anything bigger than this isn't a tug, it's a complete vessel.

Think about your example of tug boats and an aircraft carrier.  The tugs aren't too much larger than those used for smaller things.  You don't need a lot of umph for a tug.

And, while a tug can tow an aircraft carrier, it is extremely slow;  I wouldn't expect a space tug to have orbital capability

agree. Tugs have torque. they are meant to be able to move really big things  albeit slowly. they aren't speedboats, and certainly not atmospheric.  Think of them as being low Thrust, but high TWR and ISP -  in vacuum. I am unable to at this moment to come up with a better way to explain.

The extended engineonArm allows for more leverage with the engines good gimbal. 

The biggest disadvantage to the OT is the lack of fuel capacity in my opinion, hence why they are yardbirds.

[zer0Kerbal]

got a little sidetracked attempting to recompile an old mod.

still got a little work done on OT. after get some sleep will ask a couple of questions then work on OT and push the changes.

KIS - think that should be made into an optional patch (default = off).

 

[linuxgurugamer]

@zer0Kerbal

I just noticed that the light on the Grappler Jr. is on all the time, regardless of whether the lights are on or not

 

[zer0Kerbal]

1 hour ago, linuxgurugamer said:

@zer0Kerbal

I just noticed that the light on the Grappler Jr. is on all the time, regardless of whether the lights are on or not

 

am working on OT right now - will look at it.

almost done merging in most of the patches.

Made KIS.cfg.OFF by default

Seems the Pod is missing the RCS module - added in separate patch to make sure is right.

working on merging the engine - the OT patches took the thrust from 40 and raised it to 50, and then you (rightly) lowered it to 29. Maybe put it back to 40? (leaving it at 29)

Am leaving all the additional nodes and the related B9 node switch in separate patch.

Will be pushing v.20 in the next 45 minutes. will attempt to drop by twitch later today if you are streaming.

 

[zer0Kerbal]

@linuxgurugamer v0.20 pushed. kindly verify the engines - since multiple patches (including your changes) were around.

will do the Interstellar version of the engine once the dust has settled on the original engineOnArm.

Changelog.txt

Spoiler

Change Log:

     STATUS:
        * OrbitalGrapplerJR: missing reaction wheel speed
        * OrbitalGrapplerJR: missing module[command]
        * OrbitalGrapplerJR: missing ModuleDataTransmitter
        * DronePod: missing reaction wheel speed
        * helperDrone: missing hibernationMultiplier (0.00125)
        * helperDrone: missing reaction wheel speed
        * OrbitalTugPod: missing RCS? model has ports for it.
        * OrbitalTugPod: missing RemoteTech patch?
        * engineOnArm: missing explosionPotential? (added but commented out)
        * —————————————————
        * [?] DronePod: looks like cameras on bow?
        * DroneCameras
        * [?] OrbitalTugPod: has four cameras on bow?
        * TugTopRightCamera TugTopLeftCamera TugLowerRightCamera TugLowerLeftCamera
        * —————————————————
        * DronePod has two additional lights - one on each hatch door
        * bottomLamp, topLamp
        * —————————————————
        * [WIP] OrbitalGrapplerJR: KAS winch
        * [WIP] OrbitalTugPod: KAS winch
        * [WIP]code cleanup and dusting
        * [WIP] spelling
        * [WIP] demolitionDroneTAC
        * [WIP] demolitionDroneKIS
        * [WIP] impactDrone
        * —————————————————
        * [DONE][BUG 0.12a] OrbitalTugPod: light adjusting only one thing (cabin) and not the spotlights
        * —————————————————
        * [DONE][NODES] all

VERSION 0.20
        * [D] OrbitalTugCore: move node adjustments from patch into part.cfg
        * [D] OrbitalTugCore: move OT_Cores.cfg patch into part.cfg
        * [D] OrbitalTugCore: add ModuleToggleCrossfeed
        * [D] OrbitalTugCore: add skinMaxTemp
        * [D] adaptorCarrier: move node adjustments from patch into part.cfg
        * [D] adaptorCarrier: move OT_Cores.cfg patch into part.cfg
        * [D] adaptorCarrier: add fx_gasBurst_white decouple (like Jr)
        * [D] adaptorCarrier: add sound_vent_large decouple (like Jr)
        * [D] adaptorCarrier: add ModuleToggleCrossfeed
        * [D] adaptorCarrier: add skinMaxTemp
        * [D] fwdAdaptor: move node adjustments from patch into part.cfg
        * [D] fwdAdaptor: move e OT_Cores.cfg patch into part.cfg
        * [D] fwdAdaptor: add fx_gasBurst_white decouple (like Jr)
        * [D] fwdAdaptor: add sound_vent_large decouple (like Jr)
        * [D] fwdAdaptor: add ModuleToggleCrossfeed
        * [D] fwdAdaptor: add skinMaxTemp
        * [D] OrbitalGrapplerJR: move node adjustments from patch into part.cfg
        * [D] OrbitalGrapplerJR: move OT_Command.cfg patch into part.cfg
        * [D] OrbitalGrapplerJR: ModuleStockLightColoredLencfg
        * [D] OrbitalGrapplerJR: add ModuleToggleCrossfeed
        * [D] OrbitalGrapplerJR: add showVesselNaming/SHOW_VESSEL_NAMING_IN_FLIGHT
        * [D] OrbitalGrapplerJR: add skinMaxTemp
        * [D] DronePod: move node adjustments from patch into part.cfg
        * [D] DronePod: move OT_Command.cfg patch into part.cfg
        * [D] DronePod: ModuleStockLightColoredLens patch into part.cfg
        * [D] DronePod: add ModuleToggleCrossfeed
        * [D] DronePod: add showVesselNaming/SHOW_VESSEL_NAMING_IN_FLIGHT
        * [D] DronePod: add skinMaxTemp
        * [D] helperDrone: move node adjustments from patch into part.cfg
        * [D] helperDrone: move OT_Command.cfg patch into part.cfg
        * [D] helperDrone: ModuleStockLightColoredLens patch into part.cfg
        * [D] helperDrone: increased range of internal antenna to 50/25km
        * [D] helperDrone: add fx_gasBurst_white decouple (like Jr)
        * [D] helperDrone: move RemoteTech patch from part to patch
        * [D] helperDrone: add showVesselNaming/SHOW_VESSEL_NAMING_IN_FLIGHT
        * [D] helperDrone: add skinMaxTemp
        * [D] OrbitalTugPod: move node adjustments from patch into part.cfg
        * [D] OrbitalTugPod: move OT_Command.cfg patch into part.cfg
        * [D] OrbitalTugPod: ModuleStockLightColoredLens patch into part.cfg
        * [D] OrbitalTugPod: added hibernation and hibernationMultiplier
        * [D] OrbitalTugPod: add ModuleToggleCrossfeed
        * [D] OrbitalTugPod: add showVesselNaming/SHOW_VESSEL_NAMING_IN_FLIGHT
        * [D] OrbitalTugPod: add skinMaxTemp
        * [D] engineOnArm: move node adjustments from patch into part.cfg
        * [D] engineOnArm: move OT_Engines.cfg patch into part.cfg
        * [D] engineOnArm: added 50 units of liquidFuel
        * [D] engineOnArm: add ModuleToggleCrossfeed
        * [D] engineOnArm: add skinMaxTemp
        * [D] engineOnArm: add explosionPotential
        * [Deleted] OT_Cores.cfg: all patches moved into part.cfgs.
        * [Deleted] OT_Command.cfg: all patches moved into part.cfgs.
        * [Deleted] OT_Engines.cfg: all patches moved into part.cfgs.
        * [Deleted] Changelog.txt: all patches moved into KerbalChangeLog.cfg.
        * [Deleted] Changelog_LeLeon: all patches moved into  KerbalChangeLog.cfg.
        * [Deleted] TugPatches and Extras folders
        * [Deleted] OrbitalTug-Drone-Tweak.cfg - Patch from @Starwaster - merged into parts
        * —————— BUG —————
        * [BUG 0.17a] OrbitalTugPod: erroneous extra light switch
        * [SWATTED][BUG 0.18a] OrbitalGrapplerJR: missing from parts list
        * [NEW][BUG 0.20a] OrbitalGrapplerJR: light stays on

    VERSION 0.19
        * MM_Nodes.cfg done.
        * Renaming file to reflect status.
        * Added original Nil2work release notes (below)
        * [ADD] demolitionDroneTAC
        * [ADD] demolitionDroneTWAC
        * [ADD] demolitionDroneKIS
        * [ADD] impactDrone
        * —————— BUG —————
        * [BUG 0.17a] OrbitalTugPod: erroneous extra light switch
        * [BUG 0.18a] OrbitalGrapplerJR: missing from parts list
        
    VERSION 0.18
        * [MM_CCK.cfg][v0.12]
        * file header/footer
        * add :FOR[], corrected typo and fixed spacing on tag
        * —————————————————
        * [MM_Command.cfg][v0.16]
        * [DONE] fixed ControlPoint patch (OrbitalTugPod,dronePod,helperDrone)
        * fixed ControlPoint patch - OrbitalGrapplerJR - add MODULE[COMMAND]
        * —————————————————
        * [][SPLIT] OrbitalGrapplerJR: into B9 groupings
        * [] OrbitalGrapplerJR: add cargoBayFloorNodes and switcher
        * [DONE][SPLIT] fwdAdapter: into B9 groupings
        * [DONE] fwdAdapter: add BayAftBkhdNodes and switcher
        * [DONE] fwdAdapter: add InnerBayWallNodes and switcher
        * [DONE] helperDrone: successful decouple when attached to keel node
        * [DONE][ADD] helperDrone: add decouple sound
        * DronePod: stackSymmetry needs work.
        * —————————————————
        * [ADD] demolitionDroneTAC
        *     [DONE][ADD] demolitionDroneTAC: name, description, cost, title, tags, mass
        *     [DONE][ADD] demolitionDroneTAC: inject modules
        *     [ADD] demolitionDroneTAC: weld mesh, adjust size, rotation
        * [ADD] demolitionDroneTWAC
        *     [DONE][ADD] demolitionDroneTWAC: name, description, cost, title, tags, mass
        *     [DONE][ADD] demolitionDroneTWAC: inject modules
        *     [ADD] demolitionDroneTWAC: weld mesh, adjust size, rotation
        * [ADD] demolitionDroneKIS
        *     [DONE][ADD] demolitionDroneKIS: name, description, cost, title, tags, mass
        *     [DONE][ADD] demolitionDroneKIS: inject modules
        *     [ADD] demolitionDroneKIS: weld mesh, adjust size, rotation
        * [ADD] impactDrone
        *     [DONE][ADD] impactDrone: name, description, cost, title, tags, mass
        *     [DONE][ADD] impactDrone: inject modules
        *     [ADD] impactDrone: weld mesh, adjust size, rotation
        * —————— BUG —————
        * [BUG 0.17a] OrbitalTugPod: erroneous extra light switch
        * [BUG 0.18a] OrbitalGrapplerJR: missing from parts list

    VERSION 0.17
        * [NEW] make patches more resilient and use ModuleManager best practices
        * [DONE][NEW][SPLIT] DronePod: into B9 groupings
        * [DONE][NEW] DronePod: add switcherDescription to B9PartSwitch modules
        * [DONE][NEW][SPLIT] OrbitalTugPod: into B9 groupings
        * [DONE][NEW] OrbitalTugPod: add switcherDescription to B9PartSwitch modules
        * [NEW][SPLIT] OrbitalGrapplerJR: into B9 groupings
        * [DONE][NEW] OrbitalGrapplerJR: add switcherDescription to B9PartSwitch modules
        * [NEW] OrbitalGrapplerJR: add cargoBayFloorNodes and switcher
        * [DONE][NEW] OrbitalTugCore: add switcherDescription to B9PartSwitch modules
        * [DONE][NEW] OrbitalTugCore: add aft/fwd fuselage nodes and switcher
        * [DONE][NODES]OrbitalTugCore
        * [DONE][NEW] engineOnArm: add switcherDescription to B9PartSwitch modules
        * [DONE][NEW] helperDrone: add switcherDescription to B9PartSwitch modules
        * [DONE][NEW][SPLIT] adaptorCarrier: into three B9 groupings
        * [DONE][NEW] adaptorCarrier: adjust stackSymmetry placement
        * [DONE][NEW] adaptorCarrier: @&node_stack -> @node_stack
        * [DONE][NEW] adaptorCarrier: add switcherDescription to B9PartSwitch modules
        * [NEW][SPLIT] fwdAdapter: into B9 groupings
        * [DONE][NEW] fwdAdapter: add switcherDescription to B9PartSwitch modules
        * [DONE][DONE][NEW] fwdAdapter: @&node_stack -> @node_stack
        * [NEW] fwdAdapter: add BayFwdBkhdNodes and switcher
        * [NEW] fwdAdapter: add BayAftBkhdNodes and switcher
        * [NEW] fwdAdapter: add InnerBayWallNodes and switcher
        * —————— BUG —————
        * [NEW][BUG 0.17a] OrbitalTugPod: erroneous extra light switch
        * [DONE][BUG 0.12a] OrbitalTugPod: light adjusting only one thing (cabin) and not the spotlights

    VERSION 0.16
        * [ADD] OrbitalGrapplerJR: add orientation switch to command module
        * [ADD] OrbitalTugPod: add orientation switch to command module
        * [ADD] DronePod: add orientation switch to command module
        * [ADD] engineOnArm: change to surfaceattachable
        * [ADD] engineOnArm: add 50units of LF or MP to engine(model has tanks)
        * [DONE][ADD] change internal references to match part names
        * [DONE][ADD] change internal reference to use Dorsal/Ventral references
        * [DONE][ADD] adaptorCarrier: add B9 SUBTYPE Helper Dock Only
        * [DONE][FIX] adaptorCarrier: frameMid -> frameOutMid
        * [DONE][ADD] ModuleManager requests :FOR[OrbitalTug] to be a good citizen
        * [DONE][FIX] DronePod: correct AftVent14 node orientation
        * [DONE]DronePod: rename nodes.
        * [NEW] move attachRules out to separate patch?
        * [DONE][FIX] OrbitalGrapplerJR: correct Lft/Rgt to Port/Stbd (was reversed)
        * [DONE][FIX] OrbitalGrapplerJR: correct Btm to Dors
        * [DONE][FIX] OrbitalGrapplerJR: adjust behindGrappler z axis
        * [DONE][FIX] OrbitalGrapplerJR: adjust behindGrappler node orientation
        * [DONE][ADD] OrbitalGrapplerJR: 120° degree nodes on CoG with proper symmetry
        * [DONE][NEW][BUG 0.16a] fwdAdapter: B9 unbalanced brace
        * [DONE] adaptorCarrier: adjust node location and orientation
        * [DONE] adaptorCarrier: rename nodes to reflect position
        * [DONE][NEW] fwdAdapter: add AftOut node to dorsal and ventral sides
        * [DONE] fwdAdapter: adjust node location and orientation
        * [DONE] fwdAdapter: rename nodes to reflect position
        * [WIP]code cleanup and dusting

    VERSION 0.15
        * moved FireSpitter fuel switch patch to resources.cfg (internal)
        * [DONE] engineOnArm: rename nodes
        * [DONE] helperDrone: Adjust B9PartSwitch to B/BT/T/0
        * [NEW] OrbitalTugPod: add MidAftTop and MidAftBottom (always on)
        * [DONE] OrbitalGrapplerJR: Nodes - 3/2/0 engine node; generic misc placement
        * [DONE] OrbitalGrapplerJR: Nodes - correct name vs placement
        * [DONE] OrbitalGrapplerJR: Nodes - remove symmetry (wheels)
        * [DONE] OrbitalGrapplerJR: Nodes - correct orientation for Lft nodes
        * [NEW][DONE] OrbitalGrapplerJR: Node - behindGrappler
        * [WIP] OrbitalGrapplerJR: Winch.
        * [NEW][BUG 15a][DONE] uneven brace.

    VERSION 0.14
        * [DONE][BUG][0.13a] adaptorCarrier: extra '=' removed
        * [DONE][BUG][0.13a] adaptorCarrier: extra '=' removed
        * [DONE] adaptorCarrier: adjusted Attachment node(s) placement
        * [DONE] adaptorCarrier: verified node orientation
        * [NEW][DONE] adaptorCarrier: added outside lower adapter nodes (4)
        * [NEW][DONE] adaptorCarrier: renamed nodes to reflect individual locations

    VERSION 0.13
        * [BUG][0.13a] adaptorCarrier: Error - Cannot parse value modifying command:
        * [BUG][0.13b] adaptorCarrier: Error - Cannot parse value modifying command:
        * [DONE] fwdAdaptor: adjusted Attachment node(s) placement
        * [DONE] fwdAdaptor: if B9PartSwitch installed, set up  node switch
        * [NEW] fwdAdaptor: add inside pole nodes
        * [DONE] adaptorCarrier: adjusted Attachment node(s) placement
        * [DONE] adaptorCarrier: if B9PartSwitch installed, set up  node switch
        * [NEW] adaptorCarrier: add inside pole nodes
        * [DONE] OrbitalTugPod: verified node orientation
        * [WIP][BUG 0.12a] OrbitalTugPod: light adjusting only one thing (cabin) and not the spotlights
        * [WIP] OrbitalTugPod: KAS Winch adjustments
        * [DONE][BUG 0.12a] dronePod: not showing up in editor ... missing 6 commas
        * [WIP] OrbitalGrapplerJR: KAS winch
        * [WIP] OrbitalGrapplerJR: Nodes - 3/2/0 engine node; generic misc placement
        * [WIP] OrbitalGrapplerJR:
        * [NEW] fwdAdapter: merge in separate patch to adjust node orientation
        * [NEW] adaptorCarrier: merge in separate patch to adjust node orientation

    VERSION 0.12    
        * [DONE] fwdAdaptor, adaptorCarrier: split into two
        * fwdAdaptor: adjusted Attachment node(s) placement
        * [WIP]fwdAdaptor: if B9PartSwitch installed, set up  node switch
        * adaptorCarrier: adjusted Attachment node(s) placement
        * [WIP]adaptorCarrier: if B9PartSwitch installed, set up  node switch
        * [DONE] OrbitalTugPod: adjusted Attachment node(s) placement
        * [BUG 0.12a] OrbitalTugPod: light adjusting only one thing (cabin) and not the spotlights
        * [WIP]OrbitalTugPod: KAS Winch adjustments
        * dronePod: adjusted Attachment node(s) placement
        * [BUG 0.12b] dronePod: not showing up in editor ... bringing out the can of RAID.
        * dronePod: Bill and Bob each had a nodeDazzler Glue Gun....
        * [NEW] OrbitalGrapplerJR: KAS winch
        * [NEW] OrbitalGrapplerJR: Nodes
        * [NEW] OrbitalGrapplerJR:

    VERSION 0.11        
        * initial beta
        * Removed bugs
        * TugCore: add attachment nodes
        * TugCore: if B9PartSwitch installed, set up 4/2/0 node switch
        * TugCore: change node size from 2 to 1 to match rest of parts
        * engineOnArm: Add Attachment nodes
        * engineOnArm: Correct attachRules to allow node attachment
        * engineOnArm: if B9PartSwitch installed, set up 3/1 node switch
        * engineOnArm: added stackSymmetry
        * helperDrone: Add Attachment nodes
        * helperDrone: Correct attachRules to allow node attachment
        * helperDrone: if B9PartSwitch installed, set up 2/1 node switch
        * DronePod: Add Attachment nodes
        * DronePod: Correct attachRules to allow node attachment
        * DronePod: if B9PartSwitch installed, set up 7/5/3/1 node switch
        * OrbitalTugPod: Add Attachment nodes
        * [DONE] OrbitalTugPod: Correct attachRules to allow node attachment
        * OrbitalTugPod: if B9PartSwitch installed, set up 7/5/3/1 node switch
        * [DONE] fwdAdaptor, adaptorCarrier: correct node orientation
        * [DONE] fwdAdaptor, adaptorCarrier: Correct attachRules to allow node attachment
        * [NEW] fwdAdaptor, adaptorCarrier: might need to split into two, if not merge
        * [NEW] fwdAdaptor, adaptorCarrier: add Attachment nodes
        * [NEW] fwdAdaptor, adaptorCarrier: if B9PartSwitch installed, set up  node switch
        * [NEW] OrbitalGrapplerJR: Add Attachment nodes
        * [NEW] OrbitalGrapplerJR: Correct attachRules to allow node attachment
        * [NEW] OrbitalGrapplerJR: if B9PartSwitch installed, set up  node switch

    VERSION 0.10
        * Initial Commit

Edited June 24, 2019 by zer0Kerbal
add spoiler changelog.

[zer0Kerbal]

was mistaken about RCS on pod. removed experimental patch.

should the DronePod / Helper have a RELAY or INTERNAL Antenna?  (have made it DronePod RELAY and helper INTERNAL)

 

Edited June 24, 2019 by zer0Kerbal

[zer0Kerbal]

quick update

Spoiler

1. [DONE][BUG 0.12a] OrbitalTugPod: light adjusting only one thing (cabin) and not the spotlights
2. [SWATTED][BUG 0.17a] OrbitalTugPod: erroneous extra light switch
3. [SWATTED][BUG 0.18a] OrbitalGrapplerJR: missing from parts list
4. [SWATTED][BUG 0.20a] OrbitalGrapplerJR: light stays on
5. [NEW][BUG 0.20b] Jeb convinced Bill to replace all the light switches with remotes, and now Jeb is running around with the WiFi switch and giggling like a maniac...
6. [ZAPPED][BUG 0.20b] caught Jeb. reinstalled the light switches.

next will be in about a week. Since nodes are done, will be focusing on other items. Once new release out, will flatten my git, and proceed from there. Making progress on the helper variations.

Edited June 25, 2019 by zer0Kerbal

[linuxgurugamer]

New beta available here:

https://github.com/linuxgurugamer/OrbitalTug/releases/tag/1.3.0.5

@zer0Kerbal Github has been updated

Note that this beta includes patches for 2 mods which have not yet been either released or updated.  No harm will happen, the patches just won't install.

Specifically:  the MM_KURS.cfg and the MM_BurstAtomicThrustModule.cfg

 

[zer0Kerbal]

@linuxgurugamer

[NEW] v 0.23 being pushed.

changelog;
 

Spoiler

	VERSION 0.23
		* [New] OVAWinch: added for future testing purposes, might keep
		* [D] demolitionDroneTAC: added patch +PART, welded (manual), and tested.
		* [D] demolitionDroneTAC: resized, reorinated, and repositioned
		* [D] demolitionDroneTWSA: added patch +PART, welded (manual), and tested.
		* [D] demolitionDroneTWSA: resized, reorinated, and repositioned 
		* [WIP] demolitionDroneKIS: resized, reorinated, and repositioned
		* [WIP] impactDrone: resized, reorinated, and repositioned
		* —————— BUG —————
		* [ZAPPED][BUG 0.23ab] Val painted the lights on the dronePod/Pod while repainting the white stripes
		* 

	VERSION 0.22
		* [WIP] demolitionDroneTAC: manual welding
		* [WIP] demolitionDroneTWSA: manual welding
		* [WIP] demolitionDroneKIS: manual welding
		* [WIP] impactDrone: : manual welding
		* [DONE] OrbitalGrapplerJR, DronePod, helperDrone, OrbitalTugPod: SHOW_VESSEL_NAMING_IN_FLIGHT is for settings.cfg not part.cfg
		* —————— BUG —————
		* [NEW][BUG 0.22a] OrbitalTugPod: Val forgot to paint the white stripe over the entire Pod. [B9PartSwitch white stripe issues]
		* [SWATTED][BUG 0.22b] DronePod has two additional lights - one on each hatch door; Removed DuctTape.

	VERSION 0.21
		* OrbitalGrapplerJR, DronePod, helperDrone, OrbitalTugPod: ModuleLight instead of ModuleStockLightColoredLens
		* —————— BUG —————
		* [SWATTED][BUG 0.17a] OrbitalTugPod: erroneous extra light switch
		* [SWATTED][BUG 0.18a] OrbitalGrapplerJR: missing from parts list
		* [SWATTED][BUG 0.20a] OrbitalGrapplerJR: light stays on
		* [ZAPPED][BUG 0.20b] * caught Jeb. reinstalled the light switch.

 

 

Current Status:

Spoiler

	STATUS:
		* [???] OrbitalGrapplerJR: should it have module[command]?
		* [???] OrbitalGrapplerJR: should it have ModuleDataTransmitter?
		* [???] OrbitalTugPod: should it have RemoteTech patch?
		* [???] engineOnArm: what should each items explosionPotential be set to?
		* —————————————————
		* [WIP] DronePod: looks like cameras on bow
		* name: DroneCameras
		* [WIP] OrbitalTugPod: has four cameras on bow
		* name: TugTopRightCamera TugTopLeftCamera TugLowerRightCamera TugLowerLeftCamera
		* —————————————————
		* [New] OVAWinch: added for future testing purposes, might keep
		* —————————————————
		* [WIP] OrbitalGrapplerJR: KAS winch
		* [WIP] OrbitalTugPod: KAS winch
		* [D] demolitionDroneTAC: as patch +PART
		* [D] demolitionDroneTWSA: as patch +PART
		* [WIP] demolitionDroneKIS: as patch +PART
		* [WIP] impactDrone: as patch +PART
		* —————————————————
		* [DONE][BUG 022a] OrbitalTugPod: light adjusting only one thing (cabin) and not the spotlights
		* [SWATTED][BUG 0.22b] DronePod has two additional lights - one on each hatch door; removed DuctTape.
		* [ZAPPED][BUG 0.23ab] Val covered the lights on the dronePod and the Pod while repainting the white stripes on the Pod.
		* —————————————————
		* [DONE][NODES] all
		* [WIP]code cleanup and dusting
		* [WIP] spelling

 

 

Some more development pics:

Spoiler

v 0.24 will be held until enough βeta testing done.

Edited July 1, 2019 by zer0Kerbal

[linuxgurugamer]

8 hours ago, zer0Kerbal said:

Some more development pics:

* [D] demolitionDroneTAC: as patch +PART

Take a look at Tac Self Destruct, may make sense to use the code?

Quote

[???] OrbitalGrapplerJR: should it have module[command]?
[???] OrbitalGrapplerJR: should it have ModuleDataTransmitter?

IMHO, no to both of these

Quote

* [???] OrbitalTugPod: should it have RemoteTech patch?

What does the patch do?  If the pod has MOduleDataTransmitter, then probably

Quote

[???] engineOnArm: what should each items explosionPotential be set to?

Leave it at 0.5 for now

 

I've merged the PR, and will be using it this evening when working on the Burst mod.  I think this has gotten good enough to be able to use in a game, so I'll probably start using it in my Shuttle Challenge stream (could have used it last night)

Also, I'm beginning to feel that we are nearly done.  Do you have any idea how much longer your changes & fixes are going to need?

[zer0Kerbal]

2 hours ago, linuxgurugamer said:

Take a look at Tac Self Destruct, may make sense to use the code? 

yes - the TAC and TWSA both :NEED[TAC] and use the code.  KIS will use the KIS code.

 

2 hours ago, linuxgurugamer said:

IMHO, no to both of these

Done.

2 hours ago, linuxgurugamer said:

What does the patch do?  If the pod has MOduleDataTransmitter, then probably

RT patch converts the antenna into RT antenna, :NEEDS[RemoteTech] - will include.

2 hours ago, linuxgurugamer said:

Leave it at 0.5 for now

Done. What about the rest of the parts? The new demolitionHelpers should be set at 0.5 or ?

2 hours ago, linuxgurugamer said:

I've merged the PR, and will be using it this evening when working on the Burst mod. 

Thank you. I should be in attendance.

2 hours ago, linuxgurugamer said:

I think this has gotten good enough to be able to use in a game, so I'll probably start using it in my Shuttle Challenge stream (could have used it last night)

Agree. It is, as far as I can tell, currently at a very solid place.

2 hours ago, linuxgurugamer said:

Also, I'm beginning to feel that we are nearly done.

Agree.

2 hours ago, linuxgurugamer said:

Do you have any idea how much longer your changes & fixes are going to need?

Mid to late July. KAS will take a good couple hours to get working. .I also want to go through the FS patches, then the B9 patches, then finally the Interstellar engine, finish the demolitionHelperKIS, the impactHelper (stretch). My opinion is now is all about QBB (QoL, Balance, and Bugs).

Am also pondering merging the TAC/TWSA demolitionHelper into one - same code, just different models - just merge the models so instead of 4 TAC or 4 TWSA models on the helper it would be 3 TAC + 1 TWSA model on the helper model.

Am pleased, but not satisfied with current state.

Query: (I will ask over at the MM thread): how to :NEED[partname]?

watch you later.