kcs123

Yes, that is why I suggested long time ago to slightly increase part numbers for level one building. It is necessity to use RCS ports early on, and you only got limited unlocked RCS parts too. Key is to reduce thrust on those RCS ports, so that is not too powerful for early light probes/rockets. It is harsh, challanging, but possible to put rockets in orbit. I played on hard settings (everything but quick saves and reverting flight due to possible crackens). Also with all ground stations disabled and only with KSC as part of ground comm network. Long story short, I was able to establish comm network of sattelites, earn money from contracts and started to create space stations and send large expedition to Duna before I put my career on hold in KSP 1.7.x. Enjoyed all mission progress.

Yep, I know that is not proper syntax, it more proposal that MM may be upgraded for something like that. More a wish that MM can do something like that than it already is that can do that. As I said: I didn't wanted to bloat this thread too much, since it it more relevant of latest conversation in Tweakscale thread and MM thread where new problem arised with too many competitive mods that racing with each other with LAST and FINAL command. Issue is that for example mod "B" and mod "C" attempt to modify same part defined by mod "A". Both of patches in mod "B" and mod "C" use LAST command in patches. And therefore errors due to bad patching poping up. And it is not only mod B and mod C, we already have situation that tens of mods compete with each others with LAST command. With more new mods publishing situation is going to be more severe each day. So, all that talk about FOR command and how it work gave me idea that it may be good if it can be used as mentioned in example above. It might allow to create other MM patches in more convinient way than it is possible now. Sorry, I again going too offtopic for this thread, MM thread might be better place for this.

Well, as far as I know UKS does not really need another directory with "zzz" prefix. It already got "UnkerballedStart" directory. So, it can use it as advantage where needed. Somewhere might be enough to have just "UnkerballedStart" in MM BEFORE/AFTER commands and where necessary, second layer of MM commands may be used with "zzzUnkerballedStart". Btw, does not necessary be named as "zzzUnkerballedStart", but since it was used from day of release, it shoul remain, others have wrote their personal MM patches based on it. UKS does not mess around with changing parts so much, so it is less dangerous with creating something that would broke TS patching, but it is always possible, so it is best to be aware of it and avoid if possible. What about people who don't have Making History DLC ? Will be :FOR command triggered properly ? Sorry, I didn't have time to inspect the rest of code. If MM in Making History config is ensured to be executed than it is all good, but something to be aware of if it is not a case. And sorry for being a bit offtopic, but since I watched TS and MM thread and knowing about need for agreement of proper order how MM patches are executed, some idea have arised about it. I don't know if it is possible, or it may require changes in MM itself, but would be possible to have something like this: // detect combination of already installed mods @something[]:NEEDS[ModName1,ModName2] { // declare new name that MM is aware of and that can be used for other patches :FOR[ModCombination1] } @something#2[]:NEEDS[ModName1,ModName2,Modname3,Modname4] { // declare new name that MM is aware of and that can be used for other patches :FOR[ModCombination2] } // new declared names "ModCombination1" used for actual part patching only if it is declared with proper mod combo: @PART[KAXVintagePropelator]:NEEDS[ModCombination1] { @TechRequired = start } Above is most probably not proper MM syntax, but should be enough to give you idea how it should work. Meaning, "ModCombination1" should exist only with certain combination of already installed mods and any additional patches on parts would be executed only if "ModCombination1" exist. @Lisias, would something like that help with current situation with ongoing race with :LAST/:FINAL MM commands between various mods that mess around with same parts ?

Sorry, I was sleepy and my brain didn't registered new thread link. I will continue any further conversation there.

Yes, I know about it because it was adopted on my suggestion, to have increased part count slightly instead of price swap changes for SPH/VAB/Launchpad . I don't complain about it. Reason why I mentioned it is this: Meaning, since FOR[zzzUnkerballedStart] command is definded in CustomBarnKit and not anywhere else, MM is not aware of "zzzUnkerballedStart" if CustomBarnKit config is disabled. And it was disabled by default for few versions of UKS. That implies that all of BEFORE/AFTER[zzzUnkerballedStart] patches were not executed exactly as intended when CusomBarnKit config was disabled. If I understanded properly how MM works. As much as I know, disabled CustomBarnkit config didn't do any harm, or I didn't notice any on applied UKS patches. So, if :FOR[zzzUnkerballedStart] is necessary to have for proper patching order, might be good idea to declare it in some other config file that is not recommended to be deleted/disabled for users that don't like current CustomBarnKit config. Just wanted to be aware of it. Sorry if I'm wrong in case that I missed something else that I didn't aware of.

Spink originally used :FOR[zzzUnkerballedStart] in order to make sure that the UKS patches ran after whatever part mods someone might have. I asked him to use :BEFORE[zzzUnkerballedStart] so that I could make the tree adaptive - using :AFTER[zzzUnkerballedStart] to move parts around depending on which mods someone had installed. The CustomBarnKit config has :FOR[zzzUnkerballedStart], which tells ModuleManager that it exists. Not sure where the zzz came from. I might try without it, but not in my first update. I migt be wrongf on this, but IIRC, CustomBarnKit configs were optional/disabled at some point of development ? Again, it is jut my blurred memory from top of my head, I will need some time to check out all of my old installs, but might no longer be of importance at all. At time of wroting that post, I was not having knowledge about MM syntax and proper usage of FOR command.

Quote from OP: You can also other stock parts, like claw or parts from other mods, like KAS. There is plenty video examples with various combination how to do it. However, you will get better luck with older versions of mods and KSP, because latest IR Next is working stable up to KSP 1.7.2. For newer KSP verions, it may or may not work properly. Also KAS whinch and docking magnet is also not updated (last time I have checked). So, yes, in theory, you can build a crane for lifting stuff, but you may need to do some research what other mod and version of that mod work properly along each other. Especially for KSP version higher than 1.7.2.

It seems that you have more issues to properly control rockets than design / red stability derivatives value faults. When comes to rockets, it is "normal" to have red values for stability derivatives. Main control issue comes if you try to steer rockets in sam way as in stock aero physics. With FAR you should not steer more than 5 degree from prograde vector when you are in atmosphere. If you do it properly, your rocket should not need fins at all, especially if you have engine with decent gimbal and RCS. Even unproperly calculated derivatives in VAB should not have that significant impact if you gradually steer rocket instead of sudden 45 degree steering from prograde vector like most of new players have habit to do in stock game. Just my guess what is going on, it is hard to say with provided info, some screenshots or short video from flight scene might reveal if I guessed proerly or not.

Ah, that explains. It is forked version of Infernal Robotics, for backward compatibility for KSP 1.6.x/1.7.x made by @whale_2, while latest available IR Next version on githgub is no longer supported for KSP 1.6.x/ 1.7.x. Probably due to different version of unity game engine used for latest KSP. That seems to be fork of "original" version of IR linked in my previous post. With so many forked version around, it is hard to tell what is original source code. @whale_2 should be able to tell more about it, is it from original plugin, or maybe some improvements from IR Next is also included in his fork too. Sorry, can't tell more, I don't watch RO thread, so I didn't even know about that fork. Anyhow, I recommend to not use either of those from CKAN. Because latest available releases on Github, for both, IR Next and whale_2 forked versions are marked as "pre-release". Meaning, CKAN would not show those as available for install. Bugs you are encontered might be already fixed in that pre-release versions. However, it is marked as "pre-release" for a reason. Meaning, some issues might not be ironed out yet.

Can you give exact link for "Infernal RO-Robotics" ? Forum thread or github link. I have missed info if anyone created forked version of Infernal Robotics for RO. I can only guess that is forked verion of original IR plugin: It is older version of infernal robotics plugin that worked more/less properly up to KSP 1.1 or KSP 1.2 (I no longer recall exact version). With some luck it might even work for newer version of KSP, but I doubt that it can work for KSP1.9.x or KSP1.10 properly (never tried, so take this as grain of salt). Infernal Robotic Next is completely new plugin rewritten from scratch. Only name, 3D models and original idea remained from previous title. Almost everything else in code is new with some new features and bugfix/workaraonds of issues that original IR have. Unfortunately, IR Next is not yet recomiled/updated to work properly with KSP 1.9.x and KSP 1.10.x.

That looks more like Tweakscale issue than IR by it's own. What version of KSP you play at ? And what version of IR you using ? @Lisias migt tell you more about it. IIRC some kind of bug with ALT+Click copy was mentioned earlier in tweakscale thread, but I didn't remember all details about it. Logfile and craqft file with minimum mods required to reproduce bug might help to figure out issue sooner.

Well, you can workarond of it by breaking symmetry. First, place parts in symmetry mode, copy mirroed parts wiht ALT+Click and put asside. Then place original parts without symmetry and copied oposite side after that. Example that I used in the past to avoid KSP wheel autostrut issue : https://imgur.com/a/stBBB . Not exact same issue, but main idea is the same.

Yep, it is possible that some of parts still have that issue. But, you have ability on each part PAW to invert motion of that part.

I'm not sure if kOS scripts should be qualified as full mod at all. Sure, people crating quite complex stuff with kOS that almost look like a mod, but IMHO it much closer to KSP craft files (as some scripts may be even tied to specific craft files) than it is as full mod. IIRC, regular gamedata folder is deliberately avoided to be used for script files, so on any update of mod or KSP itself users does not loose their personal scripts. Btw, how CKAN handle other mods that ships craft files as well ? Like FAR, B9PW and similar (those are first that poped up on my mind). Maybe that user can create some dummy folder and dummy config file within gamedata folder and kOS scripts can be then in intended Ships/Script folder ? Anyhow, each user should be extra careful with installing those, to not overwrite their own homemade script files by installing that mod. There is small probability that there is same script filenames that is shiped with that mod and that some user is already created for himself. Not that it will happen a lot, but it may be possible.

That is why I called you for confirmation or denial.