DerpyFirework

@Beale, the realplume configs appear to have dissapeared. I can't find them in the download anywhere (maybe they got lost in git somehow?). I've also just submitted a new PR for the FGB engines.

It seems I've found an issue when this is used with ModularFlightItegrator. It spams the log and connections don't work. I'm submitting an issue to Github, with output_log attached. EDIT: Or not.. I can't get it to reproduce for a log. Sorry if this isn't actually an issue! EDIT2: Found it! It's actually a combination of MFI and Persistent Dynamic Pod Names, submitting the Github issue now.

@tygoo7, could you see about giving each nozzle on the first stage F9 engine a gimbalTransform? Right now, it seems the gimbal acts on one transform with all thrust transforms attached to that transform, which means roll is not possible. You could also add the mesh as a child to the gimbalTransform which would then animate it (ie. moves with gimbal), and you could do the same with the second stage engine. Would make the Falcon 9 pretty much perfect then! If you're not too sure about how to set this up, I'll be willing to help. (Sorry if this seems demanding, I'm not very good at communication)

Ah! Found it as part of Thanks!

Hope you don't mind me asking, but where did you get that landing zone from? It's something I've always wanted at KSC and I have never seen a mod which adds one

@Beale, would it be alright if I submitted the new Tantares mods to CKAN? I've already made the metadata files and just wanted to ask permission first. Thanks in advance!

I've been takinng care of this quietly in the background, adding them to the main RealPlume-Stock package as parts are released on GitHub (Check the RP-Stock repo) On a related note, @Beale, if you want the RealPlume configs as part of Tantares/TantaresLV, I can submit a pull request for them and you could merge it when you make a release, so then people don't have to wait until RP-Stock updates to get RealPlume support (although your custom FX looks great!)

Yes, the plugin currently works, except for the one noted issue, but it's not exactly easy to set up the configs (hence the planned ingame editor)

On collaborating on KK: I felt it would be better to make this myself, since I'm not all that confident with my programming ability, especially with a plugin of this size (It's my first independant plugin). I also think it's good to have an alternative to KK, though I'm always going to recommend using KK (It's way more developed). I created the thread so that anyone with good knownledge of programming would be able to help, since there are some things I'm just not sure I can do (Like the map view issue) And on the stock asset use, I do have a branch on GitHub that can use KSC2 models, however I'm not sure how well that method will work with mods that change planets a lot. On another note, I'm not going to be developing this for a short while, I'm a little burnt out from the push getting it working in the first place.

Early WIP of a plugin I created for placing models on planets, similar to KerbalKonstructs. (No pictures yet) Current Features: -Support for any planet -Each structure can have multiple LOD groups (LODRANGE nodes) -Each LOD group can have multiple models (MODEL nodes) -A structure can act as a CommNet node Planned Features: -Support for stock (KSC and anomaly) models -Support for custom launchpads -Support for controlled animations -Ingame config editor Known Issues: -Objects do not collide in map view (#17) (Need help with this one) No release just yet, but the GitHub repo can be found here. License: MIT

Override. RealPlume sets them to fixedScale and localPosition if they're not defined, and it uses those values directly.

Turns out you can define flareScale, plumeScale, flarePosition, and plumePosition for this purpose (And I think I've used these myself at some point)

Using :BEFORE[zRealPlume] should do the trick (Not tested)

@Sigma88, I've been working on a plugin that places structures using PQSCity2 and I've run into an issue regarding compatibility with SigmaDimensions. I'm experimenting with several objects, including some droneships, and the droneships have "snapToSurface = false". This, and using SigmaDimensions to resize to 2x, results in them being 600km (1x original radius) higher than they should be (ie. In space). Any object placed with "snapToSurface = true" is unaffected. Looking at the source of SigmaDimensions, at line 108 in SigmaDimensions.cs it compensate for the resizing of the planet for every PQSCity2, but it would seem as though every PQSCity2 that I place (in the mainmenu scene) accounts for this without any additional code, which may indicate that this is already handled by PQSCity2 itself. Just thought I'd let you know, since I have no idea what else to do.

Just found this in the SmokeScreen thread: It may just get solved by the next SmokeScreen update. And just as an extra thought, could this layer issue be related to the other odd behaviours that people have reported? I'm no expert at any of this but that sounds reasonable.

I'm afraid this is something that the core RealPlume people will have to fix. From my understanding, the effect models (the .mu files in the RealPlume folder) need recompiling to include the ignore aerofx setting (the layer or tag). So we've just go to wait for an update in the core RealPlume models, other than that, I don't think there's a way around it for now.

Good news! Build 1523 fixed everything. No crashing with the grid fins or superdracos.

You might want to check the Superdracos, they both crash the game for me in 1.2pre as well as the grid fins.

No problem! I try to help out whenever I'm pinged, and this sounded simple enough. RealPlume configs should be included in the next RP-Stock release, just added them to the repo.

I'm going to guess it's the uniquely named thrustTransforms the engines have (i.e. thrustTransform800v rather than just thrustTransform), because I just made a quick MM config to apply the RAPIER closed-cycle effects to the "Hawk" engine. @PART[engine800v] { EFFECTS { running_closed { AUDIO { channel = Ship clip = sound_rocket_spurts volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } PREFAB_PARTICLE { prefabName = fx_smokeTrail_aeroSpike transformName = thrustTransform800v //This will be unique for each engine emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.25 speed = 1.0 1.0 localOffset = 0, 0, 1 } MODEL_MULTI_PARTICLE { modelName = Squad/FX/shockExhaust_blue_small transformName = thrustTransform800v //This will be unique for each engine emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.5 speed = 1.0 1.2 } } engage { AUDIO { channel = Ship clip = sound_vent_soft volume = 1.0 pitch = 2.0 loop = false } } flameout { PREFAB_PARTICLE { prefabName = fx_exhaustSparks_flameout_2 transformName = smokePoint oneShot = true } AUDIO { channel = Ship clip = sound_explosion_low volume = 1.0 pitch = 2.0 loop = false } } } @MODULE[ModuleEngines] { @name = ModuleEnginesFX runningEffectName = running_closed } } Hope this helps! (Going to make the RealPlume configs now) EDIT: Here's the RealPlume configs. (You can include them in the download or we could include them in the RP-Stock package)

Can confirm it works here too.

Getting the same issue with a GTX 1070 here. When I press 0, the "come back in a minute" message pops up and several things show in the debug log, but no particles show. Running Windows 7 x64, KSP 1.1.3 x64 DX9. Will test with the above builds now. EDIT: Above builds show nothing. Just thought I'd check with a GTX 10xx GPU, since I'm lucky enough to have one. EDIT2: Can also confirm it works in OpenGL

It is indeed the same bug as the reloading one. I believe the issue is an interaction between ModuleControlSurface and ModuleAnimateGeneric, as I've been able to reproduce it without any plugins and only those 2 modules. I'll see if I can find anything else that might help in fixing it.

Ah, just use the old plugin, it was just a bit of an experiment and it seemed to work when I tried it. As for the plumes, just name both transforms thrustTransform and it should work. But really, the parts are good enough without any of this.

All you need is one thrustTransform for each nozzle, and that should do the trick. No extra tweaks necessary. EDIT: For some reason, the plugin just stopped working for me. Just include the last version for now, it seems I broke something. EDIT2: Found the issue, it only happens before any staging happens. I'll look into it another day, it's not as if the old version isn't working. EDIT3: The issue fixes itself on staging, so unless someone launches by action group or some other method than staging, it'll work fine.