Lennartos

Hi guys. I started getting a exception when opening the ISRU window. Here is what happens during load of scene: [ERR 14:54:07.687] Module InterstellarRefineryController threw during OnStart: System.NullReferenceException: at (wrapper managed-to-native) UnityEngine.Object:set_name (string) at FNPlugin.Refinery.InterstellarRefinery.OnStart (StartState state) [0x00000] in <filename unknown>:0 at FNPlugin.Refinery.InterstellarRefineryController.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 And when i open the window i get: ( one per frame ) [EXC 15:05:15.309] NullReferenceException: Object reference not set to an instance of an object FNPlugin.Refinery.InterstellarRefinery.Window (Int32 window) UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) Everything else seems to work, its been a while since i last used the ISRU so i don't know which update broke it. Any ideas? as for info: Im playing with the full USI(pretty much all of roverdudes mods) and all NearFuture mods + Extraplanitary launchpads.

Hi there. SETI rebalance causes quite a bit of issues with entrycost changes. Some parts for some reason have costs which are floating point values. Like for example near future parts or Extraplanitary launchpads. (Issue: Entry cost is using int.parse and will choke on the part of it contains a floating point value) I have been replacing prices on the parts i need, since i like the current entry cost balance that SETI gives, But isn't there a way to truncate a float value to integer with module manager so we can fix this in the script once and for all instead? Like Round/Floor/Ceiling? ( i couldnt find in the docs i saw, but i never modded before :))

That's exactly what i mean, if no one reports to squad that the system isn't working as intended - it wont be improved in any release.

I just went through the bug list - didn't anyone report the issues with tech upgrade not working as intended - or are these already closed for next update?

I would use both if i could... would make more sense to ask after 1.2 has been updated with engineer and MJ

Just wanted to suggest to check out just this. The only question is if its possible to stack the change of parts by tech nodes. It it indeed stacks, then it should be relatively simple to create fake tech nodes for each part where you change its stats. KRnD has become one of my essential mods - i'm still waiting for it before before launching my new 1.2 game

See the Modding notes of 1.2 there is a entire section with PartModule Upgrades

Integrated into 1.2 Thx SQUAD

Thats a bit of a grey area - since if handed by tech requirements that case isn't that much different from it lacking the un-upgraded part. If we take @pandaman 's idea then essentially you could get the warning that you still need to unlock LV909-C or tech xyz to fly that craft as intended...same way as how it currently tells you that a part is not unlocked yet. I only play career mode, and don't share crafts with others, so i have little experience with how it usually goes though. But you still need to have at least the same tech level as the components used to create the craft in either case. In this case if you ignore the above warnings you CAN still build & fly the craft, but it could lack critical components like antenna in cockpit, have less fuel ( fuel in wings unlocked ) or cannot endure the stress of re-entry heat due to low material tech( increased temp range for all components )

Ah yes, I'm actually playing with that mod atm.. It adds a lot more value to research points, and also makes it a harder decision what to spend it on. However it is a seperate part based layer similar to tweakscale ( instead of scaling size for increased money cost, you reduce component weight etc for a cost of science points ), also it only changes basic values and isn't tied to research at all. Even worse is that since its made the same way, it has conflicts with other mods that change the parts ( tweakscale, fuel switch etc), which other mods like KSPIE depend on. But it would be a good place to start for making a tech based system.

After playing KSP for quite a while ( still loving it ), it really started to annoy me that we don't have a way to handle proper upgrades through research in the game. Usually even older Parts would become more useful as new tech is researched. Upgrades could include: * Changing base values like Increasing radiator heat transfer, or engine ISP / thrust. Or decreasing weight of parts ( like fairings ) with research of better materials. * Adding/Replacing "modules" to parts, like adding / upgrading default antenna on command pods. * Adding ISRU options though unlocking more tech ( or change efficiency etc ) Some of these are already possible through clever use of module manager and a hack that involves replacing parts ( what KSPIE does ) or solved through scripting, but replacing parts is very limited in terms of modularity and worst of all the ingame GUI isnt able to explain whats happening at all. How about adding support for this in the base game, so we can see what passive bonusses im getting as well..? Advanced Enginering: All engines -5% Weight LV-T 30: +10% VAC ISP All Fuel Tanks: +5% Capacity Custom Build Fairing: Max Radius +0.5m Panel Mass: -10% Alternatively we can solve it with C# scripting, and just allow mods the ability to write TEXT similar to the above in tech screen to explain what the code will do under the hood. Any other ideas suggestions?

Looking forward to your work Linuxgurugamer, any chance you can fix all the unwanted popups of the GUI as well?

Had same issue here, there is a workaround though - go to scansat settings and disable the "imiidiate" mode of the scanner, so it works like all the others... then you can complete the mission

Great Mod! Any chance that you might add the same for inactive / target vessels ( in different color maybe )? knowing when the target will be at a specific place and its altitude would really make my day Would be especially useful for catching asteroids since getting the maneuver nodes to work on a target that is still outside the current gravity well is hell atm.. and timing science that requires alignment between several vessels... like crash!... where you need to know when target is at a certain point of the orbit + full orbit time ( lots of vessel switching done there )

Looked through the code a bit Quite a lot going on, many modules taken into account. Looots of string comparissons etc, and even worse is string parsing and splitting.... you will propably need to make some more detailed profiling on where it pays off more to improve, maybe EPS indeed is a big chunk... But if its not, then i see no other way than not to rebuild the entire data 30 times a second. There has to be a way to reduce the calculation needed, and only check production and consumption without doing all the hard work of building the part tree

1) you have done this a lot longer than me, but as fra as i have seen in the log im assuming that one can detect a change of active vessel, and propably undocking / staging. so reusing the same list for lets say an entire second or until vessel changed somehow shouldn't be that bad to do? 2) i see that, but there has to be code that doesnt nee to be calculated for each frame... most calculations should be just fine once per second instead. 3) 1 active vessel, 95 parts beeing constructed of 2 docked vessels ( my mun station ) - Image below As you can see in the image i'm not running 1:1 time after installing this mod and even a simple station like this. My biggest interest is actually the nighttime calculation, seeing if i can survive in a specific orbit while in VAB..emergency power is a nice addition, but not at this cost

Hi there. Is there a way to reduce the per frame CPU load of this mod? AmpYear is king of all mods in regards to used CPU load and garbage created.. which honestly has reached a level that seems a bit excessive. https://onedrive.live.com/redir?resid=715EC76A10372B02!12143&authkey=!APYWXCtAf0Qcy1U&v=3&ithint=photo%2cpng

Hi There great work with your mods, enjoying them throughly. I do howoever have a issue that is breaking my progress, and i'm not sure what the cause is.. however the beginning of the bug starts with a NullReferenceException from conract configurator, so im guessing it starts there. The issue is docking between 2 ships ( mun station and a new extension ) Everything is ok until they are docked and a few seconds after that - but after a few seconds error starts to appear in the log and the ship suddenly accelerates without any cause and tries to reach the speed of light Full Log: https://www.dropbox.com/s/iggrrgok48oh59g/SharedLogFiles.zip?dl=0 The error that makes them zoom away: [EXC 23:38:18.623] NullReferenceException FloatingOrigin.setOffset (Vector3d refPos) FloatingOrigin.FixedUpdate ()

Just tried serbians profile hack again, and this time installed 5.2.4 instead of using the 5.3.1 i already use for a project. Now i actually get correct profile data, and a basic overview. Its not something that the average user can do, but at a glance i can now see that a really big sinner is ampyear, consuming an entire 4ms + allocating 358KB each frame.

very interesting Padishar, will test immidiatly. But sounds to me like you almost solved it all already. If PatchAsm could also auto insert your profile code automatically in all the assemblies with assembly name + class name filled in ( attaching to basic entries like updpate etc ), then we would already be golden for a quick overview. And again: we dont need another profile method for code we created ourselves, thats what serbians hack is for - the point is to oveview ALL code paths and detect anomalies ( something broke / is incompatible ) or general resource usage ( so we know cost of specific mods ) Even better: we would have memory + profiling in one tool.

As for performance i got a few ideas: 1) its disabled per default, once activated we sum all times together until deactivated again ( we then show accumulated performance statistics or measurement window) 2) we already know that its single threaded, so there is actually no need for more complexity than a single stopwatch and then just get the elapsed time on each sample start /end. The speed cost during those few seconds is neglible and easely acceptable since it doesnt affect runtime performance for end users The only real cost is checking/detecting if the mod is installed and then skip the code. Whats the best way to solve that?

Well only if it would be official from SQUAD would modders likely integrate into all, but yeah - making our own solution might be a first step to general acceptance. I have never made GUI inside KSP - im thinking we will need something to simulate a treeview to hide away internal "inclusive" nodes until wanted. So + button to expand a node - do you have the necessary knowledge to do that atm?

Yes, if the cause was a mod, and i already knew which mod was causing the issue i could debug that single mod and solve it. But thats not really solving the issue, which is figuring out WHICH of the 130 mods i need to look at - or if its a mod at all. We simply lack some very basic tools to get a overview over whats happening - WHY is FPS low - what part of the code/game is slowing down. Anything i say more would essentially just be repeating the points above. Finding a known issue, in a known filebase (which mod / part of the codebase) that is easely reproducable is a lot different from finding "random" slowdowns that only happen after playing a while. The second DO happen, and my game still isn't that fluid atm and i simply have no chance of knowing whats causing it without recompiling 130 mods and hoping i will get lucky. Dictionary with stopwatch would be a few hours / single day well spend for future patches.

Yes i tried that as a end user to track a slowdown i had, which made me create this post. While this hack does allow one to test ones own mod, as a end user its not helpful at all. 1) because 99,9% of all lines are just mono.dll or unityengine.dll calls with no info since its not a full debug release with the necessary pdb files, 2) because there is no consensus that this has to be supported offiicially, mods dont release the pdb files with their mods either. So i can only see that something is taking up time, but i can see the same info inside the simple FPS viewer. What is missing is a way to see if its a MechJeb feature that is using 17ms per frame, or Remote Tech... or some SQUAD function, like calculating resources or the new wheels code - so you can report the issue to the correct person... which then can track it with debugging their own code. Atm its just guesswork and many many hours spend uninstalling and reinstalling folders and mods to circle in what can be the cause. Which means its really not useful for tracking real life situations ( bug only appears after long duration and in combination with x ) - only once a bug has already been confirmed and found a way to recreate it will this help to advance the tracking of whats wrong. So either we need to promote debuggability, and provide pdb files as default for this ( which requires people to be power users with coding & profiling knowledge to report better error reports ) ... or we need basic profiling support so its just a matter of reading a simple list box that anyone can do. EDIT: And as far as modders are concerned, there is simply no way to test a mod in all possible combinations with other mods / Real life situations. "In game" profiling would allow to collect data from the actual users, beyond the developers controlled environment, and detect conflicts/issues by simply comparing data from multiple users,

While we do have a FPS view under the debug window we lack any kind of info on what exactly is affecting the speed. This wastes a LOT of unneeded cpu cycles and end user performance, since modders dont have access to a proper profiling window and thus cannot estimate the CPU cost of their mod effectively. ( which in turn means un-optimized mods or worst case someone doing per frame calculations since they don't feel a drastic draw-down using only a few mods ) I heard you are using the default unity update loop logic and thus are not directly in control of calling the updates ( which could be a effective improvement if you take the amount of classes attached to each object in regard - see http://blogs.unity3d.com/2015/12/23/1k-update-calls/ ), So you cannot enforce profiling by yourself - however using a simple stopwatch list and dictionary with some public access functions you can allow both yourself and modders to add named entries into a list which allow a quick view of the innards of whats taking so long. Often the cause of slowdowns can be incompability between mods or just issue with version updates like we just had with 1.1.2, and as a end user i at least had a very hard time figuring out exactly which mod was causing the issue (131 installed mods and counting)... I'm thus proposing a simple piece of code like unitiy's profiler: KSPProfiler.BeginSample("MyPieceOfCode"); KSPProfiler.EndSample("MyPieceOfCode"); Once EndSample is called you check the correct stopwatch and insert its elapsedtime into a dictionary with the name as key, and show under the default F12 FPS view as a list, It would be up to SQUAD and the modders to add this to their code for now, but it would be a very helpful tool for everyone involced and allows us end users to get a idea of whats causing our < 100 part craft to snail along with low FPS and horrible simulationtime ratio.