Ser

What do you think of using the following syntax: To ignore the whole part: name = MyPartName.* or to ignore a single module: name = MyPartName.AnyModuleName And I think ignored parts shouldn't be ignored by FetchPerPartData() method because it calculates part temperatures etc. Can't imagine the case when someone would want to skip that.

A bit simpler. UpdateVariables already looks at every single module and decides where to add it. I'm going just to add additional check whether the module or its part is listed in the ignore list.

What do you think about having just a plain config to specify the ignored names? Something like this: RPM_IGNORE { partName = MyOwnPart1 partName = MyOwnPart2 moduleName = MyOwnModule ..... etc ..... } Those nodes might be loaded and parsed as a string list on RPM's Awake and then checked every time in UpdateVariables method whether the module in question is listed or not prior to adding to availableXXXX lists. As I see, the most of handling logic relies on these lists' contents. And the entire separate handling implementation will be on my side. Will it still require complex changes? I could make a PR if you're interested in merging it to RPM.

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

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.

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

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

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.

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 }

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.

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?

And you want this mod to show G load on kerbal portraits when you are looking at them while outside the ship?

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?

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?

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

@Euer_Hochwuergen, @Galileo Thanks for the info. Now I need to do some testing to reproduce that and see what's going on.

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.

Thanks

@politas, I've created an issue on CKAN github a week ago about incorrect version meta but noone seems to look at it. Just in case, copying the link: https://github.com/KSP-CKAN/NetKAN/issues/5824

Of course there should be a set of rules if we speak of cheating. If you play with no rules that can be broken than there cannot be such a thing like cheating. Well, you may ask someone else. Everyone who reads at least KSP weeklies regularly knows that, I estimate that's about 50% of active forum members. But if you aren't interested in that "curious fact", I'll live with that. Don't believe me, I'll save my time. When you create an algorithm, it by definition is the set of rules a machine should follow. Thus by writting a computer program you create a set of rules by default. If you don't want to allow a player to go beyond certain limits you just check his coordinates and don't let them change if they don't fit. So having a PC game means you have a set of rules automatically. Unlike a cardboard game where you have to explicitly write the rules of the game down. That's what I meant. And you cannot say that you've made a soccer goal if it was made when you didn't play soccer. So you have to admit that you didn't play soccer or that you have cheated at soccer. In both cases the goal wouldn't count. It's clear like a sunrise. What I am talking about here is constantly playing the same game by the same rules. If you break those rules, it's cheating. Too much talking around the same things on and on. Everything else I've already explained above.

I've told you above that it's not neccessary to have a competitor. I can't say about you, may be you change your rules every second while playing but when I start to play there are certain rules that I set. I don't write them or define explicitly, but they exist. And there are things that I avoid, like quickloading. And when I quickload to get an accidentally killed kerbal or stupidly failed mission back, I cheat. And those rules stay everytime I play KSP. Of course you may think of that as you change the rules for a second and then change them back, but when playing alone you have noone to fool besides yourself calling that blabla if you don't like the word "cheating"

You got me wrong. The devs said that they are not going to implement dV readout because the game was meant to be played in a way of trial and error way and encourage players to create some crazy things instead of mathematically ideal rockets. I don't need to lie to you and you may find evidence yourself in the forum if you want. For me it would take just too much time. OMG, just forget it. Do you write code? So what? There are means to alter the game, i.e. make another game with the rules you want. Does that mean those rules cannot be broken, i.e cheated? If they aren't, why they are not an official part of the game? And any developer may decide to write a completely different game. Will you still call it the same KSP just because it is written by the same developers? That's it, you got the point. Different KSP, a variant of KSP, modded KSP, i.e. another game with another rules. One variant of KSP cannot be a cheat in context of the other. We should speak of the same one. Thanks for pointing me out I've written two pages of arguments while having forgot that the question is about a modded game. But that doesn't make much difference. We just take modded KSP as a base set of rules and define cheating as above in relation to it. For example, if we speak of KSP with TAC LS, then we should take into account that it supposes that the oxygen is limited. And if someone makes himself infinite oxygen and still says that's he is cool at KSP with TAC LS, then we can say "Go away, My Friend, you cannot say that, dirty cheater". What does it mean to "play soccer" or "play basketball"? Is it applying one set of rules or another? So if while playing soccer you help yourself with a hand and say "Wow! What a goal I just made!" then you'll be cheating because you broke the rules of soccer, unless you say "I've played some unknown game and just put the ball in the net".

Well, you may call it "blablaing" if you like. That's just another name for the same thing.

In other words, playing the game by certain rules. So you don't do play another way because it breaks the rules set by you. But in some cases you may break those rules. For example, if you get tired of flying to Duna after 75 efforts because you just can't land on it properly (assume saves are not allowed). And you go against your own rules and hyperedit yourself to the orbit just to skip the boring stuff. And that's going against the rules, i.e. cheating. Noone will cry in this case or call his lawyer but if you imagine that you compete with someone by the rules you set for yourself that obviously is cheating. So since we are asked for an absolute definition, I think that's a good one: going against the rules for simplification.

So why do you keep playing in a certain way? Say, you build a rocket and then go to the parking orbit, then create a maneuver and fly there when your goal is to reach Mun? Why don't you use Hyperedit to achieve that goal?