Jump to content

Mihara

Members
 View Profile  See their activity

  • Posts

    1,511

  • Joined

  • Last visited

 Content Type 

Posts posted by Mihara

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

    in KSP1 Mod Releases

    Posted

    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.

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

    in KSP1 Mod Releases

    Posted · Edited by 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.

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

    in KSP1 Mod Releases

    Posted

    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.

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

    in KSP1 Mod Releases

    Posted

    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. :(

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

    in KSP1 Mod Releases

    Posted

    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.

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

    in KSP1 Mod Releases

    Posted 


    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...)

    Just completed my first IVA landing on Minmus in my let's play. It was both awesome and scary as hell. I'm deeply sorry I didn't install this mod sooner!

    Somehow, RPM never caught on with big youtubers, not sure if it's because it's not photogenic enough or because there's a hidden conspiracy. :)

    hi, I seem to have a problem with this mod I'v gotten it working before but after a ksp crash, all of the IVA's have returned to the default even if I uninstall and reinstall the IVA's still don't change the game however precedes to function normally.

    Missing ModuleManager.

    I had some problems with KSP 64bit, kept shutting down on me everytime i'd go from hangar or rocket bay to launchpad. I found the problem on the log file with Raster Prop Monitor and I deleted the SCANsatRPM and RPMPodPatches folders as per the errors in its loading those and now everything is fixed up and works fine. I do have the Black MFD mod running

    ...I started writing a long lecture on how can I figure from this statement that this installation has been broken for a while and now became considerably more broken, and then decided I don't have the time for it.

    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.

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

    in KSP1 Mod Releases

    Posted · Edited by Mihara

    Any idea why this is happening and how I can fix it?

    You can't. Congratulations, you've found an honest, real RPM bug. :)

    Working on it.

    EDIT: Found it. Please download the dev build (you can find the link to the current dev build on the first page of the wiki if you actually read it) and confirm whether this fixes the problem or not.

    Looks like I'll have to publish 0.18.2 soon. :)

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

    in KSP1 Mod Releases

    Posted

    VexcomHUD for RPM. It also adds a hud to Cupola POD.

    Adding this to the list of extra things in the OP. :)

    Has anyone done FAR integration yet? I rolled this early this morning, finished it up tonight.

    Woot, more plugins. :) Mind you, the best thing would be to stick that module inside FAR itself, but that depends on Ferram, etc.

    I was curious if other than action groups if there was an addy to trigger things like experiments without leaving IVA?

    You can directly trigger an animation on pod exterior, and if that's not enough there's always action handlers: https://github.com/Mihara/RasterPropMonitor/wiki/Action-handlers

    Doh, is there no way to combine them?

    There is, two actually. 1. An animation can also animate a color change. :) 2. You can have one module running an animation and another module changing the color of the same gameobject, both living within one prop, it will work.

    know what should be nice? If there is a external program to render these panels... so we can use other pcs and monitors to show them to build custom simulation cabins... :P

    Alas, I get asked this often and it is considerably more complicated than it sounds. It's easy to push the picture out in one way or another, it's not that easy to do it fast enough.

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

    in KSP1 Mod Releases

    Posted

    I did a search through your doc on setting up cameras but it didn't have anything on using them.

    Doc section on "Setting up cameras" refers mostly to camera transforms built into the pod itself. With external camera models when you're using JSIExternalCameraSelector, you need to also check the section of the doc describing JSIExternalCameraSelector: https://github.com/Mihara/RasterPropMonitor/wiki/Part-modules#jsiexternalcameraselector

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

    in KSP1 Mod Releases

    Posted

    I realize you don't have much control over this, but any ideas why it happens?

    Most likely, it's the lecture at http://forum.kerbalspaceprogram.com/threads/57603-0-24-2-RasterPropMonitor-putting-the-A-in-your-IVA-%28v0-18-1%29-27-Jul?p=1297893&viewfull=1#post1297893

    However, I see the old model from pre-RPM 0.17, which is no longer bundled with RPM in the first place, in a stock IVA edit. Which implies incorrect installation and possibly multiple copies of ModuleManager as the actual cause, as described in http://forum.kerbalspaceprogram.com/threads/57603-0-24-2-RasterPropMonitor-putting-the-A-in-your-IVA-%28v0-18-1%29-27-Jul?p=1297818&viewfull=1#post1297818

    K-P0110 - Apollo-like crew module, now with source files included

    in KSP1 Mod Releases

    Posted

    Hey look, an RPM config! Alright, it's time to fess up - this summer I'm basically not using the computer outside of work, I'm either diving, getting drunk or hanging out so I won't even pretend I'll be doing anything with this soon. Maybe in a few months, but right now, since there's still interest in this wacky pod, I'm totally willing to give up all the assets to someone who'd be willing to finish it. Heck, I might just opensource it and let anyone who wants to go at it :)

    Don't drop it, or at the very least, let it go free. :) I like it much more than I like the stock Mk1-2 for the same applications, I even keep a set of specially edited parts to go with it -- modified service module and RCS ring from NovaPunch, modified SDHI parachute docking port...

    [0.23.5] Kerbal Space Industries [26APR14] [MFD 1.2]

    in KSP1 Mod Releases

    Posted

    Haven't had a chance to look at this mod too much yet, but it looks amazing. Is there a way to bind keys to each of the MFDs buttons? I have a set of Cougar MFDs that would be awesome to be able to use for this!

    There isn't, awesome as it would be. It is not impossible, but isn't really practical to implement for the following reasons:

    1. RPM is at the mercy of Unity's input routines, the number of input keys is limited, and most are already occupied. Making RPM listen to joystick buttons would be no problem, the problem would be making sure you can configure them, because the game's native GUI will certainly not support this in any way. I suck at GUIs, or I wouldn't make what is internally essentially an 80s-era terminal on acid. :)
    2. Due to the way KSP's internals work, IVAs get destroyed and recreated multiple times per flight -- basically every time you switch vessels, which includes going EVA, the entire process of RPM loading pages into memory and sorting out it's complicated internals has to start anew. (which is why on 32 bit, out of memory crashes are most likely at that moment with RPM -- the old copy has yet to be picked up by garbage collector, the new copy tries to bite out a chunk to live in) Key assignments would need to be kept somewhere, they would need to be configured per pod, (Most pods include more than one copy of the exact same RPM prop!) or possibly, per flight. These settings would need to be stored somewhere. This is nontrivial, as in KSP, modules that run internal props do not have equal rights with modules that live in parts. -- for example, they don't get to save their data into persistence files. I had to jump a lot of hoops to circumvent that, and I don't at all like the way I ended up doing it.
    3. The only reasonable way to do that while keeping all the advanced button tricks, like multiple screens sharing buttons, is to stick the listen-for-the-key function into the button handler class. Which is not too hard either, but would require jumping a lot more hoops to a) record the data about your key assignments somewhere that doesn't stand a chance of getting wiped out in the next second, B) making sure we can get at that somewhere when the whole thing is created again and find out what key did you assign. Button handler class isn't even a prop module, it's just a simple MonoBehaviour and gets treated like dirt.

    In short, it's possible in theory, but needs some hero with a lot more spare time to implement, because it involves a lot of running around the deficiencies in KSP structure.

    [0.24.2] JSIPartUtilities -- a mishmash of clever things to do with parts.

    in KSP1 Mod Development

    Posted

    Nice. Question, toggling PartModules, that includes custom ones as well from mods?

    That includes any PartModule, however, whether it works or not is a tossup .

    Unity offers a specific flag for making a MonoBehaviour disabled -- it's called 'enabled' and setting it to 'false' makes sure this module does not get called in Update() or most anywhere else. (It also triggers a call to it's OnEnabled/OnDisabled, if my memory serves me right). But that's not enough to shut a PartModule down. :) That's because KSP has it's own update routines -- a PartModule's OnUpdate() is called independently of Unity's Update() by part's Update(). However, that has it's own disable flag, 'isEnabled'. Setting it to false will prevent a PartModule's OnUpdate from happening.

    ...But even that isn't enough to completely shut a module down. :) If it has any KSPEvents, or hooks into any GameEvents, as far as I can tell, it will get called anyway, with no checks. There's no way to disable that, as far as I can tell, without going through it's events and shutting them all down too. But then, making sure they're correctly reenabled when needed becomes a royal pain, which is why I'm not doing that.

    Which is why some modules can be disabled this way, some can't, and there's no telling without trying.

    [0.24.2] JSIPartUtilities -- a mishmash of clever things to do with parts.

    in KSP1 Mod Development

    Posted

    I totally had no idea you posted to my Reflaginator thread otherwise I would have said something. it's my fault for not subbing to my very own thread.

    Oh well. :)

    Meanwhile, wooo, I sorted out kicking kerbals out of the part on launch. :) This plugin is now suitable for use in making foolproof inflatable habitats, (you can even remove the collider on the hatch) and in a while, it should become suitable for use in making habitats which are only accessible when landed.

×
×
  • Create New...