KSR Airports for Kerbinside Remastered

[Nightside]

On 8/11/2018 at 5:40 PM, AdmiralTigerclaw said:

So, a question for anyone who might know the answer:

 

I'm considering using the lvl I KSC runway in a few of the local airports for that... EXTRA small airport feel.

But I recall there being a runway update in KSP for one of the 1.4 iterations that overhauled at least the lvl III.

 

Does anyone know if that affected the lvl 1 runway?  The last thing I want to do is install that runway at some of the local airports, only for it to simply NOT EXIST for users on higher end versions of KSP.

I love the dirt strip. I usually install them extra small around 0.6-0.7 scale.

[AdmiralTigerclaw]

@Ger_space

That's good to know, though I'm more interested if there are changes.  I know the Lvl III runway got fixed, but I don't know how much that affected its shape.  Mainly for alignment purposes.  And by association, I don't know if the dev crew went through the other runways doing the same fix on those little model seams.

 

Anyway, No airports actively made since the latest upload.  I'm working on my list of names so I can power from one into the next without having to spend half the day hemming and hawing over what I should call an airport.

 

So far, I've come up with the following (And @Bottle Rocketeer 500 , don't go trying to do any of these right now.  They are location fixed so that the names reference nearby land marks).

- Ruby Regional

- Legionnaire Central

- Lake Thunderhead Central

- Everfrost Regional

- Focal Point Regional

That leaves me with six open slots for regional airports to fill in.

Ideas, as always, are appreciated.

 

EDIT:

And just after typing the above, I had some ideas for some regionals named after Borderlands weapons makers.

- Maliwan (In the Bamboo Isles, since the name structure sounds very south pacific)

- Vladov (Up near the Zacharov mts, since everything in that area sounds Russian and that's where I wanted one of the regionals anyway, as that part of my plan is the part that got cut off.)

 

Atlas is already used and is generic anyway...  (Atlas Valley Regional)

Torgue wouldn't fit anything, so I'm skipping over his Royal Explosiveness.  (Probably call the airport the 'awesome airport of exploding kerbals', or something anyway.)

Jacobs is too generic and wouldn't only catch people's attention when teamed up with the other arms' names anyway.

Dahl might be better as a local airport, just to spread the names out.

Hyperion sounds more like a spaceport, and those names are locked in.  Plus, assuming multiverse theory, I don't want to give Jack any kind of legacy.

 

 

Maybe a few more options for Chairforce bases at this point.

 

 

 

 

 

Edited August 14, 2018 by AdmiralTigerclaw

[Bottle Rocketeer 500]

@AdmiralTigerclaw I will make the regional in the Bamboo Islands, just please tell me where exactly to put it. I was thinking of giving it a floating runway going out over the ocean. Also, maybe name it something more Hawaiian-themed instead.

[AdmiralTigerclaw]

I was thinking -51 Lat,  -158 Long.  More or less.  It serves that medium sized island to the southwest of the main Bamboo Isle.  Doesn't have to be exact, though I wanted that airport to be more landlocked on the Island than a coastal thing.  Maybe we can get you a water airport on one of the smaller locals.

Also, I was thinking of messing with the spelling of Maliwan to make it more Malliwann.  And if you put it in the middle of the island, we can name it Malliwann Central, since it will be 'centralized' on the island.  And that'll help break up the long list of airport names that end in 'Regional'.  (Trust me, reading a list where every single airport ends in 'Regional' gets old really fast.)

 

[Bottle Rocketeer 500]

@AdmiralTigerclaw I was thinking by the bay at -52.6 and -161.15 and naming it something like Kahuna Island Airport.

[StevieC]

if I may suggest naming one of the airports "Mistral"?

[Ger_space]

@AdmiralTigerclaw

Can I somehow support your project in any way? You want the export-everything by groupname funtion back in KK, so you have less trouble when saving your work? Anything else you might need?

You are still on KSP 1.3.1, right?   

Edited August 18, 2018 by Ger_space

[Bottle Rocketeer 500]

@Ger_space IIRC, he runs version 1.2.2

 

Also, I already said this many times, but I would like a feature to be able to move groups, mainly because I realized how pointless my decision to put X-KJMK where it is was, because there was a location not too far away that actually looked like New York City, so I would like to move it in my install, but don't want to manually move and re-align every static. As every airport in this mod uses a terrain decal, you can make it calculate the position of an object relative to the terrain decal, and when you move the terrain decal, it would recalculate the position of an object accordingly.

[AdmiralTigerclaw]

5 hours ago, Ger_space said:

@AdmiralTigerclaw

Can I somehow support your project in any way? You want the export-everything by groupname funtion back in KK, so you have less trouble when saving your work? Anything else you might need?

You are still on KSP 1.3.1, right?   

Saving what I've done at this point doesn't really affect me.  It all goes to the same place and I keep it under control.

 

What does affect my workflow is how clunky the interface itself is.  I have three main points of interest here:

 

1: There is a glitch when placing terrain decals.  When you switch the KK interface menu to the terrain Decals section, you MUST leave the scene and re-enter the scene before you can work with anything else.  You must also ensure before you leave the scene, that you switch back to the local objects or spawn new objects section of the interface, or you'll have to leave the scene again, because it'll see Decal mode and bork.  If you try to work with any statics without leaving the scene after tweaking or creating a terrain decal, the menus will malfunction (they freeze and stop accepting input) and you'll potentially be forced to restart KSP in its entirety.

This presents several minutes of workflow delays between dropping a decal, and getting started on actual layouts.  It also presents delays if I decide to adjust the decal.

 

2: The position and orientation controls for statics are Sub-Par.  The most time consuming task in setting up my airports has come from the amount of time I've spent clicking back and forth through the step scale buttons.  While moving the statics across the terrain in this manner is acceptable, setting orientation up is needlessly complicated.  There is a number field for the static's compass heading, but I cannot edit it by inputting a numeric directly.  I HAVE to use the step clicks.  And considering I'm making sure my headings are set to whole number values, having to go in and step them through the three decimal space options I can get at can take anywhere from thirty seconds to a minute per object, TWICE.  (Once for initial alignment, second after I move them and the alignment is altered.)  That's up to two minutes per object for up to thirty objects.  That's an HOUR spent just clicking buttons tediously.  Being able to just punch in "90 [ENTER]" for a runway that faces 90 degrees would cut 30 seconds to 5 seconds or less.  That's a reduction from an hour to a mere 5 minutes.

2b: The pitch and roll orientation fields don't even have a numeric value display to speak of.  You have to completely eyeball those values.

(EDIT::  2c:  Being able to input numerics without the interface second-guessing you is a must as well.  In the gras color fields, the interface does NOT like it when you put in zeroes or non-number characters first.  So putting in decimal values like -0.22 becomes a pain to set up because you have to enter a non-zero positive whole number, then back-edit it to get past the check.  Given that gras color doesn't DO anything until you hit the 'apply' button, it shouldn't even check at all until you're done plugging your desired values in.  Obviously, if that check gets fixed, it'll have to sanity check you and reject invalid values.  Said input check should also obviously apply to any new direct input numeric fields should they be added. 

 

3: When trying to align large objects, especially the ends of large objects like the runways and base plates, the camera being coupled to the center of the object in question with your only way to view being an imprecise camera zoom out and pan-around feature becomes very hassling.  If I could decouple the camera and move it freely on the XY and Z axis while doing fine alignments that would be very useful.  And while I'm sure other mods can do that, I get the feeling that with KK telling the camera to center on a part, those mods would NOT play nice with it.

 

 

 

Aside from that, some 'wishlist' items for KK.

 

1: Object position reference linked to a parent object.  This would make it easy for people using Kerbin rescales with KK implanted objects.  Instead of all the statics being placed in the world with their own explicit grid coordinates on Kerbin's surface, having them all positioned and oriented in relation to a base 'master' or parent object of some kind would allow you to move the parent object around, while keeping everything in place.  The best candidate for that would be using a terrain decal as the base core/parent object.  It's effectively the foundation for any base anyone is going to build outside of unique circumstances.

2: In relation to the above, also having orientation references linked to the parent object would be useful as well.  KK's statics have slight orientation shifts over the surface of Kerbin, resulting in the problems I've been having aligning things like upscaled runways and taxiways.  If every static's idea of which way is 'UP' is based on the center-point of a terrain decal instead of their exact position, then they will NATURALLY line up instead of being slightly off from each other by half a degree.

 

1 and 2 here would have the bonus affect of being able to 'rubber stamp' structure complexes.  Just copy a complex, change it's name and the name references of the child statics, and you ONLY need to change the location information of the parent.  BAM!  Instant cloned base.

 

 

I get the feeling this was either implemented and forgotten, or implemented but broken for some reason, because data files have fields like 'object is center of base' or something along those lines with a YES/NO for the bool control.  But nobody actually uses it, and I don't know how if it IS available.  There are also seemingly intuitive options in the static editing interface like object snap that I can't figure out and seem to just make things relocate to really ugly spots.

 

 

EDIT: In further relation to the idea of linking statics to parent objects, I've already done 3 months of work placing statics.  If linking objects to a parent can be implemented, it would be nice to have a button that can essentially go 'take this existing static and link its current position with parent' without having to build bases back up from scratch.  Bonus points if the link can kick the orientation parameters of said statics and force them all to align at the same time.

Edited August 18, 2018 by AdmiralTigerclaw

[Ger_space]

2 hours ago, AdmiralTigerclaw said:

Saving what I've done at this point doesn't really affect me.  It all goes to the same place and I keep it under control.

 

 

 

Quote

 

1: There is a glitch when placing terrain decals.  When you switch the KK interface menu to the terrain Decals section, you MUST leave the scene and re-enter the scene before you can work with anything else.  You must also ensure before you leave the scene, that you switch back to the local objects or spawn new objects section of the interface, or you'll have to leave the scene again, because it'll see Decal mode and bork.  If you try to work with any statics without leaving the scene after tweaking or creating a terrain decal, the menus will malfunction (they freeze and stop accepting input) and you'll potentially be forced to restart KSP in its entirety.

This presents several minutes of workflow delays between dropping a decal, and getting started on actual layouts.  It also presents delays if I decide to adjust the decal.

OK, I didn't know about it. I'll check it out and I think I will find a fix for it.   Found it and fixed it for the next release. 

 

Quote

2: The position and orientation controls for statics are Sub-Par.  The most time consuming task in setting up my airports has come from the amount of time I've spent clicking back and forth through the step scale buttons.  While moving the statics across the terrain in this manner is acceptable, setting orientation up is needlessly complicated.  There is a number field for the static's compass heading, but I cannot edit it by inputting a numeric directly.  I HAVE to use the step clicks.  And considering I'm making sure my headings are set to whole number values, having to go in and step them through the three decimal space options I can get at can take anywhere from thirty seconds to a minute per object, TWICE.  (Once for initial alignment, second after I move them and the alignment is altered.)  That's up to two minutes per object for up to thirty objects.  That's an HOUR spent just clicking buttons tediously.  Being able to just punch in "90 [ENTER]" for a runway that faces 90 degrees would cut 30 seconds to 5 seconds or less.  That's a reduction from an hour to a mere 5 minutes.

I think I can do this. It was implemented before, but I threw it out, but after Code cleanup I never put it in. Nobody complained about it (until now). 

I don't bite people, you could have just asked 

 

Quote

2b: The pitch and roll orientation fields don't even have a numeric value display to speak of.  You have to completely eyeball those values.

(EDIT::  2c:  Being able to input numerics without the interface second-guessing you is a must as well.  In the gras color fields, the interface does NOT like it when you put in zeroes or non-number characters first.  So putting in decimal values like -0.22 becomes a pain to set up because you have to enter a non-zero positive whole number, then back-edit it to get past the check.  Given that gras color doesn't DO anything until you hit the 'apply' button, it shouldn't even check at all until you're done plugging your desired values in.  Obviously, if that check gets fixed, it'll have to sanity check you and reject invalid values.  Said input check should also obviously apply to any new direct input numeric fields should they be added. 

Gras color is the same as above, I can change it to make a true editable field. The roll and Pitch values are a interlocked Vector. Its rellly ugly to edit, but I can try to sqeeze the values in.

 

Quote

 

3: When trying to align large objects, especially the ends of large objects like the runways and base plates, the camera being coupled to the center of the object in question with your only way to view being an imprecise camera zoom out and pan-around feature becomes very hassling.  If I could decouple the camera and move it freely on the XY and Z axis while doing fine alignments that would be very useful.  And while I'm sure other mods can do that, I get the feeling that with KK telling the camera to center on a part, those mods would NOT play nice with it.

Camera controll is indeet locked to the center of an object. There is an alternate camera mode available in the settings menu, maybe you like that more, but its still locked to the Object. 

 

Quote

 

 

Aside from that, some 'wishlist' items for KK.

 

1: Object position reference linked to a parent object.  This would make it easy for people using Kerbin rescales with KK implanted objects.  Instead of all the statics being placed in the world with their own explicit grid coordinates on Kerbin's surface, having them all positioned and oriented in relation to a base 'master' or parent object of some kind would allow you to move the parent object around, while keeping everything in place.  The best candidate for that would be using a terrain decal as the base core/parent object.  It's effectively the foundation for any base anyone is going to build outside of unique circumstances.

Thats something I wanted to implement, but I will need to change a lot of Code for it. 

 

Quote

2: In relation to the above, also having orientation references linked to the parent object would be useful as well.  KK's statics have slight orientation shifts over the surface of Kerbin, resulting in the problems I've been having aligning things like upscaled runways and taxiways.  If every static's idea of which way is 'UP' is based on the center-point of a terrain decal instead of their exact position, then they will NATURALLY line up instead of being slightly off from each other by half a degree.

 

1 and 2 here would have the bonus affect of being able to 'rubber stamp' structure complexes.  Just copy a complex, change it's name and the name references of the child statics, and you ONLY need to change the location information of the parent.  BAM!  Instant cloned base.

thats not possible, because Unity engine is having trouble creating copies of copies of gameObjects. I don't know why, but its my personal nightmare, since I started to make squad statics available. I could try to rubberstamp complex infrastructure, but then I would have to recreate it every time from scratch. 

 

Quote

 

I get the feeling this was either implemented and forgotten, or implemented but broken for some reason, because data files have fields like 'object is center of base' or something along those lines with a YES/NO for the bool control.  But nobody actually uses it, and I don't know how if it IS available.  There are also seemingly intuitive options in the static editing interface like object snap that I can't figure out and seem to just make things relocate to really ugly spots.

Thats an internal thing, AlphaAsh made it visible for some reason, but I don't know why. I can make my own group center anytime. (and will do it)

Quote

 

EDIT: In further relation to the idea of linking statics to parent objects, I've already done 3 months of work placing statics.  If linking objects to a parent can be implemented, it would be nice to have a button that can essentially go 'take this existing static and link its current position with parent' without having to build bases back up from scratch.  Bonus points if the link can kick the orientation parameters of said statics and force them all to align at the same time.

The only thing that would be needed would be to add the group name to the PQSMap, then I could automatically link the group objects together onload. This would make a group editor much easier. 

 

Which KSP Version are you working on? 

 

Edited August 18, 2018 by Ger_space

[AdmiralTigerclaw]

6 hours ago, Ger_space said:

thats not possible, because Unity engine is having trouble creating copies of copies of gameObjects. I don't know why, but its my personal nightmare, since I started to make squad statics available. I could try to rubberstamp complex infrastructure, but then I would have to recreate it every time from scratch. 

No, I would rubberstamp from outside the game.  If the buildings reference the parent for their position informaiton, all I have to do is copy the folder, rename it, rename the files, and change the world position of the parent.

[Ger_space]

6 minutes ago, AdmiralTigerclaw said:

No, I would rubberstamp from outside the game.  If the buildings reference the parent for their position informaiton, all I have to do is copy the folder, rename it, rename the files, and change the world position of the parent.

that will still require some hefty code&config changes, but some quick tests showed promising results. 

[AdmiralTigerclaw]

4 minutes ago, Ger_space said:

that will still require some hefty code&config changes, but some quick tests showed promising results. 

 

Cool.  The people who have kerbin rescales would likely REALLY like this working.  So long as the parent's Lat/Long data is what sources the initial position...

 

EDIT: (And I'm running 1.2.2  Bottle Rocketeer pointed that out.)

Edited August 18, 2018 by AdmiralTigerclaw

[Ger_space]

8 minutes ago, AdmiralTigerclaw said:

 

Cool.  The people who have kerbin rescales would likely REALLY like this working.  So long as the parent's Lat/Long data is what sources the initial position...

 

EDIT: (And I'm running 1.2.2  Bottle Rocketeer pointed that out.)

1.2.2... I hoped it can die out... I'll try to make the current code basis compatible again.

[Ger_space]

21 hours ago, AdmiralTigerclaw said:

 

Cool.  The people who have kerbin rescales would likely REALLY like this working.  So long as the parent's Lat/Long data is what sources the initial position...

 

EDIT: (And I'm running 1.2.2  Bottle Rocketeer pointed that out.)

here you go:

https://github.com/GER-Space/Kerbal-Konstructs/releases/tag/1.3.9.15

 

Backport of the editor changes to 1.2.2... now I will develeop everything first on 1.2.2 /1.3.1 and then port it to 1.4 

[ss8913]

I'm confused, are these airports included in KSR or is it a separate download?   or is it not yet downloadable?

Are there any plans to integrate this with Kramax autopilot or should I get started on making Kramax flight plans for these airports myself?

[AdmiralTigerclaw]

These are separate.  But they require KSR to work as KSR has the static objects (also known as assets) that they use.

 

As for Kramax, I'm not messing with that myself. 

[ss8913]

yeah, I know they require KSR, I just can't find a download link for your work, does it exist yet?  didn't find it on the first page where such things are usually pinned...?  am I dumb or is it not there?

update: I am dumb.  found it.

Perhaps I will make kramax flight plans; for those of us using FAR, it's the only functional aircraft autopilot in KSP, so... kind of a must-have.

Edited August 27, 2018 by ss8913

[ss8913]

I notice this adds a lot of new airports and removes a bunch from the old KerbinSide (like Kerman Lake, which was always a tricky approach, kinda like Kai-Tak, in a way).. so.. as of right now, the default Kramax flight plans only work for the island and KSC; runway changes have invalidated other existing approaches

 

So... I'm going to make some.  I'm familiar with real-world IFR flight, charts, procedures, I have a pilot's license.. and I'm at least somewhat familiar with the haversine formula and related stuff, and how to implement that in a few different languages, so I think I can make some python code that will take a runway heading, threshhold lat/lon, and desired disttance to FAF/IAF/etc and create something workable.  Anyone have a preference as to which airports they'd like to see a Kramax approach for first?  I was thinking one of the ones closer to KSC as that'd be easier to test.. maybe the airfield on the island NE of KSC?

Edited August 28, 2018 by ss8913

[AdmiralTigerclaw]

5 hours ago, ss8913 said:

I notice this adds a lot of new airports and removes a bunch from the old KerbinSide

 

This is inaccurate.  This doesn't remove anything.  KSR Airports a completely different brand and set of airports that share no lineage with the original Kerbinside.  Please read the information I placed in the OP.  I express this fact rather explicitly in the FAQ, among several other things.  Then you won't 'notice' anything, you'll flat out KNOW.

[ss8913]

I realize it is a new mod.  however I'm sure a lot of people are like me in that they are migrating to this mod from the old kerbinside, and in that context, my statement is accurate.  since the name is roughly the same, people think of it as a continuation,  or something co politely different, which is what it actually is.  and that statement was just a side note to the point of my post anyway.

[AlphaAsh]

On 7/26/2018 at 8:28 PM, AdmiralTigerclaw said:

D: Launch Failure, Disappearing Airports, and Vanishing Space Center Buttons.
Don't know what causes these, and they seem to be KK related anyway.  Launch failure usually involves a message saying the spawn you selected from the SPH doesn't work in some manner.  Disappearing Airports are airports in which the entire static set doesn't spawn into the scene when you do.  Vanishing space center buttons occur when you switch a default airport, and the buttons linking you to the main functions don't appear as they should.  In these three cases, don't even bother fiddling with anything.  Restart Kerbal Space Program to correct the problem.

I never could track this down when I was working on KK. I've always suspected it's a conflict with garbage handling and video drawing. The common symptom was you'd make a base, go to KSC, select the base and then promptly spawn on an invisible runway, where the colliders worked fine. Only a restart of KSP sorted the issue.

@Ger_space may have more up-to-date info on this, if it is related.

On 7/26/2018 at 8:28 PM, AdmiralTigerclaw said:

B: Mesh Drift Syndrome
Mesh Drift is mainly caused by floating point numbers and is mostly uncontrollable in KSP's grid system.  It is more or less harmless except for the runways.  On upscaled runways, mesh drift may cause small 'gaps' between the white painted stripes, and the gray concrete.  These gaps are not related to Tarmac seams.  This effect is more pronounced and dangerous to aircraft as you move away from the equator and upscale the runway.  Mostly if you upscale the runway.  I try to mitigate this as best as I can by niggling the runways around at creation and checking the gaps.  Luckily, the most probable offender, Spaceplane Runways, are right smack on the equator and their mesh drift is almost non-existent.

You can spot Mesh drift's effect when rolling down the runway over the centerline stripes.  You may spot your landing gear doing small 'bounces' as it rolls over the transitions.  The bouncing is non-threatening.  However, the red-line effect is if the gear slips INTO one of the 'cracks'.  At that point, the aircraft will 'stub its toe' and rip a gear off.  If traveling on a takeoff or landing roll, this may result in a case of spontaneous unplanned rapid disassembly (often refered to as a 'crash' of the non-computer type).

This is extremely insightful and I'm pleased to see you have formalised it from a technical perspective. This issue is something all static modellers should be aware of, especially when making larger statics, such as runways. It's also why sometimes it is better to break up a larger model into multiple meshes.

[AdmiralTigerclaw]

1 hour ago, AlphaAsh said:

I never could track this down when I was working on KK. I've always suspected it's a conflict with garbage handling and video drawing. The common symptom was you'd make a base, go to KSC, select the base and then promptly spawn on an invisible runway, where the colliders worked fine. Only a restart of KSP sorted the issue.

@Ger_space may have more up-to-date info on this, if it is related.

This is extremely insightful and I'm pleased to see you have formalised it from a technical perspective. This issue is something all static modellers should be aware of, especially when making larger statics, such as runways. It's also why sometimes it is better to break up a larger model into multiple meshes.

 

The mesh drift problem is less about the model being large, and more about the model being scaled up using the KK scaling option.  The gaps tend to still be there, it's just that when the model is scaled to normal size or smaller, the gab isn't pronounced or dangerous.  When you scale the model up, the gap becomes wider in direct proportion to the upscale.  Get big enough, and landing gear slip into the hole.

[Ger_space]

12 hours ago, AdmiralTigerclaw said:

 

The mesh drift problem is less about the model being large, and more about the model being scaled up using the KK scaling option.  The gaps tend to still be there, it's just that when the model is scaled to normal size or smaller, the gab isn't pronounced or dangerous.  When you scale the model up, the gap becomes wider in direct proportion to the upscale.  Get big enough, and landing gear slip into the hole.

I only use the unity game object scaling. I think the source of the problem is that the tm runway doesn't use a single big runway collider ( Which it should do) 

Then you would only see the gaps in the paintings, but you drive magically above it. 

Please contact the creator of the asset, either he can create a single collider or move the vertexes closer together 

[AdmiralTigerclaw]

8 hours ago, Ger_space said:

I only use the unity game object scaling. I think the source of the problem is that the tm runway doesn't use a single big runway collider ( Which it should do) 

Then you would only see the gaps in the paintings, but you drive magically above it. 

Please contact the creator of the asset, either he can create a single collider or move the vertexes closer together 

Wut?

*Blink*

 

 

GUYS!  Come on!

 

 @Ger_space , @Eskandare

Are you two not in constant communication with each other about how this stuff works?  Because NOW Ger_Space is making a post like you've never even exchanged posts before.