kcs123

Thanks again for clarification, I was not certain while I was looking at other examples should I always need @ before module or not. Regardless of that mistake, I have checked in game and seems to work properly, at least with B9, KAX, USI/MKS parts and stock parts. Have yet to investigate if I need some addition for some other mod that might not fit the above rules.

OK, I think I have found solution that is more balanced trough career game, regarding kOS for all config: @PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],@MODULE[ModuleSAS]:HAS[#SASServiceLevel[3]],!MODULE[kOSProcessor]]:NEEDS[kOS]:Final { MODULE { name = kOSProcessor diskSpace = 300000 } } @PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],@MODULE[ModuleSAS]:HAS[#SASServiceLevel[2]],!MODULE[kOSProcessor]]:NEEDS[kOS]:Final { MODULE { name = kOSProcessor diskSpace = 20000 } } So, higest end probes have build in kOS disk of 300000. That is slightly more than KAL9000, most powerful kOS CPU part. And with tweakscale you can extend capacity even more if you need it. Midlle level probes have capacity of 20000. This is double than heaviest kOS CPU offer. So, this patch does not exlude kOS parts completely, but makes late game playtrough slightly less tedious, without need to add any kOS CPU on craft.

Ah, now I see that FAR icon was not showing up properly, probably whole FAR failed either. And if I'm right, it was some silly mistake while installing mod.

Something is wrong. Such light craft ~12t and with 0.9 TWR should be able to take off at much lower velocity. At least slightly above 100 m/s, but should be possible around 70-80 m/s too. Consider using flaps, that can help you to slow down and maintain stable landing velocity below 100 m/s. That will be significant help to avoid explosions on landing. Or at least allow you to walk away from craft after landing . Nice looking craft, though.

I see that you created new set of hinges too No longer need to worry should legacy parts would work or not when this comes out.

Yep, I got errors from MM with "|" in commands, it worked with just "#minimumCrew[0]" in conditions. I didn't have time to check out all of crewed command pods, was worked properly from all moded cockpits or not. Have yet to try additional commands for other SAS levels and have another question, does "!" in front of @MODULE works properly as NOT condition ? I have yet to try everything again and test, but previously, when I wanted to exclude if kOSProcessor module exist from patch command, it was excluded from all parts. Meaning kOS was not applied to any of wanted parts. I have something like this in mind: @PART[*]:HAS[@MODULE[ModuleCommand], @MODULE[ModuleCommand]:HAS[#minimumCrew[0]], @MODULE[ModuleSAS]:HAS[#SASServiceLevel[3]], !MODULE[kOSProcessor] ]:NEEDS[kOS]:Final { MODULE { name = kOSProcessor diskSpace = 300000 } } Found that everything need to be in one line, MM complains about it otherwise, but I wrote it like this for better readability.

Uh, you are going too fast while being at low altitide. 371 m/s at 3180 m and dynamic preassure 53147 kPa. That is quite a lot. FAR apply heavy aerodynamic forces and steering manager have struggle to keep it flying straight. And you have wide crosssection area on top that makes craft even more unstable. Try with lower TWR on starting stage, like 1.4 or 1.6 to see if it will improve. EDIT: 371 m/s at 3180 m that is mach 1.1 That is transonic flight (0.8 mach to 1.2 mach) where drag and lift is very non-linerar curve. You can always expect unstable craft behaviour on those velocities.

Yes, something strange is going on. And only with some specific combination of parts within stage that have to be decoupled. After first time noticing it, I have created similar craft with only stock parts. And while issue is detectable on my machine all times, it seems that it does not happen on Rudolf's machine. So it is hard to detect and isolate that bug. If someone can create similar craft that have issues, but only with stock parts (to make debuging easier and faster), send it to Rudolf. It will be easier to solve that issue if he have way to reliably reproduce same bug.

Thanks a lot for this info, it explain why my first try didn't worked. I was put additioanal "HAS" outside first one because I was thinking that MM work like that (obviously wrong). Didn't know that MM only accept first "HAS" and any additional info have to be inside main HAS brackets. To clarify, if I want to access and check extra variables that were inside {} brackets within part MODULE block in original config file, then I have to write like this: In other words additional ":HAS[some_key] behave similar like object accessing object properties in other languages, am I right ? If that is true, than I should need this: @PART[*]:HAS[ @MODULE[ModuleCommand], @MODULE[ModuleCommand]:HAS[#minimumCrew[0]]|@MODULE[ModuleCommand]:HAS[~minimumCrew], @MODULE[ModuleSAS]:HAS[#SASServiceLevel[3]] ] Because minimumCrew was inside MODULE with name "ModuleCommand" and not within MODULE "ModuleSAS". In other words, I want to filer all modules with name "ModuleCommand" and extra filer out only those that have "minimumCrew=0" or that does not have "minimumCrew" key at all. As addition to filter, I need only parts that also have MODULE "ModuleSAS" and with exact key in it "SASServiceLevel=3". Have yet to try that while waiting for confirmation. Thanks a lot again for explanation.

Tricky, but possible. Don't know if latest APP releases add reaction wheel module to heli propelers. If not, you need to add some strong reaction wheels to craft. It is trick that KAX and K.R.X. use to make it feasible to control craft. It is sort of cheaty way to overcome game engine issues with physic simulation. Also, you need to almost perfectly center main rotor above COM. RCS build aid mod can help a lot with this. And last issue is to be very gentle on throttle. Do not allow for vertical speed exceed more than ~10m/s, otherwise aerodynamic forces step in that flips your craft over. I use personal made kOS script to help me with control of helicopters and other VTOLs. But you may also try TCA mod. TCA works much better if you have more than one vertical rotors, though.

I want to add kOS CPU module only to remote controled probes. And I want to probe with higher SAS level (ability to hold prograde, maneuver, etc.) have also better disk capacity. I tried something like this: @PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]]:HAS[#SASServiceLevel[1]]:HAS[#minimumCrew[0]]:NEEDS[kOS]:Final { MODULE { name = kOSProcessor diskSpace = 20000 } } @PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]]:HAS[#SASServiceLevel[2]]:HAS[#minimumCrew[0]]:NEEDS[kOS]:Final { MODULE { name = kOSProcessor diskSpace = 100000 } } @PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS]]:HAS[#SASServiceLevel[3]]:HAS[#minimumCrew[0]]:NEEDS[kOS]:Final { MODULE { name = kOSProcessor diskSpace = 300000 } } However, it does not properly exclude cockpits from B9 mod, only from stock parts. I have also tried with "...:HAS[~minimumCrew]". Still does not exclude them properly. Also for some reason above commands adds kOS CPU 3 times instead of just only once. Have no idea what I'm doing wrong.

That looks awesome.

Won't be last time, even if you just updated KSP to regular version, not even to talk about mods. But, backup is your friend here. I can't even count how many backups of backups of backed up stuff I have on my HDDs, DVDs, USB sticks... You name it.

Glad you have found it. I could not recall those from top of my head, I don't even know if I ever used that mod. Tried to search for them but without good results.

That was long time ago before IR Next was available. Now it is much easier to install, you have everything you need in one archive file.

Should not be issue. CKAN allows resource config file to be installed as standalone option. You can choose to install only Firespitter Core (plugin and dll only) and as separate install "Firespitter Resources config". So, mod author can set both of those as dependency or just only one if mod does not require resource config file. Good for me that I read those, I have installed MM patch to discover more uf bulkhead missing part cuplprit. I think that have some from other mods, but haven't investigated my logs yet.

It seems that it does not throw what assembly is responsible for error. I'm currently attemting to create similar craft that I have issue with, but with only stock parts. And ... it looks like I'm nailed edge of good and bad designed craft. I got similar issue with stability after decoupling as I have with KJR. So, might not be entierly fault on KJRn. Anyhow, I will try to create craft that works without KJRn, but fail with KJRn. If I succeed I will send you both, craft file and logs, so you can catch what is going on. I can definetly confirm that I don't have this error in SPH/VAB without KJRn. If I'm unable to create proper craft, I will send you just log files.

Check out what version of KJR you have installed. Also, check out stock game autostruting on wheels, those can have issues too. Use KJR Next along with IR mod, but you might want to use KJR Next version 4.0.0. Latest available still have some unsolved issues.

Take your time, you will nail it, probably just some small tweaking (hopefully) is necessary. It's like climbing to montain, just few steps until reaching top. Anyhow, I tested again same rocket with decoupling issues, and bug is still present in 4.0.7. KJR menu no longer throws nullreference object exception. But I noticed also similar error when I switch from KSC scen to SPH/VAB. It might be related to Blizzy's toolbar and new toolbar controler (new dependency for Blizzy's toolbar). Might not, but seems that this error does not happen without KJR installed. Does not seem to cause any issue on the whole game, though. But, I also noticed something new with debug version of KJR. Link to album that shows shifting joint points as rocket accelerate then it come back to original position. Also joint color changes over time, I'm not sure if that influence anything to decoupling bug though.

Do you have also firespitter resources config file ? Currently using KAX along with bunch of other mods without issues, well at least not ones that comes from KAX.

My test rocket with issues behave much better with KJRn 4.0.6. No explosions this time, but still have some kraken forces on staging where you don't expect any. Observing behaviour, it seems that on staging KJRn release too late joins between stages. At least I got feeling that it is happening from in game observation. Second issue with debug verion is that clicking on KJR toolbar button produce nullreference object exception. I tried to catch all issues trough screenshots in this album. EDIT: Have to be fair to say, that second stage after separation is slightly unstable without KJRn installed too. But, it only deviate heading from prograde just for tiny amount and quickly put rocket back on track. I might be able to solve this by altering ascent path. Btw, just idea, if it is possible trough available KSP API, to force postponing staging just for one physical tick(frame) or two ? Meaning, when player execute stage command (trough manual key staging or from any other autopilot), first to release KJR joints between craft parts on different stages, wait for one or two physical ticks and then execute staging command. That 1-2 frame will not be noticable to player, but might help with solving unwanted kraken forces.

More likely interaction between latest KSP and parts with colliders that were made for very early Unity/KSP version and part 3D meshes/configs not being updated. While some parts works without any issues at all, some produce unexpected results. Especialy when comes to wheels, those things were reinvented in KSP more times than it was in human history. Can't blame Roverdude, he already have way too much stuff on his "to do" list, I'm grateful for maintaining plugin alone, that is used in many other mods. Bugs like that prevented me to using firespitter parts, no matter how much I like them. You never know if there is some kraken food leftover in them or not. Is it only issue with wheels or some other issue exist too. IIRC part that allow you to use different launching points (cool stuff and idea) was causing massive explosions too. Haven't tried them lately, so take this with grain of salt. Maybe some day if I ever finish any career game in KSP I would try firespitter parts again, but unfortunately have to put them on hiatus for undefined time.

Collisions on IR parts definetly can be issues in some situations. It is worth to try without it. For example if you want tu hide IR parts mechanizm within fuselage for variable swept wing craft you must set collisions to off to avoid explosions.

That issue encountered is confirmed to be due to KJRn beta version- With that one removedm script does job well enough for smooth steering. However, provided setpoints are not optimised, at some phase of ascent craft may steer too much from prograde. That can make kaboooms. But as said, it can be easy customized, either by editing library for more general ascent points that work for most crafts or adjust it trough man script for each craft as you need it.

No problem, I have send you link for craft file in PM just now. I can be patient for next release, don't have much time to play KSP today anyway.