Jump to content

OliverPA

Members
 View Profile  See their activity

  • Posts

    21

  • Joined

  • Last visited

 Content Type 

Posts posted by OliverPA

    [1.9-1.10] Configurable Containers

    in KSP1 Mod Releases

    Posted

    This mod is simply awesome. There are so many lovely fuel tanks that unfortunately store the wrong type of fuel and finally with this mod they become usable.

    I wonder though if it is possible to edit the title of a fuel tank so that the "Xenon tank" can be renamed to properly reflect that it holds water or oxygen or whatever.

    [1.8] PersistentRotation 1.8.6

    in KSP1 Mod Releases

    Posted

    Regarding the MJ issues - I submitted a simple code change to the MJ project on git that makes MJ only enter warp once the rotation is below a certain minimum, ie. once the vessel has settled on the target.

    It works quite beautifully in my dev build. Of course changing towards the target takes a bit longer now, somewhat dependent on the vessel. Then, once settled, MJ enters warp. If there was a little rotational momentum left and the warp is very long, then MJ might drop out of warp once the deviation is too large and resettle on the target. But this happens fairly rarely on in my game.

    Let's hope it is included in the next MJ release.

    [1.8+] Real Fuels

    in KSP1 Mod Releases

    Posted

    3 hours ago, NathanKell said:

    @OliverPA no, that's what I mean--the interface receiver is in RF itself, so the extra dll isn't needed.

    Alright, thanks for the clarification.

    Unfortunately when I compile the dll it crashes on load so I can't do terribly much :(

    However I have noticed that the dry mass in the right click menu of the tanks scales correctly whereas the actual part mass doesn't!
    So ModuleFuelTanks.cs line 1007 produces a good result of >0 even when the actual part weight is <0.
    Maybe it's worth looking at the if() starting line 970 which has only one code flow that does not lead to part.mass = mass, ie. line 985.

    Also there always seems to be a difference between the dry mass in the right click menu and the part mass.
    Take a Mk1 pod -> total mass of 850kg according to Engineer Report.
    Add a FL-T100 tank with dry mass of 9.3kg -> total 860kg which is fine.
    Scale the tank to 2.5m (= 2x) with a dry mass of 74kg (= 9.3*2^3) -> total vessel mass of 1362kg so +502kg instead of +74.

    [1.8+] Real Fuels

    in KSP1 Mod Releases

    Posted

    9 hours ago, NathanKell said:

    I was not aware of TS-RF incompatibility; I have implemented the interface @pellinor asked for.

    Oooh, that's a bit embarrassing, I totally missed that there's a TS interface in the plugin :confused:

    But that raises the question - is TweakScale_RealFuels.dll supposed to be distributed? Because it's not in the RF release...
    I can compile the solution but get exceptions upon loading the compiled dlls.

    [1.8+] Real Fuels

    in KSP1 Mod Releases

    Posted

    @NathanKell I've not seen this TweakScale-related issue mentioned anywhere other than @ferram4's FAR mod where the error description is that vessels start floating at launch and in some cases the game even crashes. But it seems ferram's mods are involved but not the root cause.

    Now the floating at launch only occurs when parts are re-sized with TweakScale and it is actually introduced by KerbalJointReinforcement during physics easing.
    But I've tracked the root cause down to these parts having a negative part mass and a rigid body mass of 0 which only occurs when RF is enabled! The same vessel without RF but with TS/FAR/KJR works fine.
    I've reduced my ksp install to bare-bones (RF, RF-stockalike, TweakScale, KerbalEngineer) and every tank or engine that is sufficiently down-scaled has a dry mass <0 sooner or later.

    It's taken a couple of hours to get to this point but now I'm quite stuck. I can't figure out how the RF mod influences TweakScale behaviour and/or dry mass calculations :confused::confused::confused:
    Any ideas where to go from here?

    [1.12.x] Editor Extensions Redux released (with SelectRoot merge. StripSymmetry & NoOffsetLimits)

    in KSP1 Mod Releases

    Posted

    If you want to have a look at the hotkey for the fine adjust window: https://github.com/linuxgurugamer/EditorExtensionsRedux/compare/master...OliverPA77:hotkeyFAW?expand=1
    There's also a binary as draft release to try it out real quick.

    I put "None" as default for the new hotkey so if a user wanted to assign it they'd have to do it consciously without the mod spamming the keyboard with unwanted shortcuts. It's a good compromise, no? Have a look, if you like it I'd create a PR...

    The auto opening/closing of the window actually works quite nicely regarding the key-controlled adjustments. You open translate/rotate gizmo and the window opens. You switch to another gizmo and it closes: 

    // automatically show fine adjust window when offset or rotate gizmo are active
if ((GizmoEvents.offsetGizmoActive || GizmoEvents.rotateGizmoActive) && cfg.AutoFineAdjustWindow && !_fineAdjustWindow.isEnabled()) {
  _fineAdjustWindow.Show();
}
// automatically hide fine adjust window when offset or rotate gizmo are inactive
if (!GizmoEvents.offsetGizmoActive && !GizmoEvents.rotateGizmoActive && cfg.AutoFineAdjustWindow && _fineAdjustWindow.isEnabled()) {
  _fineAdjustWindow.CloseWindow();
}

    But currently the fine adjust window also removes the snapping feature when using the mouse and this would need to go to be useful altogether.

    Btw. any particular reason why the fine adjustments are triggered by GetKey and not GetKeyDown? It happens quite regularly that the part is moved too far...
     

    [1.12.x] Editor Extensions Redux released (with SelectRoot merge. StripSymmetry & NoOffsetLimits)

    in KSP1 Mod Releases

    Posted · Edited by OliverPA

    15 minutes ago, linuxgurugamer said:

    That would be a nice addition, but I don't see it on Github yet.

    If it's a simple change send me the file and I'll add it manually.

     

    Thanks

    It's this one: https://github.com/OliverPA77/EditorExtensionsRedux/pull/1/files

    I created a fork, then a branch and a pull request but apparently the PR is now within my fork and not visible to you?
    Before this I tried to create the PR in your project site but it didn't let me.

    Btw. I've also implemented a shortcut to open the fine adjust window (including setting in settings window) and am now going to have another new setting that opens and closes it automatically whenever the translate/rotate gizmos are activated. The shortcut is definitely convenient but I'm not sure yet how the auto-thing is going to be like...

    [1.12.x] Editor Extensions Redux released (with SelectRoot merge. StripSymmetry & NoOffsetLimits)

    in KSP1 Mod Releases

    Posted

    @linuxgurugamer I'm new to the Github stuff so I'm not sure if my pull request worked as expected.

    Basically I found myself wishing for a possibility to use the H hotkey to horizontally align along the other horizontal axis (z-axis).

    Only a very minor change was needed to extend EditorExtensionsRedux.cs to use the H hotkey (or whatever the user has set) for x and Shift+H for z axis.
    I would have preferred to use the mod-key but mod+H is already taken by HyperEdit :(

    [1.1.3] Procedural Parts - Parts the way you want 'em - v1.2.5 July 3

    in KSP1 Mod Releases

    Posted · Edited by OliverPA

    Alright, so line 481 in TankContentSwitcher.cs is the problem - it references part.mass instead of mass. I changed that line, recompiled the dll and the issue is gone.
    I thought about putting the change into Github but not sure how. Pull request? Just an issue report?

    Anyways, here's the change: 

    TankContentSwitcher.cs, line 481

currently:
	return Math.Round((res.unitsConst + tankVolume * res.unitsPerKL + part.mass * res.unitsPerT) * shapeMultiplier, 2);

fixed:
	return Math.Round((res.unitsConst + tankVolume * res.unitsPerKL + mass * res.unitsPerT) * shapeMultiplier, 2);

     

    On 5/15/2016 at 9:11 PM, OliverPA said:

    Same here - procedural tanks are empty to half empty upon loading in VAB even though their are full in the craft file.
    Simply replacing the 1.2.3 ProceduralParts.dll with 1.2.2 was enough for this terribly annoying issue to disappear.

    Looking at the source code there are a few changes where the part mass used to be saved in 1.2.2 and now in 1.2.3 just an event is triggered...

     

    [1.11] RemoteTech v1.9.9 [2020-12-19]

    in KSP1 Mod Releases

    Posted · Edited by OliverPA

    Since I'm constantly looking for the right antenna in terms of range, size, looks, etc. I missed the ability to scale the available antennas.

    This MM patch changes all RT-activated antennas by setting them up with TweakScale.
    Mass is scaled by the power of two since most antennas are surface-like.
    Cost is scaled linearly (simply feels right).

    Now the important bit - antenna range:
    Seems to me this should scale linearly as well since e.g. doubling a dish antenna quadruples the surface area but shouldn't doubling the range quadruple the area/energy requirements as well? I'm not an engineer so if someone knows better I'm happy to be educated :)
    So currently dish antenna ranges scale linearly, omnis a bit less and energy requirements stay the same regardless of scale. As do the data transmission parameters. All of that could be changed though if someone provides good arguments as to why...

    Range scaling - should be stock if you ask me :cool:

    Samples scaled 50% - 100% - 200%:

    llTZrNQ.png

    Spoiler

    TWEAKSCALEEXPONENTS:NEEDS[RemoteTech|TweakScale]
    {
        name = ModuleRTAntenna
        Mode1DishRange = 1
        Mode1OmniRange = 0.75
    }

    @PART[*]:HAS[@MODULE[ModuleRTAntenna]]:NEEDS[RemoteTech|TweakScale]:FINAL
    {
        %MODULE[TweakScale]
        {
            type = free_square
            TWEAKSCALEEXPONENTS {
                name = TweakScale
                DryCost = 1
            }
        }
    }

     

    [1.2] Procedural Fairings 3.20 (November 8)

    in KSP1 Mod Releases

    Posted · Edited by OliverPA

    While I love the procedural fairings both as aerodynamic and structural parts, I've always been annoyed by the height the fairing bases add to the rocket. Especially when using them as interstage parts their use quickly becomes limited as they add so much height with so much obvious emptiness inside them. And offsetting other parts into them comes with other issues like unrecoverable probe cores stuck inside, etc.

    So I created a little MM patch that makes slim-copies of the original parts by shamelessly scaling them along the y-axis. To my surprise it seems to work perfectly, ie. the fairing still attach as they should and I don't notice any weird aerodynamic behavior :) TweakScale works nicely as well...
    Because these parts are copies, they don't break existing ships in flight.

    I really like how these new 0.2x scaled bases allow for sleek command module parts (probe core, reaction wheel, batteries, mono-tanks, rcs attached to outside) that rival custom made parts. Notice how in the first screenshot both bottom interstage bases are set to 0.7m height but the slim version offers so much more space to do something useful with.

    To add a bit of a challenge in career mode, the slim bases have +1 tech level requirement than the regular versions.

    I hope you guys find them to be useful and fun as well.

     

    MM patch:

    Spoiler

    +PART[KzResizableFairingBaseRing] {
        @name = KzResizableFairingBaseRingSlim
        @title = Fairing Base Ring SLIM

        @MODEL {
            @scale = 1, 0.2, 1
        }

        //@node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 1
        @node_stack_top = 0.0, 0.04, 0.0, 0.0, 1.0, 0.0, 1
        @node_stack_connect01 = 0.5, 0.02, 0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect02 = 0.5, 0.02, 0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect03 = 0.5, 0.02, 0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect04 = 0.5, 0.02, 0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect05 = 0.5, 0.02, 0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect06 = 0.5, 0.02, 0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect07 = 0.5, 0.02, 0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect08 = 0.5, 0.02, 0.0, 0.0, 1.0, 0.0, 0

        @TechRequired = advAerodynamics
    }

    +PART[KzInterstageAdapter2] {
        @name = KzInterstageAdapterSlim
        @title = Fairing Base Ring SLIM

        @MODEL {
            @scale = 1, 0.2, 1
        }

        //@node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 2
        @node_stack_top    = 0.0, 0.04, 0.0, 0.0, 1.0, 0.0, 2
        //@node_stack_top1   = 0.0, 2.0, 0.0, 0.0, 1.0, 0.0, 2
        @node_stack_connect01 = -0.5, 0.02,  0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect02 =  0.0, 0.02,  0.5, 0.0, 1.0, 0.0, 0
        @node_stack_connect03 =  0.5, 0.02,  0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect04 =  0.0, 0.02, -0.5, 0.0, 1.0, 0.0, 0
        @node_stack_connect05 = -0.5, 0.02,  0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect06 =  0.0, 0.02,  0.5, 0.0, 1.0, 0.0, 0
        @node_stack_connect07 =  0.5, 0.02,  0.0, 0.0, 1.0, 0.0, 0
        @node_stack_connect08 =  0.0, 0.02, -0.5, 0.0, 1.0, 0.0, 0

        @TechRequired = specializedConstruction
    }

     

    [1.2.2] Phoenix Industries ³Sat (CubeSat mod) (v2.2, compatible with TweakScale and MechJeb)

    in KSP1 Mod Releases

    Posted

    So first of all thank you so much -ctn- for these lovely cubes! I've been using them for a while and they are truly awesome.

    I did notice though, that they seem hugely overpowered compared to stock parts to the extent that using them feels like cheating: They weigh and cost next to nothing, yet have SAS, on-board reaction wheels and a huge battery. But where is all this equipment supposed to be? They cubes are clearly hollow.

    So I've tried to make a few changes and am interested in everyone's thoughts if these changes integrate them better within the world of ksp.

    • Removed reaction wheels and reduced huge batteries because these parts are definitely larger than the clearly hollow cubesat models.
      In line with similar stock probes they now have an on-board electric charge of 5 (was: small 400, tiny 200).
    • Aligned cost to 75% of comparable stock parts because while I get that Cubesats are supposed to be cheap alternatives, they seem to be by far too cheap considering their capabilities and size in ksp. The small cube is comparable to OKTO2 in terms of features and now set to 1100 (was 200) and tiny is comparable to HECS - 100 for reaction wheels and now set to 500 (was 160).
    • Tried to align weight with stock parts because the current weight was set to small = 20kg and tiny = 10kg which makes the tiny cube 1/4th the weight of OKTO2 (= 40kg) which has similar features and is much smaller (= far less metal parts).
      Set the weight to 40kg for tiny and 120kg for small which still gives the cubes a clear weight advantage compared to similarly sized stock probes which could be explained by not having solid side panels.
    • Changed TweakScale settings because they scaled mass (and cost and resources...) by the power of 3 which shouldn't be due to the hollow nature of the cubes. Power 2 would seem right if the side panels were solid, so I used 1.25 which gives sensible values for the various sizes in my opinion.
      Also changed TweakScale settings to not scale the battery size.
    • Added a second bottom attachment node so that the bottom can be closed or used for another solar panel, etc. It even allows for cube stacking :)
    • Added RemoteTech support.

     

    • Also the solar panels are not aligned at with stock (weigh far too little, cost nothing, generate clearly less than stock panels). New values are based on OX-STAT panel.
    • Changed TweakScale settings to use power 2 instead of 3.

    These changes are written as a MM patch to the original mod, so put them into a new cfg file:

    Spoiler

    @PART[3Sat_small] {
        @cost = 1100
        @mass = 0.12
        node_stack_bottom2 = 0.0, -0.82, 0.0, 0.0, -1.0, 0.0, 0
    }

    @PART[3Sat_tiny] {
        @cost = 500
        @mass = 0.05
        node_stack_bottom2 = 0.0, -0.42, 0.0, 0.0, -1.0, 0.0, 0
    }

    @PART[3Sat_small|3Sat_tiny] {
        @RESOURCE[ElectricCharge] {
            @amount = 5.0
            @maxAmount = 5.0
        }

        -MODULE[ModuleReactionWheel] {}
    }

    @PART[3Sat_small|3Sat_tiny]:NEEDS[TweakScale] {
        %MODULE[TweakScale] {
            type = free_square
            %TWEAKSCALEEXPONENTS {
                mass = 1.25
                Resources {
                    amount = 0
                    maxAmount = 0
                }
            }
        }
    }

    @PART[3Sat_small|3Sat_tiny]:NEEDS[RemoteTech] {
        %MODULE[ModuleSPU] {}
        %MODULE[ModuleRTAntennaPassive] {
            %TechRequired = unmannedTech
            %OmniRange = 3000
            
            %TRANSMITTER {
                %PacketInterval = 0.3
                %PacketSize = 2
                %PacketResourceCost = 15.0
            }
        }
    }

    // **************** Solar panels

    @PART[3Sat_tinySolar] {
        @mass = 0.01 // 0.005
        @cost = 150 // 30
        @MODULE[ModuleDeployableSolarPanel] {
            chargeRate = 0.7 // 0.18
        }
    }

    @PART[3Sat_smallSolar] {
        @mass = 0.04 // 0.005
        @cost = 600 // 60
        @MODULE[ModuleDeployableSolarPanel] {
            chargeRate = 2.8 // 0.35
        }
    }

    @PART[3Sat_smallSolar|3Sat_tinySolar]:NEEDS[TweakScale] {
        %MODULE[TweakScale] {
            type = free_square
            %TWEAKSCALEEXPONENTS {
                mass = 2
            }
        }
    }

     

×
×
  • Create New...