• Content count

  • Joined

  • Last visited

Community Reputation

508 Excellent

1 Follower

About Ser

Recent Profile Visitors

2925 profile views
  1. @MOARdV, Could you recommend a way to bypass adding my engine to RPM's availableEngines list? It is an engine in fact but I need it to be handled separately from all other engines. I've thought of different ways to do it, but none is good: making it not a ModuleEngines will lead to re-implementing much of stock logic including alternator etc. Overriding engine handlers like ButtonEngineStart/State will lead to duplicating of RPM's logic for all the other engines to work properly with props and variables. It would be great to have some kind of config where I could specify that my module or part should not be automatically handled by RPM because of it's own logic.
  2. Are there any troubles with KSP 1.3.1? I was hoping that's nothing more than just a matter of numbers if we speak of 1.3.0 to 1.3.1 update.
  3. @MOARdV, Ok. And I have a suggestion for your MAS: it would be nice to be able to set a property like "transition" for some variables that would introduce a smooth transition to a new value when it's changed. That transition would make gauge needles actually turn to the new value instead of jumping momentarily. I want to implement such behavior in NavUtilities and it would be cool to have it in MAS based props also. Quite a cosmetic feature but could be good for analog gauges and compasses to act more realistic.
  4. @MOARdV, The MM patches work, it was me having messed up CUSTOM and MATH prefixes and looking at the wrong variable. Are you sure the variable ELECOUTPUTALTERNATOR is calculated properly? I specified the rate of EC resource output for alternator as 2. My engine's part menu shows that current output rate is 1.88 EC/s. I'm sure that inside alternator logic it is calculated as outputResource.rate * some thrust coefficient. But EC gauge that uses ELECOUTPUTALTERNATOR shows something around 3.8. In the RPM's source code I see that alternatorOutput is calculated as: alternatorOutput += availableAlternatorOutput[i] * availableAlternators[i].outputRate; Where availableAlternatorOutput is the base resource rate from config. So it seems like that extra multiplication is not needed because it leads to the improper result: 2 * 1.88 = 3.76.
  5. It would be but the variable I'm trying to modify is declared with MULTIPLY, and if I understand right different operators cannot be used within the same declaration. I've attached that module to an engine in config but found that it doesn't belong to it in runtime. So is there the need to attach this PartModule to any part in order to have it instantiated or does RPM do it automagically just from an existing type? Yes, that's right. Actually I have another variable that's used in a more straightforward way and I can see it evaluated, so the handler module is located by RPM. May be the problem is in evaluation chain, I could have messed up MATH and CUSTOM declarations. Thanks for the tip about logging, hope that'll make debugging less a hell.
  6. Hello, people. Is there a way to edit custom variables with MM patch? Here's what I mean: As I see, any RPM variable definition is just a plain config. So it looks like it could be edited with MM patch. I have a part and I want the ASET props to properly display its EC output. The best way is to add it to a certain ASET custom variable. I've tried the following approach: RPMCVARIABLEHANDLER //Define my own variable that is supplied by a PartModule { name = MyRPMVariableHandler method = processRPMVariable variable = MY_HANDLER_VARIABLE,0,false } @RPM_CUSTOM_VARIABLE[ALCOR_FUELCELL_OUTPUT] //Rename the existing variable { @name = ALCOR_FUELCELL_OUTPUT_RENAMED } RPM_MATH_VARIABLE //Replace the old variable with my value added { name = ALCOR_FUELCELL_OUTPUT operator = ADD sourceVariable = CUSTOM_ALCOR_FUELCELL_OUTPUT_RENAMED sourceVariable = MY_HANDLER_VARIABLE } Thus the props wouldn't notice anything and would keep displaying the same variable but with my value added. Also it would be compatible with whatever does the same thing. But that doesn't work. The handler isn't even asked for MY_HANDLER_VARIABLE. So should that work or the only way is to declare a new variable and force the props to use it instead? And another question: are operations on self allowed? I mean doing something like x = x + my: //Assume that ALCOR_FUELCELL_OUTPUT is already defined by another mod RPM_MATH_VARIABLE { name = ALCOR_FUELCELL_OUTPUT operator = ADD sourceVariable = CUSTOM_ALCOR_FUELCELL_OUTPUT sourceVariable = MY_HANDLER_VARIABLE }
  7. This mod doesn't use any advanced physics model, just linearly cuts off sound frequencies according to atmospheric density. Real physics of this process involve temperature layers and are too scary , so I guess you should look at atmospheric curve that defines how density changes with altitude. And that curve may look weird if we speak of stock atmosphere. It corresponds Earth atmosphere at low altitudes but while getting higher it should quickly reach zero density at 70 km. I haven't seen the curve but indeed, at 50 km it seems like there's almost no air and the hardest aerobraking happens at 25-35 km when the density rises quickly, and so does sound. EDIT: And yes, that feeling might be partially caused by that the most important frequencies in KSP sounds (or my headphones?) are the middles so the most noticeable "loss" of sound happens when they get muffled. Since things happen linearly, a certain altitude range corresponds to that event.
  8. That picture is exactly what the G-Effects mod does. It disables stock G calculations and those G meters and portrait noise actually correspond the values supplied by the mod, just checked that once again. So what's the problem? Why do you say that they aren't compatible? May be you want to disable blackouts/redouts in external view?
  9. And you want this mod to show G load on kerbal portraits when you are looking at them while outside the ship?
  10. I've got several requests to make the mod follow the stock G stats, but I still don't understand what do you mean by "what happens to the crew outside the ship". Do you mean that vertical G-meter?
  11. What is the "original overload"? And what effect are you talking about? There's two kind of effects the mod applies: redout/blackout and greyout that indeed is shown only in IVA by default. Which one?
  12. @Euer_Hochwuergen, @Galileo Guys, I've just tried on stock KSP with Ship Effects and Audio Muffler. 24 part light aircraft with Mk1 Cockpit - no drops, 60 FPS when looking at clear blue sky from IVA.Even with ASET. So it may be that some other mod interacts with Audio Muffler. What I suggest is to try on stock with Ship Effects and Audio Muffler, and without it, and see if there'll be any difference in FPS. I have i5 3.50Ghz, 8Gb RAM. Mesuring FPS with Fraps. EDIT: Also I've installed SVE/Medium with Scatterer to see what happens under some intense load and got 9-11 FPS. Removing Audio Muffler didn't help a single FPS, it remained in the range 9-11.
  13. @Euer_Hochwuergen, @Galileo Thanks for the info. Now I need to do some testing to reproduce that and see what's going on.
  14. I've made several iterations of optimization and caching, otherwise it would be CPU intensive but only with large part count vessels. If you still experience FPS drops then I'm sure there's something to be fixed. Actually, it is recommended to use with Through the Eyes. Sorry, but I can hardly understand what you're trying to say further. What are the exact conditions when you have FPS and muffling issues? Especially would be helpful to know how many parts are there in your vessel, and what parts with ASET props do you use. If they are your custom parts, then how many props are there. Also make sure that you use the latest 2.4 version of the mod for the correct KSP version.