Gotmachine

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.

Stabilization when in stability mode is always available, even for command pods, this is intended. What is not available is pilot or SAS attitude changes, but even stability keeping when already "locked" on a SAS target (like prograde) is always available. The intent is to force you to use RCS for orientation changes while benefiting from the reaction wheels for stabilization. Maybe you are using ReStock ? I just released version 1.3 that should fix ReStock compatibility.

I don't know anything bout graphotron, but Kerbalism does not use the stock modules (it has it's own "Experiment" partmodule, so if graphotron is checking for the stock ones it won't find them.

Surface experiments / parts are not implemented as partmodules. The partmodules are empty shells that just are here for UI/user interaction, that's why their KSPFields are only updated when the PAW is opened. The data and game logic code is handled by always alive objects, all handled by a ScenarioModule. The reason is that those experiments have to run while the partmodules are unloaded. Summary of how it's working : Classic modules - "ModuleCargoPart : PartModule" is a module that does practically nothing (define the tooltip on a kerbal inventory part ?) - "ModuleGroundPart : ModuleCargoPart" define a part that can be placed on the ground, handle the placement logic - "ModuleGroundPart" holds a reference to a "ModuleInventoryPart : PartModule". This module handle the bulk of the kerbal inventory logic - "ModuleGroundPart" implements "IAnimatedModule" and handle the animations / deploy logic - "ModuleGroundSciencePart : ModuleGroundPart" is the common base class for all the ground experiment. It handles the power and solar panel related fields - "ModuleGroundCommsPart", "ModuleGroundExpControl" and "ModuleGroundExperiment" all derive from "ModuleGroundSciencePart" They have the specific fields related their specific game usage - Every deployed experiment part is a vessel. Science background processing - a ScenarioModule named "DeployedScience" is handling all science generation/power production/data transmission, both for loaded and unloaded cases - It has a list of "DeployedScienceCluster" (Monobehaviors), a group of linked ground parts that share power and antennas - "DeployedScienceCluster" has a list of "DeployedSciencePart" (Monobehaviors) - "DeployedSciencePart" is the always active object representing a ground part. it is independant from vessels/parts/partmodules - "DeployedSciencePart" hold the various fields / methods for the antenna and power generation/consumption logic. - "DeployedSciencePart" can have a single "DeployedScienceExperiment" field - "DeployedScienceExperiment" hold the logic specific to science data generation - All the game logic is handled by the scenario module. All the data relative to every cluster/deployed part is stored and persisted by the scenario module. On its update, it does all the data/power/transmit logic and search if the Parts/PartModules are loaded and update them. All those objects are independant from any vessel/part/partmodule. Scenario objects <> partModules communication is mostly done trough gameevents. - Solar panel generation : it seem to care about sunlight/shadow condtions only for loaded vessels. Unloaded vessels seems to be treated as always in full sunlight. - Seismic experiement : this one generate data when a part/vessel crash on the body. It does it by susbscribing to the onPartExplodeGroundCollision and onVesselExplodeGroundCollision gameevents

I am converting to scaledspace. I'm pretty sure of what I'm doing in this aspect as I can draw my intended lines using another method. They just don't show up when I'm using the DebugDrawer class. Although that work perfectly fine in flight mode/scene (with non-ScaledSpace coordinates, of course ;))

In KSP 1.7.2 I can't get the DebugDrawer methods to show anything in the map view, although it seems to me the class is meant to have the ability. Is there any trick for making that work (outside of converting the values to scaledspace scale) ?

Thanks. So, a quick follow up : from my tests, it seems that correcting the longitude for the mainbody rotation is necessary only if the reference frame is rotating (below 100 Km altitude at Kerbin), not once you get in the inertial frame. Edit : I'm dumb.