Padishar

Kasuha has now updated his rules to correctly account for fuel tanks with crossfeed disabled and I have implemented the required changes in KER. My development version including this fix is in the thread linked in my sig.

I have just updated the zip in the first post with a fix for the "fuel tank with disabled crossfeed" issue. This affects some nosecone parts when using Modular Fuel Tanks or Real Fuels. I have also slightly optimised the GetSourceSet function to eliminate lots of pointless recursive calls.

Ahhh, ok. When I rewrote the KER simulation code I attempted to duplicate the fuel flow rules worked out by Kasuha but it appears there is a flaw in them (relevant KER code). Specifically, rule 3 says that a part with crossfeed disabled will return an empty list of parts (but will provide fuel via fuel lines coming into it by rule 2). If your nosecones do actually provide fuel when set to crossfeed=false then this rule must be wrong in some way (not surprising this has been missed if no stock parts are set up like this). It sounds like some more experiments will need to be done with modified parts that contain fuel but have crossfeed disabled... However, I guess that having a fuel tank with crossfeed disabled doesn't really make a lot of sense so it probably does make sense for your parts to be changed...

I've been meaning to look into this (well, the same issue with the nosecones that hold fuel in some other mods) for a while but keep forgetting about it. Are your nosecones also "module = Strut"?

I didn't say it was an extreme delay and your sarcasm is not helpful to the discussion. I was simply pointing out that the current mechanism is not exactly "quick", if f9 paused the game and opened a confirmation window which could be confirmed with enter (or even with another press of f9) the result would be a quicker quickload. More of that very helpful sarcasm, there's a reason it's called the lowest form of wit. In any case I didn't learn to always check if it saves, what it actually taught me is that the game has shortcomings in the quicksave/load mechanism and prompted me to write a small utility program that monitors my save folders and automatically backs up changes to the files so that I can recover if this happens again. I don't remember anyone posting anything that implies they want to "destroy the quicksave system". I certainly didn't and don't. Strange sense of humour you've got there... They can be told by the programmer to do any number of relevant tests that could indicate that the user is likely doing something silly, e.g. if the quicksave was done last week then loading it after having just designed a new rocket and sending it on a 4 real-time hour mission is probably a mistake and the program could easily detect this and warn you. Yes, computers do exactly what you tell them to but this is not always what you think you are telling them to do. I didn't say anything about overwriting saves but I'll respond to your inaccurate statements anyway. The user isn't hitting quicksave because they want to overwrite their previous save, they hit quicksave to do a "quick save". The fact that this uses a single "slot" and hence each quicksave overwrites the previous one is down to Squad writing the program that way. It could easily be written a different way to be more helpful to users without compromising the current functionality. The accidental overwriting of a quicksave with the current system is far to easy, there is no reason (other than the time needed to actually implement the code) why quicksave couldn't behave more like alt-f5, pausing, opening a dialog asking what you want to call the new save (with a sensible default chosen to not overwrite anything) and allowing you to just hit enter (or f5 again) to actually do the save. This would simply require two presses of f5 to do a quicksave which, in my opinion, would be an acceptable compromise that stops quicksave overwriting. When loading again, the press (not hold) of f9 would open a dialog showing all the save files with the most recent selected. Hitting enter or f9 again would do the load. This would give a faster quickload mechanism that also allows you to check if you're loading the correct save or choose a different one. Who said anything about navigating a menu? The dialog that opens with a press of f9 would either just have some details about the save file if the current "single slot" mechanism were kept or would have a list of saves with the most recent being selected by default if it was changed to keep multiple saves. If you are going to reply to my comments then, at least reply to what I wrote. If you really think that a press of enter or a second press of the f5 or f9 key (or even finding the OK button to click with the mouse) would be a "huge pain" (or even any slower than the hold f9 method) then I am surprised you ever managed to sit through the initial game loading process without quitting in disgust (and, no, this isn't sarcasm, I am genuinely surprised). Yes, people do get used to them and end up sometimes doing something silly but that doesn't mean they don't work and it doesn't make it any worse than the current implementation. This just isn't true. The "confirmation" window in the system I described above also allows the alt-f5/f9 functionality and the holding down f9 doesn't do anything about accidentally hitting f5 and overwriting your "real" quicksave. Was there any particular reason why neither of you commented on this bit or could you just not think of any reasonable argument against it?

Yes, it will be. When you are going slightly above terminal velocity, the drag force is only slightly higher than your weight force so the total force on your craft is upwards and quite small so you accelerate upwards (i.e. slow down) only slightly. If the terminal velocity remained constant then you would never actually slow down to it as the difference in the forces would shrink the closer you get to it. In actual fact, the terminal velocity keeps getting lower too, so you always lag behind it.

If you haven't done so already, I suggest you report this to the Hyperedit people. In the meantime, have you tried strapping the thing you want to launch to a large booster (large enough to get it a few hundred metres into the air) and then launch it, decouple the payload and then hyperedit it into orbit from atmospheric flight?

You seem to be misunderstanding the concept of terminal velocity. The terminal velocity isn't any sort of hard limit, it simply tells you at what velocity the gravitational pull on your craft is balanced by the atmospheric drag on your craft (assuming vertical motion). So, when you are at terminal velocity straight down, the drag is balanced by your weight and you will not be accelerating or decelerating. As you descend the atmospheric drag increases due to the higher pressure and hence the drag becomes higher than you weight and you slow down a bit more but this doesn't happen instantaneously. When you are moving at an angle to the vertical the situation is more complex. The drag force acts directly opposite to the direction of motion but gravity still acts directly downwards so you will need more drag to balance gravity. As the drag force is the only force acting non-vertically, this causes your horizontal speed to drop and only a part of the drag force is working against gravity. Does this clear up your confusion?

You need to be going fairly slowly but, more importantly, I believe that all 4 points of the claw need to touch the target for it to grab hold.

Errr, 34 m/s is approximately 70 miles per hour. Good luck with that not causing significant damage...

But they can recognise when you are asking them to do something that is probably not what you actually want to do. No it doesn't. Quickload is not currently quick because you have to hold the key down. It would be much faster if a press of f9 opened a dialog giving details of the quicksave and asking you to confirm. If you are sure you would be able to click and confirm the dialog faster than you can currently do a quickload. This happened to me a while ago and I don't believe I did anything "stupid". I had just completed a number of docking manoeuvres and then refilled 24 RCS tanks and I tried to hit f5 but due to a biscuit crumb in my keyboard the f5 key didn't actually do anything. I didn't notice the "Quicksaving..." message didn't come up as it isn't exactly in a highly visible place and doesn't stick around for long. I then ran various tests on the vessel to make sure everything was happy and once complete I quickloaded to get all the RCS tanks back to full and found that my last actual quicksave was before all but one of the docking manoeuvres. And smarter people realise there are various ways in which this issue could be addressed very nicely so make suggestions that this is done...

If I was running a QA team handling an alpha/beta release to 30 users and 22% of them reported the program didn't work at all then I would not allow the release to go wider until this had been investigated and fixed. These issues are almost certainly in Unity and so they can't be fixed by Squad. Do you understand how Unity-based games work? I highly doubt that a real release from Squad would change the numbers. No, Unity and 64bit (still) has various issues on Windows (which is what this thread is about). The Linux 64bit version works pretty well (once a few things have been patched) but I don't see how that has any relevance to this topic... Or are you saying that I am arguing against it because I am a Linux user and so don't need the 64 bit Windows version? This isn't true, I run Win7 64 bit on my new machine (i7-4770K) and used to run Win7 32 bit on my old machine (CoreDuo T2600 laptop). Admittedly, I don't often run with anywhere near enough mods to get near the memory limit of the 32 bit version (even my full Realism Overhaul install for testing KER is well under the limit) but I would use a stable 64 bit version if one was available...

This is so obviously not the real reason that I am amazed that you have posted it. There would be absolutely no reason not to release both 32 bit and 64 bit versions if they were stable. The poll is currently showing a 22% total failure rate which is (or should be) totally unacceptable for any QA/support team to allow to be released (even as a beta). The only way that Squad could release the 64 bit version in this state would be as "not supported". I'm not saying they wouldn't be interested in reports from people that it doesn't work for but I suspect they would be completely overwhelmed by the extra support load it would generate. It really doesn't make any sense for them to do a wide release of the 64 bit version before most of the serious 64 bit specific issues (which are inside Unity, not KSP) are fixed. There are plenty of other things for them to implement and plenty of quite serious bugs and shortcomings to be fixed in KSP to keep them busy for a whole release cycle (and 0.24 is bound to introduce more). They would need to shout very loudly that it is unsupported and is quite likely to not work at all to avoid harming the image of KSP in some people's eyes.

Yes, this is indeed true. The ISP varies with atmospheric pressure. For jets, the thrust is scaled by the velocityCurve (when useVelocityCurve is set as described by KerikBalm). My latest development version of KER allows you to see both these effects in the VAB by providing tweakable sliders that let you set the atmospheric pressure (as a percentage of sea level) and the velocity (0-2500m/s) used to calculate the thrust and deltaV stats.

Just go to a profile and click the "Find latest posts" link on the left, then hit back and click "Find latest started threads"... I believe that vBulletin caches the search results and allows the request if cached so you need to pick a random profile, e.g. now that I've done both of these searches on my profile (and on Woopert's) you can't repeat it, but you can on someone else's... 5 seconds is so short it only really affects people who either click the wrong link or make a typo in their search. I've seen several vBulletin forums that have turned this on, supposedly to reduce load, but when the complaints start the admins just claim it is necessary without ever showing any evidence that it does actually reduce the load...

Well, BaseFieldList (the type of PartModule.Fields) implements IEnumerable so it should do...

Well, there is nothing obvious in the last little bit of the log after the ship is loaded in the flight scene and all the plugins have started up but there are various worrying messages earlier in the log. First, you appear to have MechJebRPM installed but don't have MechJeb itself. This could potentially cause an issue. Second, I wouldn't expect that Kethane is supposed to do this: Failed to load assembly C:\Kerbal Space Program\GameData\Kethane\Plugins\MMI_Kethane.dll: System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid. at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 Thirdly, when loading the vessel, most (possibly all) of the parts report a missing PartModule. This appears to be something to do with FAR as the PartModules that don't load are FARBasicDragModel. I don't know if this is significant but I wouldn't expect FAR to cause this sort of log spam when loading a vessel. Fourth, the Clouds plugin appears to be running 3 times at once. I don't know if this is significant but it could be. If you drag the sim time slider all the way to the right (1000) and the glitches are less severe but still happen every tenth of a second then it isn't being directly caused by the simulation code as that would only be running every second (the number is the time in milliseconds between the start of one run of the simulation and the next one). KAC uses a 0.1 second timer so it may be worth removing that as a test and see if anything changes...

Yes, I understand that it is the KER simulation code causing the lag. I meant that the way struts are handled by KSP changed and if QStruts hasn't been properly fixed to work correctly with 0.23.5 then this could cause the simulation code in KER to have issues... How drastic is this lag? Are you effectively getting freezes every time the simulation code runs or is the frame rate just lower in general? Are you using the version from this thread or the official 0.6.2.4 version? Either way, can you also try the other one and let me know how they compare? I don't suppose you've set the processor affinity to make KSP only use one CPU core? That is definitely not a good idea when KER is installed (and is never really a good idea with KSP because some of Mono/Unity is multithreaded and it runs better on more than one core). Another thing that may help is for you to post an output_log.txt (from a short run of KSP, e.g. run, load save, switch to vessel or load ship in VAB, let run for a few seconds and then quit). There may be exceptions, errors or other messages in there that may shed some light on the problem...

Ahhh, another user with a Phenom II reported a nasty lag issue and it turned out to be (mostly) caused by having the AMD compatibility mode turned on. Have a look at this post (and the earlier ones from the same person describing the problem). If you do have this option turned on then I suspect that turning it off will cure the lag (or at least the worst of it)... I can't take a look at your craft right now (at work) but I will try to take a look this evening. However, I wouldn't expect your craft to give the simulation much of a problem unless there is a specific mod that is causing issues (the most likely offender is probably quantum struts as 0.23.5 changed how struts work and something may not be quite right).

You will need to upload your file to a file sharing service of some kind (e.g. dropbox, google drive, mediafire etc) and then post a link to it here. It didn't used to have any particularly useful controls (only a button to turn it on and off). I added the various sliders it has now to control the simulation rate and the atmospheric pressure and craft velocity used to calculate "correct" engine thrust/isp. Can you answer this bit too, please?

I was testing some modifications to a lander/rover design to prevent issues with the kerbal in the command seat being thrown out while docking, usually resulting in the death of the kerbal. I made various changes and was pretty confident that the kerbal should survive because, if he did get ejected, it should be in a direction away from the vessels, so I "asked for a volunteer" to test it in LKO. Jeb wanted the job but I wasn't that confident so I gave it to some random kerb I can't remember the name of now and when he docked, sure enough, he still got thrown out of the seat and he did survive, but he somehow managed to achieve an orbital velocity of over 100 km/s so he was definitely lost beyond return...

I suspect he means the stock part .cfg files...

In what way is it wrong? Do you mean during flight or in the VAB/SPH? The code "should" be using the thrust of the relevant engine module so it should be correct during flight and in the VAB/SPH it should show the rocket stats normally and the jet stats when the "Atmospheric Stats" button is pressed. The tweakable options in the VAB/SPH should also include sliders for setting the atmospheric pressure and craft velocity used to correct the thrust/ISP (defaulting to sea level and 0 m/s).

Well, now I can set the required pitch angles and have upgraded from a Core Duo T2600 laptop with a G3DMark of 47 to an i7-4770K and GTX560ti with a G3DMark of 3544, I've now rebuilt the tetrahedron using "correct" angles and a new ARM launcher and made a start on putting together the icosahedron... "Only" another 4 launches to rendezvous and 31 docking manoeuvres to go...

I saw another report of something very similar in the last few days (though I think it was with a solid booster). I'll try and find the post but in the meantime, I guess this must be some plugin that messes with engines so I suspect something like HotRockets (or RealFuels but I guess you're not using that). Do you use HotRockets?