AdmiralTigerclaw

Rocket Science is 'Rocket Science' for a reason. As others have pointed out, Delta-V stands for Change in velocity. The 'Delta' part of it is actually a term used in Calculus. The reason calculus comes into play here is because you are trying to determine the behavior of things that are always in motion. Moreso, you are trying to do so to an object that changes as it performs an action. Calculus is thus known as the 'mathematics of change'. But we're going to ignore that. You don't need to know calculus to know Delta-V. It's just useful to know that Calculus is not as intimidating as it may look. In fact, it's a shortcut. For Delta-V, we're going to imagine we're in a car. But we're going to make some assumptions. For example, the car never slows down when you coast, and the brakes don't work. When you put your foot on the gas, you accellerate from zero to say, 100 miles per hour. Then you take your foot off the gas, and the car remains at 100 MPH. If I phrase this in plain english, you have had a 'change in velocity' of 100 MPH. Or, you have executed a Delta-V of 100 MPH. Now, let's say you only have enough gas in the tank to accellerate from zero, to 70 MPH. (Not a lot of fuel, but work with me here). The Delta-V available to you is 70 MPH. Once you accellerate your car to 70, it stays at 70, and you can't do anything else but coast at 70, forever. Your Delta-V 'Budget' was 70 MPH. If you wanted to say, accellerate to speed, then slow to a stop, you need to find how much you can put your foot on the gas, and then pop the car into reverse and put the foot on the gas again. In this scenario, you can speed up to 35 MPH, then you have to put it in reverse and slow down 35 MPH back to zero. Simple enough, right? Let's move to rockets. First and foremost, the notion of 'fixed speed' like in a car on the highway is almost pointless to use as a metric once you're in orbit. That's because an orbit is simply you falling AROUND an object as gravity pulls on you. At any given moment, your speed changes depending on where you are. A low orbit around earth, for example, tends to be faster than a high orbit. Or, in an elongated orbit, you're REALLY fast at the lowest point, and slow as molasses up at the highest point. You still need to know your speed relative to the object your orbiting, but that's only so you can do the math needed to figure out what your orbit is supposed to look like. We have computers doing that for us here, so we don't care beyond understanding that it is happening. Let's say we want to execute a change in orbit, going from a low orbit, to a higher orbit. We need to perform several 'burns' of specific length and power. The lower the power, the longer the burn, and the higher the power, the shorter the burn. Either way, in order to get into the higher orbit, you need to think about what you're actually doing. Since an orbit is simply glorified falling, you need to 'fling' yourself faster so that you'll 'fall' farther up to the higher orbit. Flinging yourself is a change in velocity. No matter how big your engine is, or how long you have to burn, the change in velocity is your fixed value. Once you get up to the higher orbit, you have to burn again, or speed yourself up more, so that your new velocity keeps you up high as you fall around the parent body. Once you have done so, the only way to come back down is to slow yourself down in that high orbit with another burn, usually, a change in velocity equal to the burn that stabilized your high orbit. Every move you do from one orbit to another in this manner requires this to happen, and thus you have to burn fuel for any change you make. Now, the reason you use 'Delta-V' instead of say, 'gallons' or 'liters' when talking about rockets is simple. No two burns use the same amount of fuel. If a rocket weighs 10 tons, you need to burn MORE fuel to change its velocity than a rocket that weighs 5 tons. But wait! There's more. As you burn fuel to change velocity, your rocket becomes significantly lighter, really fast. That 10 ton rocket BECOMES the 5 ton rocket in a hurry. That means the math you need to do to find how long and how powerful a burn you need changes by the second. This is where the 'calculus' part actually comes into the picture. Regular algebraic math cannot easily solve this problem without making you rewrite the problem over and over again dozens of times a second. A computer can do that, but a rocket scientist with a slide rule back in the apollo days can't. Calculus, while more abstract a math system, has the tools needed to solve these 'changing' equations in real time. Again, we're going to skip over it. Anyway, because you can't base your ability to go places based on blind fuel capacity and a 'gas mileage' like a car, you have to determine your range through a different method. Luckily, rocket science does allow you to find out how much total change in velocity your rocket will have. As long as you know the total mass of your rocket, and the mass of your fuel, you can determine how much it can change in velocity. Likewise, orbital changes are all based on velocity changes. Thus, the Delta-V budget can almost instantly tell you where you can go, and whether or not you can come back. It is the single most important number out of all the statistics on your spacecraft. Even above the Thrust to Weight Ratio of launch. If you pull up one of the 'Delta V Maps of the Kerbol System' that are on the internet, you can chain the paths to determine how much Delta you need to get to say, low Duna orbit from Low Kerbin orbit. Then, you can look at your rocket and go 'I don't have enough, need a bigger rocket'. This isn't as 'simple' an explanation as others might be putting out. But I feel that making the explanation TOO simple may become a bit misinforming, and understanding the background usually makes the knowledge more solid. But amazingly enough, the end point of all this is pretty simple, even if the journey to get there is filled with complexity. Then again, the point of these kinds of systems is to simplify the complicated into something nice and bite-size.

It's in your folder because I chose to put it there specifically... 1: To ensure that it references your assets correctly and gets removed if they remove KSR (without having to go 'what all went with this again?'). 2: To keep it easily located and the information compartmentalized, especially while I'm busy editing new bases in. Also, at this point, the folder nesting call for all the base thumbnail images are based on KerbinsideRemaster's folder structure as the parent.

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.

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.

As @Eskandare pointed out: KSR Airports for Kerbinside Remastered will be right up your alley. I'm focused on a large number of well-documented airports scattered around the entire planet. The goal is 70, I think I'm in the 30s. I'm working on an audio project at the moment elsewhere, but I should be getting back to this soon. And @Ger_space space dropped a KK update for me to use as well once I jump back over that SHOULD increase my workflow speed significantly. EDIT: And I should mention, KSR Airports is in the mod development forum, and it has a working download to play with.

Stuff like Kerbinside GAP only works with old Kerbinside and all the goodies that were developed with that previously. With Kerbinside Remastered and my work on KSR airports, you would have to create an entirely NEW iteration of Kerbinside GAP. This is because the locations and static object assets are completely new and use different names and locations. A contract from Kerbinside GAP would thusly be unable to find anything at a minimum, and generate a contract to fly to an empty spot of land in the middle of nowhere if it DID do anything. Really, the only thing Kerbinside Remastered has in common with Kerbinside is the name and overall purpose. Beyond that, they are two separate entities.

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.)

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.

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.

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.)

@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.

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.

REJOICE! ...I have an update. https://github.com/AdmiralTigerclaw/KSRAirports/blob/master/KSRAirports_0_0_3.rar We have more Regionals, plus another Local courtesy of @Bottle Rocketeer 500 . In this edition, we worked to fill some of the far side of Kerbin from KSC to give players a general fill of airports. This will probably continue to be my method of placing the remaining airports until project completion, just to satisfy gameplay. Anyway, more ideas for regional airport names are welcome.

I don't know why I bother making a Readme file with a name as loud as "ReadMeRightTheHeckNOW!" People just ignore it... ERHEM... RMRTHN file: Section five.

Move the files manually and ensure all the relevant mods for them are installed and functional in your rollback?

I don't know. The problem isn't KSR airports if that is the case. As pointed out in the FAQ, I have no actual code here, just placement files for the statics and some extra stuff that don't go into the game. So the problem is going to be up stream. If it's not Kerbinside Remastered itself, then it is Kerbal Konstructs. And more than likely, the problem is KK having a problem with 1.4.4. Sorry mate.

Just as you responded, I found what I needed to find, see my above post.

Okay, you should be seeing Eskandare's various bases here. You could have one two problems. 1: You have old school kerbinside installed still. This will not work. 2: You have a version of Kerbal Konstructs that does not strip the old statics out. These are problems because the inclusion of the old statics interferes with the new ones, and causes them to just... 'POOF!'. I know what the correction you need to do is, but I can't remember the exact name of the folder that needs to go away. So give me a minute to hunt it down. Okay, in the Kerbal Konstructs folder, pull the entire statics folder out and drop it on your desktop. I don't want to force you to delete it just yet, but it shouldn't be there. Alternately, get the modified compatible kerbal konstructs from @Ger_space post HERE:

In the station, open the KK icon. This should reveal a strip of buttons. There you should find buttons for including/excluding open and closed points from the list. Make sure that runways are turned on, and toggle the 'show only open' or 'show only closed' buttons to see if they work. Also, tell me what the two locations it shows are if that doesn't work.

If I recall, to open airports in a campaign, you must first land at the airport and then access it through the KK menu. If you pop open a creative game, you should have all the airports visible in the tracking station. Ensure they work there, and it should just be that none of the airports are open yet. Mind you, they aren't CHEAP. And since I'm working from large to small on airports, the most expensive internationals and the medium expense regionals will be first. Use the chart to pick a destination airport you want.

And, progress on airports in the form of the chart. That's filling quite the page at this point.

Several questions: 1: Do you have any old versions of Kerbinside installed? 2: Where did you install KSR airports (where did you put the folder)? 3: Did you open the airports yet? Check if they show up in a creative game.

Feels a touch Awkward since my first name is Ernest, and I already stuck an airport in with my name hiding in it as it is. But I guess an excuse to share my name with someone on an airport works as well. I'll add it to The List.

You are welcome to that, just beware the data-chart will need to be modified to match.

Version 0.0.2 up on the github. Addition of JMK International and Angel Island. For now, the sound cube has been pulled from Loui's. More in the change log file located in the DL.