Jump to content

Nereid

Members
  • Posts

    1,043
  • Joined

  • Last visited

Everything posted by Nereid

  1. Sorry to hear that. Unfortunately I had limited time the last weeks. If all goes well, I will recompile FF and NG against 1.3. this weekend.
  2. Just delete all ribbon grafic files you do not want from the folder Nereid/FinalFrontier/Ribbons.
  3. No problem. I was puzzled quite a bit at first too.
  4. I do not think this is the case here. The OnScienceRecieved callback gets very different values if kerbalism is installed and they do not look correct for me.
  5. Ok, I will take a look into this today. EDIT: Maybe I'm wrong but with kerbalism installed the OnScienceRecieved callback gets very suspicious values. It seems kerbalism has messed up the event system somehow.
  6. Yes. Take a look into the other ribbon packs. There is a file CelestialBodies.info. It is self explanatory.
  7. What is the vesselt type of the rover? Is it really of type "rover"? If not FF can't recognize it at the moment.
  8. Well... as far as I remember mach number and altitude are checked every 1000m. Dunno why this has not triggered a ribbon. But the tests are not done every millisecond (for performance reasons), so maybe the mach 4 get unnoticed from FF and at the time it was checked just mach 2 was achieved. Unfortunately there is no mach N event in KSP (as far as I know), so FF has implemented its own checks to recognize those situations. And the checks are not done in a ribbon specific way. At any point in time a situation changes (e.g. changing from mach 3 to mach 4) FF checks all (!) ribbons. Most checks are very, very simple but we really do not want to check those 50 times a second. Conclusion: some of the ribbons have some kind of fuzzy rules - like in real life. Often the rules for military achievements are clear, but if you qualify for them its another story. I do not like the current implementation for those "custom events" in FF anymore (and maybe some are unnecessary in KSP 1.2), but I'm a bit reluctant to change them. They are working in their current state and any change may introduce new bugs.
  9. If this is the case there is nothing to worry about. I was thinking you are using Update() to do the scans.
  10. Question is: How often do you check all vessel parts? Every few seconds? That doesn't matter. Several times a second? Well then it depends what your are scanning (even PartModules?)... and if there is not a larger vessel around (a lot more than 200 parts), it does nothing of harm. But I got reports from people with larger SSTO spaceplanes that were not able to get them into orbit anymore a while ago as NG had done similar things. I have checked this (in KSP 0.90 if I remember it correctly) with some of their saves and they were right (the SSTOs and their engines just behaved differently for some reasons). Polling every part multiple times a second is a bad idea anyway from an architectural point of view - it just do waste CPU and there ist just no need to do it. But there is a simple solution: Build a class that does the scanning once, add all parts of interest in a list. If the vessel change or gets modified, scan again - once. In between just scan the few parts you are interrested in. There is no need to iterate over all parts over and over again just to check if they can hold any crew - most of them can't. Scanning ten or less parts and its PartModules even 100 times a second is negligible. A better approach would be some kind of listen/notify paradigma. But I don't think there is any for property changes on part level in KSP. List<Part> partWithLight = vessel.Parts.FindAll (p => p.Modules.Contains<ModuleColorChanger> () || p.Modules.Contains<ModuleAnimateGeneric> () || p.Modules.Contains<ModuleLight> () || p.Modules.Contains ("WBILight")); If this takes 0ms and you don't do it 100 times a second, it doesn't matter. StopWatch is used correctly. But I would suggest to accumulate the used time of the whole flight and calculate an average.
  11. Its just useful to make sure the positions between different sets are the same. The alignment gauge gets the same position for every set. So if a gauge snaps in to the alignment gauge in - lets say - "landing", a gauge in a different set get the exact same position if it snaps in there, too. I have added this gauge, because it had bothered me that switching between sets caused the gauges to "jump" a few pixel, if they were not aligned to their default positions.
  12. Implemented in 1.5.0-3056 A preview: On the left is a scale for the current throttle setting in percent. The setting is shown in digital numbers at the bottom, too. On the right is a scale for the current relative thrust of all active engines.
  13. I will see what I can do about it. Maybe this weekend. EDIT: done. I will release it tomorrow.
  14. Pilot Assistant? I have missed that one. I'm flying my planes with the sticks on a gamepad most of the time (I could use a HOTAS but this is a bit over the top for KSP ;)). Does Pilot Assitant provide any benefit even with gamepads or is it more or less limited for keyboard users?
  15. Tested: The ribbons are awarded but not shown in the summary window. This is as expected, because they'll get them after the recovery is completed and FF checks only for ribbons until the mission is finished (more or less for technical reasons). I'm a bit reluctant to change this behavior, because it is not that easy and may introduce new bugs. Its not worth the effort in my oppinion.
  16. Well, they do for me. At least last week they did. This may not shown in the summary though, because they get them after the vessel recovery (but this was 1.1.3 behavior; can't remember if this is still the case). But anyway: I will check this today. Recovery of vessels work slightly different in KSP 1.2. So maybe there is a bug...
  17. This was causing trouble, too. It should be gone with 1.4.8-3024 [or 1.4.7-3022, if one can live with a wrong elevation of the Other Airfield]. But why is the log telling, that you are running KSP 1.1.3?
  18. To avoid such issues take a look at by cybutek. In my oppinion its far better than CKAN and tells you, if a mod may be incompatible with the used version of KSP (if the author of the mod has done it right). It informs you about updates, too and provides a link for a download. EDIT: And there seems to be still an issue with Contract Configurator... EDIT: fixed and testet. CC and NG do now work together (I'm using CC myself again since today).
×
×
  • Create New...