Jump to content

TriggerAu

KSP Team
  • Posts

    2,080
  • Joined

  • Last visited

Everything posted by TriggerAu

  1. v1.8.0.0 Release * Recompile for 12.1.3 - any 1.12 version Download from GitHub or Download from Curse or Download from SpaceDock
  2. Hey All, Apologies for the slowness and details, I have two jobs and theyve both been very busy. Thanks for your patience and the PRs that come through. I've updated the other 2 main mods, and am prepping a new version of this one, but struck an issue where its crashing KSP. ONce I get that solved will publish a new version of this too
  3. Hey All, Apologies for the slowness and details, I have two jobs and theyve both been very busy. Thanks for your patience and the PRs that come through. v3.14.0.0 Release * Recompile for 12.1.3 - any 1.12 version Download from GitHub or Download from Curse or Download from SpaceDock
  4. Hey All, Apologies for the slowness and details, I have two jobs and theyve both been very busy. Thanks for your patience and the PRs that come through. v2.11.0.0 Release * Recompile for 12.1.3 - any 1.12 version * Fix for NRE on opening settings (Issue #96) * Fix EVA Fuel not displaying correctly * Fix resource duplication - thanks @Mathieu * Fix Readme.md links - thanks @rayanth Download from GitHub or Download from Curse or Download from SpaceDock
  5. Been working on this one today - think I got that and some errors solved, will publish a new version this week
  6. The Update method loops through each alarm and calls ScenarioUpdate on each alarm. The UI calls UIInputPanelUpdate on the alarm that is shown in the window
  7. Twas a very cool mechanism I have to say Theres a number of lists in KSP that use that DictionaryValueList class - its very useful Hmm, I thought it was, but now Im a wonderin... to the code EDIT: Darn sorry its internal. the way we do it in other place is a loop. This will work in the meantime for (int i = 0; i < AlarmClockScenario.Instance.alarms.Count; i++) { AlarmTypeBase a = AlarmClockScenario.Instance.alarms.At(i); }
  8. Ill put my hand up and say - I totally missed pitting the GetAlarms method in there. AlarmClockScenario.Instance.alarms is a DictionaryValueList - can be used as a dictionary and a List The quickest way to get at the list is: AlarmClockScenario.Instance.alarms.ValueList - which returns the List<AlarmTypeBase> that underpins the dictionary, etc The Modders notes are up now too:
  9. Always! I've sent everyones piece by mail
  10. Its coming in the modders notes yes, but do feel free to ask questions as we go
  11. Thanks for the info, and details, will get into it next week
  12. Ill be getting to update it in my week off from KSP shortly, there will be an update yeah
  13. If everyone had cake for brains you could sign me up wit a few million others I reckon
  14. For the weekend my wife (Leanne) made me a chocolate cake to celebrate the 10th Anniversary. Its really cool and I thought Id share it (not the cake obviously its too tasty), as thought others might get a kick out of it as well. Hope your enjoying the tenth anniversary
  15. Hey Rylant, there's a little drop down tab undersave button that give you access to the saving, same as the little drop down under launch that gives you all the launch sites Yes the KAL can be used to sequence launchers, its pretty good fun
  16. Can you expand on that one a little bit - do you mean available in the VAB/SPH scene then yes
  17. I get ya, kk so for some extra info the UpgradePipeline is what changes parts/save values when we do things like remove old parts and need to reposition new ones, or make significant changes to a module that requires field changes. Every save that is opened is checked by it, but there is no code in it for 1.10->1.11 for example. For a comparitive idea a 1.10 save opened in 1.11 would be expected to have only the version stamp changed by the upgradepipeline. It would also have new fields with their default values for existing modules, but those are handled as part of the saving process and would match the old saves behaviour (unless noted in the change log) - it can be admittedly hard to see the diff between the upgradepipeline and save Im thinkin. A good example f the UpradePipeline is a 1.6.x save being opened, which would run the upgradepipeline scripts that replaced and positioned the new separators and decouplers in place for the old parts that are no longer loaded from 1.7 onwards. Dont mean we arent seeing an issue of course, just clarifying the differnce for some info
  18. No problem! Thanks for the measured comments and responses too. We are always looking to improve the process and the game as we go, and working smarter not harder is defiitely a goal in all the teams. For that one there about upgradepipeline, we didnt do any upgradepipeline work in the last few releases, I didnt see a tracker number for that one in the github - do you know if there is one? No probs. For consoles Ive seen the same sort of conversations and clarifications yeah. There are definitely some differences, like you say though, in the impact space depending on what the after effects of unintended stuff is In my mods Ive been using System.IO.File, etc for a long time, but if you mean that Unity gets you to use WebRequests to load bundles and stuff like that so its platform agnostic, when the games platform is file system based then yeah I get ya for sure.
  19. Just reading back theres a few posts about bugs and priority that I feel I can add some context about without going into internal stuffs. Which bugs get attention in KSP land is a function of a number of variables which does have a fairly well defined logic annd process. From a player perspective issue voting is definitely one factor and people voting to indicate they are suffering the same bug is definitely a help for correlation and interest - this isnt taken as a "hey thats a popular bug we must fix it", but it is one of the easiest ways that players can interact with a specific issue. Another is to update a bug with details, if your interested in a bug and its not fixed in a release adding a comment to say that its not fixed,or how its changed in a release, can be super helpful. Outside of those some other items of consideration that have been in discussions Ive been involved in include (but arent limited to) - forum chatter about a bug, severity of the bug (ie what it does to the game and is there a workaround), impact (how many people are affected and/or how often will that bug occur for various player types), reproduction (can we reproduce the described effects), related bugs (or similar systems - so we can close multiple bugs with one fix), and expected effort to resolve can also sometimes come into it. These are all pretty standard metrics and considerations for this type of work and when solving problems - yes we get bug reports (which are like Incidents to use ITIL parlance), but every one of these is attempted to be solved as a problem and not a stand-alone incident - root cause resolution is the best fix I agree. If a point fix is chosen there is a reason. One other one I can comment on is bugs not being looked at. I can assure you that almost every one is looked at, and some form of action taken, but not all the datat attached to a bug ticket is visible to everyone. I can guaranntee you Ive read all the ones in this thread personally, as well as a number of other people. Obviously I cant share all the nuts and bolts of internal discussions and no-one makes the perfect decision every time about which bug is the "most important" to everyone - that can be subjectively different for a player, or tester, or modder, or producer, etc's point of view. I do understand what its like to be wearing all of those hats personally and it can be frustrating to feel that things arent being read at a minimum. You may not see all these interactions and work going on directly, but I hope my posting this can at least share that many of the team do read, track, repro and work on these. We would love to solve every bugs, feedback, requests, and ask all at once. And we definitely dont use the Wheel Selection method
  20. Heya, Will start looking this week. We had to get 1.11.1 to the door before I could go into modding obvs
×
×
  • Create New...