chris-kerbal

Maybe @RoverDude might want to take a look as well? As he was authoring the original games large radiators. As the 20th ISS anniversary is coming up he might be willing to help the best ISS Mod a bit ;-)

Jebediah is asking: "Launching again? Why? We always stop and reload..." @benjee10 So I figured the culprit: When removing ht2_radiatorTriple.* from the Trusses folder, I have no troubles with my SSTO. Adding it and I get the issue again. @hemeac If you could verify, that would be really nice!

To confirm: Just did a fresh install and only added ModuleManager 4.1.4, BP9PS + CRP from habtech2 zip and the craft flies as expected. @benjee10I have some time in the afternoon to do what @hemeac suggested. Is there a way to go about it? I guess there are some dependencies between your files, e.g. shared assets before parts? To give a little positive thing, it is not the complex solar duo, as that was already absent in the tests beginning of September. ;-)

I agree with the very strange, especially as the craft is not using habtech2 parts. In my recent tests I used a fresh install and only added/removed habtech2 + dependencies in one run. Within the other thread, I tried each mod and could reproduce it by only removing the habtech2 folders and not the dependencies. @hemeac had similar experiences. Also I have a game running with B9PartSwitcher and Community Resource Pack, that works fine. It might be something of B9PS + CRP + habtech2, but seems not to be B9PS or CRP alone. This btw is the test aircraft being used: https://pastebin.com/WDympGyR If I can do anything to help, let me know.

There are screenshots and some tests in my previous thread when I encountered the issue. As you said it is very weird, as no habtech2 parts were used in my tests. At that time I thought it is just an incompatibility with 1.10.x/1.9.x which habtech2 hasn't been designed for. But it seems that something else is going wrong. Maybe some part config is accidentality overwriting a stock part config? Is there a debug way to see how part configs are read and used?

So i did all sorts of tests and could not get anything to spawn in 1km height. Also no explosions. Awesome job, thank you! HOWEVER The SSTO bug is still there. When the mod is installed, my SSTOs won't accelerate above 315m/s (using rapiers). Even worse, after deleting the mod, the issue persisted and I needed to reinstall the game and create a new save. Normally it was enough to delete the mod for it to work again. O_o

Awesome! Will test it right away :-D

That is great to hear. Thanks a lot! I was asking around in the forums to find information and other people that encountered the 1km bug. I am trying to gather this in a dev thread. It is only the bits and pieces I can get from other developers. Without any modding experience on my own, it is hard to see what is valuable and what not. For players the best workaround right now seems to be World Stabilizer. This is the thread I am gathering the bits and pieces.

So within the World Stabalizer Thread @Stone Blue mentioned that he worked on this bug. Here is what he said: I asked if he would be willing to elaborate a bit more on the fixes he did, maybe he can give some valuable input and hints for other modders, but can understand, if he does not have time to give a howto.

Thanks @Stone Bluefor adding to this! I personally encountered this issue with habtech2 created by @benjee10 . He was sort of a dead end with this and didn't have the time to poke around on what the root cause of this is. So I started looking through the forum to find someone who is further in an analysis and might provide a hint to help him. Do you think that the hint on the "location of the origin" is enough for him to get on the right track? Or could you give additional information on what you are fixing? If you are willing and comfortable with it, I would love to document it in the "developer" thread over here to help him and other mod maintainers/creators to fix this issue.

I am no modder, so not sure if it helps to go there. However, what I am trying to find is help to pinpoint what the modders need to look for to prevent that issue. I would guess, that it is some misconfiguration that causes wrong calculations within the regular handling. So does world stabilizer actively identifies such out of bound collider things and hence could help find the misconfiguration?

Could you elaborate a bit on that? I would assume, that within the regular process, there is some parts data that is read and then used in a calculation. Is it that world stabilizer uses different or additional data as base or a different calculation method/formula?

Hey @kcs123 thanks for that! I saw the videos and understood that apparently the mod is better in calculating where and how big the object actually is than the game itself. I would like to understand, on how the mod achieves that and what the differences to the game logic is. With the 1km bug, it seems, that the game spawns ships - with certain parts - that high, because it thinks they are that big? As the mod fixes it, there seems to be a difference in the way the part size is determined?

I figured that @JadeOfMaar picked up OPT development and checked if he/the mod is still plagued by this issue. Here is his answer: So apparently it is still around. Will also check if I can find out what WorldStabilizer does, that this is not happening anymore.

Thanks for the quick reply. I thought, that it is some correction mechanism of KSP, however as I am no modder, I have no clue what is happening. I asked over at the world stabilizer thread, on what it does, that prevents the bug. It at least must change calculating the bounding box. I try to gather all of the bits of information over in an dev thread and will mention your input as well.

Hi there, I heard, that this mod also fixes some weird bug of ships with certain parts to spawn 1km above the launch pad? Apparently habtech2 and opt have issues with that. Is there any information on what this mod does to fix it, that might lead to prevent the bug in the mods itself in the first place?

@JadeOfMaar Just followed the traces of handovers to this thread, as I am trying to gather some information on the spawning in 1km bug. Out of others users and the first post in this thread I found, that this mod was/is suffering from that as well? Is that correct and do you know anything about this bug? I am searching for information about this, as it also plagues the habtech2 mod.

Thanks a lot, that is good to know! Sadly @K.Yeon and @stali79 seem not to have been active in recent times. They might have had a tip on what to look for.

So you encountered this as well? With the same mod or another one?

Hi there, so first things first, I am not a modder, but putting this here on behalf of @benjee10. He might be too shy to ask ;-) The issue seems to be tricky and he does not have the time to try and try. If you feel this is wrong, tell me and I will close the thread. Within his habtech2 mod there is this complex duo solar array. For some unknown reason a vehicle including this part will either combust on the launchpad or spawn 1km above the pad, then fall down. This happens in 1.9.x and 1.10.x. Has anyone of the part modders experienced similar issues and could give a hint what to look for? So far I am using the dev version from github: https://github.com/benjee10/HabTech2 @Gordon Dryadded some of benjees latest work into a test version: https://github.com/Gordon-Dry/HabTech2/tree/merge-for-playtest Kind Regards Chris

Apparently you are not getting it. It is your responsibility to check if you can upgrade. If you do so without checking, you have to live with it. Putting it up here is just increasing pressure on benjee, who stated already what the issue currently is. So if you want to speed up, find a solution to the "spawning-in-1km" and "combustion-on-runway" issues. Also your current savegames should be ok, with the versions/changes mentioned in this thread. You are just not able to launch new vehicles as they explode on the runway. So please read a few pages back. If you have additional issues with loading craft files after that, a proper log and description would probably make sense

Yes, it is normal. Dark pictures are just placeholders. In the dev Version on Github, there is one for the Cupola. Also I am not sure what @Gordon Dry did in his fork?

I just hope @G'th is alright. He hasn't been active since the Covid message.

Did you use updated dependencies for 1.10?

If you read this and the previous page of the thread you might find a risky solution.