Papa_Joe

Just an update. RL is continuing to hamper my efforts, but I am making progress. My clunky highlighting management is now better, but it revealed some nastiness under the hood with my reworking of the Entity lists (selected resource part lists, etc.). Since I've moved them out of the Frame by frame updateing, I still had some old vestiges of the old method, and they were consuming resources they shouldn't have, and lagging the system (Bad). So, these have been cleaned up. A lot of under the hood changes for this update, with only CLS integration to show for it. But, it will be leaner burning on memory now. anyway, as I work out the final bugs, a release is definitely coming soon. Sorry for the delay folks, it has been a month and a half since the last update.

Thanks for that. It makes troubleshooting much easier. Sounds like I'm not properly resetting state veariable(s) when transfer is complete. Also, it sounds like very small amount transfers may be an issue due to the sounds (start up sound and delay timer). So I have a couple of places to look.

It should work, and I've been testing my release candidate (v0.23.5.3.2) in KSP .23.5... I totally understand where you are coming from. However, there are players that would rage against the blasphemy of "automation". It IS technically possible to do. However I would have to emulate a threaded system. I could set flags and extend the part to do so. This would take some re-engineering of the way i perform transfers. As to whether I would do this, I will have to consider the problem a bit and see if I can come up with a clean way to do it. A possible work around for you might be to turn off Realism Mode. Xfers are instant. No waiting. No sound. BTW, even in Realism mode you can set the duration. IIRC, I set that up to xfer instantly if the duration was set to 0... Currently, the default setting is 5 seconds for Xfers, and 2 seconds for Moves within the same part. Edit: the durations I mention above are for Crew, not resources. Resources use a multiplier to set a rate. Best to turn off Realism mode to get instant transfers of fuel and such. Quite correct, and a mufti-threaded approach is not possible. However, given the event driven nature of the design, and the availability of the frame update method, with some fancy flag management and object persistence, I can emulate a mufti-threaded like experience. just set up a part queue and manage each part within the update event. My guess is the author does something similar to what I described above. I have not looked at Fuel Balancer's source in any depth. As for negative fuel amounts, please describe the problem and how you reproduced. I will be happy to research the issue.

Ya, I have an event handler logging excessively, and I'm battling 23.5 compatibility with the other mods I use (KW, I think...). Got dual builds being tested... sorting it thru...

Good Idea. Let me see what I can do. Also an update. I have solved my highlighting issues, and things are working as intended. I have discovered the source of the Debug log error with the collection. I have implemented the additional Event throws. I still have a couple of bugs, and some cleanup to do, but it is looking like I might release tonight (CDT). Feature list (for now): New - Crew transfer Realism enhanced with ConnectedLivingSpaces! - Connected Spaces illuminate when you select crew. - Source part color is still Red by default, but the target color is set to Blue by default for Crew Only. can be configured. - Connected Living Space Aware. Configurable switch to enable. When enabled, crew transfers can only occur within the same Living Space. - General Clean up of Code. Greatly improved error handling and logging. Should also be an improvement to performance, with no more per-frame collection management work. - Event trigger Support for TextureReplacer and Extraplanetary LaunchPads. Event throws have been added to ensure proper updating of other mods. - Latest Toolbar version distribution (assuming it isn't updated the moment I download ) - Dependencies on CLS and Toolbar. Be sure that is understood. I will look at optional dependencies in the future, but for now, it is what it is. Besides, they are great plugins. Stay tuned... Edit: Found a few more bugs still... Nothing serious, but release won't be tonight. Tomorrow.

I saw what Shaw pointed out, and as part of supporting CLS, the same event call is needed to update the CLS vessel. Therefore, it will be included with the next release. Thanks for point it it out.

Good to know. I was using the version you compiled for me with the highlighting event handlers. I recently went to 1.0.3.0 and added the config without thinking. I will test without the Config entry.

Just an update. I've completely reworked my data sources, so now Ship Manifest should use less frame resources. It no longer rebuilds each list and dictionary every frame. I never liked that... Now it stores these objects at the scene level. I've also scrapped my first attempt at integrating CLS. I mistakenly was thinking in terms of moving from space to space. Why?? Anyway, now the crew transfer is simply CLS aware. you cannot move a kerbal to a part that is NOT in the same Living Space. I've included a switch to allow you to disable CLS awareness, and let you "lazy" players (like me) move kerbals where you like. I'm thinking I will release what I have as soon as I get the highlighting proper (I currently have event handlers stepping on eachother) for the sake of getting it out, and for the obvious improvement to realism play. I'll then work on the "bells and whistles" of more complex sounds, and path highlighting as the kerbal moves... Stay tuned. More to come.

Please add the following to the stock.cfg: @PART[crewCabin]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } Thanks!

Just so we are clear, Unity 5 was announced, not released. They are now accepting pre-orders. I am indeed looking forward to the date when Squad releases KSP in Unity 5. When ever that date is...

Error was mine, not yours. Your API was clear, I was just not wrapping my head correctly around what I wanted to achieve. I'm not going anywhere. Been here since version .7 (before the existence of a stellar body). Did the Sun challenge (go 13.1 M meters and turn around and come back. the sun was part of the backgound textures then. Man was that fun...

Space Transfer was my misguided first attempt at using your API. I was thinking of spaces like another resource. Mistake. I threw away my existing code and started over. Sorry for the late response. Been very busy of late with RL. Thanks for this. I've been battling that very issue. I think it is related to the fact I'm using foreach on an object.collection I'm modifying. I will switch to Indexed loops and see if the error goes away.

Just an update on progress. I've been busy releasing a new version of some software at work, so I've not been able to do much the past week. however, time is getting better. Space Xfer Interface is complete. I have completed basic xfers from space to space. My goals for the next release include: - Add space transfers. - add move kerbals in a space. Currently, the the move only moves from seat to seat in a pert. This will allow seat to seat in a space. - Update to crew transfers to be internal path aware, so you can't move a crew member to a part that is not connected internally. - I also plan to add sounds to space transfers, - Highlighting the parts in the path as the kerbal "moves" thru the ship. This would apply to both spaces and to crew xfers. It seems a bit redundant to include space transfers and crew transfers, but it also give some flexibility. I've already included a switch to turn off crew transfers, so if you wanted you could use space transfers only.

Thanks! I've been busy releasing a new version of some software at work , so I've not been able to do much the past week. however, time is getting better. i have completed basic xfers from space to space. I'm incorporating part to part highlighting, which is when I discovered the issue above. So far the API is working well. My goals for the next release include: - Add space transfers. - add move kerbals in a space. Currently, the the move only moves from seat to seat in a pert. This will allow seat to seat in a space. - Update to crew transfers to be internal path aware, so you can't move a crew member to a part that is not connected internally. - I also plan to add sounds to space transfers, - Highlighting the parts in the path as the kerbal "moves" thru the ship. This would apply to both spaces and to crew xfers. It seems a bit redundant to include space transfers and crew transfers, but it also give some flexibility. I've already included a switch to turn off crew transfers, so if you wanted you could use space transfers only. Thanks for your efforts, and I'll keep you posted. I hope RL provides you a chance to play, and If there other changes I think of, I'll post. If I need something really bad, I'll likely do a pull and make the changes for you to examine when it is convenient, if that is okay with you.

@codepoet, I've found a behavior I'd like to tweak. highlighting is hit or miss when you mouse over parts highlighted by CLS. Crew Manifest currently exhibits this behavior as well. I had the exact same issue in Ship Manifest, early in development. I solved it using a delegate function attached to the affected part's mouse out event. This allows proper mouse behavior until you leave the part, and reverts the part to your desired highlighting. Very clean. Just remove the delegate function when you hide the control window or change the space(s) selected. Also, I'd like to be able to control the colors for part types. I'm thinking static properties would due nicely. Thoughts?

A lot of time has passed, and Ship manifest is becoming feature complete. I'm dusting the design off and reopening discussion. As we build requirements I'll begin building the structure of this beast. I will be using this post for update information and action items. First, idea born from this thread: http://forum.kerbalspaceprogram.com/threads/65916 Second, project born here: http://forum.kerbalspaceprogram.com/threads/62270

Ok. After some thought about whether to put this in Ship Manifest or not, I've decide to make it separate mod. So, Ship Checklists is born. My thoughts for checklists go like this: A persistent, configurable checklist, by ship and by flight, based on a ship's template, that can be assigned when the ship is built. I'm thinking it should be subassembly aware, and allow you to save checklists to the root node. the final ship checklist is "assembled" from these subassemblies and can be extended. This would account for undocking, etc. - They should be open and flexible, combining free text with some automation (pseudo action groups!). - They should allow you to "program" an action or activity. One button press and the action is completed. - They should have check boxes to indicate completion - They should allow you to enter notes during flight - They should be persistent. You can quit the game and come back and your list is still there. - This is where multi-part actions will fit nicely. The plan for flow (at this time)... Checklists can be created in the VAB, SPH, preflight, or in flight. You can select from a list of templates, or you can create a new template. design the checklist and it is saved when you save your ship. To use a checklist Open checklist window. Add items, execute items, make notes. Click save after making changes Actions performed by clicking on go are automatically saved. - When creating the Checklist item, using a set of drop downs, Select the action (Transfer),select resource, select all source parts, select 1 or more target parts, and click ok. - The checklist item is then ready for when you reach that part in the "program" as NASA used to call it in the day. - Clicking the Go button in the checklist item performs the action, and checks the list item. Of course, any in-flight tweak-able on a part should be available from the checklist as well. Full control in an ordered (and repeatable) way. Save as a template for the ship in assembly and you can add to the list for the ship at launch or in flight. This way you can save a Checklist for a craft, and have a "This is how you fly it" included with the ship. Thought I'd start a development thread so we can discuss anything you may want in this mod. Let me know your thoughts...

Awesome! Back to work on CLS integration. Once I got past the framework issue, the code pretty much just worked first try. Coding the fun features now.

You da man! Back to plumbing features...

Hey codepoet, I've been testing Ship Manifest with CLS integration and have hit an issue. You have compiled in .Net 4.0, and I've released in .Net 3.5. It seems it matters. I've been getting multiple errors with my code when using CLS. If I recompile CLS to 3.5, all errors go away. Obviously, I have a problem in my code that is not compatible with 4.0. however, it seems, for maximum compatibility that 3.5 would be ok. Would you be willing to release CLS in .Net 3.5? I PM'd you about the issue, but thought it made sense to also post for everyone's benefit. Thanks so much. In hopes that you are willing, I'm pushing forward. It it is an issue for you, then maybe you could glance at my code and see where I may be in error. If you choose to look I can update github with some commits of my code.

Update. It seems that ConnectedLivingSpace is compiled in .NET 4.0, and I've been releasing in 3.5 It also seems that it matters. For some reason I get a large number of errors in the debug log when trying to show the Manifest window, when compiling in 4.0. If I recompile CLS to 3.5, and then recompile my code to 3.5, it all works. Obviously, I have something incompatible with 4.0 in my code. Don't know what yet tho. I've contacted codepoet to see if he is agreeable with releasing CLS in .Net 3.5. With the 3.5 version, I've got the bones of Living Spaces working in game. So, in hopes that codepoet is agreeable, I will continue to push forward. Edit: codepoet has graciously released CLS in .NET 3.5. Thanks codepoet!

You are right, it would take a plugin, and Connected LivingSpaces is working out space recognition vessel wide, to determine which spaces are "connected", meaning a Kerbal "could" travel to these spaces internally, without EVA. codepoet is actually discussing hatches and opening and closing. so the framework is being built to do a lot of crew stuff. I see where you are going. Actual interior views that can be "walked" in? Very cool, and that is not the direction codepoet's api is going. he is setting up a means to determine where kerbal can move internally. Still helpful, but not core to what you are doing for sure.

Update. I've plumbed most of the interface for Living Spaces. Working on the logic and path of kerbals thru the ship from one living space to another. Also working out highlighting and sounds in real time as a kerbal moves thru the ship. Progress...

Given the beauty of these parts, and their possibilities, have you considered creating ModuleManager Configs to support ConnectedLivingSpace? I'm incorporating that API into Ship Manifest, and plan to take advantage of moving kerbals around extended and multiple living spaces.

Well, getting the hang of your API. I have most of the interface plumbed for Living Spaces. Now the real heavy lifting: Navigating the part path from space to space, and managing the real time highlighting as a kerbal moves thru the ship. Then reworking the interface's behavior so it is both intuitive and prevents you from doing anything you should not. Btw, the casting is working out nicely. It is allowing me to essentially work spaces into the existing interface with a fair amount of code reuse Well, off to bed for some rest and coding in my day job. I think the next update is going to shape up well. NOTE to everyone: This next update will make Ship Manifest dependent on Toolbar, ConnectedLivingSpace, and ModuleManager. I just want all to understand the dependencies.