Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by softweir

  1. It would help the debug process if you were to list your mods and upload and link to your log file, as per this link:
  2. Ground effect is notoriously difficult to simulate with reasonable realism. I guess it could be fudged, but then would an Ekranoplan work?!
  3. This has been mentioned (somewhere back amongst the hundred+ pages of this topic), and -- IIRC -- the answer is no, trees don't have collision; there are practical limitations preventing this.
  4. So, maybe if you gave it a 1:2 ellipse it would stretch it into a 1:1 roundel? Annoying, but it would get the result you desire.
  5. Oh! Gotcha! Yeah, that's a bummer. I found THIS discussion on Steam, though I accept it will only be useful if you can run a second monitor! IF you can, then you could pan the view to one side to put the rocket on one screen, then drag the window on the second screen, and post-edit the cinematic to remove the second screen - assuming, of course, that your drives can cope with the doubled video size! A thought: Set up Gravity turn. Hover the pointer over the Launch button. Hit F2 to hide the UI. Click the mouse button. Might that get the cinematic you want?
  6. Ah, yeah, that's right. IIRC there's a big button at the bottom of the main Gravity turn dialogue box and no keybind for it. I assume that doesn't do anything when you use it? Have you made sure to set throttle to max? - that used to catch me out too often! Or is it that you can't find out how to open the Gravity Turn dialogue? Isn't there a menubar button to open it?
  7. I think you may mean "keybinds"? If I remember correctly, <SPACE> will activate a launch, same as for stock launches.
  8. I spotted early versions of it on CKAN and tried it out, and I'm glad to see this has been released! BTW, as a convenience, could you update the CKAN metadata with a link back to this topic? That's always helpful to those strange people (like myself) who browse CKAN!
  9. First, many thanks for the work you are doing on KSP 2! While progress seems slow, it is obvious to the more experienced of us that a huge amount of effort is going into developing it, and this is very much appreciated. On topic, might somebody be able to usefully adopt JSI Advanced Transparent Pods? I expect the answer to be "no, it's too technical", but I feel the question needs to be asked!
  10. It's funny because it's true - people misunderstand jokes all too often, especially when the humour is deadpan.
  11. I would assume that any Steam-related code is implementing cross-loading from the net, or leading up to a simple Multiplayer setup:- while MP in and of itself is a long way away, an easy component of that would be MP chat facilities. I grant you: any bad code can create bugs in other code modules, but for MP chat or cross-loading to cause that sort of litany of bugs is unlikely! I suspect we may be seeing the results of different PC setups and gameplay styles than presence or absence of bugs themselves.
  12. @JebIsDeadBaby I don't want to seem patronising, but it's nice to read a request for support that is respectful and polite! This is the sort of annoying problem that needs more info to address than simple text. for the very best problem-solving we need pictures (better still add a craft file), a FULL mod list, and LOGS; as is addressed in the thread: With all that, it is most likely that some advice will be forthcoming. That, I am afraid, is the ugly Hydra that raises its head when it comes to running mods in KSP1 - there are too many mods with too many interactions for quick and easy problem-solving. My first, ill-informed thought, is that this sounds like you may be getting an over-slow physics and/or FAR simulation rate. That can exaggerate yaw effects under FAR. My new machine simulates reentry with much better stability than my previous, underwhelming PC could manage. On my PC (running FAR and Restock heatshields and capsules), reentry capsules show very little yaw. They can yaw, and I have found that momentum wheels make it worse. Accordingly I either: Turn off pitch and yaw to the momentum wheels (in the capsule PAW), or: I turn off the momentum wheels altogether and use RCS to control roll. I have tried turning off SAS altogether, but that makes it hard to control roll and thus direct lift as I intend. Good luck! You may get better than a Mickey-Mouse flight tutorial with the info I suggested.
  13. (tl;dr: Sequential development of Modding API and game engine good; concurrent development of Modding API and game engine bad. In my humble but determinedly held and lengthily argued opinion!) True - but imagine churning out Megabytes of code to support a modding API, then having to review every line of code and rewrite many of them because of a few critical changes to the underlying game engine that occur between first implementation of the API and completion of the game. Alternatively, imagine having to review hundreds of lines of code in the modding API implementation because one underlying game-engine method had to be deprecated and replaced with a new method. Abstraction and encapsulation only go so far when a game engine is in a state of flux and methods demand additional arguments that can't be hidden from API users, ie modders. There is a most excellent rule of thumb: don't write code that's going to be thrown away*. Most especially, don't write code if you will need to rewrite it more than once - especially code which is critical to end-user QoL but not critical to implementation of core functionality. Such is the case with a Modding API! What does make sense is to spend a few hours every week sketching up a preliminary outline of what the Modding API will look like. If it is sufficiently short on detail then it will serve as a decent roadmap for implementation of the API, while at the same time giving the game engine developers something to look at over their shoulders at as they develop their classes and methods. At the least, it will help them hit the ground running when they do start on the Modding API. My professional coding days are long over and I decided to ignore the modding scene, except as a user who downloads mods. Nevertheless, I was well aware that mods would repeatedly break with every major update. Often, I grant you, this was because of weird little changes in the physics or graphics engines, but it was also due to changes to the modding API. Usually all that was needed was a recompile of a mod, but sometimes a modder would have to spend hours trying to find out where their code was breaking and then how the blazes they needed to rewrite it to bend to KSP1's whims. My take on this comes from the days long gone when I developed databases and had to rewrite one after my boss replaced our hooky copy of the DB engine with a legit one that was just one minor release more advanced than the previous one. Cue weeks of hair-loss! * I do hope the decision to change the KSP2 graphics engine half-way through won't prove to be a mistake.
  14. They should be! Previously they *would* be hidden, but now turn up unwanted. I use The Janitor's Closet to prune all the deprecated parts: Beale has said the deprecated parts will be removed from a later update, at which point the problem ends. I hope this is useful to you.
  15. It's just KSP, unfortunately, and nothing can prevent the accumulating errors (that I know of).
  16. A side effect of removing these folders is a fractionally faster gameload! @Maxorizor Don't worry - every single deprecated part has a replacement somewhere in the parts list, which will be easier to find once the deprecated parts are out of the way. If you don't feel happy about deleting folders then you can add The Janitor's Closet to your repertoire of mods, which enables you to "prune" unwanted parts, ie, hide them from the parts lists. Good luck!
  17. I find it works well with 1.12.x. The OP looks a little out-of-date: @linuxgurugamer updated Haystack as recently as: In practice, changes to KSP (apart from the launcher) have been very light as regards core game code, so very few mods (if any) will have needed updating of late.
  18. 10 meters apart makes it sound like MechJeb is measuring the Centre-of-Mass to Center-of-Mass separation. Without examining the log file (beyond me) I can only wonder if you forgot to use "control from here" with respect to the moving truss' TCM. Apologies if I am preaching to one wiser than I!
  19. @StolasNow that is interesting and different! What mods did you use in that? - it sure looks like a few of the modules are from ones other than HabTech2.
  20. @benjee10 Bah! I'm getting so lazy I was actually annoyed at not being able to use CKAN! I really gotta get a life! However, there is a serious point: reDirect includes its dependencies, but if it is now Finished - and not being updated - then the included dependencies can go out of date and cause users problems. Reorganising the download to not include dependencies and then pushing it to CKAN with its metadata would be a service to your fans. BTW - I am a huge fan. Your mods are truly excellent!
  21. Nope! As the OP says, somewhere deep inside the text, it supports all rescaled systems by setting the "snacks day" to the day length of the homeworld, whether that is Kerbin or Earth or any other. I don't know about the other questions.
  22. @DeadJohn Many thanks for the advice! I ought to have looked into LGG's mod list before asking - there's damn little he hasn't written or adopted!
  23. My google-fu is failing me... is there a mod which will allow renaming of a craft file, short of loading-renaming-saving-deletingtheold? I would appreciate this merely trivially important QoL improvement if only I could find it! (If it exists.)
  • Create New...