Ratzap
Members-
Posts
838 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Ratzap
-
Ok, the filter you're looking for is 'Alternators'. The engines in that list means engines which USE charge, engines which generate power when they run have an alternator module. If you make something with ion engines you'll see what I mean - engines would filter those and the throttle would let you see how much gets used at what thrust setting.
-
Ah hold on, which scene is it not appearing in? It's configured to only be visible in the VAB, SPH and flight. Anywhere else it will show up in the toolbar button config list but the button will not appear when selected. This is because the plugin can only function where there is a working vessel (list of parts) but it remains registered with toolbar in all scenes.
-
That is unchanged over 1.2: blizzy toolbar or stand alone. Make sure you got 1.3 from the dropbox because curse still haven't responded to my ticket and fixed the file there. I was using 1.3 yesterday and the icon was there. jefferyharrell: read this post TLDR; When squad add the thing the new version will grok everything.
-
That would be good as an option but not default behaviour as it would cut down KAS's mass appeal.
-
Right, I got latest SCANsat, BTSM, TACLS and RT2 versions, switched the support back on where it was missing and released it as 1.3. Acknowledgements for the CKAN config and RPM code are in the readme and the OP. And I have a special DLL for Padimur to test https://dl.dropboxusercontent.com/u/71576136/Fusebox.dll I put your code into my namespace and set the relevant variables as internal, it compiles fine and should work (based on the 1.3 version). Once you've confirmed it functions it will be the next release.
-
BTSM support was removed with 0.90 because for a while he wasn't going to update at all. I don't know what you mean with RSS, I have an RP-0 GameData and it works just fine there and has done for quite a while. I could put BTSM back in if it's stable now. I'm mostly on hold waiting on the release with an event in RequestResource since that will end all this mod update silliness.
-
Nifty, I've never really been interested in IVA flight and RPM so yeah I'll look at merging it into 2.0. But as I wrote a few posts ago, I'm waiting now for Squad to make the change in RequestResource. That will be a whole rewrite and a good opportunity for this to be added in. That will be version 2.0 when it comes out. In between I'll put out 1.X based on the current design. I might squeeze it into the current if it's simple and I get bored.
-
I downloaded 1.6.2 and checked the assembly - the layout is the same as in 1.6.1 so it should work yes. Remote tech has quite a history of fiddling with the method names At first it was RemoteTech.ModuleRTAntenna, then RemoteTech2.ModuleRTAntenna, then RemoteTech.Modules.ModuleRTAntenna, 1 version back to RemoteTech.ModuleRTAntenna then reverted to RemoteTech.Modules.ModuleRTAntenna currently. In other news, I spoke to a friend who is a professional C# code monkey about the whole woeful story of trying to get charge information from mods. We both agreed that the best thing would be able to extend Part or override RequestResource. Greys on this forum has been working in the direction of extending Part which I was looking into when Dred came back with a suggestion. He'd written up some code examples of hooking an event into RequestResource in an efficient/performant way. He presented it to Maxmaps and asked if Squad would consider adding that or something like it to allow modding of generic resouce tracking. Maxmaps replied that he'd tasked it to the team and it shouldn't be too much hassle. So cross your fingers chaps, it's a simple thing but if it gets added there will be no more dependancies and *everything* will be supported.
-
That is exactly the big problem with being on the top of the pyramid. Anything supported that changes requires a new update to work again - it took a fair bit of effort to code this mod in such a way that it doesn't simply crash or refuse to load when dependencies change. C# is a strict language meaning it enforces everything at compile time and run time. If there was an API for charge that all parts had to use it would be easy, there is however no such thing. Every mod writer does their own stuff which makes it a nightmare. Even stock parts don't all follow the same pattern. There is hope though, Greys has written a Part extension which I will try and get Fusebox to use but that is going to take time while I recode everything. For now, use this updated lib for 1.6.1 https://dl.dropboxusercontent.com/u/71576136/Fusebox.dll
-
RequestResource override
Ratzap replied to Ratzap's topic in KSP1 C# Plugin Development Help and Support
Most excellent Greys, I spent tonight flicking around in C# documentation trying to put together a model of how I wanted things to fit together in my head. What you've built looks good, no license hangups and you're looking at extending it to cover more of Part functionality. It's almost like someone asked me what would make life easier right now This would be fine for the in flight part of Fusebox but editor scenes will need to be handled differently. Unless I start running a sim for those. Welp, I was going to re-write most of it anyway but not tonight, 2am and my cat is saying 'bed time'. I'll knock out a test or mock up tomorrow. -
RequestResource override
Ratzap replied to Ratzap's topic in KSP1 C# Plugin Development Help and Support
I'd thought about using MM before but I was thinking of adding to Part, it didn't occur to me to extend Part itself and add MM rules to make everything use it. It'd mean an awful lot of MM work when the game loads if used as a 'change everything' approach but it'd certainly be less effort at first. Or is it possible to use the presence of a RESOURCE line in a config file as a switch for MM? Thanks Chris. -
That might be the problem, Fusebox is linked to 1.6.0. Check your output log for something like FB - Wrong Remote Tech 2 library version - disabled. That message appears when the call to the RT2 library fails due to version conflicts. Otherwise check under filters to make sure you should be seeing anything.
-
The config file gets written when you leave a scene that Fusebox is active in. So if you go to the VAB and switch to the launchpad, it writes the config out to the path I put in an earlier post (the standard path plugins write to with KSP.IO). Mind you if you deleted the one you had it should be back to defaults anyway. Nothing much in your log except you seem to be running RT2 1.6 right? The latest DLL is linked with RT2 1.7 and the log shows the RT2 switching off due to version conflicts. I wonder if one of your other mods is trying to use the same window ID that I use for the main window (8631). That's about the only thing I can think of that could be happening because when minimize is set false, the method to set the window up doesn't even get called. Nothing gets calculated or drawn, not even the frame. But if something else told Unity to display window ID 8631 then it would show up and a minimal sized frame like that.
-
I was thinking life would be a lot easier if I could override calls to RequestResource in parts using/creating electric charge. I could then finally track charge in things which don't expose any methods to query changes. My question is, has anyone tried doing this or similar? Would putting overrides for the 6 RequestResource variants into a class and tacking them onto parts which use charge (via AddModule) work? Or would the overrides only function via the module they were added as? Basically the idea is to tack an API of sorts onto things using charge so I can track what is being used or generated and by what. Saving effort writing pull requests for mods and nagging Squad to add methods to things like reaction wheels or the lab.
-
In the VAB no, in flight maybe. The way KSP handles charge makes it very difficult, there is no API specified. Anything which can store charge has a config section and 2 variables: how much it can store and how much it has right now. Things that want to use charge make a call to a KSP function saying 'give me X amount of charge', the function passes back how much of the request was fulfilled and removes that amount from storage. The same in reverse for generators. At no time does any object say what it is using or generating, only the KSP core knows what objects are calling it's functions and it doesn't track it or make it available. That means that the only real fact you can calculate is how much change happened since you last looked for the entire vessel but that doesn't help you a whole lot. I have some more ideas to test but I'm not overly hopeful at this stage. Every mod maker seems to ignore charge interoperability and handles things their own way, almost always without outside access. So Fusebox makes guesses based on config files and hard coded values for various objects, some things are simply impossible to deal with because nothing of their workings is exposed to external components (reaction wheels, the lab). A minimal API would need to exist with 3 variables per object instance: isActive: boolean isGenerator: boolean amount: float That would make life easy and you'd have a dozen mods overnight letting you track everything. Squad probably doesn't see it as a problem and certainly not a priority so I wouldn't hold your breath waiting for changes soon
-
That is extremely odd. The display code is an all or nothing deal controlled by 1 boolean meaning that if it's drawing frame parts, it's running through the functions that draw everything. Clicking the toolbar button simply toggles the state of the boolean. So if it opens, it's changed the boolean state and drawn content. I'm stumped as to how it could only half work, it should be impossible. Can you try deleting your config file GameData\Fusebox\Plugins\PluginData\Fusebox\config.xml and see if that clears it up?
-
You must have a bad copy in your cache. I've downloaded both the curse and dropbox files again just now and they are fine - contain GameData. Sorry spad but the problem is on your machine somewhere. I would suggest trying the dropbox link or clear your browser cache and try again. Hakan, the way some folk feel about Curse is kinda how I feel about Kerbalstuff. I might change my mind in time now the stats mess is behind us but right now I'm happy with Curse and a dropbox alternate. I was looking at the documentation for CKAN with a view to writing the metadata for the next release of Fusebox but if you feel comfortable doing it by all means go for it.
-
Those are the source files so you've not actually installed the mod. Inside the zip next to those .cs files is a folder GameData, you merge that with your KSP GameData to install (like most other mods do it). Ignore the source files unless you feel like changing the mod, they are required by Squad to be available but they are not what you run.