severedsolo

Members
  • Content count

    1450
  • Joined

  • Last visited

Community Reputation

1014 Excellent

About severedsolo

  • Rank
    Junior Rocket Scientist

Recent Profile Visitors

3925 profile views
  1. I think I have an old copy of 1.2.2 lying around, I'll see if I can make it compile tonight
  2. Does right clicking your parts and seeing this make you cry? Would you rather it looked like this? Then PAWS may be the mod for you! What does it do? PAWS will add a right-click option to every part labelled "Customise PAW" - click it and you'll get a window which will allow you remove or add entries to the PAW at will. (Flight Scene only, Editor options are unaffected, as I feel like these are mainly useful). Options: Advanced Mode - there are ALOT of entries hidden in the PAW and most of them don't do anything. By default PAWS will hide entries that are not active, and you haven't interacted with them using PAWS before (so if you turn something off, you can turn it back on again) - if you turn Advanced Mode on, PAWS will stop holding your hand, and show you everything (be warned, most of these don't actually do anything or are pointless, which is why they are hidden by default). Show Fields - This shows you all the stuff that isn't a "blue button" in the PAW. Just find the entry you want, and click the handy "Toggle" button underneath it. Show Events - This shows you everything that is a "blue button" in the PAW. Just find the entry you want, and click the handy "Toggle" button underneath it. - PAWS will not let you turn it's own event off (for obvious reasons). Save Settings Globally - With this on, PAWS will remember your selections and the next time a part loads, stuff you've already turned off/on will automatically change to whatever you set it to previously (be warned, this affects all parts, so if you want to hide Reaction Wheels on one part, but not another, you should probably turn this off before clicking that button). Known Issues [not a bug] Clicking the toggle button on an inactive option does not always mean that option will appear in the PAW. This is usually because the event is not actually active, or KSP turns it off again. This is mostly on Advanced Mode. If you turn "Save Settings Globally" off KSP will not remember your settings for next time you reload that part and you'll have to turn them all off/on again. Per-part options will be coming later. Dependency Requires Module Manager by sarbian License: MIT Download: Github Source: Github Special mention to Snark - your little rant on the BetterBurnTime thread gave me the inspiration.
  3. I have (I assume you mean by changing guiActive to false, unless there is another way to do this) - this just removes both buttons, so they seem to be linked to the same Event. I did originally move it to FixedUpdate but that was probably not waiting long enough. I actually just figured out a solution (as you always do just after you post for help!) foreach (BaseEvent e in pm.Events) { int id = e.id; myEventList.Add(pm.Events[id]); } Adding the Event by ID seems to bypass whatever the issue is. Probably what @DMagic said though, as my list would be referencing the original event, which would explain why both buttons disappear when removed.
  4. Part Action Window - the right click menu on a part.
  5. I feel like I am doing something stupid, so I will post here rather than make an entire thread. This method is basically supposed to just create a list of KSPFields and KSPEvents attached to a part, sort them by name, and then cache it for later: private void Start() { List<BaseField> myFieldList = new List<BaseField>(); List<BaseEvent> myEventList = new List<BaseEvent>(); foreach (BaseEvent e in part.Events) { myEventList.Add(e); } foreach (BaseField bf in part.Fields) { myFieldList.Add(bf); } if (part.Modules.Count > 0) { foreach (PartModule pm in part.Modules) { if (pm.Fields.Count > 0) { foreach (BaseField bf in pm.Fields) { myFieldList.Add(bf); } } if (pm.Events.Count() > 0) { foreach (BaseEvent e in pm.Events) { myEventList.Add(e); } } } sortedFields = myFieldList.OrderBy(baseField => baseField.guiName).ToList(); sortedEvents = myEventList.OrderBy(baseEvent => baseEvent.guiName).ToList(); } } It works great, until I get to this bit: if (pm.Events.Count() > 0) { foreach (BaseEvent e in pm.Events) { myEventList.Add(e); } } For some reason, the act of adding a BaseEvent from a Part Module to a List causes KSP to duplicate all the buttons in the PAW. I can put anything else in the foreach loop, and the buttons are fine, but the moment I try and add them to a list, everything gets duplicated. I've commented out each line of code one by one, and thats the only line that causes the issue. I can also interact with the Fields in exactly the same way, with no duplication. It doesn't make any sense to me, I am not interacting with the Events in any way, except examining the list. So, my questions then: Am I missing something obvious, and if not, can I get around this somehow? I've already tried: - Turning the List<BaseEvent> into a BaseEventList - Using AddRange to try to bypass examining the individual events - Adding the PartModules and Events to a separate list, and examining that so I'm not interacting directly with PartModule.Events.
  6. It's already two minutes for engines (for that very reason). Regarding the base failure rates - I originally had "realistic" failure rates, based on actual NASA studies and documents. The results were... not fun.
  7. Start() is an internal Unity function, it may get called at other places too (I suspect for instance that it fires on a SOI change). Few possibilities here (in decreasing order of likeliness) 1) You grabbed the messed up release (it was up for about 12 hours before Tyko pointed it out to me) - at the point of part failure an exception would have been thrown, so the failure would never happen. Simplest fix for that is to redownload and reinstall (completely reinstall, delete the entire folder) 2) Your solar panels weren't the retractable kind. At that point UPFM would abort the failure, because there was nothing to fail. 3) REALLY good luck on the RNG. That's good data, thanks! I've got a few ideas about fixing the drop off, I think the old model dropped off too quickly, but I agree that is a bit silly. Do me a favour, I've just put a pre-release up, see if you think that's better. What I've essentially done, is loosen up the randomisation (so first part failures will be a bit on the high side), but the drop off seems to be quite sharp, and lowered the base rate, so it will plateau at 1%. Thats the 6 hour window. I really don't like that, and will be changing it back in the next release, assuming this new randomisation method works out.
  8. Under the old system, part failures would occur a maximum of 30 minutes after Start() was called (essentially, when you launch, when you switch back to the craft, or it comes into physics range). Engines shortened that to two minutes so they were more likely to fail when you launched. The idea was that you would see if you had a problem before the craft left orbit. Good idea in theory. What was actually happening though was that Unity's Random Number generator was rolling failures waaay more than it should have done. (on a craft with all <20% failure rates, I would expect the norm to be no failures, but what I am actually seeing is failures happening on every launch. I extended it to 6 hours so that if you switch away before that 6 hour window happens, the failure won't happen (essentially it is a band aid to stop constant failures). Having said all that, I am currently experimenting with a new way of rolling the random numbers which seems to be working a whole lot better and is giving results that I would expect. Assuming it pans out it will be included in the next release. (I am testing in my own game at the moment, because you don't really get a feel for these things without actually playing it, rather than using a testing environemt) The failure rates should generally still trend downwards, but it's a bit random, so if you get a good roll on Part 1 you may not necessarily notice. This is good feedback though, I will have to have a think about some changes, because I agree with you, I want parts your engineers are familiar with to be more reliable than ones where they aren't. Just for reference, this is the way it currently works: 1) The first time a part is loaded into the editor or SY applies the inventory, if it's never been used UPFM will force SY to allocate it a new ID (to stop the issue where auto-loaded vessels don't get new IDs). 2) UPFM will check it's database to see if we've already allocated this ID a failure penalty. If we have, it will just make a note and wait for Step 3. Otherwise it will generate a random failure chance (this is: (Random number between 0+1/3)/number of times that part has been built before), it will then add that number to the database, so when you use the same part, it always gets the same penalty. 3) UPFM will do it's failure calculations, then add a further failure "penalty" based on the number we got from Step 2. So, generally speaking, a part that has been built 10 times, will basically have an "additional failure penalty" of 0, of course there is a chance of a first time part getting a good roll and also coming back as 0, which is probably the bit I need to address.
  9. Good catch. Hotfix for Beta 9 (0.9.1) Released Fixed issue where displayChance updating was being skipped before the figures are passed to EditorWarnings on reloading a craft with existing failures (thanks Tyko) Fixed issue where part highlight would default to off on reloading a craft with Failures. (thanks Tyko) Further refinement to Reliability Model. Failures will now occur up to a maximum of 6 hours after craft is loaded, but will depend on how reliable the part is (unreliable parts will fail sooner) - Engines are excluded from this change. Note that it probably won't fix vessels which have already encountered this bug, but any new builds will be fixed.
  10. Nuts. I shipped the old configs instead of the new ones. I've fixed it now. Please redownload and re-install. Probably easier if I give an example - You will almost never see these figues IRL as it doesn't take into account the generational adjustments but it gives you an idea. Engine A is meant to be a launch engine. It has a "first time use" failure rate of 10% (so the first launch has a 10% chance of failure). However, it is expected to last 100 launches (so you can reuse it 100 times). This means that after it's test flight (first launch) it will only have a 2% chance of failing on it's second launch. Engine B is a space engine (say a Terrier, or a Poodle) - generally speaking these engines don't get recovered. So that engine only has a 5% chance of failing on it's first launch. However, it is only expected to last 25 launches (if you do recover it). So Flight 2 for that part would have a 8% chance of failure. Remember that UPFM failure rates are "per launch" - parts don't wear out in flight. Essentially parts that don't come back will wear out quicker between launches, but will be more reliable to start with. Again though, this is all open to feedback, I'm still tweaking it. Failures are still happening way too often, even with really low failure rates, so I need to look into that. I've not even merged it into the main branch yet, in case I decide actually I hate it and want to go back to the old system.
  11. Beta 9 (0.9) now available. BACK UP YOUR SAVES BEFORE INSTALLING THIS UPDATE. THERE HAS BEEN A MAJOR CODE REFACTORING AND THE RELIABILITY MODEL HAS CHANGED SIGNIFICANTLY. EXISTING VESSELS MAY BE DETRIMENTALLY EFFECTED OR FAIL WHEN YOU DON'T EXPECT THEM TO The changes to the reliability model are an experiment. I have been playing with them for a couple of days and am happy, but I want general feedback from other users. Overhauled Reliability Model. It seems silly that early parts fail so easily, and then later parts hardly fail at all. expectedLifetime also had absolutely no bearing on a parts actual lifetime beyond Gen 1 and this seems silly. The new model balances this. Parts that are generally designed to be recovered (launch engines, parachutes etc) - will have higher initial failure rates but will have longer lifetimes. Parts that are designed to be sent into space and probably not come back (reaction wheels, solar panels etc) will have a lower initial failure rate but won't survive so many launches. Expected Lifetime now does what you would expect it to, and can be edited via MM (note that parts can still survive for less/more than the expected, it's just an average). The overall effect should be that overall failure rates are lower, but new builds will not reduce failure rates by as much as they used to. There is a certain amount of randomisation applied to failure rates, so every part will have it's own unique failure rate, but the actual randomisation applied will be linked to how many times you have built that part (ie failure rates should still generally trend downwards the more you use that part). To compliment this change, UPFM will now track failure rates for each part from cradle to grave, rather than guessing on load as it did before. In light of the above, the default Safety Threshold (the point where UPFM starts warning you that parts are unsafe) has been reduced to 25%. This will probably not affect existing saves and you'll have to change it manually. Failures will no longer occur during KRASH simulations Added option to EditorWarnings window to automatically replace any parts that are above the Safety Threshold (note that this will also remove the part from the SY Inventory, so be sure you want to do it before you click that button). Improved Logging. Events (toggle part failure, trash part, repair) will only show once on a part, rather than once per failure module. Any changes will affect all modules (so you click repair once, and if it works, everything gets repaired).
  12. If you have the Steam version then a PS4 controller can be configured as as Steam Controller. You just need to go into Big Picture mode and turn PS4 Controller Support on in the settings.
  13. I copied the entire GameData folder from this link: https://github.com/KSP-RO/TacLifeSupport/releases/tag/v0.13.4dev to a clean (just installed from Steam) version of KSP. I then started a new Sandbox game, changed absolutely zero settings (so Unloaded Vessel Processing would be on) and built the craft I sent you the other day, but put a rocket underneath it, and took off and landed back on the pad. When I switch back to the Space Centre the behavior I described happens every time. The trigger seems to be switching from Flight Scene to Space Centre. When the save is first loaded (resumed), unloaded vessels already in the save track their EC fine. If I switch to the Tracking Station and back, while it's working, works fine. Even in the flight scene, on a vessel outside of the physics bubble, works fine. But the moment I switch from Flight to Space Centre (just for total clarity, I am using the pause menu to return to the Space Centre) - even from a different vessel, it stops working. Once it's stopped, all the above scenarios where it previously worked, it no longer works there too. Press Escape Twice, and everything starts tracking again. Apparently I am the only person having this issue though. At this point I'm considering writing a little plugin that just presses ESC twice on a scene change. Edit: OK it is SPECIFICALLY using the pause menu to return to the SC. If i use the button on the UI (where the recover button is) it also works fine. My guess would be that an event bound to onGameUnpause doesn't fire on the scene switch?
  14. Initial testing seems to be good - I reproduced the scenario we were talking about yesterday and EC was updating itself nicely. Am now moving to my main modded install to test things there. Edit: Tagging @JPLRepo in case you already ready my message and missed this. Good news is, it works (hooray!) - Bad news is, it only works if you pause the game. Repro steps: put a craft on launchpad - bring it out of prelaunch (I just took off and then landed it again) Return to space centre - start to warp. Timer will start to tick down, even in sunlight. Pause and Unpause game - timer will then properly update itself. Log (although it doesn't look to be very helpful from what I could see): https://www.dropbox.com/s/ivrtklna104p7ty/output_log.txt?dl=0 I think my initial test was a success as I remembered I'd turned off Unloaded Vessel Processing and paused the game to turn it back on again.
  15. That craft should have had 2 days worth of food, and about 4 hours of EC (Default settings, fresh install of KSP 1.3). Is there anything else I can do to help you test it? I can reproduce it consistently at my end, but obviously that doesn't help you.