Jump to content

Manul

Members
  • Posts

    438
  • Joined

  • Last visited

Posts posted by Manul

  1. 3 minutes ago, Omar X said:

    Perhaps, there could be different conditions that trigger the bug.

    Yes. There are much more reasons to KDS, including landing gear, robotic parts and ground anchor. I'm just spamming autostruts everywhere so I never experienced the KDS cases caused by reaction wheels and my creations are usually too massive to be affected by small amounts of torque created by reaction wheels. Also they are too massive to survive without autostruts. There is some shaking after docking a 120t spaceplane to a 300t station but it's not dangerous and it can't be compared to what happened when I failed docking a 300t station to a calss E asteroid: it started violently shaking and spinning,  some parts got close to light-speed after the explosion.

  2. 14 hours ago, Omar X said:

    The problem seems to stem from multiple sources of torque facing different directions. When two ships are combined, it appears that a new point of control is not automatically assigned. As a result, they start fighting each other to face the craft in their respective direction/plane, and it leads to destruction.

    Kraken Death Shake mostly appears while docking to an asteroid that doesn't have a control point or reaction wheels. There are two major reasons for that:

    1)PhysX is glitchy as hell when it creates a joint between parts that have a huge difference in their mass.  Autostruts may help or make things even worse
    2)While docking autostruts are disengaged and created again with a new root/parent/heaviest part. If the craft is being deformed while autsotruts are rebuilt they are screwed and make more deformations.

    Joint glitch also affects modded heavy parts like naval ship hulls, some lighter parts just fall of from the heavy hull under the slightest load. Or the ship just  explodes or shakes itself to death after the physics is applied.

  3. 1 hour ago, KlunkWorks said:

    There's a MiniAVC.dll

    KILL!!! Find'em all and kill'em all. They can also hide in other mod folders not related to Eskandare. MiniAVC.dll used to do only one thing: showing some messages on the loading screen, now it's outdated and causes problems. Some modmakers used to include this thing into their installs so you can have more than two of them. There is also a mod ZeroMiniAVC from LGG that removes all instances of MiniAVC.dll

  4. 6 hours ago, Stone Blue said:

    Also this OPT cockpit:

    [LOG 12:32:51.153] Unpacking OPT-J-HT-Sea
    [ERR 12:33:20.851] [RasterPropMonitorComputer]: UpdateLocalCrew() - no internal model!

    Theres also this err, related to MAS & OPT:

     

    This is normal. I'm getting this RPM error for every single cockpit in a game as long as I can remember (KSP 1.3 or 1.4) :D

    The same deal with negative scale error, it appears because some ASET props have negative scale colliders. Maybe a long time ago there was a version of Unity that supported negative scale, but this error also exists for a while.

  5. 9 hours ago, OrbitalManeuvers said:

    A cookie for anyone who figures out what that 3rd icon down is ... the green tilted clipboard.

    I've seen it several times.... and had a crash to desktop some time after. Or to the black screen of death with a built-in  speaker screaming. Mostly it happened after massive memory leaks or GPU running out of VRAM and getting deeper and deeper into RAM. Mostly it was caused by trying to run Parallax2 on GTX1050 while keeping graphical settings high.

  6. 2 hours ago, Stone Blue said:

    Hmm.. changelog is pretty thin...

    There used to be three versions of VV before: RPM-only, toolbar-only and all-in-one version (I guess it was a pain to update 3 mods instead of 1), with 0.8.7 only one remained. It's a long story why I'm still using RPM-only version. After KSP 1.4 and VV 0.8.7 update I messed up my RPM install so I had to revert and stick to 0.8.6 until I found the problem so I  got used to it (there was RPM included into VV download together with JSI utilities and I mixed 2 RPM versions, as I discovered years later when I got more experienced with mods). Currently there are two reasons why I'm still using RPM-only version: background transparency and having no ClickThroughBlocker as a dependency.  RPM-only version has a transparent background by default and doesn't need Vulkan's modifications to work with his holo-display. And CTB is somewhat incompatible with my control layout. After 1.7.1 update with all these juicy extra custom axis I had to add moar axis to my home-made hotas to control them all:  a secondary throttle for VTOL engines, servo rotation controls. All these extra axis don't have a fixed 50% central point, their neutral position is 0. CTB locks all axis that aren't centered at 50% at scene load and force sets them to 50% (this is how the stock InputLockManager works, nothing can be done)  so I get engines going half-throttle  and servos violently rotating from 0 to 50% position every scene load causing the Scene Load Kracken. CTB has an option to disable it's functions but it's hidden within preprocessor directives, and I'm too lazy to remove dust from M$ Visual Studio, take source and compile it (and face the unforeseen consequences)

     

  7. On 3/15/2023 at 9:11 PM, Hojoz said:

    I've been a user of BDAc for years now, are there any recommendations in terms of what I'd need to learn or re-learn for this BDA version as compared to BDAc?

    There are some major differences that lead to changes in craft design:

    1) Armor has mass based on the part's surface area and armor thickness. Some old parts like tank/ship hulls and turrets that already had mass based on their default  armor  thickness became significantly heavier with proper armor.

    2) Different armor types protect from different types of damage. But  30mm High Explosive is still a best anti-tank round as it used to be in BDA and BDAc  (better at shredding tanks than railgun tungsten shells). And you can make GAU-8 shoot AP and HE rounds in the same belt as it does IRL. Or use 203mm nuclear artillery.  :D Or throw asteroids with a gravity gun (good luck hitting any target smaller than Gilly)

    3) radars, RCS and countermeasures are a subject to change between BDA+ updates so they would differ from BDAc  (I don't know how exactly because I missed a few updates :D)

    4)Space combat had been fixed! Now it's possible to hit a target just in front of you with a ballistic weapon while being in non-kerbostationary orbit. Projectiles don't get spawned meters sideways from the muzzle and now they travel in a direction that the barrel is pointing, not sideways as they used to.

  8. 49 minutes ago, Dakitess said:

    The simple fact that Struts exist and are possible, even with the tree-structure, means that it would techically be possible to have closed-loops structural attachments, nah ?

    This is what I do with docking ports. They allow to create loops. If I make a heavy ramp lifted by 2 pistons I dock them to the ramp. I even made a (mostly) rigid scissor-link structure for retractable floats  to make a hypersonic seaplane, but this plane turned into a shapeless mess of parts due to Scene Load Kracken.

     

    49 minutes ago, Dakitess said:

    Is it something that's not really possible to define in KSP, multiple attachment points ? Of course, the stacking would still be Single Green Node for the user experience, when he's designing his craft, it's all in the background.

    This was already done by Kerbal Joint Reinforcement mod. These attachments are still wobbly-stretchy  UnityJoints but by using more of them things get more rigid. Recoupling Bycouplers mod does a similar thing.  This is not a fix for Kracken attacks caused by inaccurate physical calculations but it fixes sausageness.

  9. 6 hours ago, InterstellarDrifter said:

    I was just thinking it is pretty much ones with unrealistic aspect ratios and or decoupler sizes/arrangements.

    And with unrealistic joint model that doesn't create multiple joints. Let me explain why the "sausage tree" model is ridiculously stupid for everything except rockets (for rockets it works not so bad). Let's build a spaceshuttle.    IRL the Big Orange Tank is attached to the shuttle in multiple points and is perfectly rigid. In KSP with it's tree joint structure it can be attached only in one point and wobbles like hell. This can be fixed by struts and still not a big issue. So let's build something like Cocnorde: IRL the wing is attached to fuselage all over the length of it's it's root chorde and is perfectly stable at 2 axis out of 3. In KSP it's attached only in 1 point somewhere in the middle and has all 3 axis of freedom. IRL these loooong engine nacelles are attached to the wing all over their length and in KSP they have only 1 attachment point and hang from the wing like dead snakes.  Crafts inherited their tree physical structure from being a tree as a data structure. My biggest hope for KSP 2 was that it will change and we'll get a possibility to create closed rigid structures like a triangle without struts or docking ports to fix the loose vertex.

  10. 7 hours ago, Hippodingo said:

    EDIT: I tried to edit an Airplane Plus IVA and once again, flap control doesn't work. Feels like it works only in stock cockpits... Quite weird.

    There can be only one scientifically accurate explanation that doesn't involve aliens or evil curse: a problem with part config. Possible problems: no RPMComputer PartModule or multiple computers for one part. Can you copypaste here a patch that you use to add RasterPropMonitorComputer to the part cfg.

    It should look like this:

    @PART[My_Precious_Cockpit]

    {
        MODULE
        {
            name = RasterPropMonitorComputer
        }
        
        @INTERNAL

        {
            @name = Best_IVA_Ever
        }
    }

     

  11. 39 minutes ago, Stone Blue said:

    If youre doing what I *hope* you are doing there, we can take any discussion to the OPT thread :P

    In it's current state it totally destroys MAS functionality in all cockpits after the scene reload. :blush:  Looks like MAS fails to save  persistent variables for this cockpit when I exit the flight or switch vessels and fails to load any persistent variables for any IVA after this.  Making and testing new props is pain.

     

  12. 17 minutes ago, Hippodingo said:

    It happens that these levers (and ASET knobs too) don't work only in my own IVAs. This is the case only for some MOARDV and ASET props by the way, for example RPM screens work normally.

    Did you add RasterPropMonitor computer  or  MAS Flight computer PartModule to the part you are making an IVA for?

    If indicators work normally but controls don't respond to clicking them, make sure that colliders aren't ostructed. They are shown as green boxes or rectangles in Unity editor.

    PoTETq1.png

    No. You have to set the whole GameData directory in PartTools menu to be able to spawn both spaces and props. If you don't give PartTools access to AsetProps folder it will not be able to spawn them. When you need to save an IVA you should select the space in the window on the left (make sure that you select a space, not props) and click "save to config" on the right window.  PartTools will overwrite the selected IVA cfg and nothing more.

    17 minutes ago, Hippodingo said:

    If I get it well, I should not set the whole GameData as working directory but only the directory that contrains the .cfg of the IVA ? So Unity doesn't try to touch the ASET props?

     

  13. 8 hours ago, adsii1970 said:

    I also like the idea of contracts building one one another. So, your mission to test a parachute, heat shield, and a probe core were successful. So, this next contract set may have more challenges - higher orbit, test an orbital camera on the satellite, test a mystery goo container, and onboard communications to send the results back to the KSC. Oh, and then recover the satellite. And so forth until the contracts require Kerballed space flight.

    It's a boring human way of doing space program. The kerbal way is to strap Jeb to the biggest SRB available and hope he will survive. :D 

    8 hours ago, adsii1970 said:

    In real-world space programs, entire launch vehicles are tested at one time - not just an entire mission to test ONE part.

    These contracts are given by part manufacturers, the manufacturer pays for testing their product and doesn't care about anything else, testing the launch vehicle is up to the ones who build and fly it aka the player's space agency. No one will pay you for testing your own vehicle, the reward is a vehicle itself.

    Maybe it would be interesting to add some certification contracts that don't make profit but unlock the future missions. Like in the GAP contract pack there is a mission to land on the VAB helipad to be certified for helicopter-based search and rescue contracts. 
    But the same rule is already used in stock: you don't get any orbital contracts until you reach orbit, and no contracts for new celestial bodies until you reach them

  14. 2 hours ago, Picard2 said:

    Exactly! That's what I'm saying. Make contracts / missions serve a purpose in your program.

    It's up to you to make your missions serve a purpose in your program because no one else knows what is the purpose of your program. Customers will not pay for what you need, they always pay for what THEY need, this is how it works.  :wink:  After the early grindy days of career playthrough are over  you can afford being picky with the contracts and accept ones that correspond to your own goals. For example I dislike bringing more and more trash to LKO, so I mostly ignore contracts for launching stations and  satellites around Kerbin. The exception is when I need to test a launch vehicle or get more targets for space combat trials. The stock contract system isn't ideal of course, for me it's major flaw is that there is too few applications for rovers and aircraft because I like aircraft and rovers. And there is absolutely no application for naval vessels (okay, it's not a Kerbal Submarine Program, I know). That is why I use Contract Configurator with aircraft-based contract packs that allow me to get through the early career without grinding too much and turning low Kerbin orbit into a junkyard. My SPH folder turns into a junkyard instead due to countless semi-useless low-tech aircraft designes :D

  15. 42 minutes ago, Picard2 said:

     random dead-end missions that do have some challenge but don't progress the underlying space program at all.

    1) Commercial missions give funds for exploration missions, isn't it a progress? SpaceX does a lot of commercial missions to afford the Mars mission you know.
    2)Combining commercial and exploration aspects in one mission is makes both progress and profit 
    3)Contracts encourage to make more reusable crafts and interplanetary infrastructure to make future contracts and exploration go faster and cheaper, isn't this a progress?

    48 minutes ago, Picard2 said:

    Like, build a base on this moon! The base has to include these random parts slapped together, and you'll never need to go back to the base again.

    Just make it useful! Add ISRU, rovers (if there is gravity), probes, planes (if there is atmosphere), submarines (if there is liquid) and you get an exploration or refueling outpost. Also there are contracts to revisit old stuff like "make X experiments around base Y" (that's where the rover comes in handy) or "expand the base Y by adding more random stuff". Many crafts that had been collecting dust at some distant places for years (I mean human years not kerbal) got a new purpose when I took some contracts that I could use them for. With EVA construction repurposing old crafts for new goals is a really fun part of career gameplay. Like the mission where I launched an SSTO from my Laythe base, stole an RTG from an abandoned ship in Laythe orbit and attached it to a rover on Bop to complete the contract. Or an improvised mission from Pol to Eeloo because Eeloo was close to Jool at that moment and there was some work to do.

  16. 23 hours ago, Picard2 said:

    Running actual missions with real value beyond some abstracted 'funds'? So good. Want to launch that nuclear powered engine? Now you have an actual reason to scan those planets, to mine that uranium, to set up your logistics stations. So much potential for exciting and engaging gameplay here - potential way beyond 'funds'. If done well.

    I have experience with hunting rare resources in KSP with mods like Blueshift and The Gold Standart, and it isn't that exciting in long term perspective. The first missions to find Graviolium and Unobtanium and deploy bases for mining them were fun but as long as I had mining bases and reliable transports to get them home it became boring.  Contracts suggest a bigger variety of activities than just scanning and mining, if they are done the right way. Resource gathering is too predictable to be fun, and with random contracts you newer know what you'll have to do next. I had to be really creative repurposing crafts in situ to complete some contracts without waiting years for a transfer window to send another mission. That is the reason why I have to keep a large variety of crafts at Laythe base, and these crafts are capable of performing a large variety of missions on Jool moons. Replacing all this variety with a boring fleet of cargo freighters  is not exciting by any means.

  17. 21 minutes ago, Moons said:

    I dont get it either - i dont know how they did it but they actually made me invest into an - sorry but - insane way to big idea of an awesome game - and im okay with them taking their time as long as i get the feeling that they are working on it.

    They made people pay for a dream that we all have after playing 90s and early 00s spacesims like Starlancer, Independence War or Privateer: get out off a pilot seat, take a walk around your ship, dock to the station and explore it's interiors, land on a planet and explore the whole planet. We began to dream about a game like Star Citizen decades ago, so another 5 or 10 years don't make a difference. :D

  18. 4 minutes ago, pandaman said:

    Even if not, both games gave the same physics problems to solve, so it's not illogical that similar results could appear even through different causes.

    There is just one cause: both games use the same physical model, craft is a tree structure of rigidbodies connected by UnityJoints. This approach proved to be faulty in KSP 1 and now it's used in KSP 2 with exactly the same result. The cause of a problem is built-in Unity physics that doesn't simulate multiple rigidbody connections correctly, especially with huge mass differences between connected parts. Fixing this issue the right way would require   writing a new physical model from scratch and the devs were not given enough time for this.

×
×
  • Create New...