Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    @KospY: Okay, I see what's different. KJR does add some additional joints by default that are only destroyed on either 1) onPartUndock, 2) onPartDie or 3) onVesselCreate (for the root part). Firing the first one on the KIS / KAS part should do the trick and would be similar to what you're doing with that anyway. Alternatively I can add a check for all the joints on that vessel, but that's an O(n) mess to deal with every staging / breaking event which I'd like to avoid (if possible).
  2. ferram4
    @Bushi: And once again, I cannot reproduce the issue. You had better be able to provide good reproduction steps that will work for me if you're gonna go and confirm an issue that doesn't exist. @B15HOP_xmen: I mean whatever mod still exists in your GameData somewhere such that exceptions thrown from it ended up in the log that you uploaded. Which you apparently deleted from your install only after causing the bug and uploading the log, not before. Seriously, don't lie to me about what's in your install when you cause the bug, because the log will tell me what's up. @kcs123: It's not worth it, the unaware users suffering from that won't look for workarounds, they'll just report the bug and never check back. Or report the bug, have me reply that I can't reproduce it, and then confirm it again, and we'll just end up in the same loop again. Seriously, for all of you, your bug reports are not actionable unless I can reproduce the issue. It doesn't matter how many of you can reproduce an issue on however messy and convoluted an install that you can manage, if I can't reproduce it I can't fix it. Do none of you want me to fix the bugs? Because this is how you make it impossible for me to fix the bugs.
  3. ferram4
    @B15HOP_xmen: You and I both know that those reproduction steps are basically a lot of fluff immediately followed by, "and then it randomly breaks." Also, your log states that you have JSI installed and probably some other mods, and those are throwing exceptions. I can't tell if those are related to the issue or not, but given that the only time things break there are a ton of exceptions from JSI, I have to assume that it's implicated somehow. And since it's breaking, there's nothing I can do to fix it, because not my code. Come up with the reproduction steps that actually reproduced the bug, sans the hours of pointless messing around and only what actually caused the final issue. Again, actual reproduction steps. @hahawin: Your reproduction steps aren't. The issue does not occur, regardless of what fuel tanks I use or in what configuration, using the latest dev build. In addition, the minor changes when attaching wings are a result of the voxel resolution needing to change, and there's nothing I can do to fix that unless you want the game to crash constantly from too much memory usage and make voxelization take minutes. Edit: I have re-found a gif explaining my frustrations:
  4. ferram4
    @Shaman: Well, apparently it's because the CoL is terrible and inaccurate, because the graphs follow the proper stuff. This is why I tell people not to use the damn indicator because of how inaccurate it always ends up being. The only reason I haven't gotten rid of it yet is because if I did you'd be complaining about how there isn't a CoL indicator. Damned if I do, damned if I don't.
  5. ferram4
    You're not getting a voxelization debug display in flight because there's nothing to display. The voxel is destroyed within ms of it being created because it's not needed, the debug display is laggy as all hell, and all indications at this point are that that isn't the problem, because none of the reports of aero breaking have been accompanied by reports of log spam, which would happen if the voxel wasn't being built. Given the fact that the "accepted" reproduction steps seem to be, "play a bit, it'll happen eventually" and that no one ever posts the logs right after they manage that that the true cause is probably never going to be determined; I'm just going to continue fusing with some possible errors and magically hit it and no one will ever know the true cause. @bartekkru99: If you have matched all parameters (mass, wing area, thrust, distance to neutral point, etc.) the planes will fly nearly identically, with the exception of handling downforce. If you haven't and you've stuck to only aesthetics, you'll have trouble. If you're using mod parts that for some reason don't voxelize correctly due to how the mesh / collider is set up, you'll have trouble (and there there's not much I can do). But other than that last one, it's almost all user error; maybe look at the example FAR crafts, considering that the Firehound M is basically a slightly fat-headed Su-35 / F-18 mix.
  6. ferram4
    @Arathorn: Probably a stiffening joint trying to go past an IR part. I'll see if I can add an exception around that. @cicatrix: Nothing I can do; KIS / KAS needs to either fire GameEvents.onPartUndock(Part p) or GameEvents.onVesselWasModified(Vessel v) for the vehicle in question if it's going to change the configuration. This is what stock does when it undocks / modifies / creates a vessel during undocking, and KAS / KIS must follow that unless their goal is to cause a lot of other issues in the game along the way.
  7. ferram4
    Your plane has lift, it's just that the vector on the CoL is a stupid addition that is confusing and meaningless and shouldn't be there. Everything is working fine, your plane just needs a redesign to be, you know, stable.
  8. ferram4
    1) Calc derivs for the case you want to check. 2) Go to sim and select lateral or longitudinal. 3) Enter initial perturbations from nominal, and see if it converges and damps out or diverges. List of terms: Longitudinal: u = forward vel perturbation w = downward vel perturbation theta = pitch angle perturbation q = pitch rate Lateral: beta = sideslip angle phi = roll angle r = yaw rate p = roll rate
  9. ferram4
    @Recon777: Well, I can't help if you don't post the log. Obviously something is breaking, but I can't reproduce it, and without the log, I've got nothing to work with. If it's CKAN screwing things up, then there's not a damn thing I can do; CKAN's install methods have always been a pain in the ass and the only consolation I've gotten out of the situation is that I ended up being right about how it would make my workload heavier. I mean, I don't know if it does it, but maybe CKAN is saving more data about your install than it should? I have no idea, the whole thing is just hell to deal with. I'm honestly lost; you're telling me that you've got a persistent issue with a part of the menu even after clearing out absolutely everything related to all the data that it has to work with. From what you're telling me, everything should be broken in the debug menu for everyone the very second they switch to that section, but it isn't. I'll continue looking once you've posted the log. Until then, I don't know, you've got too many mods and not provided enough info to figure out what's wrong. @Wanderfound: Probably because the coefficients being green isn't the end-all-be-all of dynamic stability, so I'll have to get at better system in place. Until then, try the sims out to see if they show any instability. @gilfo: You don't need to change anything in there to make it work properly, and the next release will have the latter two tabs removed completely to avoid further issues. The rest is pretty self-explanatory... higher drag means more drag, stricter design requirements means stricter design requirements for min drag, voxelization count is number of voxels per vessel for developing the model. I really don't know how to explain it further.
  10. ferram4
    @Recon777: It's breaking because you're not actually deleting the right file. I've checked this, it works fine. And given that it's apparently such a problem to have the debug menu that lets you edit the aero stress configs in-game, I'm just going to remove them and solve the problem quickly. I can't exactly get rid of the "remove template" button without making it impossible to remove templates; just don't delete the selected template if it's the first one in the list, that's what breaks it. So since the very existence of this section of the debug menu is a problem, I'll just remove it entirely. As for your continued issues, considering that it seems completely erratic for no apparent reason, I suspect that either something else is messing with the FAR files or that you're continuing to mess with it even though you already know that it'll cause issues. If you insist on reinstalling FAR, actually reinstall it by uninstalling then installing again, don't just overwrite. Now, your rocket coming apart isn't FAR, because I can't reproduce it with an identical design. Full thrust, staying on prograde, hits Mach 0.95 at 3 km or so and doesn't want to accelerate past there, but it certainly doesn't come apart. So if it requires FAR to cause the issue, then something else is interfering. Given the extreme issues you're having, perhaps you'd be well-served by posting your output_log.txt and full reproduction steps. @Enceos: IIRC, they're sending events manually. In that case, they need to only send the events when the parts move, not all the time.
  11. ferram4
    Anything that forces an animation to occur on a part, such as deploying landing gear or a solar array; this does not include the orientation of the array or control surfaces or whatever changing in flight. Other than that, anything that fires OnVesselWasModified, OnVesselChange, OnVesselLoad, etc. constantly would also cause it. Make sure all your mods are up to date, maybe it's already been fixed.
  12. ferram4
    @Enceos: Then something is yelling at FAR to update far too regularly, unless the voxelization broke. However, it seems like the current reported issues don't have the log spam, so if you're on Ferri, then it's not that. Odds are it's something else causing it, and I can't fix it because it's not my code. @ArchmageNydia: Known issue in pWings. I suspect it's the orientation of the mesh / collider faces, since FAR uses those to get much better info on the exact contours of the vehicle. It's something special about how they're set up. Not much I can do without reverting changes that fixed a lot of other issues; make sure you're running the latest version of pWings, and if that doesn't fix it, wait until the fix shows up on their side. @Recon777: Unfortunately, I didn't plan for someone deleting the very first entry in the menu. What you want to do to bring things back is to go into your FAR folder, find CustomFARAeroStress.cfg and delete it. And then don't mess with debug options unless you know what you're doing. Ah, who am I kidding, I'll probably just remove the aerostress and atm composition tabs from the debug menu and call it a day. Anyone who actually wants to change configs can go into the configs themselves and it'll keep everyone else safe from screwing things up when they think they're perfectly safe (hint: when you mess with debug options, you never are). Also, progress report: I finally wrestled an equation for pressure coefficient across a slender vehicle out of linearized supersonic potential flow, so I should be able to use that for more accurate application of drag to transonic and supersonic vehicles. I'm tempted to maybe display the curve on the vehicle in the overlay, but I don't know how crowded that will get and if that's really such a good idea. Might be interesting to have anyway.
  13. ferram4
    NOOOOOOOOOOOOOO THAT'S NOT HOW THE CM GRAPH WORKS Alright. The stable orientation on the Cm graph is where the graph crosses 0 and is sloping downwards with increasing AoA. A Cm of 0 indicates no pitching moment, so everything is balanced out. A downward slope ensures that if the AoA decreases slightly, there will be a pitch-up Cm, bringing it back to 0; likewise for slight AoA increase. Where the Cm slope goes to 0 is a point of neutral stability where the dynamics switch from stable (where the line slopes down) to unstable (where it slopes up). Many rockets will not be stable. This is intentional, because most rockets aren't. Use thrust vectoring to keep them under control.
  14. ferram4
    Considering that the reduced area of an engine should produce drag near the back, adding an engine is not a bug. Now, the fins might be one. Alternatively, they're large enough compared to the rest of the rocket to produce a lot of nasty drag ahead of them, which would move the CoL up. I'll have to investigate further.
  15. ferram4
    The entire log, not a single snippet. I have no idea if that's the initial cause or something else. Also, for anyone interested, I threw what I know about the 0-drag issue on github. So if you're interested in progress or you can help, it would be appreciated.
  16. ferram4
    On the voxelization errors on certain parts: They're all the same issue, I just need to re-implement the fix from before I ported to 1.0. Already fixed in the dev build, everything should be fine. @Everyone talking good bug report steps: The very best reproduction steps is a video recording (with annotations, hopefully, to make jumping around easier) of everything that led up to the bug. Because then, you don't need to figure out what the steps are, and we don't have to sit here screaming because you left out something I don't do / I do something you never do. Easy. @RyanRising: All it takes is recompiling with all the lines that check Win64 in CompatibilityChecker removed. It's not difficult. Also, given that when win64 builds of KSP started they were unofficial hacks, with the same exact messy nightmare of bug reports and false information (seriously, the original "Win64 Hack Mod Compatibility Thread" said that a lot of mods were incompatible even though people were able to run them fine, sans crashing because win64), I see no reason to open myself up to more hell. Look at the bug reports now. Why would I put my workload more at the mercy of someone else's ability to figure out what's going on? Especially since all it takes is one modder to create a utility to make the hack for you, reduce it to "push button receive win64," and we're back to the same irritating mess. No thanks. @jrandom: Collision mesh looks fine for the blades. I may need to look into adding an override to make sure those meshes aren't voxelized like I do for propellers on Firespitter stuff.
  17. ferram4
    No. I don't want any other mods involved for the basic test. I don't care how difficult it is to fly your rocket without them, for bug reporting, every single extra mod you add is an additional confounder. Unless the mod interaction is the actual source of the bug (which I seriously doubt) adding in more mods just makes things harder for me to deal with. Hence the request for "just FAR."
  18. ferram4
    @Crzyrndm: And you are certain that the triangles that are created have their vertices ordered when creating the triangle such that the numbering is clockwise when viewed from the outside of the mesh, right? (Or anti-clockwise. I'm not sure which it is, so long as it's consistent). Because the results would be consistent with it being flipped for one of the meshes. @WalterB & Demuder: Unfortunately, your logs show nothing and your reproduction steps (which I basically parsed as, "launch a bunch of things into space") didn't work. I need, "these steps will always absolutely and completely reliably cause the bug every time no exceptions" steps or else I can't fix it. I believe that the bug is there. The problem is no one tells me how to get to it. Which means I can't fix it. And this merry go around continues. Let's try this: cause it with no other mods at all. Just FAR. I don't wanna hear about RemoteTech, or KIS, or Tweakscale, or whatever. Just FAR. And then, post exactly what you did. If it involves any wishy-washy, "play for a bit" or "launch a few things" or anything non-specific, your report is useless because you're missing the actual cause and burying it behind a huge mess of confounders. Then, submit that step-by-step rigorous a-robot-could-cause-this-bug-now checklist, and then I'll try to fix the bug. Rigor gets bugs fixed. Wishy-washy reports just delay the bugfixes that I already have while I wait for actual reproduction steps. @DuxDucisHodiernus: Then let me explain how you went wrong. It's really very simple. Lots of people like following the mod and watching progress. They, like most people doing this, realize that the best way to do that is to simply watch the github repo and get your information there. They can find out what's changed, without demanding special attention from me. Which you have. Multiple times now. For information that you would have known if you read the OP or the readme. Like you're supposed to.
  19. ferram4
    @Volt: Yes, that would be the full log. Reproducing the issue with no other mods is always better, it helps narrow down the issue. I would hope that KIS improves over time, but if it needs to do this stuff I don't know how to fix it. It's not mucking about with my code, it's mucking about with adding stuff in the stock game, it seems; if it's destroying and recreating vessels willy-nilly then there's not much I can do to prevent anything from going wrong, and that's really the only thing I can see causing that; destroying vessels without cleaning up their VesselModules at the same time. @Kitspace: No one is talking about mass here. I'm talking about asymmetric aerodynamic forces caused by the parts not being exactly perfectly aligned.
  20. ferram4
    Every single time you report, "for some reason, at some point, things break" and can't provide any more information, I throw your bug report out, because your reproduction steps turn into nothing more than a convoluted version of, "HALP THINGS BORKED." I need to know exactly what you did to cause it, otherwise I can't fix it. All indications are that the bug everyone is complaining about was fixed, completely and totally, in Ferri, so now you're all gonna have to tell me what you did to break it because there's no method I can see to break things now. So, full copies of logs. Full reproduction steps. What mods you're running. And some damn information that gives me somewhere to start other than a wild stab in the dark. At this point,the bug reports have reached the point of such uselessness that my main reason for releasing the mod (people provide good feedback and bug reports) is basically gone. If this continues, I'll have to reconsider whether I want to bother releasing the mod anymore given all the grief that comes with it. You guys are really not helping yourselves here. @Volt: I have no idea, the only thing that I can gather is that for some reason, KIS likes messing with a lot of stuff that just breaks anything that tries to work with vessels. I can tell this is one of those mods that I'm gonna really love, just like Tweakscale. I also guess that B9 proc wings aren't orienting their collider faces properly. I guess someone should go and bring that up to whoever's (right, Crzyrndm is) maintaining that to check to make sure that the faces are oriented right. @Kitspace: Okay,the spoilers should be a quick fix. The constant rolling / yawing is due to slight asymmetry in the vehicle.Nothing I can do to fix that, that's just a product of the game. Not entirely unrealistic too. @DuxDucisHodiernus: I'm honestly more annoyed that you didn't bother to read the changelog that covers fixing it,or Kitspace's comment above you that complains about an editor bug introduced by the fix. There's nothing more irritating than being nagged by someone who doesn't know what's going on. @Cryzyrndm: Make sure that the collider / mesh faces are oriented the proper way. FAR's using that to get finer detail about the shape,and if they're facing backwards, it'll voxelize things wrongly.
  21. ferram4
    How did you manage that? I've never seen that in my tests...
  22. ferram4
    @Ser: I cannot reproduce the issue. It has a hell of a lot of wave drag, but SRBs burn out and it continues in one piece no problem. @luckyhendrix: *sigh* I know what's wrong. Dealing with the idiosyncracies of a messed up game engine are the reason why you don't accept code cleanup PRs from other people. I shouldn't have, but I did, and now I have to go through all the bugs that I fixed with this during development AGAIN. I guess I'll have to make sure there aren't any other bugs and rush Froude out then... Edit: Alright, I have it fixed in the dev build. I'll wait on pushing Froude out because NathanKell had some concerns about blunt body drag that I need to look at. MOAR edit: Just rederived some hypersonic drag equations and I think I see what he was talking about; I made an error in the calculations that I think will make blunt bodies not quite as draggy as they should be. Change is also on the dev build, but I have not tested it yet.
  23. ferram4
    Alright, so FAR v0.15.2, "Ferri" is out. Lotsa bugfixes, and somewhat more accurate voxelization. All of the recent really nasty bugs should be gone.
  24. ferram4
    @Autochon: To do it right, there are two ways to model the effect of exhaust on the volume displaced by the vehicle: For air-breathing engines, you count the area ducted through the fuselage for the intakes -> engines as hollow and then ignore the exhaust plume itself. That's because most of the mass for that plume starts in the freestream and then returns to it, so it's simple to deal with. For rockets, you count the plume as an extension of the vehicle. That's because the exhaust exists only as fuel within the rocket before being dumped out, so it needs to take up additional area. Neither of those is exactly easy to do, so FAR doesn't do either right now. I'm working on the first, might have to come up with something clever for the second. @B15HOP_xmen: The area rule is wave drag.
  25. ferram4
    @jrandom: I have no idea what you're talking about. That issue was fixed back in Fanno and has never reappeared. Both pods are stable, with and without heatshields, when oriented blunt-end down into the flow. It is possible that the Mk1 is also stable nose-first, but that would be correct since that's the same exact situation as with Mercury, IIRC. @steve_v: Yeah, I know. There are some adjustments to it in today's builds; always check the latest builds.
×
×
  • Create New...