Gotmachine

I confirm an issue with NF Construction 1.2, causing a B9PS tank type to be missing and consequently a B9PS fatal error : [ERR 21:26:53.408] pass specifier detected on insert node (not a patch): NearFutureConstruction/Patches/NFConstructionFuelTankTypes/B9_TANK_TYPE:NEEDS[CommunityResourcePack&!CryoTanks]:FOR[NearFutureConstruction] [ERR 21:26:53.408] pass specifier detected on insert node (not a patch): NearFutureConstruction/Patches/NFConstructionFuelTankTypes/B9_TANK_TYPE:NEEDS[CommunityResourcePack&!CryoTanks]:FOR[NearFutureConstruction] [ERR 21:26:53.408] pass specifier detected on insert node (not a patch): NearFutureConstruction/Patches/NFConstructionFuelTankTypes/B9_TANK_TYPE:NEEDS[CommunityResourcePack]:FOR[NearFutureConstruction] [ERR 21:26:53.408] pass specifier detected on insert node (not a patch): NearFutureConstruction/Patches/NFConstructionFuelTankTypes/B9_TANK_TYPE:NEEDS[CommunityResourcePack]:FOR[NearFutureConstruction]

I usually give that example : Each CMR on the ISS is roughly 1.2 meter wide, weight about 280 kg (source) and provide only 0.258 kNm of torque (source). Compare that to the 0.625m KSP small reaction wheel : 50 kg, 5.0 kNm of torque. In short, KSP reaction wheels are about 100x too powerful. They are used for precise and extremely slow attitude keeping. Never for maneuvers like we use them in KSP.

Urgh... guys, pdb2mdb isn't needed anymore. Since 1.8, we have finally emerged from the dark ages of mono. Just change your *.csproj to generate "portable" debug symbols instead of the old and depreciated "full" format. The generated *.pdb file will be usable without any conversion using the Unity debugger for VS (and extra bonus, it should work on the VS for mac / monodevelop unity debugger plugin on OSX/linux) Either edit directly your *.csproj and change : <DebugType>full</DebugType> to : <DebugType>portable</DebugType> or in VS, go to your "project properties" > "Build" tab > "Advanced" button > "Debugging information" > "Portable" :

That's a KSP bug (fixed in 1.8) That menu will be used in the future for other things than science. This can't be done easily, we already had to resort to some hacks to hide the experiments themselves.

@SlashTen There was definitely some issues with solar panels in v3.0.x, although having issues while in sun orbit is quite strange. Anyway, solar power handling has been completely rewritten since, dev builds are available here : https://github.com/Kerbalism/DevBuilds/releases I highly suggest to use them instead of 3.0.2, they contain a lot of bug fixes and many nice improvements. The latest ones are quite stable, we might release an official 3.1 update soon.

Regarding Unity references, the easy solution is to edit your *.csproj file and use a wildcard search instead of specific references : <ItemGroup> <Reference Include="Path\To\The\Dlls\UnityEngine*.dll"> <Private>False</Private> </Reference> </ItemGroup>

I confirm this. @Snark In the configs, ModuleDataTransmitter is missing the DeployFxModules value that link it to the ModuleDeployableAntenna state, where DeployFxModules is the zero based index of the ModuleDeployableAntenna. Submitted a pull request to fix it : https://github.com/KSPSnark/JX2Antenna/pull/2

Our experiment module is a replacement for the stock module, you can't make it do custom stuff just trough configs. Mods like Cacteye or Tarsier that implement custom behavior/UI would need specific code support, like we have for ScanSat.

I'm not sure I understand what you are trying to do. Replacing Cacteye modules with the Kerbalism ones won't work, you will just break it. I don't think we can support it in any satisfactory way, but if drive space / file sizes is an issue, you can reduce the dataScale of the Cacteye experiment definitions (the file size in Mb should be baseValue * dataScale). Its in GameData\CactEye\Resources\ScienceDefs.cfg You can create a ModuleManager patch to change them.

@subyng The restock whitelist config was wrong. This hopefully should be fixed in the part pack v 1.4.

@baldamundoRemoteTech support is broken. Consider it incompatible with Kerbalism until further notice.

Exactly.

This organization doesn't exist. After reading this, you will have forgotten every mention of it, and so will everyone in the vicinity.

My point is : writing working code is typing a few lines of text, but the right ones. That can take 1 hour if you exactly know what you need to do because you have a working and tested example of very similar intended code on your second monitor to look at, or several days if you have to figure everything. This fact has a large impact on the total time needed to get from nothing to a ready to release game. The aren't writing KSP 2 from scratch, they are rewriting KSP, this make a huge difference.

90% of the coding process is figuring the right way to do what you want, correcting mistakes and not obvious interactions. When you need to write a class/method that achieve a specific purpose, if you have access to some stable, well tested code (and yes, KSP 1 has that) that is doing exactly the same thing, you can save a lot of that time. First, that will give you an insight of all the "traps" that you need need to take care of. And even if you are doing things differently because you want to get ride of some limitations that are present in KSP, looking at the code gives you an answer at how not to do it, which is usefull in itself. And there are a lot of things of KSP (examples : orbit solver, delta-v solver...) were most of the work is understanding and figuring out the real-physics equations and turning that into an algorithm, which is obviously a lot easier if you have access to some code that is already doing it. In the end, KSP2 is still an Unity game, it still is build upon the fundamental concept of building vessels out of parts, it still use them as rigidbodies, it still need to handle orbital mechanics and timewarp. It would be nonsense to just blindly start over without building upon the 8 years of work put in the KSP 1 code.

It seems very likely that the sole purpose of TakeTwo buying the rights to the KSP franchise in may 2017 was to allow the development of KSP 2 by another game studio. To quote the press release : So it isn't too hazardous to assume that plans were already in place at the time and that KSP 2 development started shortly after, if not before that date. With a release date of early 2020, that put the development at nearly 3 years, with a team of about 30 people currently according to the VGC interview. KSP is a relatively large game in terms of code, but not so much in terms of assets (models, textures, sound...), so those numbers feels quite adequate to me. Plus they obviously had access to the KSP1 source code instead of going into the lengthy process of prototyping everything from scratch. While it's likely large portions of the code are rewritten from the ground up, having access to working code (even if they do it differently) can speed up the early steps quite a bit.

Ha... RemoteTech... well : https://github.com/Kerbalism/Kerbalism/issues/436

@Drew Kerman In 3.0+, you may be able to disable the new science system by removing the "KerbalismConfig/System/ScienceRework" folder and renaming the "KerbalismConfig/System/OldScience.cfg.disabled" to "OldScience.cfg". This is untested so it may cause some issues but it should theorically work. Or not. Data transmission extra EC cost was part of the old pre-CommNet signal system, but wasn't ported over on the CommNet implementation until 3.0.

The current patches are indeed not great. I intend to do something about it, we have an open issue here : https://github.com/Kerbalism/Kerbalism/issues/461

You can't. Read this as for why : https://github.com/Kerbalism/Kerbalism/wiki/TechGuide-~-Background-Simulation Now, is what you want is a simple system with basic Ore > everything converters, that can be achieved by making a custom configuration pack, replacing the default profile processes with stockalike ISRU. I think that the SIMPLEX config packs does something like that, but I don't think it is updated against recent versions of Kerbalism. @subyng @afafsa We definitely have performance issues. And bugs. We are trying to improve the situation, but Kerbalism's codebase is huge and the result of many contributions from many different people that aren't around anymore.

@afafsa Kerbalism is an order of magnitude harder than stock, that's an assumed fact. Especially for manned missions. This said, I personally find science a bit too hard for my tastes. In the game settings I usually put the science reward to 200% (stock "basic" settings) and increase antenna bandwidth (in the kerbalism section). As for compatibility with Near Future electrical , we use our own converters for the nuclear reactors. It's barebones (no heat management) but functional. I suggest removing the "Dynamic Battery Storage" plugin, as anyway it won't work when Kerbalism is present and might cause issues (under investigation). We are fully aware this isn't very satisfying and will probably revisit NFE support at some point as we have (vague) plans for our own heat management system.

There is no setup for that in the default Kerbalism config. Anyway, Xenon "mining" doesn't exist. Xenon is produced by fractional distillation of Nitrogen and Oxygen, which is indeed something we could add to the converters. Unsupported / partially supported stock / mods resource producers. See https://github.com/Kerbalism/Kerbalism/wiki/TechGuide-~-Background-Simulation @John Nowak @baldamundo What is very likely happening is that you don't have enough drive space to store the full experiment result and less transmission bandwidth than the rate at which data is generated by the experiment(s). The way to detect that is if that your drives will be full while you are transmitting. The usual solution is to put bigger antennas. We are aware that you can't know what the antenna data rate is before using it (in the editor / planner), we will add that feature at some point.

@mdapol It's probably doable, maybe we can put this in the tooltip that appear when you hover on the file/sample in the file manager. We will look into it when we can, there are many more urgent issues to deal with at the moment. Putting this in https://github.com/Kerbalism/Kerbalism/issues/488

All of this. It was possible in KSP 1.2 with a few basic hacks and then since 1.3 they modified the upgrade handling to force all researched upgrades upon all parts (I can't remember exactly how but it's quite problematic to get around) Upgrades selection This allow to customize which upgrades are applied to placed parts in all modes (Career, Science and Sandbox) Parts with upgrades now have a clickable "upgrade widget" in the tooltip widget list Clicking on the widget show a list of upgrade widgets that can be toggled to enable/disable upgrades for this part Upgrades exclusivity/overrides rules and R&D unlock status can't be bypassed Vessels with customized upgrades will work perfectly if the plugin is removed, all this is done within the stock upgrade implementation. This other mod : Uses a completely different approach. It overcome the limitation by remembering the upgrade selection on a custom partmodule, and hacking the other modules from it. It's a quite heavy approach and I'm not sure it has ever become 100% functional. Do as you wish, but the OP image advertising the part selection feature is quite misleading IMO.

@zer0Kerbal Please create a new thread for it if you wish to officially re-release and maintain this plugin (which you can, no problem with that). This said, I will keep for myself my opinion on re-releasing with near-zero modification on Ckan and Spacedock a mod whose main feature (the upgrade selection) is 100% broken.