Charlie_Zulu

Aww, @Rath, you didn't mention my score in the OP!

@Rath, I'm still not on the scoreboard. Since it's not quite in the spirit of the challenge and I can understand why you wouldn't want it there, can I get a honourable mention in the light category at least?

Again, I'm not sure what I'm supposed to be checking. I've checked the engines, and they can run for several hours at the right RPM under physics warp on the test stand, so it can be assumed that they should never lose thrust. The plane can sustain flight as long as the engines don't lose thrust or parts fall off. There is no reason for parts to spontaneously fall off in flight when the plane is flown properly. Ergo, the plane should keep flying forever when flown properly, and I'm not sure how flying it for 20 minutes is any less comprehensive a test than flying it for 20 days. What exactly would flying it for a longer time period test? Edit: After a bit of math, it'd take me at least 4 days MET if I wanted to comfortably get first place. I'd rather not.

I don't see a requirement to have actually flown it for the maximum range. @Rath suggests flying it until it crashes and then using F3 to check, but again, this thing should never crash. There is no change in performance over time, and I've flown it for ~20 minutes or more wanting to make sure that it was actually capable of sustained flight and didn't wiggle itself apart. Since the plane can keep flying, it'll only crash when I stop paying attention and it starts to pick up some bank and crashes into the ocean. That's a test of my own willingness to waste a few days of time when I could be doing something better as opposed to the capabilities of the aircraft.

It's definitely not following the spirit of the rules, but I think I have an entry that literally cannot be beat. May I present the Cygnus B: Imgur Album Scoring: The maximum speed I took her to without crashing was 34 m/s. She can go faster, but it's hard to recover from the dive without stalling out and I honestly didn't bother trying. Range is infinite, since RTGs last forever and the engines run on electricity. There are 2 passengers. There are no flight attendants. Total bonus points is either -10 or something around -600. Final score is 34+(∞/10)+(2/5)*1+(0/2)-10 = ∞ Category is light.

Well, uh, damn. My F.2C's definitely not in a state where it's competitive, and the F.4C-D only wins about half the time against the current KotH - I had it winning reliably, then I tweaked some control settings, and now I can't get it to do anything better than break even. If I can PM the F.4C-E to you by Monday, can it still be put in? How successful do I have to be against the current KotH to allow entry?

Recent testing against a pair of Crown Nightingales has led me to discover some interesting things; first, the German 20mm cannons (MG FFs? 151s?) are sparkle cannons, and second, my F3C-B can fly through a Crown Nightingale's wing and suffer no damage (while the Nightingale will lose the wing). Honestly, I'm quite surprised at how the cannons are balanced in AA - Hispanos have a lower muzzle velocity than MG 151s, while doing more damage. This is despite the ridiculous amount of HE filler used in minengeschoss, and the lower muzzle velocity of 151s IRL...

How bad is the drag, though? I found that the largest source of drag on my designs was the vertical engine; you're achieving a negligible amount of lift in exchange for a huge increase in mass (almost double a single-engined design) and a lot of drag. It doesn't seem like a helicopter is worth it. I've experimented a bit with multi-engined crafts in an effort to build a "support" fighter. My largest has 4 engines in 2 nacelles and needs a fat-455 wing to have acceptable wing loading. I'll admit, I'm tempted to keep pursuing it just because it can go 80 m/s in a 30 degree climb and can outrun anything else in this competition, and the centrally-mounted guns means it absolutely tears apart anything it hits, it's just really damn big. I'm looking into possibly armouring it up and using it to tank damage while a pair of highly maneuverable fighters pick off distracted enemies.

The problem with "they should only have one engine" is that there are counterexamples in real life. The Germans loved putting multiple D.IVa engines on planes; I can't recall the name, but they even managed to make a bomber with 4 of the engines coupled together to power a single propeller. If someone wants to put more engines on their plane, that's fair, especially since it's about an extra tonne of mass for every radial engine added, and the engines produce a LOT of drag. As for speeds, the vast majority of planes in the competition are limited to under 360 km/h. While faster than most WW1 planes by about 120-150 km/h, it's in line with what would be expected from interbellum designs - the I-15, for instance, could manage those speeds without difficulty.

Also, FYI, the wing area/mass ratio on those swept wings is terrible. I switched to using them for a while after the low heat tolerance of the FAT-455 tails caused my wings to come off after a single hit, and found that I was consistently getting planes much heavier than its counterparts.

Yeah, I pretty much gave up on defeating the Sweep because of this. I'm not a fan of making planes with multi-part wings, nor do I like doing things like clipping engines into fuselages like you've done. If I made a plane with a large enough wing to support 2 engines side-by-side, I had to have larger wing pieces, which meant that a shot to the wing by a Sweep was a guaranteed death. Meanwhile, I could score 5 or 10 confirmed hits on a Sweep with twin nose-mounted Hispanos, and it'd still keep flying. Monoplanes in this competition also have the disadvantage of presenting a larger target as well, meaning it's easier for enemy planes to land a hit on them.

It's 1200 K, half that of the other airplane parts (which are all 2400 K), at least according to the KSP wiki. If anything it's a disadvantage, but I just like the wing profile too much to consider giving it up unless I'm made to do so. Here's the link again, although I'll be changing it; it consistently loses to the (old) SI-5 in a one-on-one for some reason despite having much better performance on paper. I've already made a C version that has a much lighter cockpit made of wing panels and radiators.

Do you mean the empennage or the tail parts used for the wing? The rudder and elevator are the old elevons (I think Elevon 2 and 3?). The wings are the FAT-455 tails, which aren't a Mk.3 profile part or otherwise associated with the Mk.3 fuselage system aside from being added in the same update. If you want, I can add additional control surfaces & disable the tails' built-in control surface, but I'd rather not replace the entire wing; I really like how they look. Thanks. Thanks for the fix. I've played enough flight sims to be aware of muzzle velocity influencing drop - that's why I specifically mentioned the MK108s, which had that issue in real life as well. However, it's fairly common to account for that and aim upwards slightly; I'm wondering why the BDA AI doesn't. The 12.7mm AN/M2 has a negligibly higher muzzle velocity than the Hispano Mk.2 anyways, and the Hispano's muzzle velocity is very high compared to German cannons or the ShVAK.

I've noticed some issues with the AI when trying to test ASC III crafts. I have two relatively capable fighters (one can keep above 50 m/s in a 5g vertical loop) that are both stable (both the AI and SAS hold them straight towards a moving target), and they're both armed with Hispano Mk.2s. When I pilot them, I have no trouble shooting things down, even with mouse & keyboard. However, I've had two glitches. First, the AI won't start the competition; it gets hung up on "pilots are taking off" & keeps both planes orbiting at their cruise altitude until they run out of fuel. If I use Guard Mode to get around this & attack cruising targets, the AI just shoots at a point slightly underneath the enemy. I'm suspecting that it's not compensating for bullet drop - it was even worse when using MK108s. This means you have to get right on the enemy's tail in order to land a shot, or just get really lucky. As well, a few general questions: First, how do guns interact with engines? Do guns have a virtual synchro gear, or do they just ignore the effect of the prop? Is mounting a Motorkanone desirable? Finally, here's my current flagship aircraft, the F2C-B Tern, though I've been unable to test it. I'm currently working on a high-performance monoplane variant with a higher cockpit, as well as a biplane with a lightweight cockpit and better forward visibility. If the Kerbal pops out, just re-board the seat.

If you could do this, it would be great. Kerbalism's calculation of communication range is much more in-depth than RT's thanks to the influence of space weather, but the deficiencies of the signal system (the absence of an autopilot, connection lines, and for some, signal delay and directional antennas) makes it preferable to use RT. Your adaptability to allow other mods to work with Kerbalism is already remarkable, and this would go above and beyond.

Exactly. Basically, a variable that says "this causes issues not when we're at zero/full capacity but at full capacity/full capacity" when true. As for the Persistent Rotation bug, it might be an issue with PR draining the EC of the craft for "station keeping". AFAIK, PR has a feature where you can keep a vessel pointed at a target during warp & it automatically detracts some electric charge or monopropellant to simulate station keeping. It seems that this feature is drawing too much EC when the vessel is unloaded and it's killing Kerbals.

I'm quite excited to play with the new version. Good job! @ShotgunNinja, I've noticed that it's lacking a Kerbal-ized realistic profile (like what TAC LS uses) - would you be interested in me helping in making one for you? It wouldn't be the exact same as TAC, but it would be similar. I won't have the time to do it completely, but I can source you values and do the appropriate conversions. Also, I know literally nobody else wants this feature, but is it possible to eventually add a .cfg option for resources to kill the crew not on depletion but on the capacity filling up? I feel bad bothering you incessantly about it, and I'd love to know if it's an eventual possibility or not.

I'm purely hypothesizing, but the start/stop behaviour and spinning could be manifestations of the same effect. Let's assume that the static friction is significantly higher than the kinetic friction. Let's also assume that KSP joints wobble and are generally weird, which for anyone who's built anything like this, should be fairly well-known. I'm imagining the following is happening: As the vehicle moves, the forces on the various plates are rather high and change slightly due to inaccuracies in the simulation. This, in turn, occasionally (heh) causes the joints to wobble, resulting in the plates all moving at different speeds relative to the ground. Since the forces here are pretty large relative to the breaking strength of the joints, you get parts occasionally moving backwards at close to the speed that the vehicle is moving forwards for very short periods of time before the physics sim says that they're too far from their attachment point & there's now a force pushing them back into place. During these periods of the plate being stationary relative to the ground, the game thinks the part's friction should use the coefficient of static friction, causing the force of friction to increase, in turn causing the part to "stick". The parent part now needs to apply an even greater force than normal to move the part back into place, causing greater wobbles, and increasing the likelihood of the plate sticking again. As well, this unusually high force isn't balanced out on the other side of the vehicle. Since one plate will start to wobble before the others, and the plates aren't in exact alignment (as can be proven by looking in the .craft file; numbers being exactly the same between parts is rare even with symmetry), one plate will tend to "stick" more often, and the vessel spins. When the vehicle spins far enough, the engine's now applying a force that's not directly opposing the force of friction, and the vehicle slows down. This lets smaller wobbles cause sticking, increasing their likelihood, bringing the vehicle to a stop until the thrust vector is along the velocity vector again. Note that this is all purely conjecture, but it seems likely enough. I'm not sure how we could test it, though.

@ShotgunNinja, first of all, your development of this mod has been great and it's quickly looking like it'll become an absolutely amazing mod. If you need any help coming up with realistic LS values, I'd highly recommend looking at the TAC LS configs for stock and RO, since they also have "realistic" rates scaled to kerbals and humans respectively. As well, NASA/CR—2004–208941 provides a very comprehensive baseline for human values. I've noticed that SAS stays on during a control blackout, but cannot be toggled. I'm a huge fan of this feature, especially because it means that things like fixed directional antennas (as we had previously discussed here) could be implemented without requiring a dedicated autopilot; you'd just need to have an option to "control from here" on antenna parts and use SAS to point towards target. Would it be possible to, in a future version, extend this functionality (or, at least, the circumventing of the signal block) to actual autopilots like kOS, RT's flight computer, and MechJeb? That way we could perform things like automated Mun landings on the far side, which currently is impossible. Finally, is there ever any plan to allow for multiple star systems? I'd really like to have them in my game, and while Kerbalism's finally at a state with .9.5 where I'd be happy giving up more stars for your mod, I'd rather not have to. EDIT: Forgot to ask, but under the .cfg-based LS system, would there be an eventual possibility of allowing for the buildup of toxic resources to kill the crew (i.e., when resource is full, crew dies, instead of when resource is depleted, crew dies)? That way, CO2 poisoning could be added using your mod's framework, which is something I've always wanted in a LS mod.

Still, that cuts out the niche I was looking for. I'm messing around with designs that are largely inspired by the CF-105 (which primarily would be heavy, fast missile-armed interceptors). This means that I can close in with less maneuverable targets, but single-engined fighters pose a difficulty since the AI can't use the higher top speed effectively. I was thinking that perhaps the PAC-3 could be used against them, since the higher speed would reduce the amount the enemy could evade. Sadly, it seems like it won't work out; the best bet will be to switch to a lighter concept.

My thought was that, despite being a larger missile, the PAC-3 could possibly be more likely to ensure a kill per missile due to the higher speed. Since the number of BDA parts would be limited under the new rules, the probability of kills/number of missiles becomes important. My current design's a relatively heavy fighter, and up to 6 PACs fit under the wings without a problem without a huge loss in performance. The PAC-3 being a SAM shouldn't mean it's useless against fighters; the increased size would instead suggest that it's more capable as an anti-aircraft missile. @drtricky, thanks for the info. I didn't expect a lower chance of hit, but that would definitely make the AIM-120s more popular. That's also because dogfighting then is simply a matter of who can build the plane with the greatest instantaneous and sustained turn rate. The AI's crap at energy fighting and BnZ since it won't accelerate past 200 m/s even if you have the engine power and doesn't seem to care about your energy state. Forcing all planes into gun range would make for very monotonous matches of either a quick kill by the plane to make the best initial pass or two planes endlessly circling (if their performance is relatively close).

I'm trying to design a plane for ASC-II, but I'm wondering if someone can help. First of all, the AI seems to be doing weird things; the plane oscillates up and down when it tries to fly level (despite the plane being naturally stable and requiring no trim), it doesn't retract gear when taking off, and it really likes to run engines in dry mode. As well, despite having ECM and chaff, I still routinely get killed by AMRAAMs; I think it's that the aircraft isn't very maneuverable, but increasing control deflection causes worse oscillations. Is there a detailed list of the rules for ASC-II? I'd like to know if it's worth using the BDA weapons mounts over surface-attached cubic struts in order to keep part count down. As well, have you considered implementing BDA limitations as a function of vessel mass, so that heavier, less maneuverable aircraft could carry more ordnance while lighter aircraft would be limited to fewer, and limiting not by part count, but by some other stat (total part mass and total part cost spring to mind)? Finally, has anyone considered using PAC-3s instead of AIM-120s as long-range missiles? If part count is the limiting factor, they're more effective and leave more room for countermeasures.

That would be great, but it would require an autopilot to re-orient the vessel after exiting timewarp, since the antenna will have moved off-target. Speaking of autopilots, even without signal delay, there still needs to be one. Right now, I can't execute a maneuver on the far side of the Mun unless I've got a communications satellite in Mun orbit or parked just outside the SoI. Would it be possible to allow for MechJeb, kOS, and the RT autopilot to circumvent the control lock so that we can still execute pre-set actions? I really want to find a way to use your radio propagation rules instead of RT's, since it seems more in-depth for omni antennas; it just needs some polish. As well as directional antennas, it would be nice if there were more antenna scopes; specifically, one that's below 'orbit' and only good for low orbit/cismunar communication intended for extremely small/light antennas, one that's in between 'near' and 'far' for the equivalent of trans-joolian probes, and one past far for interstellar communication (if you ever get it working). The one remaining feature of RT that you haven't replicated is ground stations; it seems like you just take distance from Kerbin. It would be nice if there was a ground station at the tracking station that has to relay your signals, and upgrading the tracking station increases the range of the tracking station's relay antenna. If you're adding a generic ModuleLifeSupport, could you add an option for the crew dying not if the resource runs out, but instead if there's no more room on the vessel for any of the resource? That way we could implement a CO2 system if we want where filling the tanks with CO2 kills the crew, instead of having to do the workaround of anti-CO2 running out which is really weird. Looking at your CME system, it seems like it won't target vessels in interplanetary space; would there be a way to add this so that CMEs are randomly fired at (groups of) vessels not near a planet? Finally, it would be nice if you could add a geiger counter that reports the ambient radiation the same way as the original stock experiments reported their respective attributes. That would make understanding what's happening with the radiation much easier. Why not just do a check to see if it's a star or a planet? Kopernicus has to have a field where the body is defined as being either being a star or planet. The issue then would probably be changing the mod from assuming that the universal parent body is the only star and modelling in the heliopause/heliosheath and their effects on radiation.

I wasn't suggesting that you add more complicated CO2 scrubbing; I was just trying to answer your question about CO2 being dumped overboard. A simplified yet quasi-realistic system would be to have the crew die if either O2 ran out or CO2 hit the max. Scrubbers remove CO2 and supply O2, the atmosphere can be vented to remove CO2 (and on airless worlds, O2), and O2 can be supplied from tanked oxygen. That forces players on long-duration missions to pack a scrubber instead of just filling a RealFuels tank with oxygen and ignoring the mechanic, but still lets players on short-term missions (LKO flights) to not worry about it. If players want more complicated scrubber mechanics, they can just delete your scrubbers and add their own. After looking at your Signals portion, it seems to be better than RT except for that it lacks directional antennas. Would it be possible to add support for directional antennas like RT, even if they're not incorporated into the mod? Finally, is it planned to ever support multiple star systems in Kopernicus?

Honestly, there's no reason you couldn't throw all of those settings into a settings.cfg file aside from coding limitations; they're all pretty simple. If someone messes around with them and breaks the balance (or the game), so be it, but that's their fault. Just throw a warning out in front. Compare that to KSP's stock settings in physics.cfg. It also makes it easier for people to tweak things for balance. If someone's playing with RT, then the occlusion will be the same (or, in the event of blackouts, add to it). Overlapping the two properly would allow for players to essentially have the best features of both - directional antennas and delay from RT, and your better connectivity settings. I'd actually be half-tempted to roll a combined .cfg that tries to incorporate both in a balanced manner so that it makes sense, although navigating both mods at once might be a headache. No, not the ninja evasion! Dealing with excess carbon dioxide can be tricky. In old or short-duration missions (up to and including STS), CO2's dealt with chemical scrubbers that run out over time. On long-duration missions, a regenerative molecular sieve is used, but this is heavy, expensive, and uses a lot of electricity. Having a proper carbon dioxide requirement would also allow for re-enactments of this scene (albeit where the Kerbals die). Thanks! The same system could probably be used for entertainment as well if needed. I wasn't referring to the effects of failures, but instead the causes. Things like throttling or restarting engines repeatedly incur a greater toll than continuous operation, as would operating under high loads. Having player actions & bad piloting take a higher toll on the parts would provide a way for players to make their vehicles perform better/more reliably without just requiring more tech upgrades. If I know my engine might begin malfunction on its third re-light, I might be tempted to take a flight path where I'm performing my plane change and TMI burns without shutting it off in between. However, your point brings up a good point - parts fail in multiple ways for different reasons. It might be interesting to implement this in the mod as well. The mod's literally called TestFlight. If you're open to ideas for improvements, I've got a few more. Likewise, I saw elsewhere that you're open to people rolling custom .cfgs for parts packs; if you want, when I get my next 1.1 playthrough ready I can send you whatever .cfgs I make that aren't already covered by your mod.