Shadowmage

[WIP][1.7.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

Recommended Posts

16 minutes ago, RedParadize said:

@Shadowmage Now I see the source of confusion... I was trying with the HAB 1B. That one do not have its stored resource increase with inflation, same with the other HAB I tested.

From the HAB-B1 Config:

MODULE
{
	name = SSTUInflatable
	animationID = deploy
	deflationMult = 1
	inflatedCrew = 10
	deflatedCrew = 0
	inflationMass = 1.9905
	inflationCost = 1194
	resourceName = RocketParts
	inflated = false
	ANIMATIONDATA
	{
		ANIMATION
		{
			name = ST-HAB-B1-Deploy
		}
	}
}

Note the line that says 'deflationMult = 1' -- this states that it has zero reduction in volume when deflated.  So it appears to be working as the configs specify.

(I may have changed the regular HABs around so as to not shrink volume; all of their 'inflation' volume is for living space, and their resource containers' physical volumes can fit into the non-deployed model with lots of room to spare)

Edit: Also note in the part-config for that part, that the 'coreContainerIndex = -1' -- meaning volume updates from the 'core' model are disabled (it effectively has volume = 0).  All 'user configurable volume' in that part comes from the volume in the adapters.

Sorry, my previously posted example patch was likely in error -- it would work as intended on the CFG parts, but the HAB parts require a different setup.

 

I guess I should ask -- what exactly are you trying to do?  (e.g. what part names, what specific volume changes (from what, to what, on which resources), etc)

Edited by Shadowmage

Share this post


Link to post
Share on other sites

@RedParadize

Here is a patch to adjust ST-HAB-B1 'user configurable' volume and enable deploy/retract based compression of resources:

@SSTU_MODEL[ST-HAB-B1]
{
	%volume = (specify desired user-configurable volume in cubic meters)
}
@PART[SSTU-ST-HAB-B1]
{
	@MODULE[SSTUModularPart]
	{
		%coreContainerIndex = 0
	}
}

Other HAB parts should be patchable in a similar fashion.  The CFG parts are simpler, and only need the SSTU_MODEL patched to adjust the volume.

Other specific outcomes should be just as easy to patch -- merely need to know exactly what you are trying to accomplish...

 

 

Share this post


Link to post
Share on other sites

@Shadowmage Yeah, as our discussion progressed my assessment of the problem and what I wanted to do evolved... At least we found a bug I guess...

I will simply patch the HAB so they have a increased capacity when inflated. I will also change the deflatedCrew to 1 on the variant that have a integrated hatch... sound like something you might want to do too. I may increase the capacity of all of them, just enough to make them more competitive against tanks and container. That bring me back to one of my original question: I would like to know how to mm patch the ModelData...

Edit Hahaha! Looks you answered before I could post this!

Edited by RedParadize

Share this post


Link to post
Share on other sites
2 minutes ago, RedParadize said:

At least we found a bug I guess...

Indeed -- a good one at that :)  (really surprised that one hadn't been seen or reported before... is much more 'game breaking' than many of the others on the issues list).

Really want to try and push out an update this weekend... just need people to stop dropping by with 'surprise' projects (both at work, and at home...).  Ohh.. what I could do with a couple of free hours...

Share this post


Link to post
Share on other sites

@Shadowmage I know I should not write this since you have so little time available, but I just can't resist.

A "nice to have" feature would be to get your rocketpart back when deflating. Maybe not all of them... A bit like Ikea stuff, when you move you always lose some part...
 

Share this post


Link to post
Share on other sites
1 minute ago, RedParadize said:

@Shadowmage There is a FX bug with the RD-110. It looks like its always on.

RealPlume, or stock (or both) ?

2 hours ago, RedParadize said:

A "nice to have" feature would be to get your rocketpart back when deflating. Maybe not all of them... A bit like Ikea stuff, when you move you always lose some part...

Has been on the planned feature list for quite awhile.  The issue is, and always has been, what to do with the RocketParts if there is not enough storage on the craft for what would be returned? (and any other resources that would be affected by the deflation of the module)

Other than that point, it really shouldn't be too hard to implement -- play the animation in reverse, dump some RocketParts into the vessel, and profit(?).

Share this post


Link to post
Share on other sites

@Shadowmage No Realplume. If you tell me that you do not have that problem under Realplume I will install it. I have a much better computer than before.

About the deflate. Excess could be dumped as they currently are. Trough a warning would be nice, regardless if you implement this or not.

Share this post


Link to post
Share on other sites

using 0.8.43.153 with ksp 1.4.5. When I bring out an SRB-A and then make it 0.625m, the cost goes negative. Then if I remove all of the fuel, the mass goes negative. Is this a known issue?

 

edit: forgot to mention, bringing out an SRB also throws an exception: 

Quote

[ERR 21:26:00.733] Exception handling event onEditorShipModified in class SSTUEngineStatDisplay:System.NullReferenceException: Object reference not set to an instance of an object
  at SSTUTools.SSTUEngineStatDisplay.getEnginePropellantMass (.ModuleEngines engine) [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUEngineStatDisplay.updateStats () [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUEngineStatDisplay.editorVesselModified (.ShipConstruct ship) [0x00000] in <filename unknown>:0 
  at EventData`1[ShipConstruct].Fire (.ShipConstruct data) [0x00000] in <filename unknown>:0 

[EXC 21:26:00.734] NullReferenceException: Object reference not set to an instance of an object
    SSTUTools.SSTUEngineStatDisplay.getEnginePropellantMass (.ModuleEngines engine)
    SSTUTools.SSTUEngineStatDisplay.updateStats ()
    SSTUTools.SSTUEngineStatDisplay.editorVesselModified (.ShipConstruct ship)
    EventData`1[ShipConstruct].Fire (.ShipConstruct data)
    UnityEngine.Debug:LogException(Exception)
    EventData`1:Fire(ShipConstruct)
    ThrottleControlledAvionics.TCAEngineInfo:update_status()
    ThrottleControlledAvionics.TCAEngineInfo:OnStart(StartState)
    Part:ModulesOnStart()
    <Start>c__Iterator0:MoveNext()
    UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

edit2: looks like perhaps this github issue: https://github.com/shadowmage45/SSTULabs/issues/733

Edited by drhay53

Share this post


Link to post
Share on other sites
13 hours ago, drhay53 said:

using 0.8.43.153 with ksp 1.4.5. When I bring out an SRB-A and then make it 0.625m, the cost goes negative. Then if I remove all of the fuel, the mass goes negative. Is this a known issue?

 

edit2: looks like perhaps this github issue: https://github.com/shadowmage45/SSTULabs/issues/733

Yep, known issue.  Need to go through and figure out where the mass is being improperly specified or calculated; likely it is just the config files that need to be updated.

 

13 hours ago, drhay53 said:

edit: forgot to mention, bringing out an SRB also throws an exception:  

Quote

[ERR 21:26:00.733] Exception handling event onEditorShipModified in class SSTUEngineStatDisplay:System.NullReferenceException: Object reference not set to an instance of an object
  at SSTUTools.SSTUEngineStatDisplay.getEnginePropellantMass (.ModuleEngines engine) [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUEngineStatDisplay.updateStats () [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUEngineStatDisplay.editorVesselModified (.ShipConstruct ship) [0x00000] in <filename unknown>:0 
  at EventData`1[ShipConstruct].Fire (.ShipConstruct data) [0x00000] in <filename unknown>:0 

[EXC 21:26:00.734] NullReferenceException: Object reference not set to an instance of an object
    SSTUTools.SSTUEngineStatDisplay.getEnginePropellantMass (.ModuleEngines engine)
    SSTUTools.SSTUEngineStatDisplay.updateStats ()
    SSTUTools.SSTUEngineStatDisplay.editorVesselModified (.ShipConstruct ship)
    EventData`1[ShipConstruct].Fire (.ShipConstruct data)
    UnityEngine.Debug:LogException(Exception)
    EventData`1:Fire(ShipConstruct)
    ThrottleControlledAvionics.TCAEngineInfo:update_status()
    ThrottleControlledAvionics.TCAEngineInfo:OnStart(StartState)
    Part:ModulesOnStart()
    <Start>c__Iterator0:MoveNext()
    UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) 

 

Ahh, good catch.  Have opened an issue ticket -- https://github.com/shadowmage45/SSTULabs/issues/739

(the quick and dirty on that is that it was a testing feature that was improperly left enabled; it should not exist in normal gameplay)

Share this post


Link to post
Share on other sites
On 8/1/2018 at 9:55 AM, Shadowmage said:

@vossiewulf You may need to enable the 'angle snap' on the ports.  IIRC there may be an issue where they refuse to dock unless it is enabled.

(if that is the case, please let me know and/or open an issue ticket so that I can remember to get it cleaned up)

I was trying to dock with the welding docking ports tonight and I can't get them to actually dock, with snap on or off. They're supposed to be extended when docking right? It doesn't really matter, I've tried both ways.

They attract, get right up close, then nothing happens.

Share this post


Link to post
Share on other sites
1 hour ago, drhay53 said:

I was trying to dock with the welding docking ports tonight and I can't get them to actually dock, with snap on or off. They're supposed to be extended when docking right? It doesn't really matter, I've tried both ways.

They attract, get right up close, then nothing happens.

They definitely will NOT actually dock if either of them are extended. Extended is the equivalent of 'soft' docking as opposed to a hard dock (or latch). Extended means the only thing holding them together is magnetic attraction. They BOTH need to be retracted before they will actually dock.

Other than that I dunno why they wouldn't be docking when retracted. 

Edited by Starwaster

Share this post


Link to post
Share on other sites
7 hours ago, Starwaster said:

They definitely will NOT actually dock if either of them are extended. Extended is the equivalent of 'soft' docking as opposed to a hard dock (or latch). Extended means the only thing holding them together is magnetic attraction. They BOTH need to be retracted before they will actually dock.

Other than that I dunno why they wouldn't be docking when retracted. 

I attached them at the ends of two DOS station pieces and tried every combo of extended/retracted + snap enabled/disabled (always using the same setting on both docks). Tonight I'll probably put a couple on rovers for easier testing but no matter what I did I couldn't get them to capture. 

I was also using MechJeb smartass to point both modules at each other with a forced rotation angle of 0 degrees. It just now occurs to me that it's possible one of the modules was not being controlled from the docking port... but the solar panels on the two modules lined up so I assumed the angle was right. Is snap strict about 180 degree rotations too? do I need to attempt rolling the module over 180 degrees?

 

edit: I ask because I tried to set mechjeb's force roll to 180 degrees but it didn't actually flip the module over. So I'll have to do it manually to test this part.

Edited by drhay53

Share this post


Link to post
Share on other sites

@drhay53 @Starwaster I have difficulty connecting regular SSTU docking port... The only way I found to make them connect was to spin until it secure the connection, not great when you want to align. Maybe its a related issue.

@Shadowmage In wish file upgrade for the fuel tank container are configured? I have almost everything unlocked but I do not seem to be able to unlock the zero boil off.

Fun note,  Everyday Astronaut used your merlin model as a reference in its last video. 

Edited by RedParadize

Share this post


Link to post
Share on other sites
6 hours ago, drhay53 said:

I attached them at the ends of two DOS station pieces and tried every combo of extended/retracted + snap enabled/disabled (always using the same setting on both docks). Tonight I'll probably put a couple on rovers for easier testing but no matter what I did I couldn't get them to capture. 

I was also using MechJeb smartass to point both modules at each other with a forced rotation angle of 0 degrees. It just now occurs to me that it's possible one of the modules was not being controlled from the docking port... but the solar panels on the two modules lined up so I assumed the angle was right. Is snap strict about 180 degree rotations too? do I need to attempt rolling the module over 180 degrees?

 

edit: I ask because I tried to set mechjeb's force roll to 180 degrees but it didn't actually flip the module over. So I'll have to do it manually to test this part.

Took a look into this today -- there was actually a bug in the plugin code that was setting the default 'minCaptureRollDot' to an improper value when angle snap was disabled.  (technically, the bug is that stock still uses the minRollCaptureDot even when angle snap is disabled).

Has been fixed in dev code and verified to work, and this fix will be available with the next update.

4 hours ago, RedParadize said:

Fun note,  Everyday Astronaut used your merlin model as a reference in its last video.  

Hahaha... indeed. Kind of scary to see my game-model render images being used as a reference for the engine... (I didn't think it was that good, likely lots of better resources out there)

https://www.youtube.com/watch?v=CbevByDvLXI

Right around 11:07....

DgCoRgW.png

Edited by Shadowmage

Share this post


Link to post
Share on other sites
2 hours ago, Shadowmage said:

Took a look into this today -- there was actually a bug in the plugin code that was setting the default 'minCaptureRollDot' to an improper value when angle snap was disabled.  (technically, the bug is that stock still uses the minRollCaptureDot even when angle snap is disabled).

Has been fixed in dev code and verified to work, and this fix will be available with the next update.

Does this mean there is "an angle" where I should be able to get them to dock?

And, with angle snap enabled, you think I should be able to get them to work as long as the angle is right (so perhaps I had an off-by-180-degrees issue)?

Share this post


Link to post
Share on other sites
3 minutes ago, drhay53 said:

Does this mean there is "an angle" where I should be able to get them to dock?

Yes, but by default it is 0.5 degrees  (one-half of one degree).  Which is likely below the precision at which KSPs inputs can be made to rotate things (also, that dot product includes any offset from angle mismatch as well, so things will have to be aligned nearly exactly).

Alternatively, there is a 'tolerance' GUI slider -- set that to something much larger, like 180 degrees, and it should let you dock pretty much anytime.

Share this post


Link to post
Share on other sites

General development update (haven't done one of those in awhile...):

Spent a bit of time over the last few days cleaning up many of the open issue tickets -- the next release should have quite a few fixes in it for outstanding issues.

Still busy as ____ at work.   And now I'm not only doing 'development' work -- I've also had to pick up the duties of two additional departments after some co-workers resigned.  So my free time (and brainpower) are scarce, at best... but I'm still trying to get a bit of modding work done when I can.  Sadly most of my 'modding time' as of late has been devoted to helping others' solve their problems, which has left little or no time for actual development work (bugfixes, features, parts, texture, etc).

 

One thing that I could use some help in tracking down is the 'tanks lose settings on load/revert' issue ( https://github.com/shadowmage45/SSTULabs/issues/730 ) -- I have so far been unable to reproduce this problem, even when using provided .craft files.  So, I'm going on to the next step -- does anyone have a save-game where this issue is occurring regularly (preferably mostly stock/minimal mods involved)?  Or has someone found steps that will trigger the problem reliably?  Are there any log files available from a run of KSP where this issue has occurred?  If you have any of that information, please see the link above and feel free to add whatever information you may have to that issue ticket.

Basically, before I can even look into the problem I need to be able to reproduce it; if I can't see the problem happening, I have no chance of finding the cause.  Would really like to get this one solved, so any additional information that could be provided would be great.

 

Will try and push out an update this weekend with this weeks' fixes in it.  Will try again to repro and fix the 'losing settings' bug before I push out an update, but no guarantees on it.

Share this post


Link to post
Share on other sites
1 hour ago, Shadowmage said:

Yes, but by default it is 0.5 degrees  (one-half of one degree).  Which is likely below the precision at which KSPs inputs can be made to rotate things (also, that dot product includes any offset from angle mismatch as well, so things will have to be aligned nearly exactly).

Alternatively, there is a 'tolerance' GUI slider -- set that to something much larger, like 180 degrees, and it should let you dock pretty much anytime.

 

Sorry, perhaps I'm being dense; I cannot find this tolerance gui slider anywhere. Can you clarify where this is?

Share this post


Link to post
Share on other sites
1 minute ago, drhay53 said:

 

Sorry, perhaps I'm being dense; I cannot find this tolerance gui slider anywhere. Can you clarify where this is?

Should be in the part right-click menu; called 'Snap Tolerance'

        [KSPField(isPersistant = true, guiActiveEditor = true, guiActive = true, guiName = "Snap Tolerance", guiUnits ="deg"),
         UI_FloatEdit(suppressEditorShipModified = true, sigFigs = 4, minValue = 0, maxValue = 360, incrementLarge = 90, incrementSmall = 15, incrementSlide = 0.5f)]
        public float tolerance = 0.5f;

 

Share this post


Link to post
Share on other sites
4 minutes ago, Shadowmage said:

Should be in the part right-click menu; called 'Snap Tolerance'


        [KSPField(isPersistant = true, guiActiveEditor = true, guiActive = true, guiName = "Snap Tolerance", guiUnits ="deg"),
         UI_FloatEdit(suppressEditorShipModified = true, sigFigs = 4, minValue = 0, maxValue = 360, incrementLarge = 90, incrementSmall = 15, incrementSlide = 0.5f)]
        public float tolerance = 0.5f;

 

Is this not there on the welding ports? I don't see it. I could take a screenshot but take my word for it....

All I see is a SnapAngle slider.

Just to clarify; for the welding ports are you supposed to dock with them extended and disarmed or retracted and armed? The part description says "Dock two of these together, retract the push-rings, and press the 'Weld' button for a permanent station construction alternative." But the user above says they won't dock if either is extended.

Edited by drhay53

Share this post


Link to post
Share on other sites

Yeah, played around in the editor with other SSTU docking ports and looks like there's no tolerance slider on the welding ports. I see them when I enable snap on the other ports, but not the welding ones.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.