Papa_Joe

Update. Multi Part Transfers have been tested and committed to GitHub. Also, the SM display issue and a minor button text color display issue have been corrected in this commit. For those that can and want to, you can fork the code now and recompile to enjoy this feature. I still have the other features as listed above to complete before 4.2 is released. The transfer window button behavior is changed as follows: Before: 1. Clicking on a part would deselect another part. 2. Parts could not be directly deselected. 3. The same part could be selected in the Source and target windows, even tho no transfer could occur. After: 1. Clicking on a part selects that part, and disables that same part in the target scroll window. 2. Clicking on a selected Part again, deselects that part (now a toggle). 3. Clicking on another part will also select that part. 4. Detail window now displays the combined totals for all parts selected. 5. Slider control range now includes total resource for all parts selected. 6. Flow button in details window now affects all selected parts. One issue at the moment. sometimes switching between resources with parts selected will produce weird display issues in the Transfer Window. Selecting another resource will correct. I will track it down before release of course. I will keep everyone posted.

Back on topic, and to the OP's question, I offer the following: 1. Just because you can do something, doesn't mean you should. Career mode feels like the developers came up with some ideas and said this looks cool to do! Cases in point. - a. Windows 8. It tried to be too many things, and be a "one size fits all" OS. Microsoft learned a lot during that one. - b. Google Glass. Google learned the hard way that it was a solution trying to find a problem. 2. The reason that Pixar was so successful, was not because of their great technology. And they have awesome technology. It was their storytelling. 3. As I said earlier, with no disrespect to Harvester and his fine team at Squad, Software engineers are NOT known for their storytelling... Insert an appropriate geek joke here, as I resemble this remark. 4. KSP is a great concept. It has awesome potential. However, the career mode lacks focus. I recommend hiring a good writer, and giving him or her the back story on the kerbals. Let him or her figure out a direction for KSP. Give the Kerbals a rich lore and the depth we all would love to see, and a reason to explore the cosmos. The Kerbals are the Stars

Looks to me like the thrust vectoring reaction time was a bit slow... need to tweak his mech jeb module a bit more...

@Fel: I see your point, and understand where you are going. Many games that have been developed to be "open" (the GTA series for example), had a "decent" campaign mode, but really shine in sandbox or open play. KSP certainly does shine in Sandbox mode. I play that almost exclusively. However, I also see tater's point and agree with him. If you decide to add a campaign game, it should be well thought out and have a purpose. For example, in WOW, the leveling is PAINFUL, but serves the purpose of introducing the lore, and building your skills in preparation for the end game. Even after leveling several characters, each new class has its own unique characteristics, and all must play together to achieve success in the end game, where all your learned skills are really put to the test. KSP lacks this kind of compelling reason to run the career mode. Yes it provides you a means to develop your skills, but to what end? Finally, If KSP stays as it is, it will still be a very successful game. Minecraft, without any additions like a boss was still wildly successful. But, give it a chance to be a bit more, with some end game component, and it could really be something else again. A franchise to last a very long time.

Outstanding! I did not think about that behavior. That would also explain an issue I had before about a slowdown when coming into proximity to debris a few versions back... I managed to overcome it, but did not realize that this was the cause. I will be sure to add that to the next version. Thanks! @BobsYerUncle: Since we seem to have identified the issue (thanks jenden!), please try setting your debris to 0 in your KSP configuration. This should eliminate the issue in the short term, until the next release.

Hmm.. .Ok. Then the issue is elsewhere. There is another method called shouldtoggle in the SMAddon.cs file. This one is called when the toolbar buttons are pressed via OnSMButtonToggle handler. This handler works for both toolbars, so I'm thinking that ShouldToggle is the culprit. In there there is a reference to !PauseMenu.isOpen && !FlightResultsDialog.isDisplaying I have recently learned that these sometimes return null exceptions for unknown reasons. Blizzy's toolbar actually encapsulates them to trap for the error... I've since added that to my code in my current dev build, as well as consolidating bouth shouldToggle and CanShowShipManifest. This may be were you are having issues. Try removing !PauseMenu.isOpen from the test and see if it then works... Thanks so much for going the extra mile and recompiling the code on your end... There are many times where I simply cannot duplicate the conditions necessary to replicate the issue! If you are recompiling, I suggest you use the latest code base if you are not already doing so... 4.1.4.4. The CanSHowShipmanifest call is called every update, as conditions can change from frame to frame based on user input. To reduce the spam, i have a static var I use as a latch to catch the first instance only of a frame based method error or message: if (!frameErrTripped) { Utilities.LogMessage(string.Format(" in IsInCLS (repeating error). Error: {0} \r\n\r\n{1}", ex.Message, ex.StackTrace), "Error", true); frameErrTripped = true; }

Thanks. The Vesseltype I'm talking about is in code, so it may not relate to the displayed type at all. the SM Config is what I needed. Is that the installed one? I noticed all windows are still in the upper left corner, which well may be if you have been testing , so I just wanted to make sure. Nothing stands out. I noticed you have realism turned off. That will have no effect on the display logic, but I did wonder if others played with realism off... If you do test with 4.1.3, let me know how it goes.

Can you post your settings file? I did go thru the UI display logic, and while I don't see anything obvious, it was clear that I could "clean it up". I've done that. One possible cause may be the type of vessel. I filter for "unknown". you did say this was a colony base right? I wonder if that is causing it.... Let me check what version I added that and see if I can point to a version that does not contain it for testing... I introduced a display filter for Vesseltype = Unknown in version 4.1.3.1. If you are willing, test with version 4.1.3. If the problem goes away, we may have the reason...

Thanks a lot for the detailed report. I noted in your post that you are seeing the debug message for OnShowUI. This indicates you are using version 4.1.4.3. You can update to 4.1.4.4 and that removes the message. As far as the error is concerned, it kind of sounds like an initialization issue with my mod. I did note in your mod list ATM (x64). Are you running 64 bit KSP? If so, all bets are off and the 64 bit gremlins are attacking you... Many mod makers will not even discuss issues when being run on 64 bit instances... I'll investigate the visibility code and see if I'm leaving something undefined. In the mean time, if you do find a way to recreate the issue do let me know.

Update: I've implemented Multi part (1:N, N:N N:1) transfers. I changed the behavior slightly tho. Part buttons now work like the Resource buttons and are toggles, so no Shift key is needed. You can now select / deselect multiple parts both on the source and target sections. Also, when a source part is selected, it will be "grayed" out on the target side and vice versa. This should make it easier to keep track of what has been selected on both sides. I'm testing it now, and will be committing changes by Feature to Github as I get a feature implemented. This will make it easier for me to revert to a known good state in the event I go down a path I don't like on a new feature, after I get an existing feature working correctly. Next is the Multi Resource feature. I intend to make it somewhat smart, as in you cannot combine crew or science with other resources, and it will respect flow modes. and realism. You could tho combine liquid fuel and mono propellent, assuming that there are parts that contain both. LF and O will be using the standard 0.9 / 1.1 ratio, and "custom" fuels and oxidizers will have an ability to adjust the ratio. If I get a wild hair and look into Real fuels and other mods, I may look at their ratios to see if it is something I can reasonably manage via a config... I invite your thoughts on multi resource Xfers... I'll keep you all posted.

I agree, I found the science portion had potential, but is as yet not realized. Indeed you did, but I kind of took that to fit within my item 3 for mission control, hence it already being discussed. I really liked your post. For item 4, I'm thinking in a grander scale. Even flight planning would be automated, and run on autopilot. For example, once you have established a mining operation, it would grow and shrink as your skill in managing the people, resources, and infrastructure ebb and flow. Same with colonies on other planets / star systems. Interstellar trade and deals would be possible. Flights would automatically fly, Resources would automatically be accrued, and shipbuilding would progress in an automated fashion... Astronauts (Kerbalnauts) would be hired, fired, live and die in an automated way. When you wanted, you could drill down into the guts of the game and fly a mission yourself, or work on some portion of the grand systems that make a space faring civilization go... That is why I think that it would be well beyond the current scope of the game. It would make the current game as we know it only a small part of the whole... It would however be an interesting direction to take it...

I've been playing KSP since before the sun was a body, and flying to the sun was a straight line flight to an imaginary point (sun was a background image). The original list of goals was little more than a list of ideas scribbled on a napkin then. KSP has evolved a lot since those days. As we witness the impending release of version 1.0, I must agree that KSP does need better direction. I love the sandbox mode, and have since the beginning. I tried the career mode when it was first evolving, but quickly lost interest in it as it was simply not "compelling". I also agree that it is more sim than game, but even as a sim, it is a "loose" sim at that. Don't get me wrong, I love the game and the community that supports it. Even in its "unfinished" state (I think we all agree that the 1.0 release is certainly good but not a finished game), it is a lot of fun, and with the modding community it is even better still. It will continue keep my interest for quite awhile into the future. With that said, The OP has a valid question. What is KSP trying to be? I simply don't know, and i'm afraid the devs don't really know either. Great games require great stories and a compelling direction, with some tension and a reason for doing things. With all due respect to Harvester and his amazing team, software developers are usually not known for those skills. I think that the game would benefit from a few storytellers... IMO, to make it a great game, we need 4 things: 1. A universe seed. 2. Other star systems. 3. A "real" mission control system. 4. A "macro" game management module. I didn't mention Multi-player. I know that multi-player is something they have discussed, but I've not heard much about it recently, and they were reluctant to build it back when they discussed it months ago. While that would be an interesting endeavor, I don't think that it would be necessary for KSP to be a great game. Not all games need to be multi-player to be great. Items 1-3 have already been discussed. What is desperately needed I think is item 4. To truly run a long term space program, we need a way to manage multiple flights over multiple years, decades or even centuries, and a "reason" for doing so. The "macro" module would fill that role and would make the space program a space program. After you master the skills for space flight, and as a consequence of advancing along the tech tree, flight automation is not only a must but would be inevitable. At that point, you will definitely need some means to "manage" hundreds or thousands of flights as you explore and exploit space... I kind of think it would end up evolving into something like Sim City, where once you have built it, you manage the higher level stuff, even as you have control over every pipe, building, and intersection. I realize that this is likely well beyond the scope of where the devs will go. So, I'd at least like to see items 1, 2 and 3. I believe these are reasonably within reach of the existing game, and would add the necessary depth to make career mode more compelling, even if it still lacks an "end game" component. Just my 2 cents.

I agree. KSP will end up on Unity 5 at some point, and it is very pretty

Unreal 4 uses the unreal engine, so it is not Unity. I understand that the Unreal engine licensing is changing and all source code is available. Doesn't help up here tho. Don't know about unity support of this feature. I definitely need to start working with unity more directly...

Interesting. I'm not aware of anyone else reporting this. I will take a look at my copy and see if it is overlapping any stock toolbar buttons... Out of curiosity, what version of SM are you using? I just tested using version 4.1.4.4, and it does not overlap any existing stock buttons. However, I do not have as many buttons as you do listed. I do have up to 6, but it seems you have 8. If you use Blizzy's Toolbar, you can configure SM to use it instead of the stock toolbar. That will at least overcome your current issue.

That is certainly possible, as I'm no expert in Unity (or the KSP API for that matter ). However, using the API documentation from KSP, they described two events tied to the F2 key called: GameEvents.onShowUI and GameEvents.onHideUI. They also mentioned that these events are where I should add my handler code to show and hide my mod windows. Therefore, I'm using those events to manage the behavior. Update: Version 4.1.4.4 - Release 10 Apr, 2015 - Bug fixes. - Fixed: Crew transfers fail when Realism Mode is Off. - Fixed: SM windows do not hide when the F2 key is toggled to hide UI. - Fixed: SM window positions are not automatically saved between scenes. - Fixed: Roster window position incorrectly saving to settings window position. - Changed: Altered Window Reposition behavior to be more intuitive. - - - - - - Was: Reset window to 0.0 when position exceeds the edge of the screen. - - - - - - Now: reposition window to edge of screen when position exceeds the edge of screen. Enjoy. Let me know if you have any issues. Now working on 4.2.0.0 Planned: Version 4.2.0.0 - Release TBD - Transfer Expansion Edtion. External Crew, Multi-Resources, Multi-Parts. - New: When using External Seats, crew can be transferred from seat to seat. - New: You can now "link" 2 resources together, by simply Shift+clicking on a Second Resource. All parts that contain both resources will be displayed, and xfers will be linked. A ratio box will appear to adjust ratios as needed. - New: You can now link multiple parts in the Transfer window, and move resources from 1:N, N:N and N:1 parts. Will not overfill a target part, and will fill all equally (you can top off multiple parts) - New: RT command queue is now respected. Antenna switching from the Control Window will now be queued.

Ok, 1. I've got the Window positions properly persisting between scenes (and not resetting the window positions). I also discovered that I was saving the roster window to the same position as the settings window. I corrected that as well. 2. I've also added awareness for showing / hiding the UI via F2. Now all SM based windows will show/hide when F2 is toggled. Thanks for that. I'm looking into the crew transfer issue with Realism Off now. for multi resource transfers, since I've added tooltips to the plugin, I can add text about using the Shift key when clicking on a resource. This will help with making what is not obvious easier to discover. That was part of the "elegance issue" in my mind. Also, based on reexamining the interface, I could change the Transfer Amount slider to simply link the two resources, and display the amounts of both instead of one. further, I can add a ratio setting to allow for "custom" ratios for other mods, and default it to 0.9/1.1 for normal fuel/oxidizer. This should allow for those that want to move more "exotic" mixes... Also, with the 1:N, N:N, and N:1 desires, I can add the same multi select capability to the part selection in the Transfer window. This should make it easy enough to do. With that said, what do you all think about having a setting to disable multi-resource and multi-part xfers. Say for Realism / Career management... I'm beginning to look at restrictions to certain features based on tech level and wonder if it makes sense... Thoughts? Finally, with the bug fixes I have completed and the planned Transfer Expansions, I think I'll release a minor bug fix release (4.1.4.4) before I move to the big stuff and make the next release 4.2.0.0. So, Release 4.1.4.4 will contain the crew xfer fix, the window positioning fix for scene changes and the show/hide UI fix. (likely today or tomorrow) Release 4.2.0.0 will be the Transfer Expansion Edition - External Crew, Multi Resources, and Multi Part transfers. (when it's done )

1. That would make sense, as I do not save window position changes between scenes. I can do that. In the short term, you can do one of the following: - A Simply open the settings window, save settings, and the new window position will then be persisted. - B. Turn on "Autosave Settings" in the Config tab of the Settings window. This will save the settings (including window positions) per the interval set below that option. Currently this is set to 180 sec (3 min). 2. Not sure about "every other mod", but I can make SM aware of the F2 key. I will add that to the next release. Thanks for the feedback!

I would tend to agree, but I'm not up to speed with the modeling side yet. I will take a look at the video and what you are trying to do to see if there are means to expose the modifications you are discussing via script. I really do like the idea.

Hey Climber, First, I believe there is a module for the flag feature, and you could create a suitable flag for your logo, and take advantage of the built in flag setting features in KSP. This would allow you to set the flag in the VAB/SPH. Not sure if you can declare a default (such as your Omicron logo), but I will research to see if that can be done. I myself am looking into building a color chooser for use in SM when selecting the desired highlight colors in settings. Not too painful to do, but will require a plugin to create the needed interface in KSP. Second, since a vessel is essentially "recovered" after a flight (assuming you landed back at KSC), there is no history of a flight, other than experience that is stored with the kerbals that do the flying. So, aging between flights as you appear to be wanting to accomplish cannot be tracked in game. Now, it may be possible to simulate aging of your vessel by persisting a separate file that tracks flights. Not sure how we make that elegant, but as I always say, where there is a will, there is a way. You could however add in-flight aging, based on accomplishments during the flight, and replace textures with the desired ones as you progress through the flight. This would also require a plugin (can be the same one) that looks for any additional fields you wish to add to your parts to track the changes needed during flight. I could help with the plugin or at least point you in the right direction. You might even use animations to simulate the process of weathering, or burning, based on temperature via Maya / Unity. Then switch to the desired new textures after the event. The modeling and texture stuff is not my strength yet. Be happy to look into the flag, aging and texture replacement needs if you wish.

I may be able to help a little if I know what it is you are trying to do.

Thanks so much!

Thanks for the feedback. I've not used gmail much, so I'm not familiar with the interface. I will need to take a look at that. Ok, so you are looking at more than just linking LF+O from part to part, you are also looking at 1:n, N:N and N:1 multi part transfers as well.... that is quite a different nut to chew on... Let me give this some thought...

thanks! I like hugs Latest version has been released. Version 4.1.4.3 - Release 06 Apr, 2015 - RT bug, External crew bug and control display fixes. - Fixed: When using RemoteTech, not all RemoteTech antennas would display in Control window list. - Fixed: Sometimes when displaying part info in Antennas, Solar Panels, hatches and Lights, a null exception would occur and "unknown" would be displayed in part parent info. - Fixed: Crew in external seats were not properly handled in SM. Attempts to transfer will generate unhanded errors, and could possibly corrupt the game save, requiring the vessel to be deleted. Removed Crew members in external seats from xfer list. Enjoy. As always, let me know if you encounter any issues! External crew transfers and LF+O xfers are now being looked at, along with RT queued commands... Edit: Oops. Left in a debugging log message. It will slightly spam the SM Error log, but is an info message and will not trigger the Debug Error window to appear on you. It doesn't hurt anything and will not adversely affect the operation of KSP or SM. I'll remove it when I release the next version with LF+O and External crew transfers.

This is something I've wanted to do since near the beginning of SM. The problem is I've not thought of an elegant way to present it with the current interface. The basis of this mod is one resource at a time, so there would be a need to "link" the two resources in the display. The issue I have is with Real Fuels, Karbonite, and Kethane, and other mods such as these, where additional fuels and oxidizers can exist. How do I link these? I want to avoid having to manage a list of pairs, as that is a maintenance burden that is not welcome (kind of like having to manage multiple module manager configs for endless addons). If you can think of a way to elegantly present it in the interface (like maybe a manual link button), then show me an example and it certainly is possible. Maybe I can use the ability to Toggle 2 resource buttons at the same time in the Manifest Window, and those parts that contain both resources then are displayed in the transfer window, and moved in a linked manner. I must admit, I've not seen this issue. If you do discover a way to duplicate it, please let me know and I'll try to track it down. LOL... don't hug me too soon, this update only corrects the bug by disabling external to internal transfers and does not add the external crew transfer yet. Still working on that and that will be a new feature, not a fix.