Box of Stardust

Looks a bit like a Dora, hits like a Dora. Also comparatively slow to its peers like a Dora... I'm starting to feel like I maybe should have done a heavy fighter (because engine power and speed and climb rate), but I spent 8 straight hours on this getting it to a spot where I think it's pretty good, starting at hour 0 with no real experience in building combat planes in FAR, and thus, no real idea what a good baseline was for flight performance other than observing aircraft in this thread.

So these corruption issues, is this only on the current version of Tweakscale? Are previous versions "safer" and won't corrupt files?

One more thing; I'm not sure if it's BDA or PRE, but I'd guess that it's probably more PRE-related (though I brought it up in the BDA thread first): 1. Camera issue. In flight, the camera moves ahead of the CoM for some reason instead of staying focused on craft CoM. 2. Sound issue. Sounds are omnipresent throughout a scene; as if all engines are located right next to the camera. Seeing that the previous one is also a camera issue, I'd assume that it's maybe PRE causing this issue.

Just a couple of notes for things I've noticed: 1. Guns clipped into other objects don't seem to be fired by the AI anymore; formerly, the AI would not care as long as the firing path was otherwise unobstructed by mesh geometry. It's a pretty edge case, but I use the GAU-8 flipped into the aircraft a lot because 1) less exposed hitbox, 2) it looks better. Not sure if this is intended behavior or not; if it is... that sucks. 2. Camera issue; potentially BDA related. In flight, the camera moves ahead of the CoM for some reason instead of staying focused. Not sure if BDA-specific related, or one of the related mods (e.g., PRE). 3. Sound issue; also potentially BDA/related mod related. Sounds are omnipresent throughout a scene; as if all engines are located right next to the camera. Seeing that the previous one is also a camera issue, I'd assume that it's BDA/PRE causing this issue. Also, seemingly around mid-April or May, a small update to BDA may have caused missile self-detonations to return? Unsure, maybe I'm just imagining it. It's not as frequent as the BDA 1.2.2 occurrences either, and the circumstances are a lot less clear. Just that it happens very consistently on certain craft, and not at all on others, or at least very, very low frequency with edge cases from other craft.

I've just updated to KSP 1.7.2 and have the current PRE version installed. It seems like the gravity easing that the KSP 1.6.1 version has been lost? Once vessels are loaded in, they're just dropped right onto the ground, which kind of causes things to break, unlike in 1.6.1, where it seems like gravity is eased in a bit so vessels/objects aren't slammed into the ground after PRE lifts them up. My current workaround for this has just been to reinstall World Stabilizer.

I'm having an issue where the constraint doesn't seem to choose an "up" axis until the part is moved around in some way, which is a problem, since the mesh this is relying on has a specific orientation. What ends up happening is that the mesh ends up starting sideways, until the part it's looking at is moved, then it seems that the node I have it parented to chooses the direction the Y-axis is pointed once rotated out of its starting position. I need a workaround for this. This whole complicated setup is pretty much a proportional reduction system for linking pieces to a gimbaling piece, but needs a proportionally less range of rotation. ... I would also not like my hours of trigonometry to go to waste, figuring out the proper lengths for this lever system I created... Prior to deciding to do this lever-link system, I had a hacky solution using separate gimbals, which worked, but adds more gimbal toggles and sliders, which isn't really a good thing. Why couldn't it just be simple after all this work... EDIT Issue seems to be solved. Issue seemingly related due to mesh geometry axis orientation itself, not rotation of any of the "nodes" in the linkage. Problem not solved. EDIT Okay, the workaround I did was to offset the "initial" starting position by offsetting the "look" node so that the "follow" node will be rotated at a non-zero value at the engine gimbal's neutral zero position, which "assigns" the "follow" node its up vector. The "look" node is positioned such that the "follow" node will never reach and cross a zero rotation value, ensuring that the "follow" node's up axis does not flip.

I'm trying to animate a jet engine's nozzle, and I'm having issues getting the animations to play correctly. I think it's a config file issue. I have two animations being used, one that opens the nozzle, and one that closes it. I've seen that the stock Panther has three animations, but I know others get away with two. I've tried multiple different combinations for the animations to play at the proper time (mode switching, throttle level), and for the one that has the correct animations, bizarrely, it encounters the problem that the animation does not close the nozzle fully when it should close. Maybe it would help if I actually understood all of the module parameters for FXModuleAnimateThrottle? Primarily, what does "layer" refer to? Is it a KSP internal layer that layers animations? How does it work? EDIT: Discovered it was a bit of an animation curve related issue. That said, I still don't exactly understand how the layers interact, but my issue was resolved by changing one of the animations to remain a constant value, instead of throttling like I thought it should. But I still don't really understand the animation layers. EDIT: Never mind, I was ridiculously overthinking this.

Is there a way to hide part toggles/sliders for things like control surfaces and gimbaling engines and the like through the config file, even if "Show Advanced Tweakables" is turned on? I'd like the option to completely lock in any settings in the config file to specific values, and have them invisible and non-adjustable in-game.

Battle: After Action Report:

Battle: After Action Report:

Battle: After Action Report:

Battle: After Action Report:

Battle: After Action Report:

Battle: After Action Report:

Are you replacing any of your other aircraft with this?

Battle: After Action Report: Another battle: After Action Report:

Battle: Bonus rounds: After Action Report:

I leaned on giving the Yari the win because of Bonus 2, honestly. Were it not for infinite ammo accidentally being on (not that any of them likely would have run out of ammo by that point), the DF-2 Yari would have been much easier to call a winner.

Battle: Okay, before we go onto the After Action Report, have some bonus battles: After Action Report:

We can consider it, it shouldn't be a problem if their settings are locked.

@Hojoz did you get my email submission? It was the PEGASys-D10N. If not, here's a craft file link on Google Drive: https://drive.google.com/open?id=1tDtMAI_pfdv_zKpdhsOx44zXapM0CWTp

You can rollback your KSP to 1.6 if you go to options and opt into beta versions or something.

Heh. So it turns out Eidahlil was still also already ahead of the curve. I guess we just forgot. He was trying to teach modern ASC lessons, but he was too ahead of his time. Hedgedrone, the missile spammer, and Cookie, the gun jouster. And he was even the one that voted to nuke the Hedgedrone out of the leaderboard when it won.

Lol, okay, if the sound gets to you then. Just making sure you know what you're trading.

Oh yeah, BDA has a better Panther engine now, by the way. It's called the Saturn, also under engines, looks like the Panther. Might want to swap the Panthers with that.