Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    KJR v2.2 is not backwards compatible. You need KJR v2.1 if you're running KSP 0.23 and not KSP 0.23.5. Get it from the mediafire folder linked in the first post of this thread.
  2. ferram4
    Alright, I've updated to version 0.13 which includes a lot of optimizations from a.g. that were in the experimental, some big changes to profile drag of regular bodies that were in the experimental, special handling for asteroids so that they work properly, and making the reference geometry used for aerodynamics change with animations. Also updated to Toolbar v1.7.1 for anyone having glitches there. It's still using the old attach node code, since the new version is very glitchy for now, as well as being really expensive to run; the methods are in the source, though, so anyone how wants to play with them can find them in FARBasicDragModel. Hopefully that will be ready for v0.13.1. Anyway, along with trying to get the attach node drag update into the next version I'll also look into adding an API and Dirt_Merchant's "dumb" control surfaces as well.
  3. ferram4
    For all the people have problems with mod parts, if the mods don't have attach nodes set to the correct sizes and don't have masses similar to the stock parts they will behave poorly. There is nothing I can do about mod incompatibilities with the new joint system.
  4. ferram4
    They're based on KSP stock planets, though those are informed by real life. Kerbin has Earth-like properties, Eve and Duna both share a similar composition (90% CO2 and mostly N2, plus some trace Ar) based Mars mostly, but also looking at Venus. Jool uses Jupiter's with as much He cut in as I could (10%) because it made the density so low compared to the pressure. Laythe has an oxygenated atmosphere, but it's mixed with CO2, SO2 and some other nasty things to simulate a sort of volcanic environment with life somewhere on it to keep O2 in the atmosphere. I thought that would be more fun. All the numbers are exposed in the config file, you just need to keep track of which body is which, since it goes by number.
  5. ferram4
    The fix for those small issues is to patiently wait until I get the next experimental out, since it involves a pretty big feature to handle the blunt drag of attach node things better. Unfortunately, currently it really makes the game chug when parts stage, so that needs to be fixed first.
  6. ferram4
    @Solestis: Read the previous page, or perhaps read the bottom of the first post and look in the readme. The way to get back to those somewhat cheaty levels of strength are shown, they're just disabled by default now. @cheshirejak: That would be because you used the old version, which isn't compatible with the update. The new version is.
  7. ferram4
    Well, so long as the parts have the proper size attach nodes the stock changes will benefit them quite well. Otherwise they'll still need KJR for now.
  8. ferram4
    As a note, any part pack where the attach nodes aren't sized correctly for the parts will have weaker joints then they should. One of the changes includes using 3 joints instead of 1 for connections using size 2 or greater nodes, and larger nodes put the joints further part, making them stiffer. So mods with improper node sizing will be wobbly still.
  9. ferram4
    You could use the old config, it should still work. Though if you absolutely need that and you're playing stock your rockets shouldn't fly to begin with. The inertia tensor fix has been removed from KJR entirely because it got put in the stock game as part of their joint fixing.
  10. ferram4
    Yes. That's why it's a config file rather than something hardcoded.
  11. ferram4
    The version 2.2 update is out, with compatibility for KSP 0.23.5. The inertia tensor fix has been removed, and most of the original stuff (while it has been set up to work) is currently disabled in the default config because most of it isn't needed anymore. I suspect that this plugin will end up returning to its original purpose: making RSS playable, and probably of little use to stock KSP. I also added some stuff that I think should fix the indestructo-bounce bug, if it's happening where I think it's happening.
  12. ferram4
    Okay, I think I might know what's going wrong here; it's being pulled in and out of timewarp and KJR isn't turning off the physics load strengthening properly. I'll make sure it does that when I get things together for the next release.
  13. ferram4
    @mentat001: Nope, splat + explosion on my end. Try reinstalling KJR and see if that fixes it. There has to be something else going on. Anyone else making this bug report, I want you to strip out every other mod that you're using, reproduce the issue with only KJR installed, and then follow the same exact steps and fail to reproduce the issue without KJR. Every test that I've done has resulted in no bouncing, only destruction of the vehicle (at speeds at and below those reported for indestructo-bouncing) on impact, exactly in contradiction to all these reports. This means that either another mod is interfering with KJR to cause the bug (in which case I can come up with a fix), another mod alone is the source of the bug (in which case there's nothing I can do), or the reproduction steps are missing some crucial detail. An ideal bug report would include a craft file (using only stock parts) along with a video recording of the entire flight from launch until bounce, so that everything that's done is documented so that I can make sure not to miss anything. For completeness, please also include your system specs and game settings (all of them from the general and graphics tabs) so that I can make sure that this isn't caused by the way physics is behaving on some hardware / settings. I'm sorry this is so frustrating. Thanks for putting up with it so far.
  14. ferram4
    There's nothing you can change to affect that without making other connections stronger as well. Docking port connections are intentionally weaker because, well, they're docking ports, not welded / bolted joints. If you insist on beefing everything up, you might want to look at the linear and angular drive parameters. Increasing those will do what you want or will summon the Kraken.
  15. ferram4
    What you're describing doesn't sound like something that KJR causes, it sounds more like what happens when a craft has its physics stopped by the game because it gets too far away from the vessel. And if it depends on the ground where you land, then that certainly isn't the issue everyone seems to be complaining about, since you're carefully selecting a landing location to prevent destruction. And I couldn't reproduce it either, every stage just exploded on impact.
  16. ferram4
    Fewer struts, better placement of launch clamps, use the lowest profile, widest surface decouplers you can use. It sounds more like you've overconstrained the part rather than the part failing itself. Make sure that something else on the rocket isn't shifting and causing a sudden application of force to one of the boosters.
  17. ferram4
    I attempted building a lander and following your steps but I was unable to reproduce the issue. Every single time the lander simply exploded on contact with the ground at ~190 m/s, regardless of the angle or whether landing legs were deployed or not, all being dropped from an altitude above 2.5km. There must be a step missing somewhere, since the landers are most definitely not indestructible in my tests.
  18. ferram4
    Can you actually reproduce the issue reliably? A few other people have reported that, but no one has been able to provide reproduction steps, so I'm not sure if it's KJR or something else. Even if it is KJR, without reproduction steps I can't track down what's going wrong.
  19. ferram4
    This is incorrect, at least for FAR. FAR correctly calculates the air density based on atmospheric pressure, atmospheric temperature and atmospheric composition (specified in the FAR config file). The only things that still use the weird density = pressure * constant in FAR are the few things that haven't had their aerodynamic properties changed. Making that change will actually make aerodynamics behave less realistically as a consequence.
  20. ferram4
    @ialdabaoth: Unfortunately, it won't. There's really not much to do there besides defining custom drag parameters for those parts since they violate the assumptions used by FAR's geometry determination. The old "primitive" based code was removed a long, long time ago, back when I shifted over to much more exact measurements, and those methods weren't very good anyway. I suppose it's possible to set something up to take a primitive and work with it, but the problem is that I'd rather try to handle it in code rather than in configs; when FAR doesn't handle things automatically part modders get inundated with requests for FAR configs (as Helldiver and Nazari have been regarding the KSO), which they won't understand and don't want to mess with, or it gets given to me, and now I'm trying to make sense of someone else's parts and trying to figure out the best approximation to use on them. It's really not fun for anyone involved, and I've been trying to figure out a good algorithm to get rid of FAR's current dependence on config stuff for wings; I don't want to add more config dependency for regular parts as well.
  21. ferram4
    It's a typo in the config, the turbojet doesn't run out of thrust like it should with FAR installed; the fix is to go into the FAR config and change the curve so that the last "key" entry looks like this: key = blah, blah, blah As opposed to this: @key,4 = blah, blah, blah Second, this seems to be placed in the wrong forum, since it's not about a craft at all, but instead about a mod behavior; it's kind of messed up to hide it here, because if this actually was an unknown bug then I wouldn't have come across it except for the rare times that this thread appears in the most recent post section of the main forum page. You basically managed to place a bug report in the one place where it would only be seen by the mod author by sheer luck, making the odds of it getting fixed (if it weren't already known) very slim.
  22. ferram4
    @Subcidal: Just checked in my current version and didn't see anything like that, so I don't know what the cause could be. @ialdabaoth: I'm sure, but the problem is that the way FAR currently handles drag doesn't work so well for heating at all; it has nothing that would allow it to determine that it should add heating to only the heat shield and none of the parts behind it. As for the way FAR currently determines shape and surface area, it takes the part's mesh and then assumes that it's some type of frustum of a cone. It takes a pretty good educated guess as to the axis, and then it determines the distances across the object perpendicular to that at either end. It averages them to come up with an approximate circular cross section to refer to and stores a ratio between the two axes for use handling body lift and drag. The tapering of the frustum is stored so that drag properties can be calculated from that and the surface area is calculated as the rounded area of the shape, ignoring the bases. It works quite well for most parts, actually. @Motokid600: Two rockets will only have the same ascent profile if and only if these things are the same between them: TWR as a function of time (not just at launch) DragArea:Mass as a function of time Obviously, a rocket with a TWR that stays at 2 for the entire launch will have a much different ascent profile than one that starts at 2 and then reaches 6 before dropping down to 0.8, which then grows back to 1.5. It just sounds like you're not burning off mass at the same rate that you're used to, so the TWR isn't increasing like you think it should, so trouble. More massive rockets aren't as affected by drag, since mass goes with length3 but drag goes with length2, so gravity easily overpowers drag at higher masses.
  23. ferram4
    @ialdabaoth: I see what you're after here... so for the first problem you're looking at heat transfer through a boundary layer in both subsonic and supersonic flows (very complicated, but I think something can be worked out), which means that I'll need to drag out a lot of textbooks and probably come up with some kind of correlation for that. The second problem is a little bit simpler, since conduction is a little bit simpler of a problem than convecting fluid flow. I figure I'll work out the math needed for the average temperature in the part and the peak temperature in the part, and you can use either of those for your purposes. I'll PM you when I have something that I think might work. @JewelShisen: I can take a look at that, but given that his parts are quite a bit different than the standard types of parts that come with the game I don't think FAR will ever be able to properly support that. They end up violating quite a few of the assumptions that FAR uses, and that basically means that everything will be wrong for them. @Dirt_Merchant: Unfortunately, I don't think that the old method is compatible at all with the current tweakables set up, and pretty much anything you could do with the old setup you can do with the current one (except perhaps very large negative deflections), and there are several things that you couldn't do, like combining flap and control surface actions. I haven't set something up for changing the zero-point of the control surface (that's still to be done) but I will see if I can set up split-aileron stuff. I'll see if I can find a way to make it useful in both pitch and roll as well, this way it can be used for that too (for madmen). @skiingrules88: If you installed according to the instructions (moved everything over to the GameData folder), so that you have the Toolbar and FAR folders in there along with ModuleManager in the directory everything should work fine. The Toolbar should load up in the VAB / SPH and the flight scene with a FAR button and FAR's drag properties should be applied to your vehicles (right-click a part to see if it has a drag force readout). If that's not happening, I'll need you to post a full copy of the output_log.txt from KSP_Data so that I can figure out what the error is. @Narcan: This is a partless plugin; it only changes aerodynamics, it includes no parts.
  24. ferram4
    You have 100 physics frames (~1.5 seconds) of no control while physics stabilizes; this is because the vehicle is completely indestructible during that time to prevent physics glitches when coming out of timewarp from causing large enough forces to destroy the vehicle. That physics easing was originally added due to bugs where people's crafts would explode coming out of warp, but now it also makes things easier when the ship first loads on the pad / ground. It's nowhere near as long as you think it is, and it's probably going to be reduced for the next update. You don't get any control because letting the player have an invincible vehicle under their control is easily abuse-able.
  25. ferram4
    I know what you're talking about, but it's not physics torque being clamped to "7" it's angular velocity. Physics engines have an upper limit on angular velocity because fast-rotating rigid bodies can cause very weird things to happen; they can easily spin fast enough that they can clip through other bodies, the terrain, the player, etc. and when this is finally detected they tend to shoot objects off at ridiculous velocities. Obviously, these are all things to be avoided if possible. So at a certain point, when the object is spinning too fast you stop adding angular velocity to it. But the problem with this is that it violates conservation of momentum and conservation of energy, which can cause very... strange things to happen in-game; things that can be picked up on by players. So instead, why not try something like clamping torques down to whatever would be necessary to keep the angular velocities below the limit? That would easily solve the conservation issues, but now all of your torques are limited by the inertia of your objects. An alternative is to take advantage of the iterative nature of the physics solver: it's not like it goes through the approximations to the equations once per frame, it does multiple iterations to increase accuracy, eventually converging to an answer; why not clamp angular velocities at the end of each iteration, to try and solve away the conservation issues? It really depends on what happens under the hood in PhysX (which I have no idea what's going on there specifically), but what was happening was that the physics engine was clamping the angular velocities to very, very low numbers, that in turn was causing torques applied to parts to be much lower than they should be (or) parts not responding properly to the torques applied to them, so wobble. As an aside, I think the "7" is 7 rad/s, since I spun up a ship as fast as possible in game and it seemed to manage a little over 1 revolution a second, which is a little over 2pi rad/s, so about 7 rad/s seems right. KJR will probably continue on in some form after the official release; it has some workarounds for bugs in the launch clamps, some physics easing abilities that make sending large rockets to the pad easier (even if it's harder to launch them) and the original functions may still be necessary for Real Solar System, where things are a lot more complicated.
×
×
  • Create New...