[1.1.2] Kerbal Konstructs v0.9.7.1 - Slopey Glidey

[blowfish]

3 minutes ago, Sigma88 said:

Hi @AlphaAsh,

some players requested me to add compatibility for Kerbal Konstructs to my rescale mod (SigmaDimensions, link in my sig)

since I couldn't see anything altitude-related in the cfgs of KK I guess either the stuff is put on the surface regardless of what the radius of the planet is, or the altitudes are hardcoded into the dll

 

any help you can give me in understanding this mod is very apreciated

I see where they're coming from but this would actually be quite difficult.  Kerbal Konstructs statics are placed using 3D cartesian coordinates relative to the planet's center.  You could scale those coordinates, but then all of the statics making up a base would either be smushed together or pulled apart by the rescaling.  I don't think it's possible at the moment.

[Sigma88]

16 minutes ago, blowfish said:

I see where they're coming from but this would actually be quite difficult.  Kerbal Konstructs statics are placed using 3D cartesian coordinates relative to the planet's center.  You could scale those coordinates, but then all of the statics making up a base would either be smushed together or pulled apart by the rescaling.  I don't think it's possible at the moment.

then it's even worse than I thought.

rescaling the 3D vector is simple enough for standard rescales:

if you rescale Kerbin by 2x the altitude of the statics doubles, and changing the vector to account for that is doable

on the other hand, my mod allows to change also the "landscape", meaning how tall the mountains are.

in that case, it's not possible to calculate the distance of the ground from the center of the planet. because you would need to know how much the old altitude was.

where are those coordinates saved? and how does KK generates them (the coordinates)?

[blowfish]

27 minutes ago, Sigma88 said:

then it's even worse than I thought.

rescaling the 3D vector is simple enough for standard rescales:

if you rescale Kerbin by 2x the altitude of the statics doubles, and changing the vector to account for that is doable

on the other hand, my mod allows to change also the "landscape", meaning how tall the mountains are.

in that case, it's not possible to calculate the distance of the ground from the center of the planet. because you would need to know how much the old altitude was.

where are those coordinates saved? and how does KK generates them (the coordinates)?

If you know the initial sea level radius of the parent body then it might be possible: just subtract it from the static's actual radius, then scale that by the terrain height scaling.  But even if that works, the bases will still be messed up - most are composed of several statics which are placed globally rather than relative to each other.  So if you upscale the solar system they will be moved apart.  Lots of things in Kerbinside especially depend on the exact placement lining up.

[AlphaAsh]

Simply put, automating repositioning of statics already placed, such as with packs like KerbinSide, is going to be a nightmare to code. blowfish covered most of the problems associated with it.

Unity/KSP's PQS system is problematic on normal scale Kerbin, due to height drift on a spherical body, anyway. Remember, there's no such thing as a flat surface on a spherical body, unless it is manually mapped into the terrain, for example. I'm not even sure they bothered to worry about height drift with the KSC even. That actually has some evidence of the issue when examined closely too.

Simple diagram illustrating the 'height drift' issue when using PQS to place statics.

Obviously increasing the scale of the body only exacerbates the issue.

Edited March 15, 2016 by AlphaAsh

[Sigma88]

16 minutes ago, AlphaAsh said:

Simply put, automating repositioning of statics already placed, such as with packs like KerbinSide, is going to be a nightmare to code. blowfish covered most of the problems associated with it.

Unity/KSP's PQS system is problematic on normal scale Kerbin, due to height drift on a spherical body, anyway. Remember, there's no such thing as a flat surface on a spherical body, unless it is manually mapped into the terrain, for example. I'm not even sure they bothered to worry about height drift with the KSC even. That actually has some evidence of the issue when examined closely too.

actually, I've already solved compatibility with KSCSwitcher, and since kerbinside uses KSCSwitcher I expect my mod to be compatible as well.

I never checked on it tho, but noone complained for now so I'd say that's a good sign.

I still am not sure where I should look if I want to know the position of something placed using KK.

Could you steer me in the right direction?

Edited March 15, 2016 by Sigma88

[AlphaAsh]

5 minutes ago, Sigma88 said:

5 minutes ago, Sigma88 said:

actually, I've already solved compatibility with KSCSwitcher, and since kerbinside uses KSCSwitcher I expect my mod to be compatible as well.

I never checked on it tho, but noone complained for now so I'd say that's a good sign.

I still am not sure where I should look if I want to know the position of something placed using KK.

Could you steer me in the right direction?

actually, I've already solved compatibility with KSCSwitcher, and since kerbinside uses KSCSwitcher I expect my mod to be compatible as well.

I never checked on it tho, but noone complained for now so I'd say that's a good sign.

I still am not sure where I should look if I want to know the position of something placed using KK.

Could you stir me in the right direction?

If you look in the instance cfg of any static you'll see one of these:

RadialPosition = -98958.78,-63098.58,589832

If you can figure out the trig/math to automate changing that, then power to you sir. Crack that then you're close to being able to automate the repositioning. Step 2 would be to go poke at KK's code on GitHub and get coding.

KerbinSide does not use KSCSwitcher, btw.

Edited March 15, 2016 by AlphaAsh

[blowfish]

@Sigma88 Even if you can update the coordinates correctly, how do you solve the issue of bases being made of multiple statics?  You're going to end up with buildings that were previously on a podium now floating in the air and taxiways that were previously attached to a runway now sitting by themselves.

[AlphaAsh]

1 minute ago, blowfish said:

@Sigma88 Even if you can update the coordinates correctly, how do you solve the issue of bases being made of multiple statics?  You're going to end up with buildings that were previously on a podium now floating in the air and taxiways that were previously attached to a runway now sitting by themselves.

Yep, this. I wouldn't know how to automate the drift correction, since the statics themselves aren't being rescaled. Hmmm, unless they can be using scale factor etc. Never tried that in a KK cfg.

[Stone Blue]

1 hour ago, AlphaAsh said:

Simple diagram illustrating the 'height drift' issue when using PQS to place statics.

Obviously increasing the scale of the body only exacerbates the issue.

Didnt I read somewhere before, that ^^ THIS ^^ is why planes always veer to the right, when speeding along the runway for takeoff?

If so, then that I guess, goes to show that even Squad hasnt been able to eliminate/work-around this issue... ??

[Sigma88]

2 hours ago, AlphaAsh said:

If you look in the instance cfg of any static you'll see one of these:

RadialPosition = -98958.78,-63098.58,589832

If you can figure out the trig/math to automate changing that, then power to you sir. Crack that then you're close to being able to automate the repositioning. Step 2 would be to go poke at KK's code on GitHub and get coding.

KerbinSide does not use KSCSwitcher, btw.

this may sound surprising, but to properly rescale RadialPosition = -98958.78,-63098.58,589832 you just need to multiply each term by the same number.

doing that, latitude and longitude will remain the same, altitude will be multiplied by the chosen number.

Basically there are three problems I need to solve:

1- Reposition statics when the planet is resized maintaining the proportions (everything multiplied by x) [SOLVED]

2- Reposition statics when the planet is resised NOT maintaining the proportions (mountains are higher or lower in proportion to the planet)

3- what blowfish said here

 

for 1 I just need to multiply every element in the position by x,

for 2 I probably will need to do some math, and I will probably need to use sin() and cosin() functions, so either sarbian adds that to MM or I will need to move everything to SigmaDimensions.dll

for 3 I can't do anything, but I think it would be possible to fix this inside KK by "linking" all the pieces of a structure to a central piece, defining their position in relative to that piece instead of defining each different piece as a separate entity.

of course I'm not asking anyone to do that, that's just a supposition.

 

thanks everybody for the feedback, I'll try testing some of these options and see what I can accomplish

[AlphaAsh]

19 minutes ago, Sigma88 said:

for 3 I can't do anything, but I think it would be possible to fix this inside KK by "linking" all the pieces of a structure to a central piece, defining their position in relative to that piece instead of defining each different piece as a separate entity.

of course I'm not asking anyone to do that, that's just a supposition.

It's not a bad supposition. It's somewhat simplistic but the principle is sound and it's certainly something I may consider playing with next time I have the time and am fit enough to work on KK. Feel free to take a bash at it. I thought C# would be a pain to move over to but I picked it up quickly enough.

Edited March 15, 2016 by AlphaAsh

[Beetlecat]

1 hour ago, Stone Blue said:

Didnt I read somewhere before, that ^^ THIS ^^ is why planes always veer to the right, when speeding along the runway for takeoff?

If so, then that I guess, goes to show that even Squad hasnt been able to eliminate/work-around this issue... ??

I don't think it's so much the veering, but rather why aircraft begin rolling forward immediately upon launch. The flat runway actually results in a slope at the ends which is exaggerated by Kerbin's unusually "small" size.

Edited March 15, 2016 by Beetlecat

[Sigma88]

@AlphaAsh turns out things are even easier than you made them out to be

the RadialPosition only defines Latitude and Longitude, the altitude is given by RadiusOffset and is basically the altitude on sea level.

this is perfect for me since I just need to multiply that value by whatever rescale I want and everything should pop up in the right place

 

only one problem remains, the position of the models is calculated relative to a certain point in the model, if that point is not at the base of the building the rescale will end up being a little offset from the ground

---

EDIT:

I've tried and it seems to work pretty well.

the altitude is pretty good... the pieces are all spread around like it was expected, but there's nothing I can do about that

this is a 6.4x resize of kerbin with landscape set to 0.25x

this means that geographic features such as hills and mountains are 0.25 times what they would be if they were rescaled by the same factor as the radius (6.4x)

 

Edited March 16, 2016 by Sigma88

[theonegalen]

Hullo, @AlphaAsh, I had a problem with using StageRecovery and KK together, and Magico13 says it's a KK issue. StageRecovery spat out about 850 "Failed Recovery" messages off a single stage. Here's the log:

https://drive.google.com/file/d/0B6ZYgATQfNhBejAxeGlvdC03cnM/view

[AlphaAsh]

v0.9.5.3 is now available FOR TESTING.

Available from SpaceDock: http://spacedock.info/mod/124/Kerbal%20Konstructs

This version is compiled against the pre-release version 1.1 of KSP with a few minor code changes for compatibility with API updates. That means there has been no major overhaul of the GUI and other planned improvements that utilise the Unity update.

It does not require module manager. The collider "fix" is now native to the mod and applied automatically to all static objects. All static object colliders are set concave and preliminary testing shows that Unity does still support them.

It does seem to work just fine in x64, based on preliminary testing.

Edited March 30, 2016 by AlphaAsh

[Sigma88]

39 minutes ago, AlphaAsh said:

v0.9.5.3 is now available FOR TESTING.

It is not available from SpaceDock. I'm hosting it myself here.

This version is compiled against the pre-release version 1.1 of KSP with a few minor code changes for compatibility with API updates. That means there has been no major overhaul of the GUI and other planned improvements that utilise the Unity update.

It does not require module manager. The collider "fix" is now native to the mod and applied automatically to all static objects. All static object colliders are set concave and preliminary testing shows that Unity does still support them.

It does seem to work just fine in x64, based on preliminary testing.

Even if the mod doesn't require module manager, will it be possible to change the statics using modulemanager? Or will it be necessary to edit the actual cfg file?

[AlphaAsh]

There's no reason for a static's colliders to be set convex, and any that already have shouldn't be affected anyway.

[Sigma88]

9 minutes ago, AlphaAsh said:

There's no reason for a static's colliders to be set convex, and any that already have shouldn't be affected anyway.

I'm not sure what you mean by convex, but I don't think it matters for me.

I just need to be able to change the altitude of each STATIC/Instances to allow KK compatibility with my rescale mod

[AlphaAsh]

Ah you just mean with cfgs in general. Yes, MM will work fine. I just got rid of the need for a flag in a static cfg that was added in a recent fix that specifically required MM to op on it.

[Eskandare]

I noticed in the 1.1 test update I couldn't get rid of air race. I removed AirRace and duplicate assets and it still was persistant. O.O

Edit: I found the rest of the assets but it still won't let me remove assets in game, even after the save.

Edited March 31, 2016 by Eskandare

[AlphaAsh]

The issue is to do with the custom flag and that you're developing with KK's tools. Whenever you make changes and addtions to any statics, all static cfgs are re-written and then all the pointername cfgs become redundant.

As a developer, to completely remove content you must delete both the packs(s) you installed and then any now core cfgs that have been created. Essentially, backup any of your own work then flush everything else.

Edited March 31, 2016 by AlphaAsh

[AlphaAsh]

v0.9.5.4 available from SpaceDock.

Changelog:

• Fixed bug in recovery, where KSC wasn't getting cleaned up and funds was continuously increased.
• Cleaned up example core static cfgs so that duplication errors aren't logged incorrectly when Round Range is being spawned on game start.

Please note that StageRecovery support may well be broken until @magico13 has had a chance to see what's what.

Edited March 31, 2016 by AlphaAsh

[Rory Yammomoto]

I'm Sorry, But I'm confused. What Problems came from 1.0.5? I heard it Disabled 'Convex Colliders' in preparation for 1.1, and I know you fixed it, But if that's true, How did you get it to render these colliders in 1.1, given someone said 1.1 wouldn't support it? 

 

T.L.;D.R. : What amount of genius work got this thing working in 1.1?

[blowfish]

16 minutes ago, Rory Yammomoto said:

I'm Sorry, But I'm confused. What Problems came from 1.0.5? I heard it Disabled 'Convex Colliders' in preparation for 1.1, and I know you fixed it, But if that's true, How did you get it to render these colliders in 1.1, given someone said 1.1 wouldn't support it? 

 

T.L.;D.R. : What amount of genius work got this thing working in 1.1?

Thomas P submitted a fix a while ago ... colliders can still be concave, just not on a part (statics are fine) - they just have to be forced to be concave in code since KSP forces them to be convex when loading the model.

[AlphaAsh]

28 minutes ago, Rory Yammomoto said:

...How did you get it to render these colliders in 1.1, given someone said 1.1 wouldn't support it? 

Basically, they were wrong.