Jump to content

[1.12] Extraplanetary Launchpads v6.99.3


taniwha

Recommended Posts

3 hours ago, pp3d said:

Hi,

I believe I have a conflict with a mod and I need some help. I believe it's MKS: USI Modular Kolonization Systems, which replaced the requirements for Orbital Construction from Rocket Parts to Material Kits/Specialized parts. What's the best way to ensure that the requirements stay with EL? Thanks.

 

--- Edit... I just saw the message above .

Note that the bug was removing some of the necessary parts of EL - the resource chain replacement is likely to stay in place.  (Though maintained by others besides RoverDude.)

Link to comment
Share on other sites

1 minute ago, DStaal said:

Note that the bug was removing some of the necessary parts of EL - the resource chain replacement is likely to stay in place.  (Though maintained by others besides RoverDude.)

Thanks. I ended up removing MKS. I am wondering if there are warnings/docs when a mod risks on replacing the resource chain... On the MKS side I didn't see any.

Link to comment
Share on other sites

2 minutes ago, pp3d said:

Thanks. I ended up removing MKS. I am wondering if there are warnings/docs when a mod risks on replacing the resource chain... On the MKS side I didn't see any.

Not really - except that there are mentions that it's a fairly major change to a lot of mechanics.

If you really want both - and don't want to use the MKS resource chain for EL - there is a 'MKS_EL.cfg' file that has all the resource chain stuff, and if you just edit that file you can remove that change.  Though really that complicates your bases as you need yet another drill, processor, and set of storage units.

(I will note that I know there are a couple of other mods that have small recipes built into them - USI's version of Orion, for example.  But MKS is the only wholesale replacement I know of.)

Link to comment
Share on other sites

Just now, DStaal said:

Not really - except that there are mentions that it's a fairly major change to a lot of mechanics.

If you really want both - and don't want to use the MKS resource chain for EL - there is a 'MKS_EL.cfg' file that has all the resource chain stuff, and if you just edit that file you can remove that change.  Though really that complicates your bases as you need yet another drill, processor, and set of storage units.

(I will note that I know there are a couple of other mods that have small recipes built into them - USI's version of Orion, for example.  But MKS is the only wholesale replacement I know of.)

yeah... i begun hacking into the MKL_EL earlier... then I decided I don't want it that bad. It would make updates an issue unless i write a patch to do this everytime. 

 

Link to comment
Share on other sites

@[email protected]: Tweakscale is one suspect, but I don't use it and got some odd behavior myself, so I suspect bugs in the placement code in ExSurveyStation.

As for building in VS, just throw all the .cs files into a project (note that Assembly.cs is generated from Assembly.cs.in to get version info into the dll).

[edit] Also note: things are in a little bit of flux as I'm working on various improvements to the survey system (eg, plaques for the stakes).

Edited by taniwha
Link to comment
Share on other sites

So I solved the problem with a rather unusual hack. Scaling the survey stakes 20x in the Y direction and moving the node attach point up to -5 again in the Y seems to have raised the spawn point by about as much distance dY in meters.

This makes me think that the spawn origin point is based on the location of the stake's reference frame (it's own XYZ origin) rather than the point to which it hits the ground, which is definitely incorrect, as the spawn point should be referencing the ground frame XYZ coordinates, regardless of how far in the ground or out or how tall the stake is. The XYZ point that should matter is the one in the middle of the circle made by the intersection of the surface of the world and the stake's planar geometry, or even just the node point translated into planet frame space. I hope this makes sense.

I've been looking through the survey station code and have not yet located where this is occurring, but will keep looking. My guess is that somehow the 0x0y0z of the stake is being used as the origin as opposed to the point where it meets the surface. Otherwise, my changing of the node location and scale would have changed nothing about the spawn point.

 

Edited by [email protected]
Link to comment
Share on other sites

1 hour ago, [email protected] said:

This makes me think that the spawn origin point is based on the location of the stake's reference frame (it's own XYZ origin) rather than the point to which it hits the ground, which is definitely incorrect, as the spawn point should be referencing the ground frame XYZ coordinates, regardless of how far in the ground or out or how tall the stake is. The XYZ point that should matter is the one in the middle of the circle made by the intersection of the surface of the world and the stake's planar geometry, or even just the node point translated into planet frame space. I hope this makes sense.

It makes sense, but is incorrect: I could have very easily made the stake's reference point and attach node match, but I chose not to as the little bit of clearance (19cm) between ground and the stake's reference point make it easier to use the stakes on slightly bumpy ground. That is, there is a very good reason for the offset.

If you don't like the offset, create a new stake model where the origin and attach node match. KIS uses the part's attach node for surface attachment.

The reference point created by the stakes is not directly applied to the vessel's spawn point. When not using any bounds stakes, the vessel is placed such that the bottom of its bounding box touches the point, and the root node is centered over the point (just like the launchpad).  EL calculates the vessel's bounding box by checking the bounding boxes of all the colliders of all the parts in the vessel.

A couple of things I've noticed in my recent "testing":

  • A vessel I spawned in orbit was about 1m "above" the orbital dock. This may be due to the experimental part in the vessel. The parts are based on tetrahedrons and octahedrons, and they were oddly rotated, so the bounding boxes may have been over-sized.
  • Both vessels I spawned on Minmus's flats (6°44'05"S, 4°06'20"E) spawned several meters above the ground (using two origin stakes). While one of the two vessels included the experimental parts, they were not oddly rotated (and the vessel spawned too high for that to be the cause anyway), the other vessel is pretty much the same design of miner/smelter I've spawned many times before, including in KSP 1.1.3.
  • The "vessel" (base foundation) I spawned at 6°39'50"S, 4°06'47"E (wow, a minute is small on Minmus) may or may not have spawned too high (hard to tell as it's on a hill using launch clamps, so I'm unsure where its bottom is), but it certainly spawned too far north by 3-4m. East-west may be ok: the bounds stake is right through the center of launch clamps on that side.

The first one may be Unity miscalculating the bounding box of my experimental parts (WIP project), I need to investigate this further. However, the other two points indicate that there may be a problem with EL's calculation of the spawn offset in the survey code.

As people have reported their vessels spawning in the ground to varying degrees (some part way, you fully), and I've had trouble with vessels spawing well above the ground or offset laterally, I strongly suspect the offset between the vessel's root part and the surveyed frame is incorrect: quite possibly incorrectly rotated.

I included the latitude and longitude in the above for two reasons: one, so people can find the area; two, I think latitude might make a difference. Local time of "day" might, too, which would explain the "it worked earlier".

Some tips for poking at the code:

  • Survey stations and launchpads use separate part modules: ExSurveyStation (Survey/SurveyStation.cs) surveys, and ExLaunchPad [sic*] (Pad/Launchpad.cs) for launchpads and the orbital dock. (* spelling mistake not mine, but not corrected to avoid breaking things)
  • Both part modules use a common helper class to do the actual building: ExBuildControl (BuildControl.cs).
  • It is ExBuildControl that does the actual building, spawns the vessel, and calculates the vessel's bounding box. ExSurveyStation and ExLaunchPad do the actual placement and, in the case of ExLaunchPad, vessel capture.
  • 3D math is hard, especially rotations, and is not helped by Unity being left-handed (Y-up), my brain being right-handed (Z-up), and KSP being both. On top of that, throw in working blind (next sub-project, actually).

@[email protected]: since you're poking in the code, if you do a fresh git pull, you'll notice a nice new QoL feature :) (currently working on toggling it).

Edited by taniwha
Link to comment
Share on other sites

Okay awesome, thanks a bunch for the additional info I'll see what else I can learn about what's going on.

I'm getting another strange bug now, where when I start a build it immediately says it's completed but hasn't started and will not progress. Can restart and reset but the same thing happens even after moving stakes around or switching launchpads

Link to comment
Share on other sites

Good news: I think I found the problem. Wasn't my math, but my usage of objects and transforms to implement the math. Possibly exacerbated by the NRE fix. Anyway, cleaning up that bit of code has my test vessel spawning correctly.

Or maybe not, still some placement errors.

False alarm: I had my debug X and Z planes swapped, so I moved the wrong stake :P.

Edited by taniwha
Link to comment
Share on other sites

On 29.4.2017 at 5:40 PM, Gilsch said:

Ok so I tried to remove all the stuff from UmbraSpaceIndustries. Didn't change anything. So I tried with a fresh installation of KSP and added the mods one by one. It seems to be a problem with the SETI-Rebalance Mod.

 

If I remove it, all parts are showing and when I add the mod some parts are missing. Don’t know exactly how they are interacting or what exactly is causing the problem.

 

Anyway thanks for the help.

This is a problem with using non-integer numbers for some part costs. cost = 2867 works fine, cost = 2867.1 does not seem to work for module manager patches.

Link to comment
Share on other sites

2 hours ago, Yemo said:

This is a problem with using non-integer numbers for some part costs. cost = 2867 works fine, cost = 2867.1 does not seem to work for module manager patches.

Actually, it's because certain MM patches (tech tree? I don't remember) use the part cost to calculate tech entry cost, and tech entry cost cannot be fractional. The ideal fix would be for KSP to accept factional tech entry costs, followed by MM having a floor/ceil/round function and it being used. While I can tweak the costs, this problem is always going to show up for parts holding small amounts of resources.

Link to comment
Share on other sites

20 minutes ago, taniwha said:

Actually, it's because certain MM patches (tech tree? I don't remember) use the part cost to calculate tech entry cost, and tech entry cost cannot be fractional. The ideal fix would be for KSP to accept factional tech entry costs, followed by MM having a floor/ceil/round function and it being used. While I can tweak the costs, this problem is always going to show up for parts holding small amounts of resources.

Yes, you are right of course, module manager patches are not the problem, non integer entryCost are the problem. I remembered wrongly.

Though the MM patches only use the costs as specified in the config, independent of the contained resources.

Since the config specified costs are the ones displayed in game, thus this number includes the costs of the default included resources.

Masses work the other way, the in game displayed mass is the sum of config mass in addition to default resource masses.

 

edit: Thus changing the config costs to integers would fix this compatibility problem. I would do it on my end, but I do not know how.

Edited by Yemo
Link to comment
Share on other sites

@Yemo: I just took a look at MM's guts, and there is hope.

Note, this will work only for positive values (negative values would need similar but different expressions):

//truncate/floor (only +ve values)
@value ^= :\.[0-9]*::
//round (only +ve values)
@value += 0.5
@value ^= :\.[0-9]*::

truncation would be ceil for negative values, and rounding negatives would require -0.5.

+ve ceil and -ve floor are tricky.

NOTE: I suggest applying that to the tech cost after calculation, not the part cost (to avoid issues with resources)

Edited by taniwha
Link to comment
Share on other sites

I have released version 5.7.2 of Extraplanetary Launchpads. Links in the OP.

Changes from 5.7.1:

  • Fix missing build info window when loading a ship in the editor.
  • Fix an in-flight NRE when loading a vessel with a workshop.
  • Fix free lunches from KIS boxes (their contents are properly checked again (ksp 1.2 breakage)). Probably affects FAR wings and various procedural parts.
  • Rocket workbench now immediately returns control to the previous control part when a kerbal boards.
  • Tweaks to some part names and balances.
  • Converter (eg, smelter) and extractor (auger) module info now useful.
  • Build info window can now be toggled from the space center and defaults to off.
  • Reversed flag in the workshop IVA fixed.
  • Survey stakes now have a billboarded plaque above them (when highlighted) making them more visible and indicating their use.
  • Improvements to site and stake tracking.
  • Incorrectly placed survey builds fixed. This should fix any issues with vessels spawning in the ground for reasonable sites (just origin stakes on flat ground, or properly used bounds stakes elsewhere).

Survey plaque (note, plaque is lower in the release): (click for the full image)
surveyplaque-small.png

 

Edited by taniwha
Link to comment
Share on other sites

Both the Build Progress Rate Issue and the Scrap Metal Storage Issue have persisted into EL 5.7.2, the former confirmed just now by a quick test at my now rarely used base on Mun, the latter by a check of the EL tab in the VAB.  I guess I'll have to continue manually overriding the variables before starting builds and accruing junk near my bases (my base on Pol is becoming particularly bad about this as of late) for the time being.

Link to comment
Share on other sites

@cgwhite4: Yeah, I haven't been able to address those yet. Turns out it happens for stock converters, too (surprise, surprise), but I don't consider that to be an excuse for EL. I figured getting a fix for broken survey sites out was fairly high priority (the new plaques are actually part of some debug info as well as being an improvement to stake visibility).

Link to comment
Share on other sites

My guess is the reason I failed to detect the Build Progress Rate Issue for the drills and ISRU is because I must build a vessel and finalize its build before I fuel it, which would take more than enough time for the system to catch up.  Because I always top off all tanks before launching, I would never have a situation where I would return to a base from the tracking station and immediately need to refuel, in which case I probably would have encountered the issue.

Link to comment
Share on other sites

It sounds like you just ran an orbital resource scanner and then turned on the overlay to check for surface resources.  By default, the KSP standard ore, which can be converted to fuel, is indicated by magenta whereas metal ore is indicated by silver, so it sounds like you are currently in fuel ore mode.  I'm not sure exactly what you mean by "fix".  If you want to turn the resource indications off, simply press the "Toggle Overlay" button, which should turn off the magenta color.  If you want to switch from fuel ore mode to metal ore mode, then press the button that tells you which resource you are set to (this should turn things silver instead of magenta).  If you want to only display the locations where there is a high level of the resource in question, increase the threshold until all of the magenta or silver disappears and then decrease it by one step.  You can also change color schemes, but I usually do not mess with that.

Also, I have noticed that the overlay will now persist in map mode if you switch between vessels near the target celestial object without going through the tracking station unless you explicitly turn it off from the scanner, go to the tracking station or space center, or exit the game.  If none of this describes your problem, and this is instead some new bug that I have not yet encountered (I have not run any resource scans since 5.7.2 came out), I have no idea what to tell you.

Link to comment
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.

×
×
  • Create New...