funk

Hey Nertea, Streetwind, I've updated to the last release and recognized an old MFT-patch. I made a new one in July regarding the dry mass fraction changes and RealFuels. Here you can download it... Regarding tank switch I'm not sure if it's working without "typeAvailable = Default". For me it works as intended with it. After all the cryo tanks are just changed default tanks, either by changing the fuel fraction in "default" or switching to "cryogenic". Nevertheless, there aren't many complains about it, so it seems most people are using IFS.

I've done some more tests and found some problems, which seem to be related to the raycast between the tested part and and the centroid of the bays. It's always the same behaviour, a part overheats, because it's occluded while its parent isn't. There seem to be gaps in the colliders especially at the top and bottom nodes of the bays. Due to my patch the search radius is increased, so it can affect more parts.

Nertea, can you pls provide some information about the engines which are affected? I'm diggin in this problem, too. Regarding this post, it says: "* Next, we compute a centroid point for the part, based on its renderer bounds. That centroid is then a product of the part's visual mesh, not dependent on attachment position, center of mass or even colliders. It's the visual center of the part. This is now our reference to test the part in a visually accurate way." So the question is, how can a model effect the reference point and why/how is the reference point moving while the vessel is in another orientation? Perhaps you can show us the affected model in sketchfab or in a picture? I suppose it's somekind of origin to mesh related... ATM my investigtion has gone as far as I described here.

I may be wrong, but doesn't FAR occlude all parts within the voxel hull? There was a bug regarding overheating parts with FAR, so be sure you're using the last version...

I'll have a look at your craft. First thing I can imagine, is that you use the claw, even with the stockbugfix, its causing issues. Second thing I was mentioning earlier, is that there might be problems with the colliders especially the Mk3 ones. So that the second test mentioned in the OP isn't accurate. I'll investigate... I don't think that removing drag helps with that. Perhaps anyone familiar with heat mechanics can explain how it works. For the lookupRadius: I suppose it's been used from the config files, but this would mean, that the updated configs should work for existing crafts. Maybe I'm wrong here. Can you provide a craft file, pls?

It doesn't seem to. I've already had one ship in orbit before installing the fix, which parts have overheated inside the cargo bay during reentry.

look here

As a first step, I've written a MM-patch, it can be downloaded here (Copy to /Gamedata, ModuleManager is needed). Now, all parts inside the bays should be occluded. I would appreciate some testing by other players to preclude side effects. @Claw: Feel free to include it to your bug fixes, if you like. For fairings I've done some tests, but couldn't find any issues. They have ModuleCargoBay in their config files and the lookupRadius seems to be to small, but I suppose, that occlusion ist determined by ModuleProceduralFairing somehow. I've tested with the craft below and all parts, which where outside the fairing have drag and conv.flux and all parts inside have not. Edit: Meanwhile, during playing, I've recognized the occlusion bug with fairings, too.

As some already mentioned it's depending on payload, engine combination and fuel fraction. It's possible, sure, but it's inefficient, because you've to take a lot of dead weight with you (rapiers, empty fuel tanks etc). So for my career I usually bring heavy payload to orbit, which can fly by its own or will be pushed by a refuelable interplantery stage.

For further tests and descriptions in this thread I will define occlusion-bug as a faulty result of the occlusion tests, mentioned in the OP. For example a part is occluded , but shouldn't or vice versa. After investigations so far the occlusion bug is caused by: Incomplete spheres of the cargo and service bays and probably fairings (has to be tested). I'm working on a MM-Patch to increase lookupRadius of the bays to reasonable values. Inconsistent or non reliable points of reference for parts which are inside the spheres. Problems with colliders of the bays I had some issues with a spaceplane a while ago. Parts suddenly explode during reentry due to overheating. Usually I'm using 4x physics warp during reentry. I had to descent with open cargo bays (which was suprisingly easy:)). After the tests above I decided to load the craft again to investigate the issues. I've successfully rebuilt a simplified, but similiar stock craft to reproduce the super heating bug (expression stolen from Claws awesome stockbugfix thread,thx), which describes suddenly exploding parts during 4x-physics warp. Test-Craftfile The following results and questions showed up during testing: occlusion-bug: the occlusion tests are proceeded once, when the cargo bays have been closed or when the vessel is leaving non-physics warp. That means a part can be occluded before entering non-physics warp, but isn't after leaving non-physics warp. occlusion, especially at the edges of the spheres, depends on the orientation of the craft. It will have to be tested/explained, if this is caused by a changing reference point of the tested part or if the colliders or search spheres of the bays are changing. The MK3 Cargo Bays may have some problems with their colliders, I could occlude parts, which had at least 1.25m distance between their own colliders and the colliders of the bays. superheating-bug (all regarding my testcraft): occurs during 4x-physics warp, if a child part is occluded but its parent part isn't. Doesn't effect every occluded part. the parent part has to have a few child and grandchild parts. My hypothesis is, that occlusion causes the formula/iteration for cond. flux to crash. Because this doesn't effect every occluded part there have to be more indications to determine what's going on, but at this point we will need more information... anyone ideas? Meanwhile there is a workaround for it: 1. search near the exploding part for a part which is occluded, but its parent isn't. 2. move the ship around (reorientate) and open->close the bay nearby or enter->leave non-physics timewarp 3. check, that the part isn't occluded anymore, else try 2. again in another orientation

I´m not sure, but usually your velocity is higher during reentry than ascent. Further you won't have your ore tanks filled up, so the thermal mass of the tanks is low. And last the panels have low maximum temperature, I assume that the bars are enabled when the internal temperature reaches a determined per cent of the max value. So this doesn't mean they're near to explosion, but if you can provide a craft file and a use case, this would help a lot!

Perhaps a mount for VTOL engines, I was building this and thought about the space which is left...

I might have found some issues in the config files of the cargo bays. According to this thread the lookupRadius is too small in most cases. It has to be the absolut value of a 3-dimensional vector from COM to the farest point within the bays. The following pictures show that the parts at the edges aren't occluded and have drag as well as thermal flux. craftfile for testing Further the nodes facing the wrong direction: node_stack_top = 0.0, 2.5, 0.00, 0.0, -1.0, 0.0, 4 node_stack_bottom = 0.0, -2.5, 0.00, 0.0, 1.0, 0.0, 4 node_stack_top2 = 0.0, 2.5, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom2 = 0.0, -2.5, 0.0, 0.0, -1.0, 0.0, 2 Usually the big nodes are at the outside. Not sure if it makes a difference. For the servicebay there are no inner nodes. Nevertheless this is a great mod and I've had some hours with my first Mk4-craft ....it was not useful at all, but pure fun... save is gone:(

It could affect fairings, too. I assume that the spheres for fairings are procedural, so if they are stingy, parts at the edge aren't occluded or in superposition... edit: To be sure enable thermal and aero data in the debug menu (alt+F12) under physics and compare parts that behave normal and not through alt+right-click.

At first: I know that I'm playing with a bunch of mods, but I'm sure it concerns stock as well, therefore I'm posting here. So let's start with the issue: A lot of players reported some bugs with overheating parts in cargobays while flying with (space)planes. Perhaps it's the same bug with fairings. Here is my attempt to explain what's happening: After this explanation ( So taking a step back, what we really need is a solution that hits the 'predictability' zone, where if something looks like it should be contained, it should be contained. The emphasis is on the word 'looks' there, you'll see why in a bit. Here's how we tackle the problem of detecting containment: * The cargo bay first detects all parts inside a spherical radius that entirely encloses it. Those are the nearby parts that will be tested. This detection method is independent of vessel relationships, being solely dependent on the position of parts. A lot of the parts in this first list will be outside the bay, and that's fine. We just do this to avoid having to iterate through every single part in every single vessel. * Next, we compute a centroid point for the part, based on its renderer bounds. That centroid is then a product of the part's visual mesh, not dependent on attachment position, center of mass or even colliders. It's the visual center of the part. This is now our reference to test the part in a visually accurate way. * We then rule out any part whose centroid lies outside the merged visual bounds of the cargo bay itself. This is just a sanity check to avoid performing needless calculations on parts that are clearly outside the cargo area already. The merged bounds are a bounding box we calculate off all renderer bounds, to encompass the entirety of the part. This is necessary as cargo bays (or fairings) can potentially be made out of multiple objects, meaning multiple renderers, and multiple bounds, hence the need to merge them. * So, we now end up with a much shorter list, comprised of nothing but parts which are in a reasonable range to warrant further testing. Now it's time to really check whether we are in or out of the bay. [a quick note here to explain that all this is done with the assumption that the bay doors are closed. If they are open, no part would be considered as shielded by that cargo bay, so that's something we can safely not worry about] * The test itself is simply a raycast, from each part's visual centroid to the bay's own centroid. Now, the thing with raycasts is that they can (and do) hit any parts along the way, and we don't want that. We are just concerned with the bay itself and each part, in isolation. This testing then is done against only the bay's own colliders. * From this we can now determine if a part is inside or outside of the bay with a pretty decent level of accuracy. If the raycast reaches the bay centroid without hitting anything, we can be quite sure it's inside the bay. If it hits anything, it must by necessity have been a wall of the bay itself, and therefore must be outside the bay. Now, you may be wondering then, what of the open sides of the bays then? Surely there is no wall there. Indeed there isn't, but that doesn't mean we can't add a 'wall' that only exists to catch a raycast. Trigger type colliders will do just that in fact, so for all testing purposes the open ends of the cargo bays are effectively closed. This still lets you pass though the open spaces normally, but catches the raycasting so we have a fully enclosed volume which defines the cargo bay. ) the game determines a part as occluded in cargo bays after the following tests: Is the parts reference point within the sphere of the cargobay? The radius of the sphere can be found in the cfgs: MODULE[ModuleCargoBay] -> lookupRadius. It seems to me, that the origin is the center of mass of the cargo bay, because the radius has mostly the same absolute value as the y-axis-value of the attachment nodes. If 1. is true the part has to have a clear line of sight to the origin of the sphere, no other parts are accounted for. If both tests are true the part is occluded if the cargo bay is closed. Now the problem is, that in some cases the lookupRadius is too small. We've to consider the absolute value of a 3-dimensional vector from the origin of the sphere to the farest point inside the cargo bay. Here you can see what happens under test 1. for the large Mk2 cargo bay (pay attention that this is only a 2-dimensional circle, KSP uses a sphere): As a result there are two solutions for this: don't attach parts near to the edges of the cargo bays increase lookupRadius in the configs During my tests I've recognized another thing, which might lead to the warp bug: It seems that either the sphere of the cargo bay or the reference point of the parts or the collider of the cargo bay changes depending on the orientation of the craft. In the pictures below I`ve built a craft with clipped intakes near to the cargo bay. On the runway and at the most angles I could open and close the cargo bay without problems. But at an pitch angle of ~30° the game decided that the intakes are suddenly occluded after closing the cargo bay. The observations above and the jumping flux values (already mentioned in other threads) lead me to assume that the jumping values are just a symptom of undefined states for parts, either occluded or not or non-constistent states between two iterations or when (un)packing a craft for default warp. Possible that physics warp causes the game to skip some iterations?!? For the last assumption pls keep in mind, that I'm not a programer and I've no clue how KSP works internally. So perhaps I'm wrong with the warp bug, but the spheres are partly wrong for sure. edit: I forgot to mention, that the conv. flux and rad. flux sometimes disappears for non-occluded parts between mach 1 and mach 2. Not sure why... Crafts for testing: Mk2-cargobay-battery test I Mk2-cargobay-intake test II

Hey Nertea, awesome work, as always...THX! I've made a MFT-patch, feel free to include it to your download. Btw, the "Heavy Extended Engine Nacelle " aka "mk4enginenacelle-25-1" has entry costs of 385000. Seems too high by an order of magnitude compared to the other parts?

Updated CryoEnginesModularFuelTanks.cfg matching IFS patch for resource amounts and tank mass. Costs are a bit odd, since IFS patch costs for stock tanks are the default drycosts but including resource costs. I've changed this and made the drycosts ~22% more expensive than LF/Ox tanks excluding resource costs.

I think I was simultanously tracking down a similar problem with heatshields. When returning from mun at a shallow reentry path the ablator was burned really fast and I was wondering that nothing happened after there was no ablator left. From the 1.0.3 changelog: "Heat shield thermal mass modifier increased to 0.05 to deal with increased heating. Max temp lowered to 3000 to avoid totally overpowered radiation heatloss." So I compared the cfg files for stock and PP heatshields. There are some different values: MODULE { name = ModuleAblator ablativeResource = Ablator lossExp = -6000 lossConst = 1 pyrolysisLossFactor = 600 reentryConductivity = 0.01 ablationTempThresh = 500 } thermalMassModifier = 1.0 MODULE { name = ModuleAblator ablativeResource = Ablator lossExp = -9000 lossConst = 20 pyrolysisLossFactor = 10000 reentryConductivity = 0.01 ablationTempThresh = 500 } thermalMassModifier = 0.001 For nosecones there are also the following nodes in stock parts which are missing in PP: thermalMassModifier = 6.0 emissiveConstant = 0.95 For fuel tanks there aren't those nodes in stock, that leads to the question: What happens to a the PP liquid tank when it has the shape of a cone ?

You're right, external cost and gains are the two sides of the same coin, but the gain for the people isn't par for par. Under the assumption that the good is dealt in a ideal market you're right because it's offered at the lowest price. But we all know energy markets aren't ideal. Besides other discounts, e.g. an absolute component of the margin for the shareholders of Tepco has to be subtracted at least. Besides energy prices there are other external costs, as mentioned above, which don't lead to external gains in the first place or can hardly be measured. You can argue that land near a power plant is cheaper, but living in a non-polluted area should be an original state where you cannot determine gains.

Nope, still not working, sry. I've uploaded "Pauli-40" again http://s000.tinyupload.com/?file_id=44808902261050018507

Mud sticks. But a lot of the implications caused by the disaster are hidden. I would like to throw an argument into the discussion which applies also to most great industries, e.g. chemical, automobile, groceries, textile, energy, pharma... infinitely continuable. It's the fact that there are external costs which aren't paid by the agent. Mostly it depends on resources which are superficially worthless atm. For example clean air, water, land, people and so on. If you've a look at Fukushima, Tepco couldn't pay their bills even for the reversible damages, though they had multi-billions-profit the years before. This causes expenditures for the japanese people. They had to shutdown all reactors which leads to higher oil imports and rising energy prices. Skimming the ground around the plant. Life with milli-sievert... Ok that's Japan, but the impact was global. Some countries shutdown their reactors, and burned more oil and coal. The japanese industry layed down so that chips were rare worldwide. As a result capital from all over the world was redeployed. People invest their money where risk and benefit suit their preferences. And here is the loop: Where external costs aren't applied to the business venture, risk is low and gain is high. And if there is a country where the law is weak, which means nothings else than an unbalanced coordination of interests, there are thousand ways to corrupt people in authority with a fraction of the revenues earned through unpaid external costs. P.S. This is not about ideology. I'm the most apolitical person I know, perhaps an One-Dimensional Man .

Referring to my post in B9-ProcWings I've done some tests with and without Dynamic Controls with existing crafts. My suspicion was right, there is a misbehaviour in stockAero of the allmoving control surfaces as shown below: Craftfiles can be downloaded here: Pauli-40 - I've removed all non-stock parts except B9 wings, using MFT but not necessary it think. Paui-Combo - same as above, but Proc. Parts needed. FYI here my log files: without Dynamic Controls with Dynamic Controls - removed IR Sequenzer, cause... reasons! Didn't effect the issue. Installed mods see logs... There are some exceptions, the ones with engineer report I cannot address whats going on, but there are also some for proc. wings. When this bug occured last week, I uninstalled also Symmetric Flameout, because I couldn't set action groups for toggling the intakes. I'm not sure if it makes a difference regarding drag in stockAero now... perhaps it's intended by SymFlameOut?!? ....and offtopic, because I'm just digging into 1.0.x: Does anybody know why the lauching state of cargo bays is always "open", but in fact they're closed, so that you've to toggle twice to open it? Hope I could help, if you have further questions, I won't go away ;-)

I had the same problem a few days ago. Uninstalling some mods resolved it. I suspect Dynamic Controls was the culprit. For allmoving wings the issue was, that the control surfaces acted in the wrong direction, depending on whether being attached in front or behind the center of mass. As a workaround I disabled roll/pitch to determine which surfaces misbehaved. As far as I remember it concerns only roll inputs at control surfaces in front of COM. Not sure at all...

ehem... and this is really patented? Basically it is just an already invented inertial confinement fusion, like the H-Bomb combined with a nuclear fission reaction of U238???!?!?!?!?! Besides the discussion above my post, there might be some issues with getting the H-Bomb device working properly. Perhaps they are using U238 because of its natural decay to fake that the device is working. U235 for example would be more fissiparous. Another thing is, that the neutron of the laser-fusion which should heat up the membrane will loose energy, which means the velocity at the nozzle will be inferior and contradicts high Isp. I'm not sure if the patent is explained correctly...

What the heck? F5 for safety!