NonWonderDog
-
Posts
116 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by NonWonderDog
-
-
Version 7.2.1 seems to be disallowing simulations unless you can afford to buy two of the rocket you want to simulate. Is this intentional?
-
I've gotten to the point where I'm pretty happy with this. It's gone from intriguing but unbearably hideous to pretty much indispensable to me now. At least, that is, until I find another planet I can't stand.
The cape is a lighter color in stock because the grass color is blended with sand. Adding noise makes it a bit like scrubland instead, but I wanted to at least try to match the altitude texture:
Javascript is disabled. View full album
This is mostly untested, so there might be some oddities around. I haven't taken a look at the island runway, either. Feel free to do whatever you want with this:
EDIT: Actually, it didn't occur to me to change the altitudeBlend in PQSLandControl. That would probably smooth out the color around KSC.
-
No idea, but an exponential curve wasn't really good enough. Here's the result of tweaking the heightmap manually. This is with almost all the random terrain noise turned off:
Javascript is disabled. View full album
-
The solution is not to be found in heightmaps, since the default heightmap, at 2048 pixels wide, yields a resolution of 1 pixel = about 12km x 12km. Even an 8192 heightmap would only yield a resolution of 3km x 3km per pixel.
Instead, you need to play with the procedural PQSMods; they are the ones that do finer detail; heck, if you set the frequency high enough you'll have significant height variation meter-to-meter.
That said, if you want to export the final map that combines all the PQSMods (the heightmap and all the procedural height modifiers) you can use the Export node in the RealSolarSystem.cfg file.
I don't know. It's not so much the frequency of vertical variation (as you said, that's what the noise generators are for), but the amount of vertical resolution that's bothersome with PQSMod_VertexHeightMap tuned upwards. On 1x scale Kerbin everything below 28 on the height map (I think?) is underwater, but the coastline is at 70. The beaches are already unreasonably steep, and if we want taller mountains on 6.4x Kerbin, it doesn't make sense to me that we'd also want even steeper beaches. I'm going to see if I can get anywhere by making the grasslands lower.
I was able to get an almost perfect height map by doing an export with "heightMapOffset = 0" and "heightMapDeformity = 255", though, thanks. Turning the radius down to stock helped to get a height map of the cape, too, although I have no idea what the stock settings for PQSMod_MapDecalTangent would be. A RealSolarSystem.cfg for the stock 1x Kerbol system would be very helpful.
Stock Kerbin terrain seems to be 30 (?) meters per pixel value and -850 (?) m at the bottom of what I'm going to call "Great Smile Trench" (pixel value 1), so 1x Kerbin would appear to be "heightMapOffset = -880", "heightMapDeformity = 7650" or thereabouts. If I've understood this properly, to put the highest peak on Kerbin at 9000 meters (a bit taller than Everest) we'd need to scale up by 33%, or to 40 m per pixel value. To keep the same sea level we would need "heightMapOffset = -1200" and "heightMapDeformity = 10200"... except that's not right at all. You need heightMapOffset closer to -1800.
Anyway, I've had massively good results by putting some luminance curves on Kerbin's heightmap. I'm still fiddling with it, but not only does the low-res texture better match the terrain, but you can actually see the mountain range west of KSC starting at 1500 m altitude (Kerbin's horizon distance is still pretty short at 6.4x scale). It actually looks pretty decent with all the random noise turned off, but it will obviously need some added to get some hills back.
The problem I do run into is z-fighting on the beaches. And the buildings at KSC. I think the correct solution for the beaches is to fade the low-res texture in sooner... but it will have to be significantly higher resolution for that.
[EDIT] The actual numbers are heightMapDeformity=5000, heightMapOffset=-1500 for stock Kerbin. The mountains are done with the random noise, which has 4000 deformity.
-
I really want to like this, and I really want to use this, but it's just so ugly.
I think what this really needs is non-linear height scaling. Making everything 1.5x taller doesn't really work, and adding what looks to be a couple kilometers of random noise just makes everything slightly ridiculous. I tried 2x height and less randomness on Kerbin and I suppose it looked slightly better, but the mountains were still just rolling hills at a higher altitude. If it could just put a power law on the height map it would probably be a lot better.
Maybe it's easier just to work with a texture and figure out what all the terrain noise options mean. What would I have to do to get a high-res image of the default terrain?
-
Honestly I just do this and am happier:
@PART[*]:HAS[#PhysicsSignificance[1]]:FINAL
{
@PhysicsSignificance = 0
}No problems so far, but on a fast-ish desktop.
You can also give landing gear mass with Firespitter:
@PART[SmallGearBay]:FINAL {
// If it's going to have a mass, it should be much lower
@mass = 0.075
// Replace the main landing gear module
@MODULE[ModuleLandingGear] {
@name = FSwheel
hasMotor = false
motorEnabled = false
deployedDrag = 0.4
}
// also make the landing light draw power
@MODULE[ModuleLight] {
%resourceAmount = 0.04
%useResources = true
}
} -
Yes – you can modify them by adding (+=) or multiplying (*=) the original value by a constant. There's also a regex replacement syntax. See the wiki section on Edit for more information.
There seems to be a key feature missing, though. You can make a copy of "maxThrust" and double the value, but you can't then rename the result to "heatProduction". Unless there's something I'm missing?
So maybe this is a feature request for a variable assignment operator:
@MODULE[ModuleEngines] {
// make 'heatProduction' equal to twice 'maxThrust'
@heatProduction <= maxThrust
@heatProduction *= 2
}And if I were really greedy, perhaps global variables and simple operations?
@MODULE[ModuleEngines],1 {
&tempHeat <= maxThrust
&tempHeat *= 2
@PROPELLANT[Oxidizer] {
&tempHeat *= ratio
}
}
@MODULE[ModuleEngines],2 {
@heatProduction <= &tempHeat
}I think that and a bit of cleverness would allow any math people anyone would reasonably want to do. With clever enough use of regexes it might even turn out to be Turing complete. (No, wait, we'd still need a way to make a loop...)
-
The avionics ring is just really finicky to snap on properly. It seems to want to snap the heat shield to the bottom node instead of the top node, and everything looks like it goes together fine until you try to decouple it. I don't know if there's a way to fix that in the model or config, but just make sure it's not clipping when you snap it on.
-
First you should always ignore what 'stats' tell you because ksp is full of lies. Second, in my dictionary 'absurd' means unreal and against physics. RF and KSPI's definition is 1 EC = 1 kJ. So you know how absurd it is to fly with 3000 EC. Tesla roadster has 200,000 EC
It's just that it looks like the motor from the Sunseeker, and the newest biggest one has 25 kW max output (the original was around 3 kW I think). No one has ever put a 200 kW motor on a plane--certainly not a solar-powered plane.
The 15 kW in the SPH would be pretty reasonable (and godawful slow, but reasonable).
The Tesla S might have a 60 kWh battery, but you'd never put that on a solar plane, either. Sunseeker Duo is somewhere around 6-8 kWh (20000-30000 EC) I think, and there really were solar planes in the '90s with 1-3 kWh (3600-10800 EC) batteries.
-
Well, the rev 2.0 spec page 171:
Devices must also ensure that the maximum operating current drawn by a device is one unit load, until configured. Any device that draws power from the bus must be able to detect lack of activity on the bus, enter the Suspend state, and reduce its current consumption from VBUS (refer to Section 7.2.3 and Section 9.2.5.1).One unit load is 100 mA. Section 7.2.3 furthermore goes on to say that you can only draw 500 uA in suspend mode unless you have specifically enumerated as a high-power device that provides wakeup, in which case you're allowed 2.5 mA. Section 9.2.5.1 says that hosts are allowed to veto your power requests (an iPad definitely will).
Of course, the spec is over a thousand pages long. Nobody who makes USB devices actually reads the whole thing, so USB hosts have to deal with a lot. Like devices that draw 550 mA without enumerating, or people who short the data pins together (I think charge-only hosts are the only ones allowed to do that). A lot of desktop PC motherboards just put a resettable fuse across several ports, rate it to a couple amps, and don't even check if devices are drawing the amount of power that they say they are.
So yeah, you can do it, but there's always a chance (a small chance) that your PC has a specification-compliant port -- in which case it won't work. I'd still put a PTC in the circuit so you don't trip the one in your PC when your wiring shorts. Mostly because it will be annoying when your mouse stops working because your hat shorted out, not because you're likely to damage anything.
-
Face tracking is probably good enough for anything you would do in KSP, but if you want to use IR tracking on-the-cheap here are some tips I've picked up:
The absolute best camera for this is a Playstation Eye. It's high resolution, high frame rate, and you can get it for $12. The new ones with the big microphone array on top are made for tracking the PS Move and have essentially no IR filtering, so you don't have to make any modifications. You do have to add a visible-light filter, but that's REALLY easy. Get a 10 cent pair of cardboard red-cyan anaglyph glasses and fold them in half. It's probably the best filter you can get without paying for professional photo gels, and it's leagues better than overexposed film negative or old floppy disk material.
Make sure you put the camera on its own USB bus (or a USB3 port). Basically just keep plugging into different ports until it works at full speed. That goes for face tracking too.
For IR leds you probably want wide-angle variants. The Osram SFH 485 P is the old recommendation from the FreeTrack forums. You can get a bunch of them and whatever resistors you need from Digikey or something similar for a couple bucks. If you're brave you can power your LEDs from USB, but you'll probably want to put a resettable fuse in the circuit. You'll also supposed to declare any USB power draw on the bus and support USB sleep if you do that, but desktop PCs don't usually care as long as it's well under 100 mA. Laptops I'm not sure about.
I sewed three SFH 485 P into a baseball cap with a pair of AA batteries in the back, but I'm not sure I'd do that if I was doing this again. I had to cut the bill of the cap down to about 2" before I could look down comfortably, and that put the LED plane too close to vertical. (The LED plane shouldn't be allowed to go perpendicular to the camera, or there's a good possibility of losing tracking.)
I also just found a break in my cap wiring somewhere that makes the LEDs turn off whenever I put it on... and come back on whenever I take it off... so I haven't tested it with this mod yet.
I've been using OpenTrack (on Windows) since it's in active development and works better than FaceTrackNoIR with the PointTracker (make sure to turn "Dynamic Pose Resolution" on), but I can't tell you if it works with KerbTrack yet.
-
Sorry if this has been answered already somewhere in these 37 pages
I just installed FAR, and it comes with a ridiculously huge plane called FAR Dark Hammer II. I tried to fly it, but it seems completely unable to do anything but crash into the ocean (or the ground before the ocean). Is there a trick to getting this thing to fly?
Pull straight up off the runway and go as vertical as you can. The wings don't help much when it's full of fuel, but it will put a decent amount in orbit if you get it right. I had to fiddle with the control surfaces to get enough authority, though.
Hopefully you've got a fuel depot in orbit or something, because I remember it being hard to land unless the tanks are nearly empty.
-
There's also the fact that KW Rocketry doesn't have the proper AttachNode sizes on its parts, making the drag forces lower than they should be, which would be helping to reduce the drag on the engine for this rocket.
What are you assuming the maximum AttachNode size is? I found an old post by Harv that said the size ranged from 0-5, so I edited my KW configs to give the 2.5-meter parts size 2 nodes and the 3.75-meter parts size 3 nodes. Everything looks proper in the editor, and size 3 nodes are bigger than size 2.
It had the opposite effect to what I expected on the aerodynamics. The center of pressure moved way far forward on all my real-life rocket replicas, and made my Delta IV Heavy and Atlas V HLV inspired designs unstable with no payload (even with no fairing drag!). Is this the same attachNode bug DauntingFlyer found, or is FAR assuming that the node size only goes up to 2 like it says on the wiki?
[EDIT] ...Or maybe that was some other display bug. It's not doing it any more. In fact the CoL doesn't move at all when I change the node sizes. I'm now confused.
-
If your payload can't fit in a fairing, build it in orbit out of pieces that can. Like a real space program. Read up on what gravity turn actually means and try to get to orbit at a maximum of 1-2 degrees angle of attack the whole way to orbit after pitchover at 500 meters or so.
Or you can always build a tractor rocket. build a cradle for your draggy payload and stick rockets around the side of it so that the center of mass is in front of the center of pressure. It takes a lot more impulse, but it works.
Here's a UFO with a frameshift drive lifted to orbit using that principle. It's made almost entirely of stalled wing sections, so the drag is insane, but the lifter was completely stable. (Sorry, ferram4 -- this probably wasn't what you had in mind with this mod. I can post more EELV replicas as penance if you want.)
-
In 0.9.2 it disintegrates at more than 3 degrees angle of attack, though, which seems fine enough to me. The major problem wasn't so much going Mach 8, since I expect there'll always be a way to break it like that. The bigger problem was the way the 8 ton upper stage with 200 kN thrust could push itself faster against the wind than the ~40 ton half-empty core booster with 1300 kN thrust when they both had the same cross-section. That would mean the skin friction is greater than the pressure drag, which definitely shouldn't be the case at Mach 8.
Running the static analysis with a fairing installed gives me "[Exception]: NullReferenceException: Object reference not set to an instance of an object." Flying a rocket with a fairing floods the log with that message. With all the fairing bits removed I don't get those messages.
-
We've definitely had a bit of a regression as far as fairing are concerned. They seemed to be generating more drag than what they were shielding before, but now I can do this:
It reached a terminal velocity of around 2.5 km/s. The second stage was much lighter and had much less thrust, but since it only had a short fuel tank and an engine outside of the fairing it went even faster. After separating the fairing the payload immediately pancaked and exploded due to the sudden drag forces, but the fairing went on to do this:
It accelerated all the way to splashdown. Version 0.9.3 seems to have removed all drag from fairings.
-
So I've noticed that my fairings from fairing factory have essentially zero drag in atmosphere after being ejected from my rocket. I followed one as it hit the ground at well over a kilometer per second, accelerating the whole way. If that's as far as it goes it's not a big deal, as it would only really affect the way they separate. What I can't tell is if they're behaving properly when still on my rocket.
The static analysis graphs also now fail to run (as of 0.9.3) if any fairing or cargo bay is present on a craft.
-
A bit of a bug report here. [DISREGARD -- FIXED IN 0.9.3]
Behold, the Kappa II 7320-9.5:
And here is is without the fairing -- I've used a few fuel tanks as payload:
Clearly, there's something wrong here. I'm sure the weight distribution is nothing like the real rocket (it's six meters shorter, after all), but that isn't the issue -- it's stable without the fairing, but adding the fairing makes it horrifically unstable. I've tested this in flight, too. With the fairing it flips pretty early in flight and there's not much I can do about it. Without the fairing it's one of the most stable rockets I've flown -- much more stable than that CoL marker would suggest.
After taking this screenshot I added "fairing" to the name of the 2.5 m interstage from KW, but it didn't actually help. It shielded the second stage engine and fuel tanks, but that didn't make much of a difference.
Using the 2.5 m KW fairing pieces with my fairing base had much the same effect, so I'm not sure it's just the slightly increased diameter of the fairing. The only slightly weird thing I've done is to make a copy of the KW fairing base, remove the decoupler effect, remove the normal attachment points, and add attachment points for Fairing Factory fairings. Is there anything special about the way FAR treats fairing bases that I should know?
Also, the CoL seems to move around a lot in the VAB. The second picture was taken after launching the rocket and reloading it in the VAB. If I just take the fairing off without doing that, the CoL is much further down the rocket.
EDIT: Ah, sorry, this was in 0.9.2. I'll update to 0.9.3 and see if it changes anything.
EDIT2: Totally fixed in 0.9.3. Without the fairing the CoL is right on top of the CoM. With the fairing it's far behind it. I guess you were ahead of me there.
There's only one remaining issue: removing the fairing doesn't update the CoL marker. I had to launch->end flight before it updated. The "update CoL" button on the graph doesn't seem to do anything. Undo still breaks the button that hides the graph, too.
EDIT3: Actually, it went too far in 0.9.3 -- fairings contribute no drag whatsoever!
-
Tested it again with a very simple plane, and it looks like it's just the GUI that isn't working. It seems to fly properly and add "isShielded" to each part when relying on the automatic behavior; it just doesn't load the GUI. I got rid of all my compatibility edits when I read that line in the readme, but it looks like I'll add them back in until the GUI works.
It looks like my biggest plane isn't really flyable any more with the latest update, though. I guess I'd misinterpreted that because the GUI was missing. It has barely enough lift as is and had kind of a biplane configuration to try to simulate a lifting body, so I guess I'm not surprised.
-
The new readme says "FAR Control Sys module automatically applied to all command pods." How is this supposed to work? It doesn't seem to add the control system to the Mk3 cockpit at least if it isn't in the part config.
-
So I found an issue, but I don't know if it's something fixable:
The big satellite dish has a huge radius, but it folds up to be pretty small. It folds up small enough to fit inside a cargo bay on a SSTO. Unfortunately, the game thinks it needs as much room as if it was unfolded, so my 120 ton spaceplane starts off five feet above the runway. That doesn't work very well.
I haven't noticed that with other animated parts, but maybe I just haven't looked closely enough.
-
can you not use such absurdly large gimbal values for your engines? It\'s not really a complaint but the ASAS modules always moves them between their max and minimum gimbal values and I\'ve had craft shake themselves apart because of it.
edit: its mainly on the smaller engines, like the 2m and below.
That\'s really just a problem with ASAS. For reference, the space shuttle main engines have a gimbal range of +/- 8.5 to 10.5 degrees. The five F-1 engines at the first stage of the Saturn V moved +/- 6 degrees. Even the space shuttle solid rocket boosters can move +/- 5 degrees. Obviously you\'d hope never to have to use that much gimbal range on any of them, but it\'s there (and the SSMEs kind of looked like they were on the stops during both roll maneuvers, even though the SRBs did most of the work on the first one).
Even though its all you usually need, I\'d really rather the gimbal ranges weren\'t set to 2 degrees. The emergency steering range is good to have.
-
So it turns out that the hard part of this challenge isn\'t building the rocket, but flying the monster you have created.
So far, I haven\'t been able to control a single stage spacecraft well enough to put it into an efficient pair of transfer orbits to and from the Mun. Landing when main engine gimbaling is your only source of control is its own adventure as well. Putting enough fuel on the ship is by no means the challenge, however.
I\'m sure one of you is a better pilot than I am!
-
Get to the Mun, with one rule: everything that starts on your ship must stay on your ship.
Bonus points for orbiting and returning. Massive bonus points for landing. Godlike status for landing, taking off again, and making it back to Kerbin.
The bonus challenges will almost certainly require mod parts. Fair parts, even very large ones (KW Challenger, Down Under) are allowed. Or try to do it with Silisko Edition for laughs.
Here\'s my entry: single stage to Munar orbit with stock parts.
Who here will be the first to land?
[Stopped] 6.4x Kerbol System v2.0.1 - RSS Config [11/16/14]
in KSP1 Mod Releases
Posted · Edited by NonWonderDog
That peak west of KSC is 9100 m tall? Oops. I think I'm okay with it, though. I'm pretty sure the config has the snow line fading in between 5600 and 6400 meters (a mistake global warming), but that might depend on latitude or might be before the mountain noise generator. There's snow on the mountains near Kermansberg and hopefully everywhere there's snow on the high-altitude texture.
The tallest point on Kerbin should be 8375 m... +/- 4000 m. The peak west of KSC is 6855 m on the heightmap, but has a massive random mountain on top of the mountain.
I don't think we really needed the 2x global terrain scalar, but this way pretty much every point on Kerbin has a scenic mountain view.
Hey, that's really nice. That's probably the best Delta-V map I've seen, even if some of the numbers are a bit scary. I might have to wait for Ferram's update to gas giant atmospheres in DeadlyReentry before I go to Jool.