Jump to content

allenby

Members
  • Posts

    30
  • Joined

  • Last visited

Posts posted by allenby

  1. 21 hours ago, cantab said:

    Did you only barely escape Kerbin's SOI? If so, you can end up being recaptured unexpectedly.

    I considered that possibility but the burn was fairly excessive. I was going for more of a rapid flyby than a soft textbook transfer. The resulting Kerbin orbit also didn't look right for a recapture. Maaaybe possible but it wouldn't be the first time I've encountered odd SOI behavior in the Sonnah neighborhood. In any case I might start recording my games so that I can do proper bug spotting.

  2. Played for a few hours yesterday and it seems to work. Only issue was getting Krakken'd on my way from Kerbin to Serran. Basically my vessel went from being on a clean Serran intercept to a small elliptical Kerbin orbit upon entering time warp (would have required tons of dv to accomplish this normally). Seems to be associated with the Schrodinger's trajectory issue where your vessel is simultaneously on two different paths until you hit an SOI boundary. Odd bug and I haven't been able to reproduce it, but thought I'd mention it.

  3. I've noticed some odd errors when trying to use this mod with procedural parts. I think it might be linked with the new PPart textures/configs that are bundled with the rebalance mod. On trying to load the textures, PParts will throw array out of bounds exceptions and no textures end up being loaded (everything is white, and the PPart texture selection menu just reads "**NOT FOUND**". Also, attempting to right click the procedural heat shield freezes the game with a stack overflow exception. Removing the procedural parts directory and procedural textures directories from the SETI rebalancing mod restores normal function.
  4. allenby, I just tested my patches including the NEEDS[!RemoteTech] and everything applied just fine. Can you make sure you're using ModuleManager 2.6.13 and that you really don't have any RemoteTech traces around?

    Had a chance to do some more testing. I tried manually installing things one at time and checking. ModuleLimitedDataTransfer seems to stop being applied to stock antennas once I install the PhantomAerospace antenna package. Steps:

    1) Clean install KSP

    2) Copy AntennaRange package to GameData - Stock antennas work as they should ✓

    3) Copy PhantomAerospace Antennas package to GameData - Stock antennas no longer have ModuleLimitedDataTransfer applied, but the PhantomAerospace ones do

    I still have to look over the files to see what could be causing this, but it's a step in the right direction.

  5. I still cant transmit any science. At any time, no matter the method I use to try and transmit. From the Antenna, the MPL or on the science dialog once an experiment is run.

    Is what your fix was my possible problem? I wasnt sure if you were replying to me.

    Hmm. I'm not sure if the two are related. I was just mentioning a possible bug. In my case, the renaming of ModuleDataTransmitter -> ModuleLimitedDataTransmitter wasn't being applied with the included MM patch. I would imagine that even if the MM config is not being applied, antennas should still display stock behavior and be able to transmit normally. I haven't yet tried MPLs in this version.

  6. More testing with Deadly ReEntry installed now, and something is *CLEARLY* not balanced correctly for Real Solar System 64K with nuFAR also installed.

    I managed to drop a 1.20 meter heatshield with NOTHING behind it (not even a capsule) on a shallow sub-orbital trajectory with a PERI at 51.6 km (that's the equivalent of about a 40 km PERI in stock), and the thing burned up and EXPLODED before reaching 50 km (PERI lowered during aerobraking, of course). That's a 1.20 meter Procedural Parts heatshield with NOTHING BEHIND IT and a full Ablator load at 100% (default) ReEntry heating setting, once again. The G-forces never even climbed that high...

    Actual craft are even worse- I had engines, fuel tanks, and a Mobile Lab Jr in a stack all sequentially burn up on a shallow Munar return-trajectory at just 67 km within a couple seconds of loading (after having the craft unloaded earlier in the re-entry, for testing purposes...)

    Clearly, something needs to be adjusted so that craft and heatshields don't burn up so easily. In the meantime, I'm using DRE's handy little difficulty slider to turn re-entry heating down to something more realistic, which should not be something I should ever have to do at default heating (that is, the default should not be so much more difficult than real life...)

    Regards,

    Northstar

    Just FYI the Procedural Parts heat shield seems to be bugged. There are reports in the main thread from other users having experiencing similar problems while the other heat shields work fine. In my own experience, skin temp will cap at a really odd value (like 4 Kelvin) during re-entry and the part explodes very quickly. Noticed this yesterday and haven't had a chance to get more observations.

  7. What affects boiloff is part temperature. That's the internal temperature which is not the skin temperature.

    Thanks. I'm just wondering about how the boiloff rates are determined in a given game state. I noticed the temperature and loss_rate variables under TANK_DEFINITION. I'm guessing temperature means boiling point, and loss_rate is the amount subtracted (or a multiple of the amount) when part_temperature > boiling point. Is that correct? I'm just trying to get a sense of calculating boiloff losses for planning purposes.

  8. Apologies for the noob question, but what variables (other than tank type) affect the in-game rate of cryo-fuel/ox evaporation? Are they just constant?

    I'm trying to imagine scenarios where I use cryogenic fuels on interplanetary missions, but need to know if there are practical ways of mitigating boil off.

  9. Just recently tried this planet pack. Very nice, especially with the custom GFX addons. I was hooked when I first saw Sonnah over the horizon from low Kerbin orbit. Also, good call on having Kerbin as a moon - it certainly adds a new layer of challenge and planning to interplanetary trips.

    Only issue I've had is that as a Science Mode + CTT player, my career is pretty much stalled in the Sonnah system. I don't know if this mod is meant to be played in Stock full career, but there don't seem to be enough available science points around the local bodies to progress to technologies required for manned landings (i.e. 2.5m rocketry, landing legs, crewed landing modules) or to even advance to the intermediate level of science instruments. I might either add some initial science points, or make a MM config for players who can't or won't play with contracts, in order to counteract the science-poor early game. I don't mind difficulty curves, but as a Science Mode player, the experience feels a little discontinuous.

  10. Thanks for these. Have you checked all tabs to make sure the parts aren't just hiding? They're all in the MM cache, and there's no part errors in the log from RLA parts. Just seems odd they'd just be gone, especially only when Stockalike is installed.

    Found them in the fuels tanks. I glanced at the other tabs but didn't check all the pages. Really wasn't expecting the engines to have moved, but mystery solved :). Just curious as to why mod engines are appearing in fuel tanks.

  11. Thank you for the update. Your work is really appreciated.

    Possible bug:

    Having a strange issue where RLA-Stockalike engines are simply not showing up in the VAB. RLA parts show up again when the corresponding Stockalike RF cfg is removed. Only tested with RLA-Stockalike 12.1. Testing with the experimental version of RLA is slower as they've changed all the PART names, but seems to be the same issue with that version as well.

  12. The configs are updated if you grab the dev version from the repo. They aren't quite "release"-ready, but they shouldn't cause any issues. I have a few more additions I wanted to get in before there's an official release. But, the new stuff for RF (like ModuleEnginesRF) is updated there. That said, if you've found errors in the dev version, please let me know specifics so I can fix them. :)

    The Github dev version has ullage simulation set to true for SRBs.

  13. I suggest using TL-linked ignitions. That means that 60s era engines can have 1 ignition and modern engines a good few (example, Merlin 1D Vac is pump-fed, kerolox, but still has multiple ignitions).

    Though in general, vacuum engines do tend to have multiple ignitions no matter their cycle or propellant type; the S1.5400 from 1960 was staged combustion kerolox and supported multiple ignitions (needed to insert Molniya sats into their orbits), and RL10 had multiple ignitions from the start.

    There's something about vacuum engines I'm wondering about, specifically hypergolic engines.

    I've been trying to get into the details of IRL engine ignitions, and some of it is a little confusing. Some sources simply state that hypergolic engines don't need ignition, but others sources describe hypergolic engines being limited to a rated number of ignitions/restarts. I suppose it makes sense, given that the components can't be expected to work forever, but are there IRL hypergolic engines that are effectively capable of many (>20-30 or 100+) restarts? I remember reading that the Apollo SPS was theoretically rated to 100s of restarts, but I don't know how true that it is.

    For monopropellant engines, I'm reading that early hydrazine engines were limited by the number of start slugs they had. For more modern engines using catalyst beds, the number of restarts was "almost unlimited." In the case of these types of engines, maybe # of ignitions could just be set to -1 in the configs.

    I'm just trying to get an idea of how many ignitions would make sense for in-game orbital maneuvering or descent engines. I'm still looking for a good summary with this kind of detailed information.

  14. Solids shouldn't have any issues firing in 0g. Which is why they're generally used as ullage motors. Are there issues with all solids or just some? It's probably a config issue, but I need to narrow it down.

    So far I tested the Sepratron I and RT-5, and they both have this issue. I glanced at the stock configs and noticed that most (all?) SRB configs have useUllageSimulation set to true. I don't know if the ullage code is supposed to distinguish SolidFuel, or maybe that boolean just needs to be set to false?

  15. @Raptor831

    Happens with all engines, but it doesn't look like it's anything to worry about, based on what Nathan just mentioned.

    I have tried to edit both the release version of Stockalike and the recent dev version (just the Squad engines).

    @NathanKell

    Makes sense. I'm fairly new to these mods (and KSP modding in general) and never used legacy EI, so I'm making quite a few assumptions as I go along. :P

    Here is an example of an engine edit I've tried. I tried to follow the directions mentioned above, but maybe something got messed up.

  16. Still haven't had any luck trying to get the ullage/ignition to work. However, I noticed a consistent error in the log that might shed some light on the issue:

    [LOG 17:21:37.557] PartLoader: Part 'Squad/Parts/Engine/liquidEngine24-77/liquidEngine24-77/smallRadialEngine' has no database record. Creating.

    [LOG 17:21:37.577] DragCubeSystem: Creating drag cubes for part 'smallRadialEngine'

    [LOG 17:21:37.622] PartLoader: Compiling Part 'Squad/Parts/Engine/liquidEngine48-7S/liquidEngine48-7S/liquidEngineMini'

    [ERR 17:21:37.647] Cannot find a PartModule of typename 'ModuleEngineIgnitor'

    Does this mean that the legacy EngineIgnitor cfg isn't being recognized? This is with a clean test install with just RealFuels and its required mods. Has anyone else been having this issue?

  17. I find it strange, but it must be it was compiled against the wrong KSPAPIE and had the right one included because I have 1.7.5 with RF, but I have the glitch with Pparts. Please update soon it's impossible for me to play without this mod and Ppart as I remove all other fuel atnks form stock and mods to save ram. Thank you!

    Strange. The RF 10.4.1 I got from Github is bundled with the KAE 1.7.3 dll.

    In any case, like you said, it looks may have been compiled against the old version. When I recompiled RF with 1.7.5, it fixed the PPart issue for me. Also make sure that you're running no other mods that have an old version of KAE.

×
×
  • Create New...