• Content count

  • Joined

  • Last visited

Community Reputation

558 Excellent


About diomedea

  • Rank
    The Right Stuff

Profile Information

  • Location Second to the right, and straight on till morning.
  • Interests astronomy, cosmology, advanced physics and more ...

Recent Profile Visitors

3197 profile views
  1. This issue seems to exist since times old but can't find any evidence it was ever correctly diagnosed, therefore never truly fixed. Don't know if there's more to @damowang2's post than Unity forum threads like this (that provides absolutely no help to determine why the issue), probably more useful is this old issue on the KSP bugtracker. I have a Saitek X52Pro, not a X56. I always use the Saitek drivers (without any middleware like AdvancedFlyByWire). I never experienced any lag from my HOTAS in KSP nor in other Unity games. For how little I could tell, a number of other KSP users also have a Saitek HOTAS but don't have lag. That makes finding the cause of this issue really difficult: the drivers may really be part of the problem, but only if there's something else with the OS that fights them; unfortunately nothing written up to now helped determine what (I could only consider showing a DXDiag save with Windows OS, hopefully it would tell if there's any conflict among input devices or with USB. Unfortunately seems nobody who reported this issue till now considered this worth showing).
  2. I only use dedicated GFX cards, so can't directly tell how good an integrated GPU works with KSP. But, even with all the power of a fast GPU and lots of VRAM, that's where my PC shows the bottleneck with KSP (GPU load is often > 90%). Even changed to a faster GPU (the most powerful my PC could handle) and still that's what could be causing FPS drops most of time. KSP isn't a graphically intensive game, unlike many others that really require a very powerful GPU to create awesome, realistic scenery (my GPU runs just fine with those). But, KSP is really intensive with physics calculations, in particular when flying large vessels (many hundred parts, physicsless parts excluded). Most of the basic calculations with physics are handled by modern GPU, to relieve the CPU of a large mass of parallel computing. E.g., Unity (the engine behind KSP) makes large use of PhysX library to offload the CPU from all those calcs. To really evaluate how large a load KSP is taking from your GPU, I always use Process Explorer which can be set to show a column with the GPU load for any running application (I'm still wondering why MS Task Manager has no such useful info). Please download, install, setup and try PE with KSP running (while flying a large vessel, some hundred parts at least), the value shown for GPU will tell you, better than any of our estimates, if your internal GPU is up to the task or not.
  3. Should you manage to ensure compatibility with Ampyear (not only about reserve batteries, that add-on adds custom modules e.g. AYPart with many parts in a savegame) I would certainly switch (back) to Fusebox, now that it gets the love it deserves (and becoming compatible with most other add-ons). Otherwise have to start a whole new save after switching to Fusebox. Anyway, please keep doing as you started with this add-on, it always had great potential, have to thank @Ratzap for how he designed it; but you seem able to solve some of the long-standing issues this add-on kept showing.
  4. Ciao redzep, benvenuto sul forum! Spero ti troverai bene nella comunità, qui toverai aiuto per qualsiasi tua esigenza. Hi redzep, welcome to the forum! Hope you'll be fine with the community here, it will help you in whatever question you may bring.
  5. As the glitches disappear when AMD ReLive is used, makes me guess this may be related to the refresh rate (anything decreasing the GPU rate hides the glitches). Refresh rate can't exceed a maximum tied to screen resolution, having two displays effectively doubles resolution. I would check what happens with: lowering refresh rate in the GPU settings; lowering display resolution (both screens). Clearly also the displays have a maximum rate allowed, though should show a message if that's too high. It's just a possibility, can't actually tell for sure, but should be worth a test.
  6. There is some explanation about negative SMA on Wikipedia including a bit of math that should be simple enough to grasp. Another description is on Orbital Mechanics (where SMA equation at 4.32 is valid for all conics, clearly when excess velocity is > 0 the result of the equation turns negative).
  7. @DavidHunter: though I'm not using Windows 10 (refused to "upgrade" from 8, guess why) therefore can't directly test the issue with security permissions, I'd advise to move KSP to a custom place where the OS doesn't mess with (User directory certainly is something the OS wants to "keep in order" in its own way). I always make a "\Games" folder (also on a different drive than the one with the system, e.g. D:\Games) where to install all those games that allow custom installation, would be amazed to find Windows 10 tries to mess with custom folders like that one.
  8. You may try if version 1.1.3 works (Steam shows that as a previous version still downloadable, selectable from Properties/"Beta" tab with the game library). Compatibility really depends on each single add-on included in the list. You may have to verify yourself with each single add-on if there was any new version built for KSP 1.1.3, or the version that worked in 1.1.2 still was valid in 1.1.3. This may become such a heavy work, to nullify any advantage with using the mod list. On the other hand, this problem with obsolete versions is exactly what I hoped would be improved making new rules for modpacks recently. Glad you reported this, it should come useful to further improve rules.
  9. Must say I'm really impressed about the ingenuity with Recoupler. Probably many know, still I'd show a few considerations about the Vessel's tree structure in KSP and topology. As it was started since when KSP first allowed to put parts together, it never changed significantly. KSP stores one single "Part.parent" attribute with all parts, so branching is strictly one-way (from one to one or many, never from many to one). IN KSP stock code, there are (that I could find) 68 routines using Part.parent, all assuming the value to be unique for each part. Of course, the resulting structure is very easy to navigate, efficient, and allows recursivity without constraints. All good reasons to wish to only deal with one-way trees of parts, instead of dealing with all kinds of more complex structures (to include loops of all kinds, see graph theory) and would require specific code to deal with path duplications (to the effect of pruning any path already travelled), which unfortunately makes for more complexity (= more bugs!) and time to compute those routines. Still, tree structures aren't fit to deal with all requirements: in KSP, the rigid one-way branching has caused many issues, e.g. no multiple docking among two vessels, non-functional claw grabbers; plus the intrinsic weakness of a structure held together from only one node with each part (very correctly highlighted by the author). Now, to me the cleanest solution would still be if KSP code was changed to allow (at least in those cases with multicouplers or other parts conceived to allow reversed branching) a part to have multiple parent attributes, all correctly managed (so adding a lot more complexity in all those routines). But I have no confidence this will ever happen. Having now, thanks to Recoupler, a working alternative, is a blessing! Sure enough, I've built a number of closed space stations that never could be correctly seen as "closed" lacking one or more joints till now (even worse since I'm also using Connected Living Space), this is something I'm expecting this add-on to improve greatly. Hope the above can bring to some more ideas on how to improve with a vessel structure, perhaps about what other features this add-on could implement.
  10. Certainly one for a FAQ about this forum (this should answer it).
  11. Nice model. I'm a Geogebra user too and often start dealing with geometrical problems (including some KSP orbital stuff) first modelling there, it allows me to get the correct relationships before I turn to strict math. Though, my models always are built from geometric elements, I put equations directly in Geogebra only when can't find an easier geometric solution (therefore, e.g., my way to draw an elliptical orbit in 3D goes to define the orbital plane, the cone (given center, axis and aperture angle), and intersect the two). Looking forward to see your model in 3D space! P.S.: yes, better show a license, the model is your creation and worth having recognition (MIT is fine for that purpose). Even if the forum rules only make a license mandatory for add-ons.
  12. Thanks for this feature, @sarbian. Just did a couple tests, KSP 1.2.2 (1622), first on DX9 then on DX11 mode. I have two monitors, different max resolution (1920x1080 + 1280x1024). After enabling sideview (Numpad 0) KSP switches from window to fullscreen (or rather, borderless windowed mode at full resolution, as I'm able to alt-tab have another window on top), cursor position and monitor ID is shown top-left of the main monitor, the second monitor also switches fullscreen/windowed-fullresolution but is currently completely black apart for the cursor when moved in there. Moving the cursor around, the correct coordinates are shown; however display id is always shown as 0 with both monitors. Another thing, if I move the cursor while on the second (blank) monitor to the same coordinate it would be over some object in KSP (e.g., buildings in space center) if it was on the first, dialogs appropriate appear over the object; same for left or right-clicks. No crashes this far.
  13. Believe you mean how to have the rover connected to the other vessel in editor (VAB/SPH). 1) build your rover, to include the part that will attach to the other vessel (docking port? separator?) 2) change the root part of your rover to that part going to connect (use the re-root gizmo in editor, 4 key) 3) save the rover as a subassembly (in editor, enable advanced mode, clicking the most top-left arrow button; find and click the subassemblies icon, then click on the root part with the rover and drag to the "subassembly drop zone", you'll be required to enter a name/description and the rover will be saved as a retrievable subassembly) 4) build your other vessel, planning for space where to insert the rover. If required by your design, have the corresponding connecting part (e.g. docking port) 5) re-open the subassemblies tab in editor, click on the saved rover subassembly, and bring it to connect where intended (Note: the editor will rotate the rover to face the same direction of the root part in your vessel, which isn't always what you would do, so use the rotation keys to align properly)
  14. I'd say, if mushrooms had to withstand serious aerodynamic flow, they would have evolved in a drop shape too . More seriously, yes, long thin objects work best (due to limited cross-section and minimal drag from surfaces parallel to the flow), and having tear drop shape at the extremities greatly reduces front and tail drag coefficient (from the dragcubes geometry with the parts, cosine of the flow incidence angle with each exposed face, and the drag multipliers that mimic Reynolds dependency as a function of speed for different attitude). Flat surfaces worked the same as properly curved ones up to KSP 0.90, while the aerodynamic model was very primitive.
  15. Hitting F5 while on the page you need to refresh generally works, but depending on your browser a force refresh could be required, believe this should provide some useful info.