Warezcrawler

I am missing the old MKS-lite. Simpler resource production chains, simpler everything really. So I've been working on simplifying it, and when good enough share it. Currently I'm looking at simplifying the Kerbal types back to the stock 3 ones, while retaining the skill sets in a meaningful manner. For that I have a question. I have tried to remove the many new types of kerbals added into the game by this mod, but currently it's like the old ones are enhanced, but the new ones still remain, somehow. @RoverDude What elements do I need to consider in order to simplify this aspect of MKS? Advise would be deeply appreciated. This is what my last (failed) try looked like (MM):

Thanks. That was what I was trying to avoid, but there is probably not a way around that.

I have a question which I have not been successful in answering through google/wiki etc..... I have a module I want to add to harvesters. Easy. However, this module I need to give a specific value only when a specific other module is present in the part. How do I achieve this? Example based on a drill in the karbonite parts pack. //Specific for one part is for testing purposes @PART[KA_Drill_Radial_01]:HAS[@MODULE[ModuleResourceHarvester_USI],!MODULE[ModuleResourceHarvester],!MODULE[GTI_MultiModeHarvester]]:FOR[GTI] { MODULE { name = GTI_MultiModeHarvester availableInFlight = true availableInEditor = true useModuleAnimationGroup:HAS[ModuleAnimationGroup] = true //??? } } It is the "useModuleAnimationGroup" field I want to set to true when and only when the corresponding module is present. From the wiki I know I can check for a specific other mod like As I understand the :HAS[] expression, it searches inside the node it is declared on, right? That would mean what I am trying can only fail, right? But if that is right, then what is my best alternative?

I too am missing the old MKS-lite. Simpler resource production chains, simpler everything really. So I've been working on simplifying it for myself, and if good enough share it. However, it is a lot of work. For that I have a question. I have tried to remove the many, many, many new types of kerbal added into the game by this mod, but have just ended up removing them all, somehow. Can anybody point me in the direct of how to remove the new types and add the new abilities to the old 3 ones. (I really like my game simple and entertaining, rather that real like). This is what my last (failed) try looked like (MM): Even through I did not try to delete the Pilot/Engineer/Scientist they still got removed from the game.....

I get some nre's from eva enhancements. I hoped it was just because I had not updated to the latest version (0.1.8).... But sadly is did not solve the NRE's.... I don't know if this log segment is sufficient. If it is not, here is the full log. I hope the fix is simple.

I order to get the animation right, you need to look into how it works through the effects nodes. And while on the subject of multi mode engines, you could check out the GTIndustries mod.... It is basically only doing multi mode thingi's

So I've been looking at utilizing the CustomParameterNode to get the configurations incorporated directly into KSP. However, I cannot figure out how to sort the elements in the settings menu. I thought that the sorting of the elements in the class would be inherited to the menu... Seems I was wrong. But I haven't been able to localize a sorting parameter for the elements. I have the following elements String heading for event settings Bool for activation of events integer for how often the check for the event integer for how fast to repeat the check just after it has been last found true String heading for debugging section Bool for activation of debugging messages in the log custom enum for level of debugging messages. Now when I run the game to sorting is different, like String heading for event settings Bool for activation of debugging messages in the log Bool for activation of events integer for how often the check for the event integer for how fast to repeat the check just after it has been last found true String heading for debugging section custom enum for level of debugging messages. And this does not make any sense to me, so I want them sorted. Does anyone have a suggestion on how to proceed??

If you don't need the vessel module abilities in the VAB, you could consider using a KSP add-on which only runs when in the VAB. But I guess you have already considered that?

Well, I think that if you do heavy calculations, then creating a new thread would be the way to go (example can be found in the linked GitHub code below). If the calculation is light using update() could be fine, many modders use this approach where they check for simply criteria. You can easily subscribe to an event like the above ones which is a great way of having you code only run on demand. And if a suitable event already exists then that would be my recommendation. Coroutines can be used if you want some code to run much less that e.g. the update() or fixedupdate(). Coroutines are apparently much less demanding than using "Invoke", according to the research I've done on related topics. You can have the coroutine only run e.g. every 5 seconds if that is what is needed. I do think that could be more efficient that counting frames, though both should be quite light. If you need a custom event, I would recommend reading this thread I also posted some question regarding throttle event, where there might be some interesting facts. Furthermore, I created the onThrottleChange event, which you can look at if you go for a custom event https://github.com/WarezCrawler/Guybrush101/blob/master/GTI_Utilities/GTI_Events.cs The code also have an example on subscribing to an event. Subscribe: https://github.com/WarezCrawler/Guybrush101/blob/master/GTI_Utilities/GTI_Events.cs#L58-L63 Subsciber: https://github.com/WarezCrawler/Guybrush101/blob/master/GTI_Utilities/GTI_Events.cs#L195-L204 I know the code is commented out, but that is only because it was not for the final release, only for testing purposes.

If you create a new thread, I've noticed that if that thread call a coroutine, then that coroutine is executed on the main thread. Maybe that could help you. So I'm thinking something like calling a coroutine when the calculation in the thread finishes.

OK... I'll add it so that the Multi Mode Intakes are not added at all when KSPI-E is installed. Then you can activate what you think is relevant in regards to this. Makes sense to me, since KSPI-E is a mayor mod, while mine is for some isolated features enhancements. I'm just updating now. EDIT: I added the "NEEDS" part, but have not tested it. Hope you will revert if anything is wrong. Thanks.

Actually you could argue, that it would be enough to change the property "checkForOxygen" on the intake instead of the resource.... That way we could all just use the intake as-is.... This is basically the only real change when we turn towards the IntakeAtm resource anyways..... I will make the change to my mod as requested.

I seems that we are conflicting because of the MM of multi mode intakes. Here I apply it to most intakes, and removed the intakeAtm.... I do this, because of the fact that having two intakes is the opposite of the purpose of the multi mode intakes module, and that it reacts really funny when this is the case. @PART[*]:HAS[@MODULE[ModuleResourceIntake],~name[NuclearJetEngine],~name[M2X_RadialAASRB],~name[M2X_RATO]]:FOR[GTI] { MODULE { name = GTI_MultiModeIntake availableInFlight = true availableInEditor = true resourceNames = IntakeAir;IntakeAtm checkForOxygen = true;false } } @PART[*,!M2X_RadialAASRB,!M2X_RATO]:HAS[@MODULE[ModuleResourceIntake],@RESOURCE[IntakeAir],@RESOURCE[IntakeAtm]]:FOR[GTI]:FINAL { !MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAtm]] !RESOURCE[IntakeAtm]:HAS[#name[IntakeAtm]] } As you can see I already had to do some stuff because of some MM in "Mk2 Stockalike Expansion" mod. That said, we can look at at least two approaches to solving the conflict. Either KSPI-E is changed so it does not assume this anymore, but as KSPI-E is a large mod, that could take some time to work out. And you might not be interested in compatibility of that plugin? Alternatively, I could add ":NEEDS[!WarpPlugin]" on my end. What do you think? Originally I wanted the intake to switch like I do in the converter and MultiModeEngineFX, but for some reason that did not want to work....

I'm sorry, what exactly are you trying to achieve? Are you running some heavy calculations? or are you more looking for some specific event to occur?

[1.2.2] GTI Utilities v1.4 New event called "onThrottleChange" added. It is running only in flight in separate thread, and should therefore not impact performance on multicore processors in any significant way. It is detecting changes to the throttle, and fires when it changes. Added new "throttleISPCurve" to GTI_MultiModeEngine Added "usethrottleISPCurve" semicolon separated bool list to GTI_MultiModeEngine ISP will be calculated as the atmosphereCurve value (ISP) times the evaluation of the throttleISPCurve, where time = throttle. Value is between 0 and 1. eg. throttleISPCurve { key = 0 2 key = 1 1 } meaning double ISP at zero throttle, and normal ISP at max. The module GTI_MultiModeEngine now overrides the "thrustPercentage" field (UI_RANGE) of the moduleEngines, so that the new ISP curve updates as it is supposed to do when the thrust limiter is changed. Centralized some GTI global settings in "GTI_Config.cfg" - settings for debugging will be moved from individual modules to the common static class General cleanup and moving stuff around between the class' To use the new throttleISPCurve for GTI_MultiModeEngine, you need the following ISP is then calculated as the ISP in the "atmosphereCurve" * ".Evaluate(.requestedThrottle) of the throttleISPCurve". requestedThrottle is the throttling the engine is asking for. This incorporated the thrustlimiter as well as the global throttle. I created this throttleISPCurve because I could not get the stock thingy to work. This one is a bit less sophisticated (design choice), but I think it works. Hope you will enjoy.

I've run into something I just can't get my head around. I created a custom event and wanted to have my parts module listen for it, but I got some errors because it was "listening" for the event 3 times. On investigation, I found that the OnLoad(), OnStart() and OnStartFinished() methods was called exactly 3 times on startup of scene for my module. Now I can find anywhere where I do anything more that use those methods once. Therefore my question is. Have anybody seen this behaviour before? Are anybody aware why this could happen. Normally it does not mess up my plugin is it is executed more than once, but in this case it is important that it is only done once! An observation I had was, that even if I introduce a bool, which I switch on first execution, the next one does not recognize that, and reports it to the log as false still - it's like it is a new instance, but why..... I've gone through my save file to see if my module was there more than once on my vessel, but I could only identify the one. I'm testing on the simplest craft I can think of. Command module, fuel tank, engine. My module is in the engine part. So again, have anybody observed anything like this? I'm definitely still working on the assumption that the error is mine, but I'm trying to gather information. EDIT: LOL....... Just notice, I had another craft at my space center on the runway, and it had two engines...... Nevermind!

I haven't profiled it as such, and your point of specific impact of my code was also pointed out by blowfish. And I do not see it to be a problem if it was my mod only. But we are all piling on, so I just aim at not creating a mod that have unnecessary performance impact. When running with 100+ mods, this is snowballing. Every modder can approach this as they want, but I want KSP to run as smoothly as possible - and I do love that the core game have been optimized a lot since 1.0! And my point here was to ask if KER intentionally wanted the behaviour of running code in mod's using GetModuleCost() all the time. If it is intentional and with good meaning, then that is just that. If it is not, the dev might look into changing that at some point. All good intentions only. And in the meantime I will do on my end what I can to keep my mods as light weight as possible.

How can it be premature optimization, when I just want to avoid having irrelevant code running each frame. But yes, I'm looking at reducing the code running to just be lookup of a value, and then changing the value at the right time.

I managed to create my first event, and it is even running in a separate thread. So event if I stress it, KSP keeps running smoothly, which it does not do if I do the same using coroutines. I sharing it, for all those who are struggling with event's, thinking it could help somebody. https://github.com/WarezCrawler/Guybrush101/blob/master/GTI_Utilities/GTI_Events.cs First I initialize the event in it's own static class, which runs at the main menu. [KSPAddon(KSPAddon.Startup.MainMenu, true)] public class GTI_EventCreator : MonoBehaviour { public static EventVoid onThrottleChange; private void Awake() { Debug.Log("[GTI] Event 'onThrottleChange' Created"); if (onThrottleChange == null) onThrottleChange = new EventVoid("onThrottleChange"); } } Then in another class, I start the detection of the throttle to change. It starts a parallel process when in flight, which is cycling and checking the state of the throttle while in flight.

I've been working on adding GetModuleCost() to some of my modules, however whenever I do, the thing start spamming my debugging logs. As far as I've been able to gather, it is not supposed to do that. Now blowfish was really helpful in advising me in how to track the behaviour back. Based on using " System.Environment.StackTrace" the log showed that Kerbal Engineer was seemingly was implicated. I have no idea if this is a known behaviour of KER, or a bug which might have creeped in when functionality in KSP evolved. But now I've tried to make sure it is known about. I hope this is something that can (and will be changed/fixed). I am considering not using GetModuleCost() / IPartCostModifier until this is not an issue anymore as I am very focused on having my mods being light weight. Highlights of the log Full log file

This also seems indirectly related to my request way back in the thread. I know time is a rare resource for many of us, but when the issue is being addressed it would be great to take the relevant bits and pieces into account.

The mod in itself targets others mod makers primarily, since most of the functionality needs somebody to incorporate it into parts. I am personally using it heavily I'm my personal mod I'm having along side other mods. That said there are some MM included with the mod, which I will come back to, as well as some example parts I made as show case (unbalanced). The theme of the mod is currently "orbiting" multi mode... If you are familiar with Interstellar Fuel switch, or any of the other fuel switch mods out there, then you basically know what it does. Mine is just currently targeting engines (a generalisation of the stock multi mode for engines, which have two modes only), intakes, converters. Then engine multi mode plugin actually have two different modules since animations are a pain. To you second question, what is atmosphere curve - I'm guessing that since you ask you are not familiar with any of the curves of the engine modules. Before 1.2 there were 3 different curves that could affect the performance of any engine in KSP. atmosphereCurve velCurve atmCurve The first one is mandatory, while the other two are optional. These are technically called floatCurves in KSP and are using Unity AnimationCurve. Basically it is a method where you can describe any curve using Time, Value, inTangent, outTangent. For any such curve the interpretation of time and value is important. Curve Time Value atmosphereCurve Atmospheres of pressure, where 1 = Kerbin Sea Level Specific Impluse (ISP) velCurve Mach value Thrust Multiplier atmCurve Atmospheres of pressure, where 1 = Kerbin Sea Level Efficiency, how much thrust can be provided at that pressure. So these curves combined defines how much thrust, and how efficiently you engine runs. There are two new curves with KSP 1.2, which in theory also let's engine ISP be linked to the thrust, but I have yet to figure out how it functions. I hope this answer helped.

@FreeThinker FYI.... I have added the mod to SpaceDock, and through that CKAN.

Thanks... Am I right when I read it as, it is simply easier using CKAN when hosting on SpaceDock compared to other solutions?

I updated the heading, thanks. CKAN..... Well never used that, what does it take to use it? Do I have to upload a specific place or something?