SilverWolf

Thank you, @Caerfinon. I'll look in to that feature. Good news: I got something working. Bad news: I do not understand why. At least I've learned that the spawn point needs to be Y-up, Z-forward. Thanks, SW Ahhh, so the spawn point GameObject must be an immediate child to the root GameObject. It can't be buried in the hierarchy.

Thank you, @Caerfinon. Your personal preference would be mine as well, as it were. How would one create a universal spawn instance, to begin? Setting that question aside for a moment, since the runway model is the suspect, what might I need to fiddle with? In the absence of documentation, my spawn point is an empty game object, Y-up Z-rear. Does the spawn point need a collider? Is there a layer it must needs be assigned to? Is it acceptable for it to "rest" on the runway surface, or must it be elevated? Thanks, SW

Thanks for getting back to me, @ColdJ. Yes, this is a custom built model. I've got an empty game object sitting above the runway 12 designator named "spawn." Could it possibly be upset due to an incorrect orientation? Thanks, SW

Please forgive the inquiry; I am not smart enough to resolve this on my own. May I have some help troubleshooting this runway? It refuses to populate in the launchsite menu. Thanks, SW

I’ll throw my opinion in the hat for giggles. I beta tested for Final Fantasy XIV after Garlemald pulled Dalamud down and meteor fell. 2.0 was in development for about two years, because 1.0 was a train-wreck due to performance and interface. Beta testing occurred in several rounds, where our game progression was volatile. We spent about a week to two stress testing and bug hunting each round as finished systems were sequentially brought online. When we were done, and Naoki was satisfied, then he asked us to renew our subscriptions, and I was happy to do so. From that experience, cross-referenced with videos and forum posts by my fellow Kerbonaughts, I suggest this game is in a very loose alpha. You cannot morally ask consumers to pay finished-product value for an unfinished-product, let alone a product that is still in alpha, or even beta. Early access does not mean an alpha or beta release; it means you think the product is ready to launch. We go through this every time we release an expansion in Final Fantasy; and sure we find some bugs, and a massive hot fix comes out in a week, but at its core it performs well, and is ready to go. I do not agree that we can soundly compare KSP1 to KSP2. Squad was a couple of guys in their garage (initially.) It takes me a long time to do something, even after I decide to throw a whole week at it. Take 2 is major league. The expectations are justifiably different, and when you’re this big, you don’t get any passes, because you’re supposed to know better. I do not have the answer to this question, but I would be curious to know how many manhours went into one game versus the other. That would be a nice datapoint. I think this decision to request an exchange of value for alpha test was a financial one, and folly at that. Here’s what happens next, I think: they’ll get what they have working, call it 1.0, then Interstellar and Colonies will be their own paid DLCs. I hope I’m wrong.

I've been debating with myself about offering my thoughts for a few days, now. With regards to the development and launch of Kerbal Space Program 2, there are many things that occupy my thoughts. That said, brevity is my native tongue, and so I may not adequately articulate or explain some of my concerns. My point of view is also counter to the majority, so I recognize I am about to generate more enmity than an endgame tank (Final Fantasy reference) in about zero point three eight seconds, but I feel the need to speak. I am approaching Kerbal Space Program 2 with very curbed, perhaps even absent enthusiasm. As I look over game footage, something jumps out at me: the polygon models of most of the parts are the same as they are in the original game. New shaders are being implemented with new, massive textures. The planets in the Kerbol System have received new visuals. Effects have been overhauled and buffed. The UI has either been completely rewritten, or significantly overhauled. Visuals. Visuals. More Visuals. This is what taxes a consumer PC. Texture map size and image processing is the most intensive task of any video game. Add a physics-based simulation on top of it, and well, things get heavy quickly. Yet what are we actually getting for all of these taxes we are about to pay? I personally have not seen anything that tells me there's any real fillet and potatoes to go with weighing the system down. My priorities are probably different than most others': I'm more gameplay-focused than visual-focused. I watched the DailyAstronaut's video from the ESA event, and the higher-end gaming system he was afforded struggled with a simple moon mission because it was bogged down with all of the graphics. Those of us who had initially purchased KSP for $5.00 when it was in alpha were promised by Harvester and his team that in return for backing them so early, we would receive any DLCs to come down the pipe, forever. As soon as Take2 purchased the game, they announced the sequel, and immediately I felt I knew what was going on. They had just purchased a title that had gone viral across the world, and now they wanted to extract as much value from it as they could. The only way Take2 could get around Squad's promise was of course, to terminate the project and launch the sequel, KSP2. Visuals. Visuals. More Visuals. That's what KSP2 so far is. Visuals are inexpensive, modeling and coding are not. Metaphorically, they are applying lipstick and eyeshadow to a pig, and asking all of us to purchase a minimum viable product while dangling a carrot in front of us, a carrot we all have been waiting years and years for, since we started playing KSP in alpha: Colonies, Interstellar, and Multiplayer. The reason these features aren't ready to go on early access is because they require coding, one of those insanely time-consuming and expensive things, and they have yet to determine how much money they are going to pour into them. They're waiting to see how early access sales perform before determining that number. With early access opening in less than twenty-four hours, I just want you all to be careful about your enthusiasm. You're already made the choice, You're here to understand why you made it. I'm not writing to dissuade any of you. If I have given you something to think about, however, I am grateful. My attitude towards this launch precludes me from investing in it, because I see it the same way I see most modern Hollywood sequels: a money grab. However, for those of you diving in head-first, Good Luck and Have Fun.

I'm looking forward to releasing the Kraken. Most of all, I look forward to an updated aerodynamic model that will better facilitate my spaceplane-based space program.

I'm sorry, friends. I know everyone is on the hype train for KSP2, but I'm still awaiting a solution for this problem. I've gone as far as to: Empty GameObject containing the R_Wing_204 model, R_Wing_204 model has it's pivot aligned with the aileron, Renamed Aileron to ControlSurface, R_Wing_204 and ControlSurface's pivot points are +X outboard along intended axis of rotation, +Y forward, and again their pivots are co-linear along the +X axis of rotation, Remove the collider from R_Wing_204 Verify on every test case that ModuleManager.configcache has the module "FARControllableSurface", and the key: transformName = ControlSurface, spelled correctly. As I said, my part works perfectly if I unload FAR. Can someone please educate me what additional requirements FAR has that I am not fulfilling? Thanks, SW

Good evening, lads. I'm experiencing some difficulty with a control surface part I've made with reference to FAR, so I wanted to inquire as to how FAR wants surfaces rigged up. What is happening? The aileron mesh is not being rotated to the full-scale deflection specified in the PAW while running FAR. If I remove the FAR module, everything functions as expected. I have attempted using both the ctrlSrf gameobject and the aileron as the transform with no change to my result. Understanding the heretical nature of my inquiry, I came bearing receipts. I'm also experiencing another anomaly whereby if I write-in the node_attach in the parts' configuration files, their centers of pressure move. Can someone educate me on how node_attach interacts with rootMidChordOffsetFromOrig? Thanks guys, SW

I really admire what you’re doing, sir. You told us if anyone talks about the secret organization, we gotta get his balls.

Some time ago, I noticed how disproportionately massive cockpits were to other aircraft parts, resulting in nose heavy planes in the absence of a rocket engine on the back. What started as a rampage against heavy cockpits metamorphosed into something much more sinister. Using 3ds Max, I created and weighed aircraft structure to create a frame of reference, and thus the games began. Aircraft parts have all been measured and "weighed" using the "volume" of their surface area, including external and internal structure. A considerable weight reduction for airplanes has resulted. Flight deck components such as switch panels, computers, seats, and pilot interface have also been accounted for in part mass. Fuel tanks were measured, and internal structures modeled from scratch to determine fuel capacity. Fuel capacities have also been added to additional wings. Applying rules learned for aircraft has also resulted in dry-mass reductions for all fuel tanks. Liquid Fuel, Oxidizer, and Monopropellant were removed from the game, replaced by JetA-1, KeroLox, HydroLox, and MMH/NTO. This is where Firespitter comes in: each fuel tank has several variants, but now only carries one type of fuel per tank. As a friend kindly stated, I went "Vlad the Impaler" on reaction wheels; they have been removed. Engines have had their masses tweaked, placing them on a steady TWR curve, with the most powerful engines featuring the highest TWRs. Many liquid fuel engines can no longer throttle below 70%, so stages and burns must be planned accordingly. MechJeb is not required, but the module has been integrated into command modules, as well as Kerbals on EVA. Requires Module Manager and Firespitter Download: SilverWolf Rebalance 0.1 Imgur Album: https://imgur.com/a/Mo8GpCY All Rights Reserved.

SilverWolf Aerospace 0.1 has been re-released, and is available on CurseForge.

ModuleManager, there it is. lol. Thanks for the reminder.

Is this compatible with 145? I'm having some trouble in that department, despite a clean install.

I have two saves. Once is aptly named "Crashbox," and the other is my career. All vehicles are tested ad naseum in the simulator (Crashbox) until confidence is high. Once all the gremlins are worked out, the vehicle enters production. Its craft file is moved to Career, and only very minor alterations are permitted (such as adding a piece of equipment, or removing an antenna.) Any modification that does not fall under the purview of a CDL essentially cancels the vehicle's airworthiness, and it must return to Crashbox to receive an STC. What happens in Crashbox, stays in Crashbox. Once a vehicle flies in career, optimal or catastrophic, the results are final. There is no reverting. There are no quick saves. Kerbals do not rise from the dead. I find the introduction of such finality keeps my knuckles white. No one gets left behind, and no Kerbal is expendable. On a side note, I don't hire new Kerbals. I bolster my ranks by rescuing those the Contractors left for dead. As a result of playing MMOs for many years, I'm a completionist. I farm Kerbin for every scrap of science possible before leaving for the Mun. This is quite tedious, and dangerous, but it also means I typically leave for the Mun fairly well prepared. I don't use rockets. Everything, including tankers, are airplanes.