Jump to content

DRVeyl

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

7 Neutral

About DRVeyl

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

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

  1. @darthgently Most parts don't have a CoM Offset, so the position of the part is the position of the center of mass. What you want is part.position + part.CoMOffset. That CoM offset I believe is part-local, so if the part is placed upside-down you may need to account for this. Interesting catch on the HASPHYSICS flag. I don't know quite what that translates to, exactly, in the KSP part info. But it does seem like ProcParts should definitely not be physics-less and should not apply their mass to any parent parts. Maybe part.physicalSignificance or part.PhysicsSignificance? @Hebaru
  2. Please see the release notes for v2.1.0, particularly in regards to part sizes. "When upgrading an existing career, you may need to purchase the part size upgrades in R&D for previously unlocked tech nodes.In sandbox play, you will need to enable "All Part Upgrades Applied In Sandbox" in the Difficulty settings, Advanced tab." If you are not able to play on 2.1.0, v2.0.3 is probably a reasonable fallback. 2.0.4-2.0.6 attempted to re-institute some volume limits that were around in the pre-2.0 releases. This illustrated a few inconsistencies in how we were handling the tech limi
  3. 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) doe
  4. 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.
  5. 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
  6. 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 upgr
  7. 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.
  8. 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?
  9. 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 fun
  10. 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 s
  11. 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 de
  12. 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.
  13. 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.
  14. 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.
×
×
  • Create New...