Araym

^_^ I put them on "public release" just to allow anyone to use them, if they will fit a role, Inigma. Obviously I thought that they could have, eventually, some room directly inside the Final Frontier mod. (Or at least, they are fitting now, for me, exactly the spot occupied by those "Custom" ribbon I never used :P) My 2 cents about Final Frontier, now, should be a way to allow some "open coding" to add freely other custom made ribbons, both for "free form" assignment and for "custom events" maybe triggered by external events (specific contracts, like yours, for example). I'll be enough happy to be able to add (maybe in a custom directory) more ribbons than those "hardcoded"...

For my needs, In my "Comic Adventures", I made some extra Ribbons, loosely ispired by Star Trek's StarFleet officers (on my end, I thought that they fit for the best the "three specialization types" we have in KSP). For Engineers: - Engineer Ensign - Engineer Lieutenant Junior Grade - Engineer Lieutenant - Engineer Lieutenant Commander - Engineer Commander For Scientists: - Scientist Ensign - Scientist Lieutenant Junior Grade - Scientist Lieutenant - Scientist Lieutenant Commander - Scientist Commander For Operation (Pilots): - Operation Ensign - Operation Lieutenant Junior Grade - Operation Lieutenant - Operation Lieutenant Commander - Operation Commander Extras for Higher Commanding Officers, in charge for a whole ship and/or fleets (as StarFleet, they are "Red Ranks"): - Captain - Rear Admiral Lower Half - Rear Admiral Upper Half - Vice Admiral - Admiral - Fleet Admiral Differencies from Star Trek: if I'm remembering well enough, there should not be any "Commander" from Engineers and Scientists (Commanders are "red" as Captains). I added them for a sort of "equal promotional possibilities", as I made only the "Captain" the first of the "Extra special red rank" for commanding officers. Also, I never saw a "5th rank" admiral (the "Fleet Admiral"), as the rank was considered (in actual Navy Forces) as a special rank (mostly under war), but I added it anyway --- I actually "cut" in my game this last "Fleet Admiral", as I renamed all my creation as the "Custom" Ribbons, and in actual Final Frontier Release there are just 20 position, against my 21 designed, and it seems that names are "hard coded" in the mod--- This should be a zip with all the ranks (I'm not very good with Dropbox, so for that I also directly linked every single rank images here, so, if you like to add them in future release, Nereid, you can directly save them): Ranks download Feel free to Add-Use-Modify them at your liking, if you wanna add them in future Final Frontier releases Also, If you like the idea, I could made the "extra commanding officers" (from Captains and above) as well colored in the other 2 branches or in any other color you eventually like (I limited myself actually by the number of "Custom" ribbons)

Found an issue with TweakScale config: your new added parts have a missing "{" between the "@PART" line and the added tweakscale lines :P One of your actual cfg (example): [CODE] @PART[bluedog_thorXLtank]:NEEDS[TweakScale] //SSR-900 %MODULE[TweakScale] { type = stack defaultScale = 1.5 } } [/CODE] should be: [CODE] @PART[bluedog_thorXLtank]:NEEDS[TweakScale] //SSR-900 [B]{[/B]// <---added %MODULE[TweakScale] { type = stack defaultScale = 1.5 } } [/CODE] It's an issue with all the new Thor/Able/Ablestar parts added :P (mostly tanks and decouplers...)

Some bugs: old Fuji parts still in catalogue (aside from new capsule/heatshield) are referring to a missing texture from folder of the old pod. (no texture on engine, solar, orbital pod, etc etc etc) Adding it back (just the folder and the texture, not the model/cfg) fixed the issue.

*_* Very very very interesting mod! Immediately download!

Quick look at the new release 31.1... TKS: "Spectre" Capsule (Alnair_Crew_C) still need a pass to be modified like all the pods with ablator Salyut: you added a new Node (MIR_Node_A), but there is still a cfg about a MIR_Node_B (the old one) without any model. Remove the cfg... or add back the old model (I selected the second option, on my end: the more round one fit better 0.625 docking ports) PPTS: sad about your decision to erase it. It makes a good pod as it was... (Another one moved directly to "my modified directory" to keep it as it is, to be more looking like the Tantares ones, overall) Contares one are not very different, aside to be just "different" outside, as they are using your own IVA, so they are not "better", just "different"

[quote name='lextacy']oh ok, lol What I did was I found the internals in the SPaces folder, then took the name of that and made an Internals module entry in the part file. Fixed it right up . Also this might be what you guys where talking about earlier....I have the same re-entry heating problem everyone else has? I put 6000 units of ablator on it and still it ate it all, and my trajectory was a standard arch. Is this due to the ball like design ?[/QUOTE] Yes, totally caused by how KSP handle, for the moment, the sphere shape of the Almach (Vostok) capsule. There were also some issues with other pods (they sink like stones, as there were not set any buoyancy stats) and, maybe, some other heating problem. [URL="http://forum.kerbalspaceprogram.com/threads/81537-1-0-5-Tantares-Stockalike-Soyuz-and-MIR-31-0-13-11-2015-New-Soyuz?p=2297093&viewfull=1#post2297093"]Here[/URL] there is a sort of fix (the best I could do, together with Beale) for the Almach and its parachute... and a couple of post before another for the Khleb (Soyuz), by Beale... ... but for the moment I could advise a couple of thing: Almach is ver dangerous if not re-entered with a very, shallow, angle, due its poor drag properties (it barelly slow enough to deploy parachutes at 2000m -SEA LEVEL-) Avoid steep re-entry or mountain range (you could not be able to open parachute in time). Soyuz fixed as Beale's post works, actually, perfectly even from a return trajectory from the Mun, with a direct reentry with a PE 28km altitude inside Kerbin atmosphere. Other pods need still fixes, I know Beale is working to another release more in line with KSP 1.0.5 requirements...

Question: could it be done toggleable? I mean: sometime I wanna take a "clean screenshoot" as your mod enable, sometime I wanna keep the "stock" behaviour to hide the HUD, but saving some of those message (... if you could check on my signature, I used the "transmission datas" on some of my comic's episodes)...

[quote name='lextacy']Id like to report a bug , there is no IVA in the Vostok capsule. At first I thought my kerbal was missing , but he is really inside because when you recover craft it shows crew member recovered. But the lower right hand IVE/EVA kerbal photo is missing due to no IVA being provided. Now im using 1.0.4 , I dont know if you fixed this issue for 1.0.5.[/QUOTE] There was a Vostok IVA on older Tantares release, but it was deprecated after new-actual model were implemented. Actually a lot of crewed parts are missing an IVA definition: for myself I add them using some of the placeholders ones that KSP still has in the Squad folder... (or, like I said, having a lot of older release, still using the older ones from Tantares when I feel they could fit...)

[quote name='tjsnh']With araym's vostok config I was able to survive a shallow-angle re-entry 5 out of 5 tries. Steep-angle still explodes in upper atmosphere on 5 consecutive attempts. Survivable shallow-angle is better than no-survivable-re-entry-profile. We're making progress.[/QUOTE] I kept contact with Beale, and from a couple of tests more, definitely is proven that Almach is (for the current design) NOT a capsule that like steep-angle re-entry. To be consistent (and to not change reentry profile) I let Mechjeb perform the reentry from a 120km circular orbit in each test (as Mechjeb is a very popular mod and probaly a lot of people will use it). Final tests (pending to be further checked by Beale) proven that from that orbit, reentry is (almost) safe... ... definitely a "low Kerbin orbit only" capsule that need careful planning on reentry (not only to "how to do it - NOT steeply", but also "where I should land - MOSTLY near sea level" :P). Someway, 1.0.5 does not like spherical pods, as it seems that they are not having enough drag to slow down. On contrary, Khleb-Soyuz pod edit (as proposed by Beale itself) is plenty capable of a Mun-return trajectory, as I already tested... ... waiting for the whole pack, now, as it is needed in the career save i'm using to develop my KASA Comics (I was planning the first Kerbal in space, just with an Almach capsule, but I'm not confident to risk it now with half baked edits :P)

Soyuz capsule tested, as I said, to a fast Mun-fly by, with "maxTemp = 1200", "skinMaxTemp = 3400" (and a "safety" of Ablator still set to 600): plotted a direct reentry from Mun-orbit AP altitude, with a PE at 28Km altititude inside Kerbin atmosphere. Decoupled propulsion stage just when I hit the atmosphere (to let all the ride in the air only with the soyuz capsule), with a surface velocity more than 3100 m/s: reach less than 300° on internal temperature on max peak, 1800/1900° on external temp, spent less than 70/80 ablator points (on 600). Definitely safe on all projected scenarios, probably even from Minmus orbit with 200 ablator point in a LK -like configuration Now I'm playing to tweak on my own the other pods (I got the hang of it, because I have some other old mods upgraded for myself, to use them in my Comics... and I NEED the Tantares one the most )

Soyuz tested with the exactly cfg, with just "maxTemp = 1200" changed (like I said, it's the "internal part temperature"... the external one now is "skinMaxTemp", left at 3400) From a Mechjeb driven reentry, 120km circular orbit, to VAB, hit internal temp 370° and external 1700°... probably 3400 for the skin temp is "overkill" (but you could leave it looking for mun-minmus orbit reentry ) I'm gonna just now shoot a capsule to a free-return trajectory to the mun...

For liquid fuel/oxidizer and monoprop engines: heatConductivity = 0.06 // half default skinInternalConductionMult = 4.0 emissiveConstant = 0.8 // engine nozzles are good at radiating. and (not very game breaking) just inside the engine module: MODULE { name = ModuleEnginesFX .... // omitted lines for FXs// // Possible EngineType values: // Generic, SolidBooster, LiquidFuel, Piston, Turbine, ScramJet, Electric, Nuclear, MonoProp EngineType = LiquidFuel PROPELLANT //....... Omitted fuels values, ISP curves etc etc// } and, obviously, for monoprop engine, the line changed to: EngineType = MonoProp For Solids (from sepatrons to boosters/LES): heatConductivity = 0.06 // 1/2 default skinInternalConductionMult = 4.0 emissiveConstant = 0.5 ... and then the appropriated solid engine type ... Ions/xenon pure electric engines seems to not have any thermal value (they lack in heat production), but just the electric engine type... ... Hybrid Liquid fuel/electric (like some of your Castor ones) should be considered like "liquid fueled" if producing heat, or like electric if not (it depends on your engine config) For nuclear Engines heatConductivity = 0.06 // half default skinInternalConductionMult = 4.0 emissiveConstant = 0.85 // engine nozzles are good at radiating, NTRs even better radiatorMax = 0.35 //Default = 0.25 but nuke engines are meant to run hot ... and again then the appropriate "EngineType" (probably to let KSP to know the different thermal production profile) (For references, just take a look on Squad engines cfg: they are totally the same, despite from Thrust or ISP, for each category of engine types. You have just to copy the missing lines to your cfg)

I was looking to launch vehicle too: Engines are lacking on some thermal definition too. Not game breaking (like pod's issue), but be aware that they tend to be hotter than stock...

Beale: you put a double "heatConductivity = 0.1" string in there... ... and also, I think you could keep at an high value just the "skinMaxTemp" (the external one). "MaxTemp" is now related to "internal values" (like for ISRU, that works inside "hotter" than the outside capability to sustain heat damage) My only issue is if the Soyuz capsule can sustayn a Kerbin-Mun reentry. To avoid the unneded mass for LKO, you could add this: RESOURCE { name = Ablator amount = 200 maxAmount = 600 } It gives a double function: a low mass (by default) for LKO orbit, and a safe margin to be added manually, for Kerbin to Mun-Minmus orbit mission. Also, from my (previously done with tjsnh config) to the Vostok capsule, leads to this two config for capsule and parachute. (Very issue was the capsule lacking in drag, to slow down enough... the added drag helps a lot and now it's plenty safely): PART { name = Vostok_Crew_A module = Part author = Tantares MODEL { model = Tantares/Parts/VOSTOK/Vostok_Crew_A } scale = 1 rescaleFactor = 1 node_stack_bottom = 0.0, -0.541875, 0.0, 0.0, -1.0, 0.0, 1 node_stack_top = 0.0, 0.541875, 0.0, 0.0, 1.0, 0.0, 1 bulkheadProfiles = size1 TechRequired = start entryCost = 0 cost = 525 category = Pods subcategory = 0 title = A541A Ballistic Capsule manufacturer = Alnair Design Bureau description = Tested rigourously with 4-legged creatures, this capsule is now surely ready for 2-legged creatures. attachRules = 1,0,1,1,0 mass = 0.7 dragModelType = default maximum_drag = 0.4 minimum_drag = 0.35 angularDrag = 2 crashTolerance = 25 MaxTemp = 1200 skinMaxTemp = 4400 thermalMassModifier = 1 heatConductivity = 0.1 bulkheadProfiles = size1, size0 CoPOffset = 0.0, 0.5, 0.0 CoLOffset = 0.0, -0.35, 0.0 CenterOfBuoyancy = 0.0, 0.5, 0.0 CenterOfDisplacement = 0.0, -0.3, 0.0 buoyancy = 1.5 buoyancyUseSine = False vesselType = Ship CrewCapacity = 1 MODULE { name = ModuleCommand minimumCrew = 1 } RESOURCE { name = ElectricCharge amount = 125 maxAmount = 125 } MODULE { name = ModuleSAS } MODULE { name = ModuleReactionWheel PitchTorque = 2 YawTorque = 2 RollTorque = 2 RESOURCE { name = ElectricCharge rate = 0.1 } } MODULE { name = ModuleScienceExperiment experimentID = crewReport experimentActionName = Crew Report resetActionName = Discard Crew Report reviewActionName = Review Report useStaging = False useActionGroups = True hideUIwhenUnavailable = True rerunnable = True xmitDataScalar = 1.0 } MODULE { name = ModuleScienceContainer reviewActionName = Review Stored Data storeActionName = Store Experiments evaOnlyStorage = True storageRange = 2.0 } RESOURCE { name = MonoPropellant amount = 30 maxAmount = 30 } MODULE { name = ModuleAnimateGeneric animationName = Almach_Crew_A_Light actionGUIName = Toggle Lights startEventGUIName = Lights On endEventGUIName = Lights Off } MODULE { name = ModuleAblator ablativeResource = Ablator lossExp = -7500 lossConst = 0.1 pyrolysisLossFactor = 6000 reentryConductivity = 0.01 ablationTempThresh = 500 } RESOURCE { name = Ablator amount = 200 maxAmount = 200 } } ... my last test was with 300 ablator, using 141, with Mechjeb landing automated trajectory (to have a consistent profile every test) from an 120km circular orbit... I feel safe to low it at 200... Added buoyancy: it is stable, bottom down, a little less than half submerged, with enough room to a kerbal to go EVA in the water and board it back. Then the Vostok parachute: PART { name = Almach_Parachute_A module = Part author = Tantares MODEL { model = Tantares/Parts/VOSTOK/Vostok_Parachute_A } scale = 1 rescaleFactor = 1 node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 0 node_stack_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 0 bulkheadProfiles = size0, srf sound_parachute_open = activate sound_parachute_single = deploy TechRequired = start entryCost = 0 cost = 420 category = Utility subcategory = 0 title = A070A Return Chute manufacturer = Alnair Design Bureau description = In the event of an emergency, the handle can be used to manually release the parachute. Or at least that's what we think it does, nobody has every actually tried it. attachRules = 1,0,1,1,0 mass = 0.07 dragModelType = default maximum_drag = 0.20 minimum_drag = 0.15 angularDrag = 2 crashTolerance = 10 maxTemp = 2500 fuelCrossFeed = False bodyLiftMultiplier = 0 stageOffset = -1 MODULE { name = ModuleParachute semiDeployedAnimation = Almach_Parachute_A_Semi fullyDeployedAnimation = Almach_Parachute_A_Full invertCanopy = false autoCutSpeed = 0.5 capName = Cap canopyName = Almach_Parachute_A_Canopy stowedDrag = 0.22 semiDeployedDrag = 1 fullyDeployedDrag = 500 minAirPressureToOpen = 0.04 clampMinAirPressure = 0.04 deployAltitude = 1000 deploymentSpeed = 0.12 semiDeploymentSpeed = 0.5 chuteMaxTemp = 650 } MODULE { name = ModuleDragModifier dragCubeName = SEMIDEPLOYED dragModifier = 0.67 } MODULE { name = ModuleDragModifier dragCubeName = DEPLOYED dragModifier = 25 } } ... I just conformed it to Squad values from stock parachutes. It allow the Almach-Vostok pod to land safely at 8m/s

I found some issues with mk3 expansion parts: on my end, the Node endcap (to mount 1.25m parts) and the air intake have some nodes messed up (fairly forward than they should be: i took for reference previous mk.3 parts release, and older one shows - at least for the Node - the right position), and some parts have texture references to 1.0.4 Squad folders that are now differently organized in 1.0.5. Also the mk.3 Cupola reference to stock Cupola texture gives to me a weird, unalligned, texture both in the upper section and to the EVA airlock

If you are not against use another mod, Stage recovery adds not only the ability to recover fund from dropped stages (if having the proper amount of parachutes on it... and it works on background, even if they are not deployed at the moment of staging) but also, if you click on StageRecovery icon inside VAB or SPH, it gives to you the approximate landing speed of the stack you have at the moment (I build the capsule/part I'll recover, do the check, then add the rockets/boosters/whatever it is needed to space )

I having my trial launches in 1.0.5 on my shuttles, and I found a workaround for the nodes not allowing "mirror simmetry" to the shuttle thrust plate: I add the upper engine on the node, and the 2 lower on the surface, avoiding the free node, in mirror-mode. Then I can tweak them with the gizmos to move/rotate freely as needed, to achieve the right position.

My first craft, with a bit of Infernal Robotic inside, is this: http://imgur.com/a/QEjLQ A beautiful plane for two new "Panther" engine (YAY! Finally I have an afterburner for fighter jets!!!)

Unrelated to the comic itself, I have almost sorted out all my mods to be compatible with the Comic's save. I sorted out, also, a couple of modifications in the craft already used to be the most "look-alike" what they were in 1.0.4... ... now I have just to test out some "custom editing" I did on modded parts (mostly on Tantares), to check if they could work (I always make modifications on mods, to integrate them better with stock parts, a lot of time tweaking values to not be overpowered). In meantime, I'm randomly doing some "sandbox mode" flight, to sort things out. For example, this: http://imgur.com/a/QEjLQ The "K-14 A TomKat" my kerbalized version of a well known plane (stock+Infernal Robotics, for the moving wings). I was waiting the new "Panther" engine to improve the looking of my planes, and nothing fits better to try it on one of the sexier plane of all time ... Flown by Jeb, with Bob as passenger, they went in a trip to the north pole, just to plant a flag (it's a test sandbox mode, so no need of science), cruising at a good 2.6 mach at 18km altitude, at full afterburner for the whole trip. Good range, for a fighter. Now they are waiting on "top of the world" a recovering team, having no fuel to return back (probably I could return avoiding the use of the afterburner, but it'd take, probably, a lot more than the 35 mins needed to reach it in afterburner mode only). But it's just a sandbox, so the recovery should need just the time I need to click on "recover" button ---- Update ---- And in meanwhile, a patch was done to 1.0.5....... ... I'll check things back a bit further... (ç_ç)

Not a list of "deadly bugs", but noticed some "differences" to similar parts from Squad (both in MK2 Expansion and Mk3 Expansion): - all Squad engine have now the "heatConductivity" parameter activated: it was previously on hold by the double-slash "//", but now it seems abilitated... you have also it in your cfgs, just need to delete those slashes - decouplers missing "ModuleToggleCrossfeed" to let the fuel flow thru them... but, again, this is just a new feature not eventually needed... - docking ports have a new, selection about using them as decoupler, but, as always, shielded one are not available as node in VAB, so again could it be just an option not totally needed... (I added it my builds, just in case for some strange craft in which I use docking ports as "launch stability nodes" (opened) between long stacks, like orbital station parts, orbital rings or other absurdity contraptions, when physics kick in at the launchpad, and post-lauch, flushed, less visible invisible parts, post-launch/in space ) Then a question (not enough data on it): does your mk2 nuclear reactor act something like the new ISRU or RTG, building (and needing) core heat (or similar effects) during their use??

Confirmed: no issues for the moment

Basically, the window are missing because Squad's mk1cockpit is totally different, now (no more the same model-texture). I copied the old texture from 1.0.4, and redirect the link in the model, and all is working as before. Suicidal... you could do it in a more definitive way, storing it once in your mod, in a pre-decided path (like a common asset), where your models could referr. (I'm saving the old cockpit as a whole, because I find it better for some roles than the new one)

It could be possible to obtain both feature, using Firespitter plugin to switch meshes (with turbine, and without)... ... I'm looking to this option, at the moment, for personal use, but I'm not so great with the option of that plugin (even if I have it already for other mods).

You know, Ingma, that I work "on par" with your shuttles, so... my 2 cents: - My own shuttle it is working perfectly as it was in 1.0.4, using Skipper engines as Orbiter engine. I had to rework the external fuel lines on the central tank, caused by the new pilon model, but it was a marginal change not changing a thing (and removed their decoupler ability, to avoid problem with staging) - I tested the new SSMEs (and the related engine mount): they are far more powerful than needed, with marginal differences in payload capability (this is related, now, to the cargobay dimension: we squeezed the max, with a single, long, cargobay, at 42t) or range. I found myself more successful once I lowered the SSME thrust at Skipper level (1 Skipper = (rougly) 65% SSME thrust) to be balanced with the SRBs stack (mine were built very likely as your solids assemble, at 80% limited thrust) to mantain the 3xengine Orbiter look. I found the engine mount a bit difficoult to be balanced, now, if used with the 3 nodes available, just to keep simmetry working (and to not tweak any engine one by one) but I did a workaround about it: the upper one added on the upper node, and tweaked as single, then the lower 2 added as surface mounted on the engine mount, in "mirror mode", to change on both the inclination) PROs: The look of the orbiter improves a lot: it seems a LOT MORE like the NASA shuttle. (SSME's flame is VERY LIKELY the real one *_* I like it) CONs: if the SSME engine mount used AFTER the two mk3 monoprop tanks, the Shuttle's fuselage seems too long. I'm not sure if clipping it "inside" the rear monoprop tank, to leave it show just barelly from the rear. I then having some issues on the SRBs separation moment: with the low gimbal Skipper, as soon SRBs are depleted (but also with my liquid booster version), the orbiter+ tank push more vertical, helping with its momentum to "launch away" the spent SRBs... ... BUT the SSME high gimbal rate keep the orbiter+tank a LOT more flat, orizzontal, trajectory: this always means SRBs to hit the wings (I copied your SRB's sepatrons configuration, up until now) even if adding to sepatrons more thrust. Probably are needed some more sepatrons, to the booster's base, pushing "away" from the orbiter. --- further reports will be added as more tests will be done ---