kcs123

I have encontered different issue. Previously working craft created with 4.0.0 and 4.0.3 version of KJRn started to explode when I staged it with KJR 4.0.5. Upper stage craft parts seems to receive a lot of aerodynamic stress that was not happening before. Have yet to inspect to see what is going on. Have to revert back to KJR 4.0. or 4.0.3. and attempt to re-create same craft again from strach with KJR 4.0.5. to narrow down issue. Don't know if I would have time for it today, though. EDIT: Yep. Without KJRn craft behave just fine. It is lightweight rocket, though, so issue may not happen on heavier/larger crafts. I will send craft file soon. Currently downloading DBG version of KJR to see if I can find more about issue.

Nope, wasn't found in that library, must be elsewhere, but it does not matter. I have created monotone cubic interpolation function for usage in kOS. Wasn't tested extensively, altitude/piching points may require some tweaking too, but general functionality of spline interpolation works as intented. When I started to test, my previously working rocket started to explode on staging. I think it is KJR next culprit, since it is only mod updated since yesterday. But, that is different kind of animal that I need to tacle down. kOS script prepared to be used as library is under spoiler: Example of usage from main script: parameter MyHeading is 90. // initial heading for orbit - influence starting inclination parameter MyApoapsis is 120000. // Desired APOAPSIS of orbit clearscreen. // load the libraries I'm using: runoncepath("lib_navball"). runoncepath("interpolation_lib"). // you can override default AltPoint and PitchPoint list set in interpolation_lib // first you need to clear list and then set new points for both arrays // last point on interpolation graph must be always Apoapsis set AltPoint[AltPoint:length-1] to MyApoapsis. PopulateInterpolant(). // first call on startup - you need to execute it each time you change Apoapsis print InterpOut. // you can use this value to check for errors and track what is interpolation doing function AltitudePitch{ local Pitching is 90. if (SHIP:ALTITUDE > 1000) or (SHIP:AIRSPEED > 100){ set Pitching to round(CalculatePitch(round(SHIP:ALTITUDE)),2). }. DynamicDisplay("Turning to: "+Pitching+" "). return Pitching. }. wait until SHIP:MAXTHRUST > 0. // waiting idle until staged once for launch // program will not continue down until staged SAS off. DynamicDisplay("Launch started"). // Initial throttle and heading SET SHIP:CONTROL:PILOTMAINTHROTTLE TO 1. lock STEERING to HEADING(MyHeading,90). // works better than UP direction as UP tend to rotate wait until SHIP:AIRSPEED > 70. // no stearing until proper velocity gained set myPitch to AltitudePitch(). // first input from Pitching curve function // Lock is needed only once, outside loop, steering will be changed whenever myPitch changes lock STEERING to HEADING(MyHeading, myPitch). until (ship:APOAPSIS >= MyApoapsis) { set myPitch to AltitudePitch(). wait 1. }. I have maybe over engineered library script and wrote comments for easier tracking if I have made mistake somewhere. For that reason, file is bigger than need to be. It is clearly disadvantage. However, you can tune altitude/pitch graph points that suit well for your crafts and wanted ascent path in easy way. You would not need to use external tools to calculate constants for pitch function. Let me know if you have tested it and how it is working for you. Also, feel free to upload it to kOS github library, if you find that have some merit. I still don't have account on github and don't plan to create one yet.

Why not ? SQUAD doing that all time . They do tests, just not well enough. Anyhow, it is always good idea, regardless of software you develop, to give your product to other people for testing. No matter how effort you made to test for yourself, you will always miss something. Heck, I even found some bugs in my code after several years passed since I last time worked on some pieces of code. So, no worries, as soon as people notice something they will report and you can have starting point to search for fix.

Might look into that as well, thanks for mention it.

Yep, it is always good idea to start steering only when your craft gain some velocity, usualy above 120 m/s (depending on craft), but should also be carefull to s steer gently while below 10km and with velocity close to mach 1. Based on empirical results in KSP, most critical regime is from 0.8 mach up to 1.2 mach when you are below 10 km. After that steering is much more forgiving. Btw. thanks for sharing that video and examples. That gave me idea to attempt create cubic spline interpolation function for kOS. Alghorithm is shown on linked page, just a matter to code it in kOS. Someone have already made kOS function for linear interpolation somewhere (can't recall where, sorry), but cubic spline interpolation is more precise. Somehow I often get traped in more investigation and re-learn forgoten skills as well as learning something new when I attempt to just play a game for a while :). Edit: Even better page with interpolation alghoritm.

I understand your idea behind choices you have made. However, there is some gaps that need to be attended for better overall gamebalance. I have pretty much stummbled upon with lack of some parts that are available only in DLC or covered with oter part pack mod that player for some reason don't have installed (for various reasons: not being supported with current KSP release, conflict with some other mod that player use, or simply don't like some mod etc.). To test overall gamebalance with this texch tree, I'm using pretty hard difficulty and with minimal mods installed (still tracking what mod can cause issue and what not). Installe dmods in spoiler section: I have ditched out SETI contracts (some of contract packs were causiing spam in logs and this pack may contain obsolete MM commands). That contract pack also mess with Custom barn kit configuration. Starting funds is 10000 and 0 science points. Have to pay entry for each researched part, no additional relay ground stations besides KSC. I also restricting myself only to level 1 buildings, to see how much is feasible to accomplish. So, I need to establish comm network in orbit with minimum of 6 satelites in equator orbit somewhere between 120 - 160 km and additional 2 in polar orbit with 90 degree longitude orbit difference. Whole craft need to be cheap as possible as I might not be able to have any contract from it as minimum refund. But those are necessary to be able to accomplish any future contracts and grind some scinece points later on. Since picture tells more than thousens of words - craft example: So, for latest stage, to be controlable in space I need 8 linear RCS ports with still lacking 4 more to have proper roll control. Those weight too much for such small probe, cuting down upper stage dV a lot. Yemo have solved this issue by adding custom parts in SETI probes mod, previously being integrated with UBM. Sure, I can cut down throttle on those to 25% for better control with kOS, but trough ascent is necessary to have 100% of trust, because boosters don't have any gimbal control and wing surfaces are too heavy. Instead of solid rocket boosters I can use engine attached to truss and surface attach those to fuel tank. But for 4 engines it is additional 4 more parts that adds to overall part count in VAB/SPH. 40 parts as I suggested might not be enough to counterbalance this issue. And more than 40-50 might be overkill for level one buildings. Sure, I can use tweakscale to cut down weight of RCS linear ports in half, but I attempt to do test without it, using tweakscale only for IR parts. Just to test overall game balance and get better feel what might be necessary to change. I have only "cheated" a bit trough GAP mod, to get decoupler slightly earlier. Otherwise, might not be possible to even reach space early in game. There is also missing longer variant of oscar LQ fuel tank, I need to put stack of 3 of them instead of using just one as you have used in your video examples. I understand your reasons to not change any stock parts. But it might be necessary to add some new ones similar as it is case with LVT-10 engine. I have used MM patch over stock part, but might be better idea to create new part from stock part copy with custom modifications on it. Structural adapters might be also good idea to create 2-4 stack addapters, but for 0.625 size tanks. Just scale down existing stock parts and put it somewhere earlier in tech tree. That would cut down part count from 8 to 5 for same thing. I would try at first by only adding mentioned additional probe with poor reaction wheels and scaled down 3-4 way adapters. There was some issues with custom RCS ports inYemo's command probes mod between KSP versions, so I would not recommand those as it might be difficult to maintain in future. Also with ARR licence that mod can also become obsolete, so there is need some other solution for people without DLC packs. No worries, I was not being able to play KSP for a long time either, not to mention ability to help with mod. Take your time, I will keep posting any other obstacle I found and possible solutions. I understand that you might not be willing to addopt all of them, but I will leave it here for others if they want same changes/solutions that I made.

@OPBlue, good luck on test ! Torque is already modeled to some degree in game. Look at existing electrical engine. More torque means quicker response to throttle input. Electrical engines are capable to spin up much quicker than piston engines. Meaning, full thrrust is established much quicker with electrical engines (almost instant) than it is possible with piston engines with comparable power. That feature make electrical engines exelent choice for various PID controled autopilots. Almost instant response on throttle changes make it easier for autopilot to handle craft. Drawback with electrical aircrafts is still battery weight, you still can store much less energy per kg in battery than it can be used from fuel. But good feature from battery is that when you drain energy from it, they still weight the same (at least that can be measured). That means, craft COM would not shift as it was with ordinary crafts with fuel tanks. I have nothing against firespitter, it will be easier to copy values from existing engine and adjust thrust/air preassure curve, adjust EC drain etc. Heck, for testing purposes might be even feasible to use existing 3D mesh from one of piston engines and only change config files to be "electrical". Don't know how much of other data unity pack within mesh model, is something else required or not, though. Is it enough data to get starterd with it ?

Yes, it is only MM config and currently looks like this: @PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[kOS]:Final { MODULE { name = kOSProcessor diskSpace = 10000000 } } Yes, it would be nice if it is not hardcoded by part name, so it can work with probes from other modes, not only stock module commands. Also, my personal preference on this is to not have kOS inside of maned command modules. On craft with several maned command modules kOS CPUs raise too quickly even when you don't need one. Thinking more about it, probes that are capable of holding prograde/retrograde are earliest that should be capable to have kOS equivalent KR-2042 CPU built in. Probes with normal/antinormal ability might even be able to have KAL9000 CPU integrated. At that point of playtrough craft mass is no longer of ultimate importance as well as craft part numbers, so it becoming just unnecesasry obstacle in late part of game playtrough. Have no idea how to write down such MM patch,for myself, though. Have yet learn a lot more about MM syntax.

Found that this one is intended from this MM patch: @PART[winglet3]:NEEDS[AirplanePlus|SXT|KAX&CommunityTechTree]:AFTER[zzzUnKerballedStart] { @TechRequired = stability } EDIT: Doing some more testing and thinking about it AV-R8 winglet is much more apropriate for 0.625 early rocket size. It should be earlier in either, "stability" node or "earlyAviation" node. Both cost the same and without much mods installed earlyAviation have much less parts, might be better to put it there. EDIT2: Nevermind, I was writting from top of my head. Stability node have less parts and rocket builder might benefit much more from that one. Delta deluxe winglets might remain in same node (from KAX patch) if someone is capable to build larger rockets earlier.

Found another compatibility issue. It was feeling from the begining that delta deluxe winglet is too early in tech tree. It start in aviation node while should be somewhere higher in tech tree. More apropriate would be to have AV-R8 winglet early in game as first controlable fins instead. Furthermore, I have installed KAX mod in the middle of playtrough and delta wiglet is moved to diffrernt tech tree node. I started to investigate things and found that AV-R8 winglet is initaly intended to be placed in aviation node. File UnKerbaledStart.cfg: However, it is being moved to other nod with MM patch placed in UKS-Galen-AirplanePlus.cfg: It might be apropriate to do that if AirplanePlus mod is installed, but looks odd without it. I think that is type made on those lines and should include APP inside NEEDS brackets, not only Ctt as requirement. Should look like this: // around line #27 @PART[CanardController|tailfin|sweptWing|R8winglet]:NEEDS[AirplanePlus&CommunityTechTree]:AFTER[zzzUnKerballedStart] { @TechRequired = flight3 } @theonegalen, I belive that is your config file for additonal mod support, but I don't know is it intended to be like that or typo was made while creating file. I noticed few other MM patches in same file intended to be used with APP installed that have only Ctt in NEEDS command.

kOS for all settings seems to be overpowered, especialy early in career game. At least to my personal preference. Is there a way to tie kOS integration in command module with respect of regular kOS part unlocked trough tech tree ? It would be better to tie with specific part, if possible, rather then tech tree node, because of diffrent placement of parts in various science tree node available for career. That way would be easier to maintain compatibility. For example, if I have unlocked KR-2042 CPU, I got it's values integrated in command module. When better part is unlocked then values of better part is integrated in command module up to best part available KAL9000. Issue is that early part of career game is overpowered with integrated kOS while at same time in late career game when you have unlocked most of parts and have unlimited weight/size/part count on launchpad/runway it become tedious to add kOS CPU on each craft.

Thanks a lot, that will indeed save a lot of time and will be foolproof whenever I try some ne contract pack that might have missing agent title in it.

I will need some guidance on this. There're some electrical props on FireSpitter, there're some on KAX. I don't know exactly what you guys need - and we have to remember that we would need a electricity source to feed such engines! Yes, I was thinking about same craft and more specific SP260D engine that powers it. Found some more data about it(links were buried somewhere on siemens page) and mentioned it in APP thread long time ago: Unfortunately, blackheart612 was seeking for accurate blueprints for exact replica. I don't think that is necessary for in game purpose. What we know from this datasheet is engine power of 260 kW, weight of 50 kg and engine efficiency of 95%. Obviously we lack a lot more of other data, but I would suggest that by using mentioned data we seek for some piston engine of similar 260 kW power (~349 hp for easier search/comparison). With data from such piston engine, how much of thrust it can provide on any given altitude we can get thrust/altitude or thrust/air preassure curve. But slightly better than chosen piston engine. Reason is that unlike piston engines, electric engine does not need oxygen as part of fuel source that feeds engine. Piston engines lose power with altitude due to lack of oxygen needed for combustion. Modern turbocharged engines are slightly better, but still have limitations with it. On the other hand electric engine with propeler lose thrust with altitude only because there is not enough air particles that propeler can push and provide thrust from it. It also does not need oxygen in air, so it can be useful on celestial bodies that have atmosphere but with too low oxygen in it. As for 3D model of such engine, does not have to be anything fancy, something like KSP stock small nose cone of 0.625m with propeler blades attached to it (~ 1.25m of diameter should be good enough in my opinion). Either, 3 or 4 blade propeler will be good enough. Whole engine with adjustable pitch propeler blades should weight around 70 kg. If pictures from siemes page are not good enough as reference for 3D mesh model, you might find some inspiration from video: As power source, we already have batteries in stock game as well as from various mods. We also have solar panels to charge those bateries. There is also plans for B9PW to have solar panels built in wings, so we are covered in that regard. From provided datasheet we know that engine have efficiency of 95%. That should help with decision how to set energy drain from batteries appropriately. Should be better energy efficient engine than current electrical engine in KAX while more powerful at same time. Existing engine is nice, but I always found it odd how to surface attach it to craft (too long 3D mesh model). You can also use existing sound effects from existing electrical engine, maybe slightly change pitch frequency just to have some difference but not absolutely necessary. The rest will be up to players to create some nice crafts with it. My small contribution to brainstorming whole idea.

Thanks, I indeed have RealChutes mod, checking that first it seems to be fixed already since first report about it. Following your advice, I found in MM.ConfigCache this config that is suspisious to me: All other contract packs found in MM cache have in second pair of UrlConfig{... config definitions} properly defined agent title. In first group it is always agent name and in second one is again definition of agent with title defined. AnomalySurveyor seems to missing that. But might be wrong about it, I'm only capable to compare two similar pieces of code and with some educated guess find what might be issue. Are there any more convinient way to search trough MM cache with some keywords, beside "AGENT" to search all of possible places of wrong wriiten configs ? I will try to inspect folders of contract packs too, I will upload MM cache and logs if I fail to find culprit.

I got lot of following, hopefully useless spam in log: Probably happening when game try to generate some new contract. Haven't yet pinpointed exact contract pack that cause this. But I also found this at beggining of log: So, my guess is that some of contract packs use legacy system for contract generation or something. Am I right ?

Answer is on previous page, just few post before yours: Title says ">=1.4", but I was confused too, I was not certain is it work in KSP 1.7.

Ah, no, you missunderstand me (I should explained better). I was not thinking about firespitter dependency, I was thinking about that propeler I was not yet try in game: Thanks for info and I can oly advice you to take your own pace in development, working on mods when you also enjoy working on it. It is almost only (and important) reward you will ever get.

Seems that solution from github still have issue. I got this in MM log: [WRN 2019-05-14 17:48:01.673] unrecognized trailer: ',*' on: ContractPacks/AnomalySurveyor/SCANsat/@CONTRACT_TYPE[AS_*]:HAS[#tag[SCANsat]]:NEEDS[SCANsat],* Should not that config file look like this: @CONTRACT_TYPE[AS_*]:HAS[#tag[SCANsat]]:NEEDS[SCANsat] { // Increase the rewards of all contracts with extra SCANsat requirements @rewardFunds *= 1.30 @rewardReputation *= 1.10 } I can't say that I'm familiar with all of MM syntax, just taking peek into config files from time to time. Seems to me that "[....],*" syntax for MM is either wrong or obsolete in new MM version. I don't recall that I have seen something similar in other MM patch config files.

I have created some MM patches for personal usage, posting it here for others if they find it useful in their game too. CustomBarnKit.cgf (reposting here for completenes) - instead of switching prices, level 1 part limit count is increased from 30 to 40 for VAB/SPH B9 Procedural wings - placing it lower in tech tree at tier 4 Aviation mode: Adding reaction wheel module to stock Probodobodyne QBE probe. Have quite low torque, it would not be much of help to steer rocket, you will still need RCS or fins to steer it trough atmosphere, but should be able to slowly steer low mass probes (lower than 1t) and with high electicity usage compared to more advanced probes. Reposition of DMagic SIGINT parts, because those are too powerfull relay antenna, compared to stock antenna parts: Reposition of IR Next parts. While IR Next comes with Ctt support, it does not fit well in UKS tech tree. So, I re-positioned those along robotic line of tech tree branches: New postitions for Breaking Grounds DLC parts. Just slight movement trough tech tree that have more sense with UKS.

Back on topic. What is current status of KAX ? Is it safe to use on KSP 1.7.x ? I was on hiatus regarding playing KSP for long time, I think that I skipped almost all of Spanermonkey's maintenance releases. And last question, latest KAX release available from CKAN is one from keptin, for KSP 1.2.2. Now way obsolete for usage on KSP 1.4.x and greater. Is there are a reason why it is not distributed trough CKAN (like author does not allow it), or noone mentioned to CKAN staff that there is new repository available ? That reminds me, I almost forgot about this one: And, yes I agree there is a gap with electrical engines, there almost no mods to create some small electrical drones. Perhaps same model used for early pre WWI craft can be used for that, but instead of using fuel, to use electricity instead.

@Rudolf Meier, seems that you have forgot to update version file. That is most probable reason why CKAN have issues to pick up new version even after 20h. It usualy recognize update within 6-12 hours.

Found some small compatibility issue between kOS and RealChute mod. It is being present for a while, but I forgot to mention it before (several KSP and kOS versions ago). Reproducing steps and description: Have some craft in orbit with only 2 stages left. Last stage contains decoupler and RealChute. Current stage have some engine engaged with some fuel left. Open terminal and type some command in it. For example, I want to run my script with command; "run maneuver." What is expected is to kOS run that script, but as side effect RealChute also "arm" parachutes to deploy at certain altitude or preassure. Note that proper KSP stage is not executed, decoupling of last stage didn't happened, only RealChutes become "armed" I'm not sure is it issue on RealChute mode side or on kOS side. It was not something critical either, but can be annoying sometimes if I didn't noticed and disarmed chutes on time.

Finally being able to try career game wit it. Hard game, stock comm network without any additional ground stations, only ting to make it easier is to allow quicksaves and reverting flight (mostly due to fear of kraken and unexpected CTDs). Some suggestions: - instead of swaping prices, set lower part number limit for VAB/SPH to 40 - radiators in gizmos node - no use for them that early in the game, can be safely moved to early heat managment node - At least LVT-30 engine (without gimbals) in tier 3 node General rocketry - there is few 1.25m fuel tanks unlocked, but not much use of them because almost all of engines are much higher in tech tree. - B9PW should be in tier 4 Aviation node instead of Advanced aerodynamics node - people who use them would usualy not need wings of other kind, but P9PW are too high in tech tree for them - Basic rocketry node contains resource tanks from USI/MKS mod, those should be placed somewhere higher in tech tree, with their ability to be used for various resources it seems to be too early for them to apear in career game - RA-2 antenna should be slightly earlier in tech tree - in Space Exploration node, to be able to establish better relay network when it is time to explore Mun/Minimus Probodobodyne QBE - add reaction wheels to it. With very low torque, though. Something like 0.1 or 0.05. IIRC, Probodobodyne OKTO have lowest value of 0.3 torque in stock game. Found it necessary because linear RCS ports are too powerful for small probes, making even kOS steering manager to jerk it a lot, wasting monopropelant and still not being able to point probe in desired direction. Linear RCS port is on right spot in tech tree, though and may be necessary in ascent of unstable rockets, can even be better and lighter solution than wing control surfaces. Because wings are only useful in lower atmosphere. I have changed my CustomBarnKit.cfg like this: @CUSTOMBARNKIT:FOR[UnKerballedStart] { @VAB { @partCountLimit = 40, 255, -1 } @SPH { @partCountLimit = 40, 255, -1 } } Now, have to restart my career, becasuse I'm stuck (unlocked wrong tech tree node) and currently not in the mood for too much grinding.

How to enable visualisation ? Does it require some changes in config file or it is in some hidden menu ?

Speaking of data ... Does latest release include KJR autostrut visualisation, if so, how to enable it ? Stock debug menu only shows stock autostruts. Haven't encountered any issues yet, though not being playing much either.