Jump to content

Kaa253

Members
  • Posts

    612
  • Joined

  • Last visited

Everything posted by Kaa253

  1. Thank you for the comprehensive answer. I really appreciate you taking time to explain it. If/when the 2 dll are on the correct paths then it is not working for me. I do see assemblies loading in alphabetical order so there is hope that all is not screwed. However, I am not sure what I am seeing! It looks like the assemblies load in correct order at game launch and then around the time the menu appears for some reason the Player.log file is getting deleted and started afresh. The new Player.log starts with the RPM dll failing to find MechJeb and it seems that a bunch of dlls are then getting loaded for a second time. Why this is going on I don't know but I do have a lot of mods and one or two are not behaving well. I think the restart of logging is in itself indicating something wrong with my modded KSP. That odd restart of the logging makes it pretty difficult to diagnose. I am a bit too tired to chase it further tonight. I am waiting for a couple of mods to release 0.23.5 versions. Perhaps these updates will make a difference. Otherwise I should be able to look at this again come the weekend. Armed with what I have learned from your "proper" answer I might be able to figure it out then.
  2. I am having the same problems. I uninstalled Distant Object which contains "DarkenSky" and got no change with the mechjeb RPM not working. I have uninstalled RemoteTech a long time ago as it is very seriously bugged at present . My Player.log (Linux) says... The following assembly referenced from /home/kaa/KSP_linux/GameData/MechJeb2RPM/MechJebRPM.dll could not be loaded: Assembly: MechJeb2 (assemblyref_index=3) Version: 2.2.0.0 Public Key: (none) The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/kaa/KSP_linux/GameData/MechJeb2RPM/). So largely on a whim I moved MechJebRPM.dll into the ~/GameData/MechJeb2/Plugins directory (sitting beside MechJeb.dll) and now it appears to be working correctly excepting that it prints large on screen the message... "ERROR:MechJebRPM.dll must be in GameData/MechJeb2RPM but it's in GameData/MechJeb2/Plugins"
  3. I deeply concur. Thank you stupid_chris for this truly awesome mod. Congrats for the 4000 posts and even the beautiful coding (I am a scientist who "attempts" to code too )
  4. MechJeb's docking AP is currently broken as it backs me up about 1 km from my space station before it starts in to dock. I can manually dock the stock game but it takes an age and often involves knocking off a solar panel here and there. OK I thought, what else can help me to dock better? I found this, download/install, put my capsule about 20 meters off the station dock. Next, watch the navball, 4 fingers on the RCS keys and I just drove straight in for a perfect docking. Amazing! Faster, simpler and more entertaining than AP docking. I highly recommend this utility, thanks. Edit: Gosh, and I used only 3 units of monoprop as well!
  5. I hope and trust that's Woomera range in the image Looking really good! I am definitely following your progress on this.
  6. A big thank you to r4m0n and all the MechJeb team. The blank icons seems to be caused by the change in folder location. Before the icons were in MechJeb2/Plugins/Icons and in the later release they are located MechJeb2/Icons. If you install them in the new location for the latest builds then they are not blank. On the other matter, I think the behaviour I am seeing is the icons disappear after all the main windows (i.e. excluding the custom windows... odd???) have been closed. Hope this helps.
  7. Build #198 & #200 have been giving me this... (Filename: /BuildAgent/work/d3d49558e4d408f4/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53) MechJeb module MechJebModuleStageStats threw an exception in OnFixedUpdate: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2[Part,MuMech.FuelNode].get_Item (.Part key) [0x00000] in <filename unknown>:0 at MuMech.FuelNode.FindSourceNodes (.Part part, System.Collections.Generic.Dictionary`2 nodeLookup) [0x00000] in <filename unknown>:0 at MuMech.FuelFlowSimulation..ctor (System.Collections.Generic.List`1 parts, Boolean dVLinearThrust) [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleStageStats.StartSimulation () [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleStageStats.TryStartSimulation () [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleStageStats.OnFixedUpdate () [0x00000] in <filename unknown>:0 at MuMech.MechJebCore.FixedUpdate () [0x00000] in <filename unknown>:0 Occurs at staging. All remaining stage's delta-V are then reported as being = 0. Returning to the space centre and then back to the craft appears to clear up the incorrect display of remaining delta-V for the current stage. When the exception occurs, if I am using Ascent Guidance there is no problem, mechjeb still delivers a normal climb program to orbit.
  8. Confirmed. Thanks for reporting it Jeffrey. Always good to know that it is not just my install doing bad things. It is spamming errors in the log as well.
  9. Oh... awesome. Thanks heaps for the rapid hotfix. I have been busy with RL work and missed your update 4 days ago. I will test it over the weekend and let you know ASAP.
  10. I may have found something myself. I found I had one old Moho lander probe with a dish aimed at a no longer existent comms satellite. I re-targeted that dish (after warping days ahead for the sunrise/solar power) at a satellite in my new comms fleet and Hey Presto!, I can enter the tracking station again. I don't know, is it a hint to what is going on perhaps?; or just a totally unrelated and random set of events? Is there an attempt being made to do a line rendering from the probe to a non existent vessel? There have been others who might have been reporting (months ago) a possible link between the lock-ups and dishes targeted at "unknown" vessels... http://forum.kerbalspaceprogram.com/threads/56399-0-23-RemoteTech-2-v1-3-3-Late-Christmas-Edition?p=842972&viewfull=1#post842972. I will keep watching for clues to this problem. I appreciate that it is a Unity crash and hence very difficult to debug. What's the bet that I get the opportunity to investigate further when the tracking station lock-up returns to my current career? Oh, yes, and I am using KAS. Edit: No... more testing and it doesn't hold up I got past the lock-up which is great but I still have no clue why it happens nor why it later on stopped happening.
  11. It sounds like a KAS issue to me rather than an RT2 one. I have come to expect the unexpected spontaneous disassembly with KAS:huh: Otherwise, I am out of ideas, sorry.
  12. If you are using the community hotfix on the first page of this thread it is probably NOT RT2 causing your ships to come apart or explode. You should check in the tracking station however to make certain that you have not got any duplicated ships listed there (this is now a rarely occurring bug). If you have any duplicated ships listed in the tracking station then delete the duplicate versions and exploding will then cease. The separate tracking station lockup bug seems to be the only real bug coming out of the hotfix version of RT2. No known fix for that, only work-a-rounds. If you large ship is falling apart rather than violently exploding then I strongly recommend Ferram's wonderful joint reinforcement mod http://forum.kerbalspaceprogram.com/threads/55657-0-23-Kerbal-Joint-Reinforcement-v2-1-3-7-14. In my experience, the TAC parts mentioned in the reddit thread you link above have particularly weak joints.
  13. Just reporting that I have struck this too. Twice my heavily modded careers have reached this point and it does occur at around 30 or so active vessels. The tracking station lock-up rapidly eats RAM as reported before. I have tried to perform a diagnosis to determine if another mod is involved with RT2 "playing into this" but found nothing to point a finger at. It's indeed a mystery. My Player.log (Linux, non-steam) contains no errors or exceptions (besides a few Kethane ones well documented as harmless ). If anyone finds a fix it would be great to hear. Love RT2; I would uninstall any other mod if I knew it would help. Hopefully the next release will sort it. Thanks Cliph, keep up the great work.
  14. I have been playing around with these parts and I have to say ... BRILLIANT. However, yes there is a minor nightmare. I have several shuttles based on the excellent shuttle engines mod (where I first found these smart parts) and the heaviest of them needs to have the main engine trim adjusted periodically during the ascent to orbit or else it will start to tumble end over end as the fuel load in the external tank decreases. I would like to program the timers to adjust the engine trim, say every 30 seconds during the main engine burn. I thought it might be possible to use one or two timers to fire an AG to adjust the trim one notch; reset the timer and; start the countdown again. That way over the 3 minute duration of the burn I could "smoothly" move the engine trim through 6 trim steps or thereabouts. With two timers and two AG's everything appears to work except at the timer reset step. My testing seems to indicate that the timers are simply not being reset via the AG. This is despite the fact that there is an AG menu option and what's more, the red light on the timer case can be made to turn off via the AG but from the tweakables menu it is clear that the reset has not actually occurred. Caveats Am I doing something wrong? Do I have a broken install? Has it been reported already on the one page of the forum I may have missed to read? I think there might be several applications for a timed "loop" action trigger? If anyone has a way to make it work I would like to know how. In the meantime I can just use about 6 timers I suppose.
  15. This shuttle building pack has two big advantages over all the other shuttle based mods. By my testing to date it provides (a) the most creative design freedom and ( by virtue of B9's great FAR support, the best compatibility with Ferram Aerospace Research. FAR is now an essential part of my game. So, I highly recommend these parts and say keep up the great work! . The Kerbin Mini Shuttle (or KSO) is perhaps the most beautiful shuttle mod available but with FAR and DRE installed it was simply one gorgeous little death trap. Sure it can be landed with a suicide 180 m/s approach profile; 1 time in 10. FAR reveals the truth about the KSO, if you built it in RL, with those tiny wings for that mass, then it would fly as a lifting body, well... worse than a brick.
  16. F5, Alt Tab, copy, paste, rename, Alt Tab, F5 ..... What! I don't have to do all that anymore! Yeah! Yeah! Awesome. Thanks Man . A shame that when you type the filename the game still responds to the key presses, but, I have lots of other mods that do the same.
  17. Ahhh! That little T! I wondered what that was for. Thanks a lot Oinker, its working fine now. I had already downloaded and installed your wonderful icon pack. @sarbian: This is a very useful addon to MJ. (Oh, and that's as I rely on MJ 90% of the time, because besides, who ever heard of a space program without flight computers? At the same time of course, I have bothered to properly train on taking on full manual control in the ever frequent emergency situation.) I would love to see the in-atmo landing guidance integrate better with FAR, but I also appreciate the difficulty & time required. Just my one vote for it. Thanks so much for all your work on MechJeb and ModuleManager.
  18. I am finding that many, or even most, of the buttons fail to appear in the toolbar. I have tried toolbar versions 1.5.3 and 1.6. In the flight scene I get the main MJ window and Landing Guidance for example but I don't get the Docking Autopilot (again for example). The contents of my toolbar-settings.dat look correct. I even tried deleting that file and regenerating it with the clean upgrade install but it made no difference.
  19. On second thoughts and after further experience, now that I have several reactors on my microwave network (~40 GW available) , I support this request. Although I can limit insane accelerations through MechJeb I am having trouble with extremely high rates of overheating during high warp (even with one Huge Radiator for each small size Microwave Beamed Power Receiver) which cause my receivers to shut-down and then all my batteries go flat. With RemoteTech2, this is a real problem.
  20. I know that many people have an "issue" with MechJeb but the "Limit acceleration to..." under Utilities works a treat for me in these situations. I set it to 30 m/s and generally leave it there. The Space Shuttle was designed with a ~3 g limit so if it was good enough for them, then its good enough for my Kerbals. If you want to do an Al Shepard then just turn it off.
  21. Specifically the engine produces no thrust. It must be just my install if no one else has noticed it... Static engine test. Tip says Thrust = 260 kN at 100% throttle. No fx_exhaust going on at all. When the launch clamp is released an acceleration occurs... falling object style . He doesn't have a history of reliable reporting with this plugin but on this occasion MechJeb agrees with my observations... TWR = 0. Under the same conditions but with the 1.25 m ATTILA Thruster there is nice blue light and smoke and on release it goes up... fast. I tried re-installing KSPI, after deleting WarpPlugin folder, results the same. Linux 64 - lots of mods.
  22. Is it just me or is there something wrong with the 62.5cm ATTILA Thruster?
  23. Yes. The existing wiki IS very helpful and I have read about 300 pages but still the best way to explore the parts is to put them together on the launchpad and try to discover what does what . Doesn't always work out but mostly it does.
  24. Ah! So having Helium-3 is not optional. That must be it. Thanks a lot.
×
×
  • Create New...