Someone2018

Members
  • Content Count

    58
  • Joined

  • Last visited

Posts posted by Someone2018


  1. @damonvv Why is Ghidorah a 2.5m design if it's clearly a falcon 9 clone? I was expecting a 3.75m design, like the real life counterpart. Otherwise it becomes near impossible to launch the thing of an earth like planet (with orbital velocity of 7800 m/s) with any kind of payload, even after adjusting for KSP's insane dry weight and similar things. 


  2. On 4/19/2019 at 9:14 AM, Steven Mading said:

    @Someone2018
    If nothing else, I can at least tell you how you can try to bypass that screen by directly editing your persistent.sfs savegame to trick it into thinking you've already given it an answer.

    (As with any edit to persistent.sfs, make sure you copy it to some other name first in case you screw up so you can get it back.)


    Look for this section of your persistent.sfs save:

    
    		kOSConnectivityParameters
    		{

    Look for which of the conditions below is the one you want, and edit your section to look exactly like it shows:

    IF: you do NOT have Remote Tech installed, and you want to use PermitAll (kOS ignores comms and always pretends you're connected), then make that section look like this:

    
    		kOSConnectivityParameters
    		{
    			version = 0
    			knownHandlerList = PermitAllConnectivityManager,CommNetConnectivityManager
    			connectivityHandler = PermitAllConnectivityManager
    		}



    IF you do NOT have Remote Tech installed, and you want to use CommNet (you want kOS to obey the stock game's antenna connection rules), then make it look like this:

    
    		kOSConnectivityParameters
    		{
    			version = 0
    			knownHandlerList = PermitAllConnectivityManager,CommNetConnectivityManager
    			connectivityHandler = CommNetConnectivityManager
    		}



    IF you DO have Remote Tech installed, then you should use Remote Tech connectivity manager, and make it look like this:

    
    		kOSConnectivityParameters
    		{
    			version = 0
    			knownHandlerList = PermitAllConnectivityManager,RemoteTechConnectivityManager
    			connectivityHandler = RemoteTechConnectivityManager
    		}


    If nothing else, that should let you get past that initial dialog box so at least you can play, but I still would like to get to the bottom of what causes this.
     

    I narrowed it down to the "moving window change" that really doesn't work well with UI scaling != 100% (i.e. the window is moved offscreen). I have a fix for this, but github forking is broken right now (for me), so I can't put up a pull request.

    Figuring out the correct settings is non-trivial (took me several hours at least), so don't bother replicating it :-)


  3. 6 minutes ago, Steven Mading said:

    Well darn.

    Can you temporarily set the 180% scale down to 100% just to see if that changes the behavior of the bug at all?

    One change I made in kOS 1.1.7.0 was to move that dialog box offcenter to fix this issue: https://github.com/KSP-KOS/KOS/issues/2456

    I don't know if that affects this, but the place it is crashing according to your log *is* the place where KSP checks the corners of that box to see if it's offscreen.  Why that would throw a null exception instead of just handling it or refusing to work if it doesn't like what it sees, I don't know.  I also know I had the box hanging partially offscreen a number of times and it was fine when I tested anyway.

    The problem seems to be happening when the box is trying to *close* itself, actually.  So I wonder if some weird timing issue is causing KSP to try calling the offscreen checker *after* the box has started to dispose of itself and its not all there anymore, thus the null ref.

    Also, that box appears only if the game is a newly started save from the beginning, or at least a game in which kOS was just installed and had not been running beforehand in that save.  If it's a save where kOS was already installed and used in that save, and that dialog box was already answered, then it shouldn't come back again in that save.

    Which situation is having the crash happen?

    1 - kOS already installed, then start a brand new savegame from scratch.  (This is a case that I would expect the dialog box to appear).

    2 - kOS NOT installed, then start a brand new savegame, then exit KSP and install kOS, then run KSP and resume that savegame.  (a game that was started without kOS, then had kOS added later).  (This is a case that I would expect the dialog box to appear).

    3 - kOS already installed, the savegame already has the connectivity manager selected, and you continue it as normal (this is the case where I would NOT expect the dialog box to appear).
     

    I did mostly 1, but also 2. Testing at 100% scale will have to wait, not at my game pc right now, and won't be for the a few days.


  4. 5 hours ago, Steven Mading said:

    Okay you have *got* to be kidding me.  The dialog box that kOS opens to ask for a connectivity manager is causing some weird nullref exception in KSP if any corner of it is off the edge of the screen when it gets dismissed.  WTH???

    Are you running in a small screen resolution where that dialog is hanging off the edge of the screen?  I tested for the smallest resolution setting available on the settings screen when I moved the dialog box offcenter and it never bombed out even when one corner of the box was off the edge of the screen, but in your case that is the very call it's bombing out in - the call KSP makes to test the bounds of the box.  Note this is happening when kOS tells KSP to *dismiss* the box, so it may be that KSP will crash whenever a dialog box goes away while partly off the edge of the screen??

    Also, annoyingly, your case isn't the one the others are talking about.  You're having KSP crash *before* it loads.  Other people are having the terminal fail after KSP is loaded.

    [Edit: sorry - what I mean is annoyingly for me, since I want to find out what is causing the terminal not appearing bug, since I thought I had it nailed down to Wind Tunnel, but if people are getting the problem without Wind Tunnel then I haven't totally found it.  I still need one of THOSE logs to look through.]

    The connectivity manager box never appears for me at all (on screen), although i did see it in a non-responsive state after switch from fullscreen to non-fullscreen once or twice over the past week.

    My resolution is actually large 3840x2160, at a scale of 180% though.


  5. 4 hours ago, infinite_monkey said:

    I had trouble getting rid of the incompatible mods warning once. After showing up while KSP was loading, i could dismiss it, but it showed up again. Clicking on it didn't have any effect, finally I got rid of it by hitting ESC. Not sure if that helps you in any way?

    It might help for that case, but I have permanent UI breakage once I install kOS. Of buttons I actually need to use in order to play the game.


  6. 1 hour ago, blowfish said:

    @Someone2018 because the REFUSE_wet_mass value is left on the PART at the end, and KSP doesn't know what to do with that when compiling the part.  It's harmless but you could include a separate patch to remove it at the end (it would have to be a separate patch - all values are processed before all nodes so you wouldn't be able to use it in the RESOURCE node otherwise).

    Oh, I have that patch, but since I tried with and without (and got the same warning) I removed it from the example.

    @PART[*]:HAS[@REFUSE_wet_mass]:FINAL
    {
        // cleanup
        -REFUSE_wet_mass = delete
    }

    Anything wrong with the way I clean up?


  7. @PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[KerbalEVA],!MODULE[ModuleCommand]]:FOR[ZZZ_REFUSE]
    {
        // dry mass
        REFUSE_wet_mass = #$mass$
    
        // original liquid fuel mass
        temp_mass = #$@RESOURCE_DEFINITION[MonoPropellant]/density$
        @temp_mass *= #$RESOURCE[MonoPropellant]/maxAmount$
        @REFUSE_wet_mass += #$temp_mass$
        -temp_mass = delete
        !RESOURCE[MonoPropellant] {}
    
        // configure new propellants
        RESOURCE
        {
            name = HTP
            amount = #$@REFUSE_FuelTanksConfiguration/HTP_units_per_metric_tonne_of_wet_mass_for_HTP_tank$
            @amount *= #$../REFUSE_wet_mass$
            maxAmount = #$amount$
        }
    
        // adjust dry mass
        @mass = #$REFUSE_wet_mass$
        @mass *= #$@REFUSE_FuelTanksConfiguration/HTP_dry_to_wet_ratio$
    }

    Anyone understand why patching a simple mono-propellant tank produces a warning about variable not found in PartLoader:

    [LOG 22:12:15.795] PartLoader: Compiling Part 'Squad/Parts/FuelTank/RCSFuelTankR25/RCSFuelTankR25/RCSFuelTank'
    [WRN 22:12:15.800] [ShipConstruct for RCSFuelTank]: part cost (330.0) is less than the cost of its resources (811.4)
    [WRN 22:12:15.801] PartLoader Warning: Variable REFUSE_wet_mass not found in Part
    [LOG 22:12:15.808] PartLoader: Part 'Squad/Parts/FuelTank/RCSFuelTankR25/RCSFuelTankR25/RCSFuelTank' has no database record. Creating.
    [LOG 22:12:15.809] DragCubeSystem: Creating drag cubes for part 'RCSFuelTank'

     


  8. On 11/27/2018 at 9:02 PM, Thorn_Ike said:

    True enough; I wanna make a mod for KSP, but I just don't know where and how to start.

    Learn by tweaking inter-mod compatibility, or improvements in general to the stuff you already love. Lower amount of time needed, and you get something out of it. That would be my tip. Mods become attractive when the quality is high.


  9. 1 hour ago, Nightside said:

    Interesting idea, I've thought about doiing something like this myself.
    What fuels are you planning to use?

    RP-1/Kerosene, liquid hydrogen now for fuel, only liquid oxygen for oxidizer

    Liquid methane is an interesting one as the third dominant fuel class if there are actually mods/engines out there

    And hydrogen peroxide as monopropellant, because hydrazine is too toxic for my taste :-P

    I try to keep the readme up-to-date, which is why I point to it


  10. 25 minutes ago, HansSoban said:

    @Someone2018

    Hi just deleted old ModManagers and went back to the game, the undocked satellite still did the same thing and on the MechJeb it does show a zero TWR.

    Switching back to Space Center does helps, but if I switch back during focus on the satellite it's gonna went back to last save due to the satellite is under that acceleration.

    The current solution is undock the satellite first and then switching back to Space Center immediately when focusing on the stable ship, it saves the orbit for satellite.

    The problem still exists, and I still hope that I can solve this from the root. but thanks! things are already going in a better place.

    It's still strange, but at this point you'd need a minimal reproduction scenario (as in less mods, and the simplest instructions) to get proper help I suspect. And for 1.2.2 I don't think that's even going to happen anymore, because it's ancient.

    Why are you on 1.2.2 if i may ask?


  11. 19 minutes ago, HansSoban said:

    @Someone2018

    Hi, yea I should be a bit more specific about it.

    The injected orbit for the entire craft is 450 km both at Ap/Pe, and the Karman line of the earth in the game is 140 km.

    The orbit of the satellite after undocking was NOT stable. The Ap kept rising and Pe kept to dropping all by themselves, resulting in the undocked satellite reentry to the atmosphere at last. Like I have said in the main post, it was like an invisible and constant thrust toward nadir is applying to the satellite. And it was undocking from the port, not separating by staging so it should not be adding to much force.

    I see multiple module managers, maybe get rid of the older versions.

    If you use kerbal engineer redux does it show a non-zero TWR? Does switching away to the space center and then back to satellite make a difference?


  12. @HansSoban

    Assuming you had a perfectly spherical orbit, ejecting a satellite while pointing prograde will reduce it's oribital speed at that point (you can calculate it based on the ejection force and the total satellite mass). This means that the satellite doesn't have enough velocity to make the same orbital altitude 90 degrees later in orbit (with gravity constant).  This will make the satellite orbit slightly elliptical, thus moving radially up and down relative the celestial body.

    Your satellite should still have a stable orbit (i.e. apoapsis, periapsis, and orbital time are fixed given the stock 2-body gravity mechanics), can you check that?

    How different are these parameters from your launcher?


  13. 27 minutes ago, Gordon Dry said:

    So, i just fiddled a little bit in sandbox ... many mods/part packs use other stuff than "just" B9PartSwitch. Could be IFS, could be FS.

    For example, Bluedog DB - tanks got stock fuels.

    This is the point I stopped fiddling - when even BDB does not work, then I should stop.

    btw BDB does use B9PartSwitch ...

    I'll see if there is a smarter way to deal with B9 tank configs, than adding all their names as they are found. FYI the BDB ones are probably not even working in SMURFF.

    I'm aware of IFS, what is FS? (i.e. have a link?)


  14. 2 hours ago, Gordon Dry said:

    Because I'm a beta-tester-like-to-bork guy, I will give it a go - after backing up the save.

    btw removing SMURFF and adding REFUSE - I'm curious because many part packs have this smurffexclude tags - or even special SMURFF patches like BDB.
    So let's see how it goes now.

    I will wait for the buildings to be on fire, lol

    The scaling ideas are not that different, so there might be some super overpowered engine now.

    I only excluded the NearFutureSomething launch abort engines.

    I wasn't aware that it was a common thing to have high TWR engines in stock game.

    Please be aware I haven't even looked into the ISRU stuff, so you won't be able to create any of the fuels after launch. This is why I referenced the readme, which has the latest info.


  15. Something which is in early development, and thus not even versioned yet.

    It essentially patches a very limited set of realistic fuels into the stock game. It's scaled to the Real Solar System.

    Please see readme at: https://github.com/madman2003/REFUSE

    If you are curious about this, please let me know what you think of it. Can be from a gameplay perspective, or realism perspective or a "code" readability perspective.


  16. @Nertea

    Given the use-case you mentioned I understand why you went for these thrust numbers. Out of curiosity, how did you balance engine mass?

    EDIT: most rockets are at a factor 3-4 higher TWR in real life, but this has to do with kerbin's orbital velocity of 2300 m/s vs 7800 m/s for earth while having similar gravity, your use-case doesn't really scale with orbital velocity as far as I can tell, which is why you end up with high TWR by KSP standards


  17. On 11/12/2018 at 6:00 AM, Nertea said:

    I just uploaded the new release of NF Spacecraft. This is the last targeted content update for this mod, we'll be moving into maintenence/minor renos now.

     

    Changelog

    •  Added 64-8S 'Chickadee' Landing Engine: high thrust small radial monoprop engine for Nereid, Tethys
    •  Added 96-8S 'Mockingbird' Landing Engine: higher thrust larger radial monoprop engine for Almathea

    The mono-propellant engines you added have a TWR of 70-80, which exceeds the best bi-propellant in the stock game by a factor 3. This is a bit crazy.

    Judging by the physical size, I would expect a thrust of a factor 5-10 lower than current.

    An engine which is physically larger, yet only has one nozzle: The aerojet MR-80 is a (mars) lander engine with a mass of ~8 kg and a thrust of ~3.8 kN while being 40 centimeters long (see page 17 of https://apps.dtic.mil/dtic/tr/fulltext/u2/a545862.pdf).

    That gives a TWR of 48, which is higher than a typical RCS thruster, more in line with not-so-high-TWR bi-propellant engines.

    KSP stock engines have TWR's that are more than a factor 3 lower than real life (some people claim up-to factor 4). That would put you in the 12-16 TWR range. 

    That's usually expressed by engines being far too heavy compared to IRL counterparts. But in this case your combination of 2/4 thrusters might just be output'ing an insane amount of thrust.

    My "ballpark" recommendations (despite the current size models being smaller than the 40 cm of the aerojet MR-80):

    Chickadee (2  thrusters): 8 kN thrust, 0.056 metric tonnes mass, TWR of 14.6

    Mockingbird (4 thrusters): 16 kN thrust, 0.112 metric tonnes mass, TWR of 14.6

    A set of 4 chickadees can still land a mk1 pod/can, with a TWR which is high enough for a planet without extreme gravity. (mars/duna being a typical case)

    And a set of 4 mockingbirds can do the same for a mk1-3 pod/mk2 can.

    Should be enough for propulsive landing of a lander. Although not for getting into orbit again i suspect, unless it's just a moon.

    If you wanted them to be some sort of base landers, or large craft landers, or work in very high gravity, maybe make them bigger.

    Although at some point moving away from monoprop makes sense.

     


  18. 13 hours ago, Ezriilc said:

    I'm sorry, but I don't have any tips to offer - I'm not The Creator, and not fully fluent in C# or the KSP API.  I do, however, know a little bit, and I maintain the code on GitHub: https://github.com/Ezriilc/HyperEdit

    I'm quite open to making changes to improve integration with other mods or whatever, so if you learn anything helpful, please come back and let us know, either there, here, or on my site.  Thanks in advance!  :D

    I doubt I’ll find anything, because principia takes over the simulation of positions of crafts and planets and uses the full history of a craft to determine where it will go next. But if I ever discover a way I’ll let you know.