[0.25] RasterPropMonitor - putting the A in your IVA (v0.18.3) [8 Oct]

[LameLefty]

RPM is ONLY tested on 64bit. No, really. I don't believe there's a point to run anything else, so I don't even run the 32bit build when testing it myself.

Thanks for deprecating all the KSP players who use Macs. This is exactly the **** I expected when Squad announced 64-bit was Win-only. Sadly, I didn't expect it from such an otherwise-excellent mod.

Edited August 1, 2014 by Rich

[Padishar]

Thanks for deprecating all the KSP players who use Macs. This is exactly the **** I expected when Squad announced 64-bit was Win-only. Sadly, I didn't expect it from such an otherwise-excellent mod.

You have misunderstood what he said. He meant that he only tests his mod on the 64 bit version because his mod doesn't care what version it runs on and should work on both quite happily.

[nli2work]

RPM does get tested in 32bit. I do it by using the plugin to build IVAs. Any issues I contact Mihara and it gets resolved quickly. Whatever he's running on x64 runs just fine on x86. If you have an actual problem post it and it'll get resolved.

[Mihara]

Sigh...

Okay, I think I should elaborate on what I actually meant to say.

Unity is a game engine, but this term, in this case, involves a so called execution environment for managed code. Unity is a program in machine code that includes an interpreter for managed code. Most game engines these days do. In case of Unity this is Mono which is itself an open-source implementation of Common Language Runtime, which is originally Microsoft's platform which was created with the idea to improve Microsoft's reputation regarding things that crash for no rhyme nor reason, by making what is essentially a not-insane version of Java. It turned out to be so much not-insane that an open source clone was created and it became one of the decent things to make an execution environment with.

What this means in relation to KSP is that when a plugin for KSP gets compiled, it is not compiled into machine code that a computer directly understands. It is compiled into so called Common Intermediate Language. The Common Intermediate Language has no notion of being 64-bit or 32-bit or even 128-bit if that becomes the thing in the near future -- it is a programming language that a virtual machine executes, sort of a pseudo-computer not unlike an emulator of a gaming console many of you have probably enjoyed. That's where the notion of "managed code" comes from -- as the code does not directly run on hardware, but is instead processed by a program that runs directly on hardware, there's no way in hell it can possibly cause a crash of the entire operating system, it's easy to disallow it from doing something, it makes no difference whether it's a 64-bit or a 32-bit operating system, and in the whole, such an approach offers a lot of help in writing games in particular.

Now, notice that the DLL file you get in the package of RasterPropMonitor or just about any other KSP plugin (The only exception in recent memory would be Kerbcom Avionics, which included routines in actual machine code) has no notion of what 32-bit or 64-bit even is. In an ideal world, it would run absolutely identically in either a 32-bit or a 64-bit operating system, because the "Common Language Runtime", the virtual machine that actually executes it, would take care of the difference.

We do not live in the ideal world, because just like plugins have to contend with the rest of KSP, this execution environment lives within a somewhat greater monster called Unity, which is actually a program in machine code, that deals on the low level with entities like graphics drivers -- particularly those. It offers a large structure that is controlled by managed code -- both KSP and KSP plugins. And that monster, itself is either 32-bit or 64-bit.

And it's common knowledge by now that Unity x64 on Windows is more buggy than Unity x32.

Now, I test "ONLY" because that's the only thing worth running on Windows, and because the likelihood of tripping over a 32-bit specific bug which is not present in 64-bit Windows KSP is really low. I do not code specifically for 64-bit Windows (I do not actually concern myself with anything beyond interfacing to KSP's managed code in the first place so the notion of 32 or 64 does not even come up) nor do I plan to abandon anyone if they DO find a 32-bit specific bug that is not present in 64-bit.

BUT, if you say 'oh, I run 64 bit, this must be the problem, your plugin doesn't work on 64 bit Windows', you can't say that because that's where I always test it.

[Hodo]

TypeLoadException: Could not load type 'MechJebRPM.MechJebRPM' from assembly 'MechJebRPM, Version=0.16.5223.32098, Culture=neutral, PublicKeyToken=null'.
  at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool)

This looks like a stray MechJebRPM from all the way back in version 0.16. MechJebRPM now lives in JSI/RasterPropMonitor/Plugins so you have two, which seems to be the cause. (The actual cause is a variable handler not getting run after being instantiated...)

Thank you for sorting that out for me, I don't think I would have found that anytime soon.

[John FX]

Sigh...

Okay, I think I should elaborate on what I actually meant to say.

Unity is a game engine, but this term, in this case, involves a so called execution environment for managed code. Unity is a program in machine code that includes an interpreter for managed code. Most game engines these days do. In case of Unity this is Mono which is itself an open-source implementation of Common Language Runtime, which is originally Microsoft's platform which was created with the idea to improve Microsoft's reputation regarding things that crash for no rhyme nor reason, by making what is essentially a not-insane version of Java. It turned out to be so much not-insane that an open source clone was created and it became one of the decent things to make an execution environment with.

What this means in relation to KSP is that when a plugin for KSP gets compiled, it is not compiled into machine code that a computer directly understands. It is compiled into so called Common Intermediate Language. The Common Intermediate Language has no notion of being 64-bit or 32-bit or even 128-bit if that becomes the thing in the near future -- it is a programming language that a virtual machine executes, sort of a pseudo-computer not unlike an emulator of a gaming console many of you have probably enjoyed. That's where the notion of "managed code" comes from -- as the code does not directly run on hardware, but is instead processed by a program that runs directly on hardware, there's no way in hell it can possibly cause a crash of the entire operating system, it's easy to disallow it from doing something, it makes no difference whether it's a 64-bit or a 32-bit operating system, and in the whole, such an approach offers a lot of help in writing games in particular.

Now, notice that the DLL file you get in the package of RasterPropMonitor or just about any other KSP plugin (The only exception in recent memory would be Kerbcom Avionics, which included routines in actual machine code) has no notion of what 32-bit or 64-bit even is. In an ideal world, it would run absolutely identically in either a 32-bit or a 64-bit operating system, because the "Common Language Runtime", the virtual machine that actually executes it, would take care of the difference.

We do not live in the ideal world, because just like plugins have to contend with the rest of KSP, this execution environment lives within a somewhat greater monster called Unity, which is actually a program in machine code, that deals on the low level with entities like graphics drivers -- particularly those. It offers a large structure that is controlled by managed code -- both KSP and KSP plugins. And that monster, itself is either 32-bit or 64-bit.

And it's common knowledge by now that Unity x64 on Windows is more buggy than Unity x32.

Now, I test "ONLY" because that's the only thing worth running on Windows, and because the likelihood of tripping over a 32-bit specific bug which is not present in 64-bit Windows KSP is really low. I do not code specifically for 64-bit Windows (I do not actually concern myself with anything beyond interfacing to KSP's managed code in the first place so the notion of 32 or 64 does not even come up) nor do I plan to abandon anyone if they DO find a 32-bit specific bug that is not present in 64-bit.

BUT, if you say 'oh, I run 64 bit, this must be the problem, your plugin doesn't work on 64 bit Windows', you can't say that because that's where I always test it.

there is now a thread all about lamelefty complaining that windows has a pony and he doesn`t...

Myself I am glad you are testing in 64 bit so you can catch all the bugs. I love your mod and hope you carry on making it as well as it has been made in the past.

EDIT : "Not much of a feature, but Junk Systems Inc. now has a flag and will offer contracts in the same manner as the stock agencies do -- please don't blame me when those become silly."

Ooh, we get RPM junk contracts? Nice.

Edited August 2, 2014 by John FX

[Mihara]

there is now a thread all about lamelefty complaining that windows has a pony and he doesn`t...

The particularly sad thing is... He does have a point. Only it's not the point he actually stated.

What, exactly, is the benefit of running a 64 bit version of KSP?

1. Better performance due to not having to load invoke 32-bit copies of OS libraries when running in a system that is otherwise 64-bit? Not really, the performance drain from that is miniscule. KSP spends the grand majority of it's time computing physics on one core of one CPU, there's no appreciable difference.
   
2. Better memory management? Well... not really, because everything except physics that we're running is managed code anyway. In fact, I expect the 64-bit garbage collector is slightly slower.
   
3. More memory allocation? Yes, that is a very compelling benefit.
   

Well, it's in fact the ONLY practical benefit. It's just so important because KSP is so memory hungry, and we're all in this section of the forum because we like KSP mods. But why, exactly, is KSP so memory hungry? Unity includes native support for memory management and delayed loading. Unity graphics assets, packaged into *.assets files, are automatically loaded and unloaded as needed, by Unity itself. A programmer who writes managed code within Unity environment never has to worry about using too much memory unless they actually need most of their graphics all at once. Very few games ever do.

Only, KSP is not using this asset management system. Instead, it maintains it's own infrastructure to manage textures for parts:

1. Upon startup every texture is loaded into memory. Whether it's needed, not needed, whatever, it's there - it's loaded. That's what's taking so long, actually.
   
2. They are never ever unloaded.
   

Now, the only moment where KSP ever uses all of it's textures (with the exception for textures of internals, which do not get spawned during that time) is when giving a palette of parts to the user while the user is editing a ship. In all other cases, it would be pretty easy to only load textures for parts which are actually present in the scene, and throw away everything else -- KSP would run on 2-gig machines with thousands of mod parts just fine, and the delays involved in loading textures from disk would remain unnoticed among all the other mess that happens when you switch ships. Palette would be the only stumbling block, and it would be best circumvented by rendering every part into a flat image, loading those while in editor and only loading the rest when the part is actually spawned.

I was hoping they would do something of the sort eventually. The GameDatabase structure introduced in 0.20 looked like the beginning of such a mechanism, introduced to promote texture reuse, and offering a clear path to load and unload textures on demand.

Well, instead, they made those neat spinning parts in editor, which actually make unloading textures much more complicated, and ran off to make science (which I remain dissatisfied with), technology tree (which was and remains silly) and contracts (which are even sillier). And they gave us a 64 bit version which doesn't work particularly well to make up for it.

Basically, we need the 64 bit version because someone decided they will put off optimizing until later, but now it's actually too late, so they have to cover up one blunder with another -- because Windows 64 bit version is generally problematic enough to be called a blunder all on it's own.

...I actually said all that time and time again and I probably will keep repeating it, and nothing will change.

[Mihara]

Ooh, we get RPM junk contracts? Nice.

I'm actually not certain if the contracts really work. I mostly did that to get the company logo into the agencies rather than flags, because that's where it should, in theory, be. The logo works, whether the contracts actually get generated remains to be tested.

Not that I'm going to be particularly sad if they don't.

[Padishar]

The particularly sad thing is... He does have a point. Only it's not the point he actually stated.

I agree with virtually everything you say in your post except for this bit. "He" does not have a point because that is definitely not the point he was making. These are your points (and good ones too).

Oh, I don't totally agree with your assessment of science, tech tree and contracts though, there is only so much they can do and they want to reach their goal of "scope complete" before doing other improvements and optimisations. It doesn't make sense to keep optimising stuff as you go along as it generally makes the code harder to maintain and develop (though I do agree that some systems are so far from optimal that they should never have been implemented in their current form in the first place, e.g. texture handling).

[Mihara]

Oh, I don't totally agree with your assessment of science, tech tree and contracts though, there is only so much they can do and they want to reach their goal of "scope complete" before doing other improvements and optimisations.

My complaint here is not about whether it's optimized or not, it's about game design. My opinion -- which I don't hold as ultimate truth, but if you're in the thread might as well listen -- is that it's not working.

Prior to the introduction of science, my particular playstyle was about gradual colonization -- most of it only made possible with mods -- to reach further and further locations, primarily for their easter eggs. To say I've been there. It was a fun story about kerbals discovering traces of alien life and coming to terms with their universe in their clownish kerbal way. The story was interesting even though there were (and are) no answers to their questions. I've spent days upon days in the VAB, tuning the next lander, the next base module, building gigantic orbital stations and rebuilding them, sending them to other planets, and otherwise it was fun even if I had to make up my own goals myself.

It's not that I can't do the same now, since the sandbox mode never went away, naturally. However, I have, numerous times, attempted to play the same way with career mode. Every time it's been frustrating. Right from the start, I can't do anything because I don't have any parts to play with, I need to earn science. Once I blitz my way through the tree, which takes about ten hours at most, I'm so annoyed with it that I drop the save -- because it's been so tedious, and because sending science back home loses any meaning, it becomes, how to say this... No longer fun, no longer useful, and since it's been useful it can't be decorative. Contracts livened this up a bit, but they are so nonsensical that they clash with any attempt to inject narrative meaning into what's going on.

If the goal of the introduction of science and contracts has been to entice me to play longer, they have failed in that. What they might have succeeded is making things easier for new players, which is an obvious strategic goal since we don't pay a subscription, new players pay for the continuing development.

However, the primary driving vehicle for KSP's success was good word of mouth, and I'm having less and less of it to offer as time goes by.

[nli2work]

man, you are such a downer.

[Brucey]

Mihara. I completely agree with your above post. What I felt was missing for a proper career mode was some sort of structured storyline. I was hoping the addition of contracts would provide this through the contract descriptions and results dialogue. I think they really could have made it interesting by also incorporating the "Easter eggs" or other such anomalies in the missions to tell a story of exploration and discovery. Instead they'd went with "procedural" contracts which have no meaning. So all we really get is another random thing to try out. They didn't really make funds a valid game mechanic either, because the existing contracts seem to spam you with money. Hopefully, since the goal was "scope complete", the next step might be to address storylines and game balancing. Keeping fingers crossed....

[Mihara]

man, you are such a downer.

I'm a sociologist in Russia. What did you expect?

Before anyone says "it's easy to criticise" well, here's my constructive vision: It can be made much more fun, cheaply, at the cost of a few pages of code, now that the money system is in. It's not exactly practical to mod this in for technical reasons, because I'd have to run after KSP's own code with a flyswatter undoing the changes it just made to implement what I'm describing.

Decouple science from technology. In the historical space program, advances in planetology rarely, if ever, lead to new engineering insights. What gets them through is money, epic amounts of. Make the player pay with funds to acquire new technologies, and pay with funds to acquire new parts made possible by those technologies.

Keep the contracts as they are. (Well, make them more sane if possible.) They aren't the primary source of funding for any real historical space program, the primary source is taxes -- the contracts should be enough to gather funds to launch one more mission, not enough to pay through a new technology. How much funding does a space agency get heavily depends on how important does the government and the population consider spaceflight. I.e. prestige. Well, KSP has prestige values now, it's called Reputation. Make that Reputation slowly drain over time as kerbals forget the past glory, make it rise when something spectacular happens that would get on the news, like someone getting a Final Frontier ribbon. Make the yearly funding a function of total reputation acquired over the course of a year.

What to do about science? Feed it directly into reputation. Acquiring new scientific data raises the prestige of the space program among the scientific community, the more data you bring home, the more they lobby for you to get more money.

Keep all the components as they are, just connect them differently.

Edited August 2, 2014 by Mihara

[nli2work]

I'm a sociologist in Russia. What did you expect?

LOL. Touche!

Thanks for the informative posts, and the plugin.

[Pecan]

...Prior to the introduction of science, my particular playstyle was about gradual colonization ... to reach further and further locations, primarily for their easter eggs. To say I've been there. It was a fun story about kerbals discovering traces of alien life and coming to terms with their universe in their clownish kerbal way....

Totally agree. My tutorial is a sandbox campaign simply because that's the only way to structure missions, progress and the complexity of the required vehicles in a logical order. Satellites lead, manned orbital doesn't even happen until Chapter 4 (of 8).

What they might have succeeded is making things easier for new players

That's the thing I'm not so sure about though. Contracts of the 'test X part at NN altitude and NN speed' sort are a lot harder than they should be for people who don't even know how to design a rocket; especially as Squad won't even show total mass in the VAB/SPH, let alone give us a stock deltaV calculator.

[Mihara]

Bump for point release.

RasterPropMonitor v0.18.2

This is a bugfix point release to take care of problems that cropped up after all the changes introduced by KSP 0.24+

Some warnings for the users:

• ModuleManager 2.2.0 appears to work incorrectly in situations where multiple copies and multiple versions are present on the system. It didn't before, but now it's pretty clear that is the case.
  
• At least half the problems reported result from stray files left over from previous installations, including in particular multiple copies of MechJebRPM.dll (there should only be one, in JSI/RasterPropMonitor/Plugins) and stray copies of SCANsatRPM.dll (these shouldn't exist at all)
  

Bugs fixed:

• In certain cases, when used with transparent pods, RPM monitors could report initialization errors in editor, even though they work fine in flight. That's because some things they need simply don't exist before they go to flight, and as such, generate errors while in the editor. A few of such problems were caught and fixed.
  
• JSISwitchableVariableLabel would trigger a spurious configuration error warning if the label has no text.
  
• The ModuleManager patch to install the RPM-ified Mk1 pod IVA into every pod would also install it into the DERP lifeboat, where it would spam the user with error messages asking where's the IVA when the pod is not inflated. An exception has been added. Thanks to Kaa253 for catching this.
  

New features

• Not much of a feature, but thanks to ArcFurnace, the Basic MFD now has more data on the PFD screen, because it's a good idea.
  

[rabzoue59]

PFD screen

? So with RasterProp + MFD it shows some new things ?

[Mihara]

? So with RasterProp + MFD it shows some new things ?

http://forum.kerbalspaceprogram.com/threads/57603-0-24-2-RasterPropMonitor-putting-the-A-in-your-IVA-%28v0-18-2%29-3-Aug?p=1315337&viewfull=1#post1315337

[nli2work]

\o/; Initialization errors are gone in editor.

[rabzoue59]

Great thanks

[Hanzs Klopek]

Quick question here .. I've installed Raster Prop Monitor and it seems to work very nicely. I also added NavUtilities. I have the NavUtilities screen when I'm in IVA but can't seem to be able to see it when I'm not in IVA. I tried all the keys on my keyboard .. help please !?

[K3-Chris]

Mihara any idea why this causes an initiation error?

PROP
{
	name = B9_Fuel_Gauge

	MODULE 

	{
		name = JSIVariableAnimator

		VARIABLESET
		{
			controlledTransform = GaugeEmissive
			textureLayers = _Emissive
			textureShiftStart = 0,0
			textureShiftEnd = 0, 0.5
			variableName = SYSR_LIQUIDFUEL
			scale = 0,SYSR_LIQUIDFUELMAX
			threshold = 0.0,0.1
			refreshRate = 3
		}
	}
}

Trying to slide an emissive across a model to make a fuel gauge.

[Mihara]

Mihara any idea why this causes an initiation error?

PROP
{
	name = B9_Fuel_Gauge

	MODULE 

	{
		name = JSIVariableAnimator

		VARIABLESET
		{
			controlledTransform = GaugeEmissive
			textureLayers = _Emissive
			textureShiftStart = 0,0
			textureShiftEnd = 0, 0.5
			variableName = SYSR_LIQUIDFUEL
			scale = 0,SYSR_LIQUIDFUELMAX
			threshold = 0.0,0.1
			refreshRate = 3
		}
	}
}

Trying to slide an emissive across a model to make a fuel gauge.

1. refreshRate should be outside the VARIABLESET block. Not that this would cause an initialization error...
   
2. Are you sure such a transform actually exists and has an attached renderer?
   
3. For that matter, you have "threshold" in there, which would not make emissive slide across the gauge, it would flip it between states if you have less than 10% fuel remaining.
   
4. Seeing the log would be helpful, because the actual reason for init failure is logged.
   

[ofan]

Hi, thanks for the great mod. I got some strange problems from yesterday, and it only happens when I'm controlling in the cockpit and approaching to a station.

The target velocity displayed above the nav ball starts increasing rapidly. I used HyperEdit to put my vessel close to the target, and the same thing happens.

I'm running KSP 0.24.2 64bit on Windows8.1.

Here's the list of related mods I'm using:

RasterPropMonitor 0.18.2
ALCOR Capsule 0.9
ALCOR IVA Patch
SCANsat 6.1
vesselview
Kerbal Engineer Redux 1.0(new version)
NEAR 1.1.1
VOID 0.13
ModuleManager 2.2.1

The last error I see is "[ERR 23:56:23.935] RasterPropMonitorComputer: Processing error while processing TARGETALTITUDE: "

Complete KSP.log http://www./view/paxbev9bndqiucv/KSP_log.txt

[Mihara]

The last error I see is "[ERR 23:56:23.935] RasterPropMonitorComputer: Processing error while processing TARGETALTITUDE: "

Complete KSP.log http://www./view/paxbev9bndqiucv/KSP_log.txt

I get 'access denied' on that file, and anyway, that's the wrong file. You want KSP_Data/output_log.txt or KSP_x64_Data/output_log.txt depending on which were you running, the "KSP.log" file you find in the root KSP directory is far less verbose than needed to debug these problems.

But it sounds like the case in http://forum.kerbalspaceprogram.com/threads/57603-0-24-2-RasterPropMonitor-putting-the-A-in-your-IVA-%28v0-18-2%29-3-Aug?p=1322065&viewfull=1#post1322065 which was a stray MechJebRPM.dll -- the actual cause of the error is a failure in a variable handler module, and the failure is because the wrong version gets loaded.