Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    Oh, I see. You're using "surface area" to mean the visible area of the plane from a certain angle (i.e., its area when projected onto a specific plane) rather than the total wetted surface area. Ah, it's a confusion of terms. Which is blatantly obvious, but based on the arguments against box planes, it also follows that biplanes, multiplanes and multiple tails allow the same thing, just only from one axis. Which is the point I'm trying to get people to argue over; the only difference that I've been able to see between the box design and any of the other designs is that the box is like a compact biplane from multiple axes, and if that should be banned, then logically all the other types of biplanes/multiple tail designs should be banned as well for the same violation of lowered projected area (surface area) from a given direction.
  2. ferram4
    ...I have no idea what you mean by this. If you mean projected area, then if we compare your planes to the box-planes that you fought against, the boxes have a larger projected area from the front/back, larger projected area from above/below, and about the same projected area from the side. All of which points to the box-planes being easier to hit than yours, which doesn't seem to be the argument you're making. So basically, you're pushing for a ban on biplanes of all types then? You need to be a lot clearer and straightforward with the rule you want. Except your X-plane doesn't have greater side-surface area because the wing tips aren't appreciably higher than the fuselage, so no, that's not guaranteed, by your own example. And I gather from the vertical tail argument that the sides of the box plane aren't part of the problem, after all, it's necessary for them to be there. If a plane is well designed, it can lose half of its control surfaces and still fly, regardless of its shape. There was a fighter submitted to the WWII BDArmory challenge that looked very much like a P-38 that could lose half of its tail, half of the boom for that side, and continue to fly and still take down other fighters as if it didn't lose anything. It's not something inherent to boxes, it's something inherent to robust, damage-resistant design, which this particular box plane obviously is, while your X-wing obviously isn't.
  3. ferram4
    I gather by "surface area" you mean "projected area"... but under that understanding, wouldn't that ban all multi-planes, including X-wing designs and multiple vertical tails? Both provide the same advantage, that of lower projected area for specific directions for the same lifting area as their monoplane / single vertical tail counterparts. If not, then... what's the crucial, objective difference?
  4. ferram4
    Some points worth noting on the box design compared to the other designs: 1) it had much more lifting area, which would have made it much more maneuverable. 2) it had much more in the way of control surfaces, which would have made it more maneuverable. 3) it appears to have the CoL closer to the CoM, which would have certainly made it more maneuverable. 4) it had 3x as much engine, which would have made all the extra drag from the extra wing area irrelevant. 5) wing area in virtually every direction ensures that it has some extra protection for deflection shots. 6) using multiple parts for the wings ensures that damage at one location doesn't wipe out a large wing part, ensuring that damage is minor. 7) keeping everything close together ensures that for minor damage that doesn't destroy a part, heat can quickly dissipate throughout the vehicle, effectively nullifying all of the damage. It is a well designed vehicle that is clearly optimized wrt stock's aero model and BDArmory's heat-damage model, as well as being able to get guns on target to force the enemy AI to go into evasive maneuvers and become less of a threat. Yes, it's ugly, but when you have that much engine, it's certainly realistic to be that ugly and still fly.
  5. ferram4
    @cantab: Already is an indicator; the various buttons are different colors when you push them down to activate them. If you decide to hide the interface, the results of that are on you; there really isn't a good way to change the icon on the toolbar for both stock and Blizzy's toolbar, so that's not a viable option. @WildLynx: Nope, not adding it. If it's not on by default, it won't get any use. If it's on by default, people will be ticked about everything shutting off when they don't want it to. Finally, I'll never use it, so why should I bother? @Darren9: Is this reproducible in older versions of FAR, or was it introduced by the latest version? @Crzyrndm: So for pWings, it needs to voxelize both colliders and meshes? Dammit, right after I made sure that when meshes and colliders are voxelized separately to deal with the AJ10 Lack made for RO. So the solution right now is to either break compatibility with that, continue to break compatibility with thick pWings, or add some extra convoluted thing to handle both that will just make this even MORE complicated.
  6. ferram4
    @zomos: And as I already stated, I cannot reproduce any issues with just FAR and OPT. This means that any bug is either due to 1) different parts causing the issue that you will not repeat, or 2) another mod interfering, in which case you need to find out and talk to them instead. From all my tests, FAR and OPT play perfectly fine, though their wings lack any config data and so they will not produce wing lift at all. But that's not the issue you're talking about, and so is irrelevant. @p1t1o: FAR is as "finny" a universe as real life once everything else is taken into account. If you have the same amount of thrust vectoring and stability (note: real life rockets are often unstable) as real life, you don't need fins. Pictures dammit, pictures.
  7. ferram4
    Yeah, that all looks correct. The problem is the fins are too small and the rockets are too short for how slow those rockets are going. No hope of making those stable. Vehicles in previous FAR versions didn't handle body lift properly and so were unnaturally stable; perhaps the drag on the front of this is somewhat off, in which case it's less stable than it should be, but most of the instability is due to the lift at the nose which is acting as expected. The absurdly low TWR for a sounding rocket doesn't help. For something that shape you'd be looking for an initial TWR somewhere > 10 so that you fly in the direction you're pointed rather than five degrees to the side. Then you have a hope of it being stable, but it needs more thrust. Look at how the real-life WAC Corporal and Aerobee rockets were set up and flew, then you'll have an idea of what you need to do.
  8. ferram4
    If you're throwing on the smallest, most blunt fairing you can, yes, the payload might be more streamlined, especially if it's a typical KSP payload, since then what you're putting in a fairing doesn't really need the fairing. If you're making a longer, more smoothed out fairing, especially one that isn't significantly wider than the vehicle, then you won't get more drag. If your fairing's radius is twice that of the rest of the rocket (read: you made the stock fairing as wide as you could), you're talking about taking up 4x the area of the rest of the rocket cross-section, which should be a sign that your fairing design is silly and will produce a lot of drag at transonic and supersonic speeds. Finally, stability is not a sign that the fairing is poor at it's job. Its job is to reduce drag and to protect the payload; the engines have enough control authority to keep the rocket on course with thrust vectoring. Extra stability is nice, but a properly designed fairing will probably produce more body lift than the payload will and make the rocket less stable. I guess I'll have to add some extra code to make unstreamlined payloads really come apart at high speeds then just to make things absolutely sure. Pictures are helpful. Pictures tell us if you're doing something reasonable and that there's a bug or if you're doing something really silly.
  9. ferram4
    I understand that you're trying to be helpful, but the problem with any report that includes "I did the absolute same thing and got different results" is that since computers are deterministic, that can't happen in this situation. If this involved multithreading here, I'd see, but this particular situation doesn't, which means that some step is missing. Unfortunately, nearly every bug report that I can't reproduce always involves people leaving out the crucial step in causing it, which puts fixing the bug off for over a month in some cases. It's incredibly frustrating for everyone, which is why I keep asking about that because there has to be something different if I can't reproduce it. Okay, so I made some changes that makes the second plane consistent; although I think it's wrong, apparently my code reports that the stall-at-45-degrees solution is correct (this hints at some errors in the large-sweep lift calculations though, but that's for another fix down the road). The other one, no idea, can't reproduce it. I hope you'll understand if I don't follow up much more on these issues; both look like bugs that run into the legacy wing code, which is slated to be replaced for the next big FAR release, so more time wasted on that means more time until awesome good wing code. Thanks for the report, at least it's consistent again. Anyway, v0.15.5.1 Hayes is out, which has some very nice bugfixes, changelog knows all.
  10. ferram4
    @CrisK: I can reproduce the craft second craft, which I see is a main axis error; I'll look to add something to make it more consistent. Not sure why it's affecting the wings though, but the stall at 20 degrees AoA is correct. Even highly swept delta wings stall at 30-35 degrees, they don't maintain it to 45 degrees, that's just wrong. I can't reproduce any errors with the first craft. "sometimes" is a cop-out reproduction step; you did something different when it loaded broken, what was it? Edit: if this can't be reproduced without pWings, then it's likely a pWings issue and I can't fix anything then. So far I've seen no indication that stock wings show behavior like this, so it's likely a pWings issue then.
  11. ferram4
    @zomos: Well, if it's supposed to be the turboramjet that's the problem, it certainly doesn't seem to be. Can't cause any issues with it. I'd suspect problems with something else breaking and then causing FAR to break once everything else is broken. @cantab: If they're occluded, there are two options: A) main axis error somewhere, but that should be fixed with being occluded when they shouldn't be in the next update. they actually are completely occluded, in which case, intended behavior.
  12. ferram4
    @zomos: 1) OPT does not appear to have any nuclear thermal jet parts, so until you tell me which mod includes that, I can't hope to test what's up with that part. 2) The remaining OPT parts show no issues and I could not reproduce any errors with them. Your reproduction steps are incomplete; provide more complete steps and a problem craft file with no extra mod parts. @CrisK: Here's what you can do: provide reproduction steps that function. Absolutely none of yours have. I covered a plane in BDArmory missles seeking differences after loading and the only difference I found is that I had added enough missiles for them to interfere with the lift on the wing they were mounted under; other than that, nothing. Provide your craft files with every non-necessary mod part removed, and complete and exact reproduction steps. As of right now, I haven't managed to reproduce anything that indicates that there is an issue. @Veeltch: FAR GUI in flight -> Settings -> Dropdown -> AirSpeed Settings
  13. ferram4
    @CrisK: And I am telling you, no I cannot reproduce deploying/undeploying gear changing AoA, and the graphs that you are showing in the latest pictures are correct. I have been unable to create any vehicle that suffers from the issues you describe in the dev build. AFAICT, there are no issues to solve. @123nick: Yes, and I believe them just as much as the people who were saying the original 0.23.5 win64 hack was stable. Those people downplayed and made excuses for any instability, blaming mods for all of it, and I know that the same will occur now. No win64 support from FAR until a confirmed-stable official win64 KSP build exists. @Johnhii: It works perfectly fine assuming you follow the instructions in the message and place the mod directory in the correct place. That's why that message is there; to tell you how to make it work correctly. @zomos: Read the first post; CKAN installs are not supported here thanks to frequent screwups on their part. Go complain to them, not me.
  14. ferram4
    @Gaiiden: Well, I can confirm with the saved craft... do you have any different craft that also exhibit this issue? Do you have any identical craft that don't? Where are they orbiting / what speed are they orbiting at? Edit: nvm, found it. Fixed it. @CrisK: I don't see what bug you're talking about. All the data you're showing shows highly swept wings (with nearly the same, but not identical shapes) having nearly the same, but not identical lift slopes. The lowest manages 25 degrees AoA before stalling; the other 35 degrees. Those are both amazing angles of attack to reach before stalling and are absolutely correct. From what you actually showed (not much) of the earlier crafts, they all have identical wing configurations... which means they should have identical liftslopes and stall performance. I don't see any bug with the dev build, I think you're simply mistaking correct behavior for bugged behavior and vice-versa.
  15. ferram4
    Welp, then that's a bug in the legacy wing system. Okay, I see what's wrong; it's not properly updating when attaching new parts, and the loaded version was correct. That has now been fixed.
  16. ferram4
    Nope, sorry, not moving forward with a release until this is fixed. This is a game-breaking bug that possibly extends to breaking aerodynamics completely on the affected crafts. One of the tell-tale signs of voxelization completely breaking is that everything on the vehicle is stowed, and if I release with that bug still existing it means that I'm slating another bugfix release in between the upcoming one and either the first pass of the wing overhaul / Unity 5 + KSP 1.1 compatibility update. I'm not going to release a bugfix release with a gamebreaking bug still existing if I know it's there and I haven't made progress on fixing it. So at this point, since you're the only person who's reported this, please, provide all the info you can, the saves, logs of the issue occurring, the craft file, mods needed, and anything you know about how to reproduce the issue. Otherwise I'll simply delay the release until I, you, one of my testers, or someone else provides the info needed to make things work. No half-assery when there are game-breaking bugs afoot.
  17. ferram4
    @sashan: That's in the current dev build as a fix, though I dislike that method. @Gaiiden: Yes, that's the correct procedure. Well, then I'm gonna need you to figure out how to reproduce it with minimal mods and steps; there's absolutely nothing that FAR puts in the save file, so something must be different with the deployed vehicle compared to the one spawned on the ground. I need to know what that is, and until that happens, bugfix release with other crucial voxelization fixes gets held up. No, don't just say that it's not an issue because you found a workaround; workarounds should be unnecessary, and until I have enough info to reproduce the issue with the bare minimum, I can't fix it. @123nick: FAR itself won't. If you're using a mod that adds parts that (for whatever reason) depends on FAR, then those parts might not load, and then you'd get issues.
  18. ferram4
    @The HengeProphet: Probably gonna be the latter one. Some weird things can happen starting stuff up. @Gaiiden: Try the dev build on the master branch and see if that fixes your issue. I just fixed a rather critical voxelization error and I wanna see if that got it; if it did, I just need to do some testing and then a patch can be released to fix other bugs.
  19. ferram4
    But there is no difference between those vehicles. If the parts are the same, the meshes are the same, and the orientations of the parts are the same, then the voxels will be the same. FAR doesn't save any voxelization data, so there should be absolutely no difference between the newly-created and loaded-in-space version of the vehicle. Very strange; does one of the mods you're using save special mesh-based data for craft to load or something?
  20. ferram4
    The voxel is updated immediately after the craft loads because it would really suck for the craft to enter an atmosphere and now need heating calculated, or for it to have parts that are covered in fairings that fire when they shouldn't. Nothing special about IR here. Now, that said, FAR deliberately makes sure that engines, RCS jets, and a few other part types get priority in the voxel, so that they can't be borderline-exposed but then counted as stowed due to their voxels being overridden. So that points to the voxel being modelled as much larger than it should be and completely covering up the RCS jets there. Given the size of those jets relative to the rest of the vehicle, the problem is unlikely to be FAR itself; I suspect a part with a collider that is much larger than the visual mesh there creating the issue. Reproduce the issue with the fewest number of mod parts, and if it can't be narrowed down to one part being incredibly finicky, then I'll look at it. Until then, it's probably just an oversized collider from some other part.
  21. ferram4
    Depends on whether my tests indicate that win64 is stable during experimentals. If it works, great. If it doesn't, and win64 still comes out despite remaining a mess, the lock will remain. Trust but verify. I'm hopeful, but I'm not going to back myself into a corner if everything falls through and it ends up being a situation where nothing has changed.
  22. ferram4
    I've been using Pparts with 0-diameter ends with none of those problems, which indicates some other issue. In any case, if there is an issue, then likely it's something with how the mesh / collider is generated, because FAR is just reading off the mesh / collider. I can't fix that, it needs to be fixed on the Pparts end.
  23. ferram4
    That likely needs to be fixed on their end; probably what's happening is that the bay doesn't actually include colliders that close, completely / at all, and that screws up the voxelization. In that case, nothing I can do unless we're gonna bite the bullet and make voxelizing that a lot more expensive to use the mesh itself. I would much rather have the colliders fixed to keep it efficient, but I can't fix someone else's assets.
  24. ferram4
    @Kussris: Looks right, drag rises sharply at supersonic speeds, which is why most things stick to subsonic flow. The dropoff after implies that there's the confounder of decreasing air density though, so you'd get better data if you divided out by air density. @sashan: Unfortunately, needs to be changed on the VNG side. If the parachutes aren't working, that implies that they're trying to work as a multiplier to the stock model, which is 0'd by FAR to let the voxel model do its thing; they would have to fix it by applying the drag force directly instead.
  25. ferram4
    @cantab: Well, I don't know. I updated the version file as I was supposed to, is KSP-AVC now doing CKAN-style screw-ups too? It amazes me that automated systems that are supposed to be more reliable than humans always end up being less reliable.
×
×
  • Create New...