• Content Count

  • Joined

  • Last visited

Community Reputation

9 Neutral

About JebIsDeadBaby

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Disclaimer: I'm not the mod developer, in fact I can't even program in C#. That being said... #autoLOC_number are handles for strings defined in localization files. Whenever the game finds such a handle, it looks for a string defined for this handle in config files. Squad's file is located in GameData\Squad\Localization and is called dictionary.cfg. You'll find all these #autoLOC_number handles there with their corresponding strings. You'll also notice that strings missing from e.g. Configurable Pods are all tech tree node names. The reason for this is, to the best of my understanding, that Kerbalism code tries to get these names by looking for title field in GameData\Squad\Resources\TechTree.cfg, where all tech tree nodes are indeed defined. However, this particular field uses #autoLOC_number handle and the code doesn't know this. So it copies the handle string and that's what you see in the game. The only solution I see is to manually change tech titles from handles to their proper names (which is not hard as they are literally in the same line, at the end). Then they will appear properly in the game modded with Kerbalism.
  2. Since no one seems to know the answer, you can easily check it yourself. Rename your GameData folder to, say, myGameData, create a new empty GameData and fill it only with mods (+dependencies) you want to check (+ Squad folder of course). Once you're done, rename your folders again. This way you can easily run the game with different mod configurations without deleting and reinstalling all of your mods.
  3. It is for me. I specifically created GameData folder with Kerbalism and VSR only (+ dependencies) to check VSR effect on Kerbalism and there is no doubt about it. I'm not saying it's the only mod that causes conflict with Kerbalism, I'm saying it's the only one of 36 mods I use.
  4. Well, it looks like you're using some ancient Kerbalism version meant for KSP 1.3.1, while playing KSP 1.6.0. I'd start with manually deleting Kerbalism from GameData folder and replacing it with the latest version downloaded from here: (2.1.1). Don't use CKAN, it sometimes gets confused by version numbering and downloads a wrong version, which is what I think happend to you. EDIT: and you may encounter the same problem as I had if you keep VSR, so try it without VSR at first.
  5. Are you sure you've attached the right log? Unless I miss something, the log shows you run KSP 1.3.1 with no mods whatsoever.
  6. OK, so I figured out what was causing all my problems, which included: - Kerbalism planner not working in VAB, only the header with SOI appears - resources not consumed correctly (for example solar panels do not produce EC, oxygen is not consumed, EC is consumed but shown as perpetual in the planner) - inability to move up and down in VAB (!!!) And the mod causing all this trouble is... VenStockRevamp (of all things!!). Without this mod everything works fine. With VSR, the moment you place mk1 pod in VAB, log gets spammed with this message Now, I have no idea why, as the new, revamped mk 1 pod is not affected by VSR (to the best of my knowledge), it has nothing to do with liquid hydrogen and I don't even think VSR messes with resources. The problem is easily replicated with KSP 1.6.0, Kerbalism 2.1.1, CRP, MM 3.1.2 and the latest VSR release. Would be nice if this conflict got solved as VSR still has some nice looking parts I like to use.
  7. I have the same problem (one of many). Have you figured it out?
  8. Please keep maintaining Basic DeltaV. Stock dV does not work with Real Fuels, so your mod is still very useful. v4.0 has a slight problem with KSP 1.6 though - display background color does not work. Instead of dark gray it's white, so white text becomes unreadable. It's readable with transparency set to 0% (or 100%? No color basically) but it's not as convenient as dark background.
  9. OK, so Kerbalism 2.1.1 with KSP 1.6 is a total mess for me. For starters, Kerbalism planner does not work in VAB, only the header with a name of a ship is visible. It shows in flight but resources like oxygen and EC always show perpetual even though they are consumed. But that's not the annoying part. The annoying part is - if I send a ship without food and water into space and switch to the map, Kerbal dies of hunger and dehydration in a matter of seconds. This does not happen if I don't switch to the map but for example return to KSC. The moment I switch to the map all hell breaks loose. No one seems to complain about this problem, so I guess I'm quite unique here? I also downloaded Kerbalism-master 2.2.0 that has some of bugs already addressed but it's just as bad.
  10. My guess is this is your problem. You're probably using new probe cores introduced in 1.5.1. RT 1.8.13 has no config files for them, they were introduced in RT 1.9.0. Without config files these probe cores do not obey connectivity rules and are controllable when there is no connection. Update your RT and this should solve the problem.
  11. JebIsDeadBaby

    [1.5.1] Advanced Jet Engine v2.12.1 (Nov 11)

    Hi, for every AJE jet engine I get the following error in KSP.log However everything looks just fine in Modulemanager.ConfigCache. Can anyone take a look and hopefully figure out what is the problem? ModuleManager.ConfigCache KSP.log EDIT: solved. I noticed in KSP.log that AJE still depends on 3.6.1 version of Solver Engines, while I had it updated to the latest 3.7.0. After downgrading to 3.6.1 AJE started to work properly. KSP.log I attached shows previous version of AJE installed, as I was trying different versions at the time of posting and didn't notice it's the log from that trail. However the latest 2.12.0 version of AJE depends on 3.6.1 version of Solver Engines too and that's the working combo I use now.
  12. JebIsDeadBaby

    [1.5.1, 1.4.5, 1.3.1] RemoteTech v1.9.0 [2018-10-29]

    Yeah, sphere got v2 variant to. And few others. You need to add configs for all of them if you want to make them obey RT rules. Just check Squad/Parts/Command folder for new v2 variants. Can confirm there is no delay though, both with new and old cores.
  13. JebIsDeadBaby

    [1.5.1, 1.4.5, 1.3.1] RemoteTech v1.9.0 [2018-10-29]

    Is it the new OCTO probe you're using? New probes introduced in 1.5.0 have different names in config files than the old ones, probably to let players use old versions in their ships designed in 1.4.5. So the new OCTO is now called probeCoreOcto_v2 while the old one is just probeCoreOcto. RT was not updated for version 1.5.0, so it obviously has no configs for these new probes. You can however add them by yourself by editing RemoteTech_Squad_Probes.cfg. Simply copy a config for the old core, paste it below and add _v2 to part name. I had the same problem as you and this solved it.
  14. Sure, it's pretty easy as it turns out. Just word of advice - in FerramAerospaceresearch -> CompatibilityChecker line 61 - set Versioning.version_minor == to match your KSP version. Otherwise it won't work.
  15. Can't see anyone trying to recompile against 1.5.0, so I gave it a try. Thanks to @MicUK88 for detailed instructions. Here is the link to zipped .dll files. They should go to Kerbal Space Program\GameData\FerramAerospaceResearch\Plugins as usual. Everything seems to work as it used to for me. This was however my very first contact with Visual Studio, compiling and all that stuff so I don't give any guarantees. Feel free to test it. Also @Cholerix I can confirm that without setting minor version to 5 in CompatibilityChecker.cs, new .dll's did not work and affected aerodynamics in a strange way. Some instruments in Mk1 pod (altimeter, atmometer and speedometer) did not work at all, as if the game somehow could not get this information. Above 1000 m drag was almost nonexistent.