Jump to content

kcs123

Members
  • Posts

    2,593
  • Joined

  • Last visited

Everything posted by kcs123

  1. I don't know, I'm not that familiar with Restock mod. It is worth to try. Stock engine names in config files that were copied are "liquidEngine" and "liquidEngine2". UKS copy those parts and put some custom config to scale it down, to be useful for UKS mod. Config files for those part are "UKSliquidEngineLVT05.cfg" and "UKSliquidEngineLVT10.cfg". And now that I have opened those files, I have found that there is some additional MM command if Restock is installed or not. As well as if some user have MissingHistory DLC or not. I'm not sure what is effect of those additional MM commands. But it also give a clue that UKS was working properly with Restock mod at some point in development. Not sure what exactly happened that those parts are become broken. Anyhow, there is few options to try. One is that you whitelist mentioned stock engines. If that does not help, then it may be possible to write custom MM config file that would make a copy of Restock engine, instead of stock engine names. Don't know what part name from Restock is suitable for this. Third option would be to use some of Restock engines and put those earlier in tech tree, if there is some comparable engines with size and thrust from Restock mod. If neither of those help, you could try to ask for help in Restock mod, because, as I said, I'm not familiar with that mod and how exactly works, so I can't give you accurate answer what MM patch can help to resolve issue.
  2. Uh, that same piece of code from TS seems to be much needed to integrate within MM. Not only to throw error in log, but also to give same/similar scary message on UI too. Not much developers and users use TS, although there is plenty, but MM is mandatory for everyone. That might help developers to find faulty patches prior publishing mod.
  3. Yes, Restock seems to be culprit. Already reported on previous page:
  4. I think that TS does dump those in logs, probably MM put something in logs too. But logs are often oversighted by regular user until issue become obvious in gameplay. Scary warning on screen is huge plus with something like this. Without TS warning, who knows how much time will be passed until error is discovered.
  5. Yes, but exception might be parachutes. After you uninstall FAR, make sure that FerramAerospaceResearch folder is deleted from Gamedata folder, otherwise MM could apply patches on parts unproperly. Now, parachutes may be exception because FAR use light version of realchute parachutes. You may want to remove those from craft and put stock counterparts. Next thing to pay attention is that wings/control surfaces may have different weights due to FAR feature of increasing wing strenght and mass vs stock default fixed weight. therefore COM may shift and planes could not behave properly. In conclusion, comparing two "same" craft with and without FAR could be like comparing oranges and apples.
  6. Take your time, this kind of bug is not always easy to narrow down. I think that recently reported issue: https://github.com/shadowmage45/KerbalFoundries2/issues/12 is same as this one: https://github.com/shadowmage45/KerbalFoundries2/issues/42 I don't think that it is related with FAR voxelization, FAR can do that pretty fast and does not cause much of hickups in more complex crafts where KSPWheel is not on craft. I was able to narrow down issue to having KF wheels on craft and time when GC doing garbage disposal. For some reason GC have difficulties to do it's job with KF on craft. MemGraph helps a bit with this, but does not solve problem. Don't know if issue is more or less obviuos with or without FAR installed. If FAR still cause slowdowns, it may be related to animation being triggered. Each time some animation happens, FAR also do voxelization process, to recalculate forces based on new craft shape after/trough animation. It's wild guess, but could be possible that KF keep triggering animation or something while in flight, regardless of animation not being visible on scene ? Anyhow, I hope that my thoughts would help you to narrow down issue, rather than distract you from true point of that issue.
  7. AFAIK, it is still WIP and not published yet. Don't know if there is github repository or something with current status and source code if you wish to contribute.
  8. There seems to be already opened issue on github: https://github.com/shadowmage45/KerbalFoundries2/issues/42 You may want to post your craft example and issue description too on github or in KF thread.
  9. That looks to me like collision issue, either, between craft parts and/or between craft and ground. Several things might be worth to try: Avoid cliping craft parts on craft More distance between wheels and drill higher clearance between ground and craft parts Try to test same craft on Kerbin, leave it somewhere, return back to KSC scene and then go back in "flight" to that rover, to see if it will bounce when scene is loaded You could also discover some specific spot on EVE that might cause kraken forces, maybe to move rover away from that exact spot could help ? Anyhow, I don't think there is issue with WorldStabilizer mod, rather something else that yet need to be narrowed down.
  10. Unfortunately, no, I also like those AGL, but could not find alternative to those. And AGL is not originaly developed by current maintainer, so there is quite a lot possible issues coming from this and from integration with KF or KSPWheels. I'm not sure how much can be done with that bug, but if you report politely and provide as much as info as possible, including that video it is more possible for Shadowmage to investigate it and eventualy make a fix for it. Quite a lot was changed trough KSP developement and mod development, so it can be anything causing it. I was not 100% sure about exact reasons behind it and didn't want to bother developers with false bug reports if I'm wrong.
  11. Have you tried same plane, but without advanced landing gears ? IIRC, I was having similar problem in the past, I narrowed it down to issues with KSP garbage collector and ALG in combo. I tried using MemGraph mod that track down memory usage and disposal and help to some degree with garbage collector slowdowns. But, could not make it run completely smooth in KSP 1.7.x I don't think that issue is with FAR, it is something else involved or some combo of different mods used.
  12. Above MM patch should work. But, since there is several patches that may try to move part around, it is good idea to put your own custom patches in folder with name that start with "Z". Whatever that will ensure that your folder is last in alphabetical sort between all other folders witin Gamedata folder. For example, I have named folder with personal custom patches as "ZX_CustomTweaks". Therefore "FINAL" command in MM patch is not needed. On the other hand, if in some cases you want some patch to be executed before any other MM commands, you can use some folder with name that starts with "_" or "(".
  13. Not sure if I have understand question, I guess that you want to increase stiffness of joints ? it is possible to write custom MM patch that will increase joint strenght: However, it helps to some degree, but not completely solve issue. Main reason is KSP/Unity piece of code that was changed in latest Unity game engine version. So, in general, all joints are weaker than it was with old KSP 1.1.x and old IR mod. I doubt that something in IR code can improve joint strength much further without breaking whole game. So, you might need to invent diferent contraptions to make craft working better. Like using more than one IR part to move one craft piece or similar.
  14. It worked: Solution is to trick CC that returning ship is "station" that was around celestial body for X amount of time or whatever requirement is, or "main" craft for contract requirement. Whatever part of ship that remains in orbit should be considered as "probe", "debris" or something that is not important piece of craft for given mission. Unfortunately KSP by default use bigger craft in terms of mass and part counts to be "main" craft after undocking. That can confuse CC contracts.
  15. I'm glad that it helped to rename ship, at least some kind of workaround. What can also help is to click on "[+] Note" to reveal all details on contract requirements. Some of those may change on (un)docking and when ship is renamed. Can't help you much how CC works, I bothered with some of contract mods when I discovered exceptions in logs and searching how to fix those. But, best bet is to check CC thread and github source code to get better info how it works internaly. Might be possible to change how contract is generated to avoid such issue, but also it is possible that something have to be changed within CC and even in KSP code to fix such issue.
  16. @Crixomix and @MissMolly, current stock comm-network does that, but you have to choose option in difficulty settings - require connection to control and comm blackout on re-entry. It is more simple than RT, though. You don't need to specify connection to other crafts/relay stations, but you are still required to have optical visibility and enough power/range to establish connection on distant probes. It is not bad, in my opinion. You no longer need to micromanage each connection route, but it is still necessary to launch sattelites and establish proper comm network. In my last few career games, I have also restrictred myself to only KSC as ground station. Using Unkerbaled strart tech tree as well, it provide good chalange in the game. Still, RT have charm of it's own with more antennas and different way of calculating signal strengths.
  17. Yep, while EVE is closer, dV requirement is much higher, so it is not good choice if you want to leave Kerbal SOI early in career game. You may not have enough parts unlocked and enough science for EVE and that might you leave to tedious grinding around Mun and Minimus, while other planets may provide better rewards in terms of science points required to unlock more parts. I didn't used much of other mods that mess with reaction wheels, except already mentioned semi-saturable reaction wheels. Others might be able to offer better suggestion on this.
  18. I haven't tried PCB, although, I know about it for some time. So, not exactly opinion based from gameplay, but rather what is written in PCB thread. Yes, both mods are similar in concept and have similar goals. There few differences that I have noticed though. UKS does not alter stock/mods parts, it only moves those around in tech tree nodes. Instead, to fill gap from stock parts, UKS provide few parts scaled to smaller variants of existing stock parts (engines). Early in game, UKS encourage usage of RCS to steer craft, rather than reaction wheels. This also leed to requirement of more parts allowed on craft at level one SPH/VAB buildings. Therefore is Custom Barn Kit MM patches to balance this requirement. PCB have positioned some of parts in slightly different manner than UKS does. Science requirements to unlock some nodes and what you can get from contracts are bit different too. Without actualy playing game with PCB, can't say much more about it, which one works better than others. It is worth to try both if you have some space on HDD, you can have two instances of KSP install, one with UKS and one with PCB, so you can try both and compare.
  19. I belive that it is due to how contract configurator works on all contracts. When you undock, your return craft is renamed automaticaly to something like ship/probe with some name. Try to use PAW on command module and rename that ship to be "space station", despite you don't have any space station module on it. CC alghoritam is stupid enough in some scenarios, so that will be enough. Unless in contract is stated that craft need to have some exact part to fulfil contract. Above is based on my experience with some other contracts, not exact contract with Station Science. I don't think that something is wrong with Station Science, but rather how contracts are configured to be generated with CC for Station Science parts. Try above advice to see if helps and picture of contract requirements might help a lot to narrow down issue
  20. It depends mostly on available free time of developers. In most cases, any craft part mod that is compatible with stock or CTT tech tree is supported without any necessary changes. Only reason to write part/mod specific MM patch would be if some part breaks gamebalance too badly. Meaning, such part is overpowered for some early techtree node or some part become available too late in techtree node when it is already obsolete due to other better parts being available etc. If you think that some mod/part need changes, make a suggestion in this thread. Even better if you are familiar in writing MM patches, you can post it here to others for testing and if it fits, it can be included in some of next updates. Other than possible gamebalance issues, there is no reason to not use any mod part pack that you like to use in your game.
  21. Neither, manual install or trough CKAN is completely foolproof. Manual installs can be tedious and when you doing install when you are tired or sleepy, it is easy to make oversight and create silly mistake. On the other hand, CKAN installs are only good as how good is metadata written, to know conflicts with other mods installed, dependency mods etc. Key is to know how mods work behind a scene, so you can detect install mistakes, regardless of install method, manual or trough CKAN. While CKAN is improved a lot over the yers and users also become better with manual installs, mistakes still happens. It is good to detect those early, so that developers don't waste time in attempt to solve bugs that don't exist.
  22. I can only guess, but I think it is last option, that someone patched it badly, but I can only guess what is going on. TS have improved a lot lately, I didn't tell that it cause kraken-a like bugs, but my habbit was stayed, to use TS on limited number of parts, from times when TS was less stable (much longer before you taken a torch in development of TS).
  23. Have you tried to play arond with craft naming feature under command module PAW ? For each probe is possible to set specific ship name that should be preserved even after undocking. IIRC, it is stock feature and it should prevent creating random craft names after separation. It is being a while, but I think it is possible to create script in a way that use exact vessel name instead generic "SHIP". Hope that it helps.
  24. Most probably because those are already scaled down versions of stock engines (without tweakscale plugin, using only "stock" MM patches). So, yes ordinary TS scaling might not be proper for those and can mess up things. @Lisias might be able to tell more about it when times allow. Those engines are not even considered to be scalable, it was introduced with UKS to help filling part gap for early career game where smaller crafts and probes are intended. Later on, when you unlock regular stock parts, those should be properly scalable up and down with TS. Can't tell how those parts were even get TS MM patches, I didn't pay attention for those that much. I was using TS mostly on IR parts and limited few other parts in my career game. That helped me to avoid most of the kraken attacks. Good guess. Those engines rally on stock parts. It is just MM patch that copy stock part and make some adjustments, to be smaller in size and weight, thrust, prices, tech tree node when be available, etc. As much as I know about restock mod (never used that one), restock hide all or most of stock parts and install it's own version of those parts. To fix those, it would be necessary to write new MM config file that would copy restock engines and create new LV-T05 and LV-T10 engines from restock files. Just in case when both mods are installed : restock and UKS.
×
×
  • Create New...