DRVeyl

Members
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

4 Neutral

About DRVeyl

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Realize this is the 1.5+ thread for this, but highlighting an issue I'm coming across in 1.4.5. Opened an issue on rsparkyc's github page, re-posting here for visibility -- or someone to identify what I'm missing or that it is fixed in 1.5+. Context is running 1.4.5 + RO/RSS/RP-1 (github latest). -- KSP 1.4.5, with Procedural Fairings 1.4.5.5 (via CKAN) (Technical: Unable to set KzResizableFairingBase 's MODULE[ModuleDecouple].stagingEnabled to True. It is unset in KzInterstageAdapter2 but set to False in KzResizableFairingBase) The Payload Fairing - Base (Extended) does not show a staging icon when added in VAB. The fairing staging works as expected, the payload base is the issue. Right-clicking the part gives the expected menu items (Extra radius, strut/size toggles, fairing nodes, interstage toggle, size tweakable, mass, cost, decoupler force percent, crossfeed toggle) but nothing to enable staging. The decoupler can be activated by action group or right-click menu on the payload base during flight. Seems the toggle got lost from the GUI? Non-scripting workaround is add a separate decoupler part above the payload base. Scripting workaround (assuming you will ALWAYS want to use the decoupler?): @PART[KzResizableFairingBase]:AFTER[ProceduralFairings] { @MODULE[ModuleDecouple] { %stagingEnabled = True } } Same for @PART[KzResizableFairingBaseRing]:AFTER[ProceduralFairings] Scripting workaround works as expected: decoupler icon for staging shows in VAB, triggers appropriately upon vessel staging in flight.
  2. I suppose I outlined my objection to this in my earlier post. It's not about the features that the base KSP provides that are absolutely necessary. It's not even about the features within RO itself (or its dependencies). It's about all the ongoing development in other mods that become inaccessible to the RO player because RO does not upgrade, and it's questionable that other mod developers should be expected to maintain development and release for older versions of KSP. As an example, RemoteTech fixed a breaking bug w/RO compatibility in March with its 1.8.10 release and update to 1.4.1. It had to re-release in JUNE with 1.8.11(.131) for RO. It's fair that a mod suite with external dependencies like RO is slower to update. I think it is harmful to development to argue that new features in the core system aren't necessary, so no update should happen. And its a flaw in the development cycle if an individual external mod is holding up your compatibility, for apparent lack of activity in that mod. [I have no insight into Ferram's situation or why FAR appears to be going without development. I love FAR as a mod. But from a programmatics standpoint, losing supply of a required component is a program risk, and there doesn't appear to be any mitigation.]
  3. I keep lurking around Bornholio's Golden Spreadsheet for 1.4.x (https://docs.google.com/spreadsheets/d/1jqFjaHCo0gdIj5mX61V8D02Ma6v1WfH2Zuv0ddXgG5M/edit#gid=0) and appreciate all of the updates he and a few other anonymous contributors make to it. It attempts to track the compatibility of various mods required for the RO and RP0/RP1 mod suites. So practically speaking, what -is- delaying release of a newer version of RO? FAR & KJR are both Ferram's. Starwaster's DRE. Real Solar System + textures (tho textures shouldn't have any dependency on the version of KSP). Testflight has a PR waiting. What else is an actual dependency that would halt release?
  4. Probably blasphemy, but I definitely see the point of the question. There are a couple PRs in FAR with recompiles for 1.4.x that haven't been merged in for quite a while. RO updates have lagged because of dependencies, which makes sense but there's also something to be said for RO itself to be a forcing function / show desire for those dependencies. An argument for just playing older versions doesn't work very well since bug fixes on many systems [that are RO dependencies] often don't get older versions re-released. This also ignores that players might want new features from base game upgrades and other mod updates [required or otherwise for RO], and also that it becomes a much bigger lift to catch up multiple significant releases later. After the last long hiatus from releasing, I think the RO team wanted to move to something more spiral-development with smaller monthly releases. But... RO's last release was 90 days ago, and is 30+ commits behind the master branch at this time. With FAR, I assume [speculation] that nobody else has privileges to merge into master.
  5. Start with 1.3.1 and pull from CKAN. Then manually pull just RP-0 (or rather, suggest the developmental branch on github aka RP-1) and the suitable version of RSSVE. I believe the dev branch of 1.3.1 has the correctly-compiled RP0.dll.
  6. I'm uncertain why you're looking for a 4-stage tier-0 *reliable* orbital rocket design. If you DID prove one out, would that suggest that whatever you design contains gear that doesn't belong in tier-0 nodes in RP-1? Or is the conceit that American rockets used as an upper-stage to heavier Russian first stage rockets could have done better than either nation's approach, given some hypothetical world where cooperation drove development rather than competition?
  7. Ouch. I'm nowhere near as fast as they are. But I didn't feel like fighting for achieving orbit before the 1956 Orbital Rocketry tech, where an LR79 + AJ10 definitely has the capability at ~40 tons [requires a pad upgrade.] If you know when you're <3 years out, the 500k advance for achieving orbit pays for the pad upgrade (75k), the rocketry entry costs (~150-200k?) and several upgrade points. Early, each point seemed about +10% to research speed or production speed. Being way too cautions in buying upgrade points, I got 1956 orbital rocketry tech mid/late 1955. Most of my funding came from doing way too many repeated missions for sounding rocket altitude and difficult sounding rocket payload missions, and some of the world-first payouts for altitude. IMO this time period could use some balancing, as it feels like you need to do the missions to generate cash [especially if playing with the recommended "hard" settings] but it is a long time between interesting new capabilities from research. I wasn't doing anything interesting or different with the launches, and had designed an LV that would generally last through several iterations of contracts. I was aiming to keep rocket build times around 30-40 days. I freely admit that my opinion about balance is based on not knowing an optimum path through this early game [specifically when to take which advances, what upgrades/unlocks are absolutely necessary, what excess funds should be assigned to upgrade points and spread across build/tech times]. I stayed at KSC, so didn't spread any to get "quicker" access to different biome sciences eg flying/high atmo/space low from different launch facilities. I missed the whole "sounding payload in pressurized tank-1," too, and ended up waiting for service module 1. Thus... I certainly wasn't spamming the payload missions until a little later, and it was basically just altitude!
  8. It's an incredibly informative tutorial series! Also, check out the wiki on the RP-0 github [ https://github.com/KSP-RO/RP-0/wiki/Tutorial:-Getting-Started ] which includes more detailed installation instructions and a guide for the first couple rockets. Feel free to mix and match parts from the differing space programs. For the most part, the tech tree isn't program specific. Different engines/engine subtypes [and thus fuel types & mixtures] become available as you increase tech level, but boiled down to a game mechanics perspective, you end up selecting for the engine+tank stats, mainly ISP and fuel density. It's neat to know some of the history or space program preferences and/or why that was the case, but your rocket will fly the same regardless!
  9. Note that the "Last edit was made x days ago by y" at the top of the spreadsheet opens a menu to see the change history. I'm not sure anyone is willing to claim they've tested something enough to mark it green. I sure am not. [My KSP activity is extremely bursty and inconsistent.] From my observation, the main holding pattern is that the spreadsheet indicates a lot of updates available via github [usually] that are in mod PRs but not yet merged into the mod's dev or master branches, let alone a release. And if those haven't released, RO doesn't itself want to cut a release when its dependencies are not easily available. I'm not sure why some of the 1.3/1.3.1 update PRs seem to be sitting for a long time in some of the mods. However, if you do follow the spreadsheet for installation, you have a playable game. [I don't know that the significant amount of updates to RP-0 are balanced yet, so a formal (non-beta) release might still be a ways off, but they are playable.] Some of the mods are still marked yellow, but I don't see that any of those should prevent a release. It's also possible that someone just hasn't marked some of them blue yet.
  10. RP-0 will definitely work without KCT. The main effect of KCT is to make time a resource, rather than the default of instantaneous building/construction/research. In practice, I've found that it causes me to spend more time at each effective tech level, rather than "skipping ahead" by researching multiple levels further into the tree and never using some of the intermediate items [especially engines]. Similarly with TestFlight, if random engine failures just isn't your thing, it's perfectly fine to play without.
  11. Link to the RH 1.3 Test DLL is in the GitHub PR: https://github.com/KSP-RO/RealHeat/pull/4 PhineasFreak was nice enough to supply the compiled dll [unofficial, for 1.3 testing purposes only!], also linked from there.
  12. If I recall correctly, the RemoteTech contracts require that your satellites have links between eachother, not that each satellite has its own link to the ground. Try pointing sat-2 at sat-1, sat-3 at sat-2, sat-1 at sat-3. The other dish on each sat can be pointed at Earth IF your satellites are close enough to close the link using the dish+omni.
  13. Bump. I've been poking at that doc and marking things blue that seem to work and generally don't throw exceptions. Have only done the barest testing, usually launching a basic craft with some of the features from a given mod attached, so haven't marked anything green. Looks like just about all of the requirements for RO function in 1.3, and the ones I haven't poked at yet shouldn't be strictly necessary. So if anyone out there has a 1.3-compiled variant that they would like the community to test...
  14. Also had this in RO, which led to a little digging. Went to prep some screenshots but couldn't duplicate. However, think this is related to MJ2+RealFuels, specifically the ullage requirement / propellant state. For "Very Stable" MJ2 correctly calculates "Node Burn Length" and "Node Burn Countdown." If the propellant is not "Very Stable" those numbers become INF. I think this is some fighting between RealFuels (RealFuels/SolverRF ?) and MJ2/FuelFlowSimulation.cs? http://imgur.com/a/vTzAh