Shadowmage

Have just re-started working on them. Will likely bash out a model for an initial concept part today along with doing a bit more work on the plugin that will drive it. The main points that I'm curious about currently are the 'Control from Here' and 'Target Here' options; I'm wondering how nicely these will play with MJ/etc for autopilot control, and wether they work properly for targeting and control orientation -- did not get a chance to test them last night, so will be looking into that a bit today as well. If all goes well, I might be able to get at least an untextured multi-docking port part for this weekends' release. Excellent work on the research, has provided some interesting insight, and certainly saved me some time on that end of things. I'll be trying to incorporate a 'shielded'/unactivated mode into the multi-port parts, to hopefully cut down/eliminate the CPU hit for the docking node code. Will post some preview/renders as things develop

Negative, and negative. Go and read my post again. Or..here are the relevant bits: "For many parts using one of each unique part will be okay - EXCEPT in cases where they used the same transform or animation name in both parts (which is quite a few stock parts)." I guess I should have added the info to that exception that stated in those cases (of multi same-named transform/animation) that it will NOT work right (only one will function). ONE of each unique part -might- work (e.g. one spot-light and one wide-angle light). Quite often though you will run into problems due to the model or module setup for those parts having conflicts (e.g. if those lights have their light-emitting object named the same, only one will work). Two of each will NOT work properly (only one will function). Four of something will most definitely NOT work (again, only one will function). Really though, I would just try it out and see what worked/did not work.

For many parts using one of each unique part will be okay - EXCEPT in cases where they used the same transform or animation name in both parts (which is quite a few stock parts). E.g. if the deploy animation for two antennas is both named 'deploy', only one of them will function. Or if two different solar panels use the same deploy animation name or the same suncatcher or pivot names, again only one will function. The best example I can think of is probably the two standard stock docking ports (regular and large); they both use the same default docking-node transform name, and only a single will function. Generally I would just give it a go; the worst that could happen is that it doesn't work and you have to delete the part. (Edit to note -- RCS ports generally work fine even with multiples, as the module that drives them is already multi-transform aware)

On a more positive note; Mutli-docking port parts are a go. Did some quick testing with a mockup geometry part with the requisite docking node transforms. With the stock ModuleDockingNode you can successfully dock and undock multiple craft to it the same part, it all comes down to having the transforms in the right place, with the right names. There is still a problem in telling which part to decouple/undock with the stock module, but I -think- I have a little bit of custom code that should clean it up quite a bit by labeling the undock/decouple node options in the context menu. So, expect to see a couple multi-docking node parts in the semi-near future; will probably be 2-4 different parts, each with 5 docking nodes on them (and one non-docking attach node). The different parts will have different combinations of docking port sizes on them -- standard x5, standard x3 + large x2, large x5...(others..?) Will also be using these types of multi-docking ports on some of the upcoming Station Core parts -- such as a large storage torus with integrated docking ports, lights, and solar arrays. Will investigate using mesh-switch on them to limit the editor part list additions, but not sure if I'll be able to pull it off cleanly on these (due to needing different settings for node positions and docking port sizes). Will also be investigating a 'docking port toggle' that would activate/deactivate the magnetics, etc; would basically function as the shielded docking port (without an animation) to hopefully reduce the CPU overhead caused by docking ports in general. Still doing some thinking on the 'welding docking port'; I believe I should be able to pull it off, just need the time to sit down and tinker with it.

Looks like classic mipmap induced blurring/sampling. What does your UV map and textures look like? From the myriad of vertical lines on the tank sides, it would appear that you UV mapped each face individually as its own island. Either way, the usual solution to mipmap induced problems is to remember to 'color outside the lines' for your UV map; your texture should extend 4-8 (more?) pixels outside of the UV lines.

For those wondering why IVAs are so slow to create: It is because you run into (potentially unsolvable) problems such as these: Note the terrible shading on the left. Note the proper shading on the right. Because I am working on 'internal' geometry, the normal tools available to fix such problems don't work. As such I had to spend the entire last two days (something like 20 hours of modding time) to re-learn basic Python (because for some obtuse reason Blender.org decided to use Python as their plugin language), and write a custom blender script to fix the normals for a cylinder with extrusions. What should have been a simple 'push the button' operation has turned into such a major affair... I'm not even sure I want to continue working on the IVAs after this. Seriously, in the time I lost fixing an issue that should never occur, I could have modeled several parts (at least one!), or gotten a texture mostly done. And I haven't even started on the actual geometry for the IVAs; all this was just to fix the @#$% shading problems for the main cylinder walls. So... for now IVAs are on hold until I can find/create the tools to work on them without massive frustration (or until someone else offers to create them(IVAs or tools)). Because if I have to spend another two days dealing with python/blender scripting and fixing &^$#@*( shading and normals, I will be done modding and never look back; I enjoy creating things, but it is not worth the level of headache and frustration (and lost time!) that I have dealt with over the last couple of days.

Aye I was playing around with the SRB effects for another (new) part that I'm working on... and figured what the heck, lets try copying them into the BPC to see what they look like. And...well... it looks acceptable. Will play around with it a bit when I have time to see if I can get the smoke effects to lineup with the (angled) thrust effects...it seems they currently spawn from effect origin without the same angled velocity component that the flame effects have. Might not be much I can do about it, but will see what I can do about cleaning it up.

Thanks for the support The low impact tolerance is intentional; notice how light the pod is compared to other available options based on the number of occupants it carries and the included features. 6 occupants, RCS, and heat-shield. Something had to give somewhere. I've also always thought that the 45/60 m/s impact tolerance of some of the manned parts is.... silly. 45m/s is ~90mph. I've personally never slammed into the ground at 90mph... but let me tell you... I don't want to... it sounds very painful. Example: The Apollo command capsule was validated for a touchdown speed of 7m/s. During testing anything above ~12ms could cause potentially harmful/fatal damage to the craft (e.g. crushing the heat shield, rupturing propellant tanks) and the astronauts (massive g-force spike, potential for concussion or compression injuries). (Source: http://www.dtic.mil/dtic/tr/fulltext/u2/a455658.pdf). So... I might consider raising it to 20m/s, but even that is quite a bit higher than it probably should be. Anyhow, I think I will likely be working on IVAs this week. Gotta get started on them or they will never get finished. Will continue to slowly poke at some of the other stuff I'm working on, but the IVAs will be the main focus this week. Will hopefully at least have internal geometry finished for one of them (yes, will probably take me all week.... have I ever mentioned how slow and painful they are to work on?). Edit:

I have (hopefully) fixed the sliding landing legs problem (will be available with the next release if it works). On the engines - if you are referring to its lack of ability to be deployed/retracted via an action group; I will look into that as well, shouldn't be too hard to add to the plugin. Edit: Also... (BPC particle effects!)

Updated test release is available: https://github.com/shadowmage45/SSTULabs/releases/tag/0.2.9-beta Please see the link for the full change log. Mostly texture updates, but did fix up one known bug regarding the LC3-FL landing leg module (it was causing some... weird issues). - - - Updated - - - This is a perfect example of why; I had noticed the sliding landing gear problem before while I was testing out other things, but as I was testing out -other- things I forgot to take note of it (e.g. open up the ticket), and as such it was completely forgotten about =\ So, yes, please - open up issue tickets, it is the only way to make sure that I will see it and look into it.

Right click on the engine and click the 'add node' button. I could not have them on their full time last I checked because it aggrivated the stock node bugs. - - - Updated - - - https://github.com/shadowmage45/SSTULabs/issues

I would suggest that you try SSTU on a clean install (only SSTU and stock) and see if you can duplicate the problem. If the problem does not manifest on a clean install, begin adding mods back in one at a time (or in small groups), checking for the function after every mod/batch of mods. When the problem manifests again, you know that one of the mods you just added was the culprit. Sadly, I do not have time to investigate random mod conflicts with such a large mod list; however if you can narrow it down to a single mod or very small list of mods that are causing problems that would give me a good starting place to begin looking into things. So far no progress has been made on the IVAs. I've spent this week finishing up textures (and prep geometry work on an as-yet-unannounced part) - Fuel tanks are done, ascent and descent engines done, monoprop and rtg fuel modules done. Still have a few more to do (decouplers, pod externals, landing legs, deployable solar panel module). Will likely issue an updated release over the weekend with the updated textures and any bug-fixing/issue cleanup that I can squeeze in tonight/tomorrow morning. Next week will be more texture cleanup for the remaining unfinished pieces. I might get a start on the IVA internal geometry, but no guarantees. As V. stated, being an purely aesthetic bit, they do not rate the highest on my priority list (and they are a major PITA to model and texture...).

There are a TON of errors in that log NOT caused by SSTU. Fix those (or remove those mods), and then re-test. If you see even a single exception in your log it can mess up completely unrelated things. Example : [ERR 18:31:19.134] [PlanetShine] An exception occured reading CelestialBodyColor node: CelestialBodyColor { name = Tal color = 108,97,82 } The exception was: System.ArgumentNullException: Argument cannot be null. Parameter name: s at System.Double.Parse (System.String s, NumberStyles style, IFormatProvider provider) [0x00000] in <filename unknown>:0 at System.Single.Parse (System.String s) [0x00000] in <filename unknown>:0 at PlanetShine.ConfigManager.LoadBody (.ConfigNode bodySettings) [0x00000] in <filename unknown>:0 Until you have those errors cleaned up, I cannot offer assistance, as I cannot fix other peoples mods nor fix problems caused by others mods.

I am unable to duplicate your non-charging solar-panel problem. The solar panels work fine for me (note the EC charge numbers in the resource panel; negative values indicate that it is receiving charge) regardless of if there is crew present on the ship. In the SS below, there is no crew, and only an MJ module for pilot/controllability. In orbit: (Had on on-the-pad SS for here too, but apparently I took the SS too late and the EC had already charged back to full...) Have you checked your logs to see if anything is throwing exceptions, or if any errors have been logged? At this point I would wager that either there is something that has thrown an exception and is causing problems (after the first exception is thrown, anything after that point in time is likely to not work reliably, regardless of where/what threw the exception), or that there is some other mod incompatibility at play. Could you provide a log file where this issue has occured? (Please use paste-bin, dropbox, etc for posting logs)

You can deploy them in the VAB for the singular purpose of EPL survey stake builds - so that when you build the craft on a different planet it can start with the panels deployed (unlike stock panels, which will leave you with a dead craft until you can connect it up to refuel/recharge it or run a kerbal over to manually open the panels). While this feature is not necessarily needed for the SC-B-SM, it is needed for the module in general (as the module is used in other places as well).

I was using the SM/CM stack as a contract-rescue vehicle in my latest career game, sending up unmanned with only MJ as the probe-core. I don't remember seeing any problems with it. Was a couple weeks ago, but I don't remember making any changes to the solar panel code since then. The only issues I ran into were when I forgot to deploy the panels and ran the craft out of EC during time-warp... Silly question -- are you deploying the panels? Anyhow, as I've already said, I will look into the problem when I can.

I use MJ extensively as well, and have never had any issue with these parts (at least no issues that I could not duplicate with stock parts). Is there something specific that is not working related to MJ? (have already said I will look into the power thing)

As VenomousRequiem had stated, I've taken a time investment vs reward/usability stance on the BPC particle effects; could take hours to figure out/get working, for a part that is used for a whole two minutes during ascent with the effects for only ~2 seconds of that. Having said that, I had already opened up a 'known issues' ticket regarding it a few days ago; so it is on the to-do list and will get done eventually, but do not expect it anytime soon. As to the solar panels not charging -- I cannot say as I had seen that problem last I checked. Is it that it is not adding EC to the vessel at all, or that it does not transmit power to the CM? (Have fuel crossflow disabled on the CM, but I don't think it should effect EC). Will look into this when I have time (hopefully this evening after work). Any more information you can offer would be appreciated. BTW -- Github issue tickets will get a faster and more reliable response for bug reports. I do not check the forums often, and its notification features are... hit and miss. However, GitHub reliably notifies me whenever a new issue is opened or updated, and I generally respond to/investigate those as soon as I see them. In the future, please check the known issues list (such as for the BPC particle effects) before submitting issue reports; and please submit any bug reports through the GitHub issues system -- I cannot guarantee that I will ever see (or remember) issues that are posted here in the thread. Regards, Shadowmage

I've never had a problem with installing or uninstalling this mod on an already running save. All of my craft maintain their proper orbits/speeds, and it all seems to 'just work'.

Public beta-test releases are now available. https://github.com/shadowmage45/SSTULabs/releases Any future dev-test / pre-release packages will be available from that link. I will not be uploading anything to KerbalStuff/Curse/Etc until the non-beta public release phase; dev test releases will always be found only through the github link. Please use the bug tracker for submitting reports regarding bugs, etc (other means of reporting will likely be forgotten before they get fixed; the bug-tracker ensures the info does not get lost). It may be found at: https://github.com/shadowmage45/SSTULabs/issues Please check the existing issues list before opening up a new ticket; if your problem already exists on the list, please add a comment with any new/relevant information that you may have regarding the problem. OP has been updated with links and notes regarding future updates/current plans. Thanks and enjoy Shadowmage

My personal settings for the GIMP normal-map plugin are: Filter Type: Sobel 3x3 (though, you can play around to find what works best for you) tick the check-box for 'invert Y' (needed, as otherwise the normals come out...uhh..partially inverted) All other settings left at default Yes, DXT5nm is the correct format for normal maps.

Ouch; hope it all works out well and she gets feeling better. Wish you both the best. I had intended on waiting for your updates (for the names/descriptions/etc) for the initial public test release, but I will proceed with what I have currently in place (can always update that cosmetic stuff later). On that note, I will hopefully be publishing the first public test release later this evening. Have a few plugin changes to do testing on, then just packaging things up. From there I intend to spend likely the rest of Sept. on cleaning up textures and finishing up all the WIP stuff.

Balancing has been... going. I think I have things to a more usable state though. Parts are still balanced using stock balance mechanics - actual measured volume, 85% fuel mass fraction for tanks. Raw engine TWR is identical to the LVT-45 (13.3)(which is quite terrible, compared to skipper/mainsail(21,25), but very slightly better than lv-909(12)). Pod masses have increased fairly significantly for the LC2 and LC3 pods; though still lighter than the stock 3-crew command module, they are heavier than using multiple stock 1-man lander cans; so I feel they are probably in the right ball-park for mass balancing (additional mass could be explained by the inclusion of RCS and solar panels). Had a heck of a time trying to enable an Altair-styled Tylo-capable lander. But I think I have the parts capable of doing one now, without mucking with stuff too much. 12-part, 2-stage, 3-crew Lander. Uses LC3-POD, with LC5 fuel sections, so should look fairly Altair-like, at least the earlier concepts with the horizontal crew compartment. 59.9405t total mass (quite overweight compared to real/scaled down Altair; mostly due to hypergolic fuels, resultant low ISP, and terrible mass-fraction of stock balance on the tanks) Total delta-V: 6280 (-should- be Tylo capable, with a small margin for inclusion of Ascent stage: 5 parts 9.4623t (5.25t fuel, 4.20 dry) 350 ISP engine (lc3-asce) 2788 dV 1.29 Kerbin TWR Descent Stage: -- Has spare dV, so could easily be used as a cargo-lander variant with increased payload. 7 parts 50.48t (38.23 fuel, 12.25 dry) 350 ISP engine (lc5-dese) 3491 dV 0.80 Kerbin TWR (Tylo TWR of 1 on start of de-orbit burn on Tylo, will increase substantially as the burn goes on, ending in a Tylo TWR of ~3.5 with empty descent tanks upon touchdown) Anyhow... Will be issuing an updated test release this evening with the new balance on the parts. Hoping to get a few moments to re-create the example ships for this release, as I think I'm nearing the stage where the parts should be stable enough that the examples should not be breaking constantly. If no large problems are found with this test release I will probably open it up as the first public beta release, likely Monday or so. Edit: While doing balancing, I found the need (desire?) for oversized ascent fuel tanks for the LC2 and LC3 pods, so they can act as dedicated ascent modules in multiple configurations. For example in the previously mentioned Altair-styled lander, I had to use an additional fuel section below the pod to enable proper ascent dV; with a larger ascent tank this extra fuel section is eliminated, reducing overall mass of the lander and resulting in a much cleaner looking 2-stage setup (and proper RCS balancing without the extra mass hanging below). So, I -will- be doing up a second mesh-switch option/variant for the LC2 and LC3 pods. However, these will likely come with a future update; expect to see them along side the skycrane and service modules in a 1.1 update (after all current stuff is -finished-). More Edit: Adding some updated images (if it ever updates...):

Thanks for the feedback. Will keep this in mind when I am moving on to tackling the IVA stuff. However, I'm not sure there is any way to get a true 'downwards view' while still having isntruments in view; at least not with the current pod geometry. About the best I can do is the view-switching. Or I guess I could move the kerbal seats -way- upwards. The overall geometry though is flawed in regards to Kerbals; It works/would work for humans IRL, as we can move our head around to look out the window, and move it back to look at instruments if needed; not so easy to do with a Kerbal in-game. IIRC, that was how the Apollo crew flew the LEM - standing up with their noses pressed into the window, moving back and looking around at instruments as needed (or relying on the co-pilot to relay vital information). Unfortunately, it is a bit hard to do that with a Kerbal. Still, I'll see what I can do. Can't promise perfection, but I'll try to at least make it more usable than it is currently. Thinking about saving the pods to work on last for texturing, in case I need to make any model changes to accommodate an improved IVA experience. Aye, their thrust is quite OP at the moment, at least compared to their size. I was waiting to finalize the masses on the pods before working over the engine thrust and mass values. 40 or so will probably be about right for the single engine; It just needs to be powerful enough to be used as an ascent engine for the LC2-POD+ascent tank (updated full/wet mass value of 2.82; 40 thrust would give a vacuum TWR of ~1.41). Might even bring it down a bit further; the single engine is at most intended for low-gravity worlds, so it likely doesn't even need a 1:1 TWR on kerbin. Will investigate something like 28-30 thrust, should allow it to still be quite usable for the low-gravity worlds, and possibly allow for a slight mass reduction as well. I've based the ISP on real world examples for upper end/higher tech hypergolic fueled engines; specifically a scaled-down https://en.wikipedia.org/wiki/RD-0124 (~ 0.5t, 300kN thrust, 359 ISP). Yes, it is one of the highest ISP RP1/LOX engines available; why would you use anything but the most efficient engine available for a real lander design? However, the ISP might come down slightly (350?), as I believe the performance #s of the parts with their new fuel/mass values might be a tiny bit -too- good. Might make this during a second balance pass; will probably keep the ISP as-is for now, and look into adjusting in the future if needed. The engines will start to be available about 1/3 the way through the tech-tree (45 or 90 science nodes); one or two nodes deeper in than the most similar stock counterpart, but still early enough to make the landers useful in a (still developing) career game. They should be all set into the tech tree currently, but some of the current positions will likely be adjusted during this balance pass. On the note of tech-tree nodes; If you have any suggestions as to where to place the higher-end parts (LC3, and mostly LC5), I'm all ears . It seems the current standard is to stuff any/all high-end parts into the far-upper-right tech-node (don't remember what it is called; very-heavy rocketry or something), but I would much prefer to have some variation as to the placement of the parts. I'm not familliar with JSIPartUtilities (will take a look!), however I do have a custom part-module (SSTUSelectableNode) that allows for adding/removing/inverting attach nodes while in the editor that I will be adding (back) onto a couple of these parts. Most parts originally had it present, but was removed earlier in the dev cycle as it was not needed at the time; I thought I had found solutions to all of the attach node stuff. Might also add back in the rest of the 'optional' nodes to the parts that had them (using the node switch module)... such as the upper-middle node on the engine clusters. Anyhow, thanks for the feedback and info. Should be able to get most of the stuff sorted out without too much difficulty. Will likely have one final test private release in a day or two for a quick testing of the updated balance on the parts. I expect it should be ready Fri. night or early Saturday.

Yes, AO = Ambient Occlusion. If you are familiar with normal map baking in blender, AO baking is a very similar process. If you are not familiar with AO baking in blender a decent read on the subject can be found at: http://www.katsbits.com/tutorials/blender/basic-ambient-occlusion.php Unfortunately no such operation is available in blender. The closest you can come would be to delete all but one of the quads, UV unwrap it to where you want it, and then duplicate and rotate it into place. The duplicates would all share the same UV coordinates. A very similar process is what I use for unwrapping with various mirror symmetry. Manually snapping them on top of each other is the only other way that I'm aware of.