Senaurus

So in order to accommodate myself I added my own patch that adds both "hollow cylinder" or "hollow cone" to procedural decoupler and have been playing with it since my previous post with no problems, which makes me think even more that it was an oversight and proc. decouplers should have that option and that release should have updated them also.

So I discovered that procedural decoupler does not have "hollow cylinder" or "hollow cone" options unlike other procedural parts. Based on the fact that it does have "hollow fillet cylinder" it is safe to assume that it is an oversight, and dev's missed it when they did relase 2.3.0. Is this assumption wrong and there is a reason for proc. decouplers not having those two options? P.S. I did search internet, github, and these forums for an answer and did not find anything, so asking here.

I figured out how to get the main window back. What I think is happening is that the game stores the window location values in memory once they are loaded and ignores value changes from save files. So I think for the changes in the save file to take effect user at least has to be in the Main Menu of the KSP (i.e. no saved game loaded), I actually existed the game completely, then changes have to be made to persistent.sfs file and not any other save file. After that load the game and EL main window will use the saved values. Two notes: 1. If I'm right on the behavior I described I would say that ignoring the position values from the save file is a bug and I will file it if @taniwha agrees. 2. The original issue of "window walking off" is most likely is still an issue and If I see it again I will comeback here. Also during troubleshooting this issue I did see the position coordinates change, while there is no way I could have changed them, since the window was invisible. The coordinates changed from the value in my original post of -137.293961,1822.5592 to -152.548859,2025.06592.

Hi guys, awesome mod. I've been using it for years. Thank you. I have an issue where my build window has "walked off the screen". What I mean by "walked off" is that last few times I used the UI I noticed that window would move up every time I would switch to my construction station and open the EL UI. Last time I saw the window it was only lower half of it, and I tried to drag it to the middle of screen, but nothing I did would grab it. So I just let it go, betting that the next time I switch to the station and try to open the UI it will be gone, and I was right. I did find a fix in this forum topic, what looks like for old UI, since there is no longer "rect" attribute with 4 values, but there is "position" and it only has 2 values instead of 4. Still I tried to zero out position in the MainWindow node (it was -137.293961,1822.5592. ) I only did MainWindow, since the ShipInfo one was already 0,0. Unfortunately this did not return the window. So I re-saved the game under another save file and looked at the "position" values and they were back to the original: -137.293961,1822.5592. What gives? Is the window location no longer is saved in the save file? How do I get the EL window back? Please help. Also my window that shows up in VAB/SPH comes up just fine. Another thing to note is that the mod worked just fine in the last few months, but not sure if that is related, I updated to KSP 1.12.3 and some mods few days ago. P.S. Not sure if the @zer0Kerbal experiencing same issue. His post is quite vague with:

Lol, maybe. I actually had this happen and was wandering what it was. Well now I know. One strange thing I noticed when that happened was that velocity indicator did not change and was still displaying orbital velocity as the ship, clearly, was moving way faster than orbital velocity. In the end I decided not to use computer core or IHal. A while back, like in KSP 1.4 times, I believe, computer core had best reaction wheel to weight ratio, but nowadays it is the same as any other reaction wheel, and that was the only reason I wanted to use it.

Yeah, they do look awfully similar. As far as "Auto stabilizing" goes I did test enabling and disabling it, because I thought slowness had to do with it, but removed those steps from the post because when I was doing timing it showed there was no definite difference between that option enabled or disabled, and post was already too long. In the end, I posted the issue, because I really wanted to use Computer Core, and the reason for that was that I remembered wrongly, that Computer Core had the best reaction wheel strength to mass ratio in the game, but I just checked and it clearly is not the case. At this point I don't think it is a big issue for me. I will just use IHAL instead, since it works just fine when "Auto Stabilizing" is Disabled (due to the RCS translation issue, not performance.) Thank you FreeThinker.

Man you are good, thank you for reply. I did say "but when I do NOT use the computer core everything behaves normal", what I meant by that I had exactly the same 2 ships, but the tug had no computer core on it (that was the only ship out of two that did have it). Tug already was using the Construction Docking Port, which already has Command Module, so I did not have to replace Computer Core with another item, I just removed it. During this the game ran just fine, no slowdown. Clearly the only steps I did were 1, 2, 5 and 6, since there were no performance degradation. Also, I did the same steps (1, 2, 5, 6) with only IHAL being replacement of Computer Core , which was implied by statement: "IHAL does not have this issue " Sorry for not being clear.

First of all one of the best mods ever. Thank you @FreeThinker. I am experiencing interesting issues with Computer Core. If I use Computer Core on a ship then following happens: 1. Something is starting to eat up processing power of the threads on which the game resides, and the game turns into a slide show, but when I do NOT use the computer core everything behaves normal. IHAL does not have this issue 2. When "Auto Stabilizing" is set to "Enabled on either Computer Core or IHAL translation using with RCS is not possible unless the ship is ordered to rotate first, that does something that allows for translation using RCS to work for a short time, about 5 - 10 seconds (this time is dependent on how ship responds to rotational input. If ship has to takes longer to counter rotate or stabilize after initial input to rotate, then there will be longer time of functioning translation.) Disabling "Auto Stabilizing" allows for normal translation using RCS. Now more detail on the issue with performance. There are two ships: a station (162 parts) and a tug(50 parts) and here things that I did in the last test: 1. Deployed Tug on surface of the Earth. Performance is fine at this point. 2. Used cheat menu to rendezvous with station 250 meters away. Performance still fine. 3. Did not touch anything and let the two ships sit at least 250 (they slowly drifted apart) for about half an hour. No noticeable performance change. Wanted to rule out that this is time related, which looks like it is not. 4. Rotated and translated for a while (about 5-10 minutes) without closing the gap between the ship (at this point ships where about 360 m apart.) No noticeable performance change. Wanted to rule out that this has nothing to do with translation or rotation of the tug, due to the "Auto Stabilizing" issue described above. 5. Started to close the gap at about 2 m/s. a. At about 200 m performance is significantly worse, and the closer ships get together the worse it gets. b. Somewhere between 200 and 100 m RCS translation stops working, and to get it back I either have to send rotation command first or set "Auto Stabilizing" to "Disabled". 6. Docked the tug to Station. Performance stays bad. 7. Undocked and tried to move away from station in order to test if increasing the separation returns the performance back to normal, but unfortunately station exploded due to gravity forces (I think it has to do with Auto Stabilization.) 8. Repeated steps 1,2 and 5 with same results. 9. At 50 m started to use RCS to reverse the ship movement to test if increasing the ship separation returns the performance 10. Got as close as 42 m at which point the ships did not get any closer. 11. Increased separation velocity to 1.8 m/s. 12. Separation is at 120 m the performance is not returning and it is less than 1/10 of real time. (in 6 seconds ships only moved 1 m apart when they should have moved about 10.8 m. Original performance probably was not real time either but it was pretty close to 1 to 1.) 13. At separation of 200 m performance is still bad at about 1/10 of real time as in step 12. 14. At 300 m Performance still bad. Tried to activate engine via staging but it did not activate had to manually trigger via part menu. 15. At 320 m used engines to accelerate to 42.2 m/s 16. 1000 m no change in performance. Still bad. 17. Even after the Station has unloaded at 2.5 km performance has not returned to normal. I did not expect this.

So there is am intermittent bug with the contract system. Specifically, for some reason Space Camp contract lost track of a Kerbal. I looked for that kerbal for an hour across all of my ships, and eventually found him where he supposed to be and on the station where the camp was supposed to be happening, but the contract info showed him absent. I moved that kerbal from one part of that station to another and contract refreshed and he was shown as present, but timer got reset. I do realize that the issue might be be exactly the problem with contract but it would be nice, as someone else already asked before here, to make the contract not reset the timer but pause it, if some criteria turned from compete to incomplete. This at least will somewhat address this issue and actually would make Space Camp contract more realistic.

This happens on attempt to dock in orbit of Earth at altitude of 800 km. My statements are based on info I gathered when I was researching the issue I mentioned about the runway being uneven, which could be worked around by constantly reloading a save and eventually get a relatively smooth runway (sometimes I get a runway at Kourou that has a minimal bump but this happens extremely rarely.) This was long time ago so I cannot reference. Still, even if the coordinates are not heliocentric, but whatever body I'm orbiting (Earth in this case), double precision values are only good enough up to centimeter precision (I think half a centimiter to be exact, I did a GPS sim using Java for my final project for Numerical Analysis at university and double precision values were only good up to that point ). So if they system does constant recalculation of position errors can pile up and eventually things will go out of place.

Just letting others know what possible solution could be if you are using Real Solar System mod (RSS). Fix: Save game and reload the save. Possible cause: I believe it has to do with Real Solar System mod. RSS exposes one of the limitation of KSP game engine: it cannot calculate location of things precisely enough at the scales of RSS (I speculate that was one of big reasons why we got a solar system that is 10 times smaller than real one in the stock game.) Good examples are the runways that have bumps between sections (I use Kourou and that one has one huge bump between 3rd and 4th sections.) This problem exasperates by 3 factors: 1. Time since the vessel(s) have been loaded. 2. Size of the vessel. Specifically it seems the farther the part is from either root part or center of mass will have their bounding boxes dislocate faster as time passes. I am not sure about this one, but docking ports closer to center of the vessel did not give me any problems but ports at far points did. 3. Also not sure about this one, but it seems that the bigger the port the more likely the issue will occur, so Docking Port Sr. is more likely to glitch than regular port.

MechJeb has it. There are check boxes for all three in Attitude Adjustment panel. Extremely useful for balancing the plane with fuel.

Not sure where to raise this problem, but decided that KSPI is better place because it is a less global mod than Principia. Anyway whenever Principia(https://forum.kerbalspaceprogram.com/index.php?/topic/162200-wip131-143-principia—version-dedekind-released-2018-06-13—n-body-and-extended-body-gravitation-axial-tilt/) is installed (a drop in, not in ckan) ArcJet RCS based components stop providing linear thrust ('h' and 'n' keys in rcs mode) but rotational (torque) works just fine. Just to clarify stock rcs work correctly with principia installed.

Not sure where to raise this problem, but decided that KSPI is better place because it is a less global mod than Principia. Anyway whenever Principia(https://forum.kerbalspaceprogram.com/index.php?/topic/162200-wip131-143-principia—version-dedekind-released-2018-06-13—n-body-and-extended-body-gravitation-axial-tilt/) is installed (a drop in, not in ckan) ArcJet RCS based components stop providing linear thrust ('h' and 'n' keys in rcs mode) but rotational (torque) works just fine.

I have same issue. Collect rear science from Water Landed and I cannot get it to register that I have collected science data. Originally it was three peace: collect laser data, Hydromomenter (both DMagicSci mod) and Magnetometer. On that mission I was able to collect first two but the magnetometer would not collect. The one difference with that experiment was that it was already completed, which is strange in the first place, since mod was smart enough not to include completed experiments up until that point. I eventually completed that mission from the ALT+F12 console, but mission came back, but only had magnetometer scan. I assume that is because i have completed all experiments (including the magnetometer one), but the magnetometer one does not get registered as completed. So what is going on? Update: After some digging, I found what the issue is: it is does not actually looks like the problem is this mod, but some other mod (probobly community science.) Magnetometer is registered as one name, but when the game is saved completed science for this experiment gets recorded as another, so contract parser thinks that magnetometer experiment is not complete. I worked around this by adding completed experiment with correct name to my save file.

I reinstalled KSP and it seems these problems went away.

I'm having difficulties with two of my ships. Whenever I'm viewing space map, there are two ships (out of a dozen) that have blue brackets around them and I cannot select them while on the space map. Thankfully Kerbal Alarm Clock allows to jump to those ships, if I have an alarm setup for those ships. Another way I can do it is by going to Tracking Station and selecting the ship from the list only, not the map itself (that still does not work in tracking station.) Since the both ships have blue brackets around them, I speculate that the issue I'm having is part of the game play, so not an issue with the game but me, not knowing what is going on. Now, I think it might be Remote Tech mod that is doing something, but I'm not sure, since one ship is crewed, and another has a link to Mission Control and I still cannot select either of them. I do have a bunch of other ships.probes that work just fine. Anyone knows what is going on?