johnsonwax
-
Posts
291 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by johnsonwax
-
-
6 hours ago, johnsonwax said:
I've seen something similar. My last 3 craft, 2 of them hit the ground at 600+m/s coming in from a standard 70K orbit, but one hit terminal velocity of 200m/s up around 8Km and landed nicely - just as I was expecting. Also no FAR, etc. here. So at the very least I think it's intermittent. Those were all different craft, so maybe it's related to specific parts in use? Almost as though one part such as the heat shield has a near zero drag coefficient where we only see the effect when it's not occluded during reentry.
Ok, I consulted with an expert and he suggested that my suspicion was probably right and likely a corrupted drag cube config in the part database. Deleting PartDatabase.cfg and letting it rebuild (simply restart KSP) appears to have solved the problem. Valentina appreciates the more predictable return procedure.
-
On 3/8/2019 at 2:05 PM, kurgut said:
No, In all my attempts the craft was oriented retrograde of course. Yes, they're some realchutes (radial), but the actual real chute parts, not stock (using for a while, so don't think it's this).
Anyway, I did like 10 reentry tests, and it wan't nominal. But I'll test further before considering this as an issue, with just a command pod heatshield/ with a shuttle/etc (reentry profiles I know), to see if there's really a difference.
I've seen something similar. My last 3 craft, 2 of them hit the ground at 600+m/s coming in from a standard 70K orbit, but one hit terminal velocity of 200m/s up around 8Km and landed nicely - just as I was expecting. Also no FAR, etc. here. So at the very least I think it's intermittent. Those were all different craft, so maybe it's related to specific parts in use? Almost as though one part such as the heat shield has a near zero drag coefficient where we only see the effect when it's not occluded during reentry.
-
I would like to add my congrats to everyone for their hard work on this mod. I can attest to the level of effort on this as @CineboxAndrew is my son so I've been seeing the effort first hand. He knows his old man really digs a well animated antenna and I especially thank him for sweating those details. However much effort you think this required from all involved, it was a lot more, I can promise you.
Great work everyone - it really looks amazing.
-
Would like to note that 1.26 Preview is working massively better for me on OS X.
-
On the garage structure one of these nodes is wrong:
// --- node definitions ---
node_stack_top = 0, 0.359, 0, 0, 1, 0, 2
node_stack_bottom = 0, -0.34, 0, 0, -1, 0, 2Pretty sure one should be the negative of the other, as with the garage front, except that it also sits at a little angle.
-
Ah, now I see it. Let me play with those settings.
[Edit]
That seems to work perfectly, thank you. Might want to add that as a super-simple example for how to use TCA. The ability to stabilize a VTOL rover even while having MechJeb piloting is super-handy and I would think quite common given a number of VTOL part packs (Malamute, Karibou, KPBS, etc.) Most likely would be people's first use case for TCA.
-
I'm having trouble doing something that I *think* should be simple. I'm trying to land a USI Karibou rover with a pair of VTOL engines. TCA works great until periapsis falls below 0, and then it (usually) turns on 'Level' mode and will not turn off no matter what. Sometimes the other control options turn on below peri 0 and Level stays off and I can try to land, but somewhere along the way it'll always turn itself on. I've played with the engine groups and made sure the Level button was disabled there, but nothing works. If there were a way to keep the on-planet autopilots disabled, that'd be fine too. All I need is to balance the engines while fuel drains.
-
One of the landing leg nodes is a bit off on the Garage Structure part. One side is good, but the other sits slightly above where the node should be and is slightly rotated. Mostly cosmetic, but anyone trying to birth one one of these things out of a Mk4 spaceplane cargo bay can barely spare the extra inch.
-
I'm neutral on the eye issue but I would vote in favor of visual diversity between the equator and the poles as 1 and 3 most show. If the storm spins, well, that's pretty cool...
-
On July 14, 2016 at 3:11 AM, svendii said:
EDIT: The CKAN reference should get changed automatically so that it's possible to update seamlessly.
The CLI lists the mod as 'SpaceXLegs' so finding your mod is a bit of a challenge there. Might want to have a little note telling people to look for that if they use CKAN CLI. CLI is always a bit of a haystack so it's not horrible, but usually you can start with the right letter of the alphabet and S is quite far from K.
-
23 hours ago, geekasylum said:
There is defiantly some interest here, however I dont often find myself using the Kontainers to store materials. Instead, I sit a UKS Inflatable Storage Module (the surface one, with the long extending legs) on top of a Cross-Way and then add a PB Planetary Adapter front and back, (with wheels and some small IR Extendatrons underneath to raise it up to allow docking of other ground PB modules still on the wheels) and a docking port at each end, with Flexible Corridors on the sides of the Cross-way. It works pretty well for me, so my storage / warehousing issues are solved. The ISM also works as a Planetary Warehouse, as opposed to the 2.5m Kontainer (tho the 3.75 and 5m Kontainers do function as Planetary warehouses (but not the 1.25 or 2.5m ones).
What I'd prefer is an adapter from the UKS MK III parts (which I still need for production), to PB so that I could dock them to the rest of the base.
For now, I've used ModuleManager to make a copies of the PB Habitat Mk2, and turn them into Worksops and Refineries etc (doing the same job as the UKS MK III modules did). The only one I havn't done this for is the UKS Mk III (Large) Sifter, but Im happy to park that off to the side and connect it to the base with Flexible Corridors.
Hmm. Those are good points. I was thinking of the 2.5m Kontainers as dockable sky-cranable units (use the adapters and wheels to dock, move to the crane) rather than as long-term storage, but the ISM is a good idea. I'll poke at that idea a bit.
-
Thank you for this set, it's turning into one of my favorites. Sympathies about the lost work - I've been there.
I would like to request a small part, if there is broader interest - an adapter from a KPBS element to a 2.5m UKS Kontainer (I suppose this could go to to @Roverdude as well). The nodes on the garage adapter appear to be almost exactly right - it needs to be raised just a hair so the bottoms align, but the part would terminate instead into a Kontainer shaped octagon. This would allow us to shove either a pair of planetary adapters and wheels to move it around a dock it to a base, or a pair of Meerkats and land it.
-
On July 4, 2016 at 0:50 PM, the_Demongod said:
I don't understand how all these ridiculously long burns are possible, how can you have a burn that's longer than the orbital period? Don't you just end up going in a big spiral (if you point prograde) or reentering the atmosphere? On tiny stock Kerbin, even an 8 minute burn starts to push you into the atmosphere unless you break it up into multiple peri kicks...
If you are doing asteroid captures, with good planning you'll intercept it near Kerbin SOI which will have an orbital period of about 20 days, and if you are trying to raise its periapsis, your job is to increase that orbital period so you may be buying orbital time faster than it takes to make it. Even with my horrific mass mismatch, I was able to increase orbital period by more than a minute per minute. If you are doing a slow burn to Eeloo, you're probably looking at a 3 year transit time, so plenty of time for long burns.
-
The cost/benefit crossover is pretty high, so if you are trying to break-even on fuel, you need to chase class Es and you need to focus on minimizing TWR and maximizing ISP. If you can push it into orbit in counts in terms of minutes, you've overbuilt. If it takes hours or days, you're more on track.
Just Jims 3700t asteroid which is 80% ore will yield about 2,960t of ore or 5,920,000 units of lf+ox. An orange tank is 4t and 6400 lf+ox, so his asteroid should push out about 925 orange tanks of fuel. Even a low-efficiency rocket should be able to put that in orbit for no more than dozens of orange tanks. Move it with a few Nervs or even higher ISP engines and keep your ship down to no more than a few % of the size of the asteroid and it should be well profitable. -
Didn't take much patience as I was asleep. But I have some experience with patient gaming.
-
21 minutes ago, purpleivan said:
I had some seriously long burns flying this thing.
It was for the How fast can you make a ship go. As I remember one of the stages took 3 hours to consume all its fuel and as the intention was to get the vehicle up to the highest speed possible (I got up to 90877.7m/s while flying really close to the sun) while zooming in towards Kerbol, then there was no practical limit on how long the burns could take.
Way back in the day we had a 'how fast can you hit the surface of Kerbin' challenge and sent a pretty similar ion powered ship up with 40K or so ISP, reached a solar orbit, then reversed course into a retrograde orbit and hit Kerbin head-on at ~20K m/s (I think it was 22K). There was no heating yet, so no chance of burnup, but the atmosphere did slow me down remarkably well. I think it was a 12 hour burn or maybe more.
With a more reasonable sized ship, pushing that 4megaton asteroid I indicated above into a sungrazer orbit would get some absurd speeds since you can mine it continuously for fuel for the entire multi-week burn. Hmm...
-
I've been doing 24-32 hour long burns the last few nights, trying to move a 4.5 million ton class E asteroid into a aerobrake orbit using an entirely too small tug with 4xLV-N engines.
Set up the attitude with MechJeb, tune the fuel rate to the ISRU rate so it doesn't run out, physics warp 4, and go to bed. It's working - changed inclination 20 degrees and periapsis by 50km. At that rate I should have no problem pulling it into the desired orbit while only consuming about 0.05% of the recoverable resources from the asteroid - though it'd take an additional 16 days of continuous burning.
And with that demonstrated tonight I'll hyperwarp it into the desired aerobrake orbit so I can get on with things. The final post-aerobrake maneuver should only take about 4 hours (1 hour warped).
-
No, it's really 4,500,000t. That's a 75t tug attached to it - gigantor solar panels and 4x LV-N in a puller configuration. PPD-1 Heavy Command module (3.75m) with a single engineer onboard to increase mining speed and to do some necessary KAS reconfiguration.
I had theorized that when they fixed the 150t bug, they accidentally changed the upper bound from 150t to 5,000kg but accidentally made it 5,000t (or some such), but no, it's ART doing it. So, install ART and haul the Death Star around.
-
Ah, figured it out. I had installed USI-Asteroid Recycling Technologies without remembering it (CKAN be too easy sometimes) and apparently along the way RoverDude added a feature that increases the size and mass of asteroids, something I didn't realize was so easy:
@PART:HAS[@MODULE[ModuleAsteroid]] { @MODULE[ModuleAsteroid] { @density *= 33.3333333333333 // Stock asteroids will have density of 1.0 maxRadiusMultiplier = 5.0 //Default is 1.25 so up to four times larger } @density *= 33.3333333333333 // Stock asteroids will have density of 1.0 }So, my nearly 100m asteroid is 4x larger than stock and 33x more dense. So if you want supermassive asteroids, there you go. Might be contributing to my physics glitches as well.
-
Hmm. Getting back into KSP after a while. On 1.1.3 I just started a mission to recover a Class E. It's just shy of 100m in radius and weighs north of 4 million tons. Needless to say, it's a bit of a bear to move and seems to glitch physics from time to time (stops rotation as if it's anchored to the universe - but orbit still works).
I can very slowly move it with 4 LV-Ns, and it will take me around 50 years to mine out, but if my math is correct I can get it into a aerobraking orbit before impact in 26 days, but it requires continuous burning for around 20 days. I have a TWR of 0.0 and 0.0 delta-v (was 4,000 for a 75t ship prior to docking). The upside is that COM misalignment is barely an issue because of the mass imbalance.
I don't recall them being so large. I wonder if the 150t bugfix caused Squad to miss a unit conversion in there and cause my 4,000,000 kg asteroid (4,000t) to be 1000x heavier than intended. Haven't seen any other reports of supermassive asteroids, though.
-
I'm up-to-date per CKAN. Not sure what else to offer in this case, unfortunately. I'll do a bit more testing to try and reproduce, but removing Field Research eliminated the problem completely.
-
I just ran into a performance issue with this mod that cleared up the moment I removed it:
http://forum.kerbalspaceprogram.com/threads/125411-Stuttering-and-Log-Spam?p=2017802#post2017802
Can you check to see if there's some spurious debugging or file reading going on? I don't know if it'd be in Field Research directly, or triggering something in CC. I've got a pile of other CC mods installed and they're working fine. It seems to be localized to this one for some reason.
I did have an active Field Research contract at the time - surface sample on Mun, IIRC.
-
Yeah, it looks like a mod was the cause. I had installed (and forgotten I installed) ContractConfigurator-FieldResearch right before the problem started. I'll follow up directly with the author.
Because there was no mod tag on the log entries, I had assumed it was KSP core doing this. Apparently not. So kids, keep track of your mod installations so you can unwind them one-by-one when problems arise.
- - - Updated - - -
I'm not sure if this is related but there are a group of us who suffer from stuttering issue that is caused by the GC, but it's not as frequent as once a second, more like once in 10-15 seconds.Thanks. I think I have it sorted, but I'll keep an eye on that thread as well. Good reference for anyone who stumbles on this thread first.
-
I'm suddenly getting this performance stuttering in-game. About once a second or so it stutters for a physics tick or two. I'm fine on RAM, etc. but my logs are now getting spammed with information like this:
[LOG 10:31:06.728] Parsing bool
[LOG 10:31:06.728] Parsing bool
[LOG 10:31:06.728] Parsing int
[LOG 10:31:06.728] Parsing bool
[LOG 10:31:06.728] Parsing bool
[LOG 10:31:07.127] Parsing int
[LOG 10:31:07.127] Parsing bool
[LOG 10:31:07.128] Parsing bool
[LOG 10:31:07.128] Parsing bool
[LOG 10:31:07.128] Parsing bool
[LOG 10:31:07.128] Parsing bool
[LOG 10:31:07.128] Parsing bool
[LOG 10:31:07.128] Parsing bool
[LOG 10:31:07.128] Parsing intWhich I suspect is related to the problem, since I never saw that in my log before. It's suspiciously unhelpful, which makes me think I accidentally hit some hotkey that means 'dump useless information to the log'. I don't think it's mod related since there's no tag for a mod on the log entry.
Any thoughts?
[1.12.3] Restock - Revamping KSP's art (Feb 25)
in KSP1 Mod Releases
Posted
Congrats all. I can attest to the hard work these folks are putting in.
- @cineboxandrew's dad.