SabertoothMosquito

Understood. Well, you pretty much described the core of the problem. To try reiterating : the suggested workflow is that user activates plugin GUI (the window with numbers and few buttons), then clicks the target part, now plugin is in "target" mode, and all operations from there on are applied to target part. Any click on next part, any selections in part tabs, action groups, pretty anything other than going straight to editing angles CANCELS target mode. This will most likely be frustrating, but it ensures that plugin does not further block any user input. Or it could be (via GUI) set to some kind of "lock" mode (to keep plugin in "target" mode) but that is a risk that user should be warned about a taking it on their own responsibility. Yes, the action group mode does just the above, but i somehow do not see it used for part geometry editing. When i first used Modular Fuel Tanks i was a bit uneasy going to action group editor. Now it has it's own resource editing GUI accessible via right-click menu. HEEEYYY !!! What if you can use same right click menu item to show GUI, or have all buttons and angle numerical feedback labels right there INSIDE menu ! That way you maintain "targeted" mode of part. Now that i remember, Modular Fuel Tanks, Tweak Scale, Tweakable Everything and others do just that ! Also, Procedural Parts (previously StretchySRB) uses multiple keyboard shortcuts to handle it's own commands while mouse is hovered over a stretch-enabled part (but that will use up available keyboard shortcuts, read below for more). [Oh boy there is more ... ] Plugin authors should really try to work out some common mouse/keyboard input capturing API (can KSPAPIExtensions.dll do this ? Or at least can it be updated to cover this ?), unused keys will be quickly exhausted with ever growing number of "must have" partless plugins / plugin-driven part packs. Maybe each plugin could "take turns" in capturing mouse/keyboard input if exclusive access is needed, also common API should register all capture keys, report any overlaps and offer user with choice to remap keys. Those remapped keys are then returned to all plugins to "listen". Maybe plugins could register in that API keyboard hook functions formatted as "PluginName.UserFunction" strings that are then mapped to keys requested by plugin(but possibly remapped). Also API should have a Blizzy Toolbar integration for mouse-controlled layout switching that could group keys, avoiding input collisions when two plugins need same shortcut keys in same conditions (those shortcuts would reside in different layouts).

I have tried it and i may have misunderstood how to use it properly : i have a part that i attached at angled surface. As expected, attaching it caused part to change to new angle. Then i wanted it to re-align it again in relation to editor space (and cockpit/root part) to make it "straight". When i activated GUI to display angle, it showed the angle relative to attachment point, but i was hoping it would show absolute angle (relative to editor orientation). If this is not yet implemented, i ask if it can be added (editor or "absolute" angles with usual relative-to-attachment node ones). I don't know how ships structures in editor look from programmer's point of view, it may be needed to "trace" through several parent parts to calculate "absolute" angle. Also a GUI improvement suggestions. Workflow type 1 (numerical feeback) : 1. activate plugin GUI via Toolbar 2. click "target part" button (maybe use same alt-p to both open GUI and activate part selection mode) 3. select target part 4. use commands and watch for angle changes Workflow type 2 (numberless visual feedback): 1. activate plugin GUI vi Toolbar 2. click "target part" button (maybe use same alt-p to both open GUI and activate part selection mode) 3. click on desired part 4. targeted part now shows alignement vectors in editor 5. click angle buttons to change angles 6. each angle change is followed by new vector guides being moved, when an angle vector guide is aligned to some predefined angles (like 30, 45 or 60 degrees) it turns brighter Both workflows assume part can be optionally manipulated while still attached to ship. Also, it would be nice to have "zero" buttons for both relative and absolute angles. I admit, this would make more sense for absolute angles as it would align part to nominal orientations instantly. Absolute angles do assume target part is manipulated while still attached to ship, otherwise they are meaningless. NOTE : Look for vector guides examples at landing gears in firespitter pack.

An idea for stage / action group for engine/rcs thrust calculations and com/dcom/acom centering. For example, i had designed engines in two stages (jets and rockets) in SPH. It would be useful to make this plugin aware that they have separate thrusts and thus separate effects on vehicle. I could assign engine disable/enable function to action group key 0-9, and (with action group editor selected) plugin would detect my keypresses of keys 0-9 and show new thrust/torque vectors. Similar for mass centers : if it could be possible to click on 1 or 2 construction elements (fairing/stack decouplers or ports) that define separable payload, that way i can review how centers look with and without payload (even better when this get taken into account with above engine forces).

I pm'ed author a while back with link to my previous post, got no reply. Plugin is ok and has a potential to grow, but i wouldn't hold my breath I just keep an eye on this thread in case plugin development is continued or resurrected.

Although i do only space planes, i too experience rolls and flips. Especially after deploying a payload and deorbiting into atmoshpere below 40km. But i can't blame it on STs, in my case thats construction issue.

Test platforms : -XP 32 bit KSP 0.23 in virtual machine (fresh install + similar set of apps as on physical machine) -Windows 7 64 bit KSP 0.23 in virtual machine (fresh install + similar set of apps as on physical machine) -Windows 7 32 bit KSP 0.23 in virtual machine (fresh install + minimal set of apps) -Ubuntu 12.04 LTS 32 bit KSP 0.22 in virtual machine -Windows7 64 bit 64bit on physical machine (main KSP platform) Test KSP config: -minimal set of plugins on Ubuntu in virtual machine StretchySRB, Toolbar, ModuleManager -set of currently used plugins under XP/7 in virtual machines (same as phyiscal machine) Toolbar, ActionGroupManager, EngineerRedux, ProceduralFairings, KerbalJointReinforcement, ModularFuelTanks, Personal modded copies of ram air intake, strut connector, swept wing, large girder for part count reduction notes, ProceduralDynamics (procedural wings), RCSBuildAid, StretchyTanks, TriggerTech Kerbal Alarm Clock, TweakableEverything ModuleManager Unfortunately, in all tests the same bug showed up, while editing geometry or textures, RCSBuildAid reported same torque/translation problems. The only difference in tests was in KSP 0.22 under Ubuntu LTS 12.04 inside virtual machine. RCSBuildAid did not load properly (i looked in log file, there were mono errors about unknown types) so i removed from GameData. Toolbar also did not load properly so i just left it there. Test SPH vehicle was created and it's geometry/texture changed several times under this version of KSP and then transferred to my Windows 7 physical machine and RCSBuildAid showed same problem. All in all, no matter what OS, 64 or 32 bit, physical or virtual machine, StretchyTanks show same symptoms. I just can't believe my eyes. I know other people don't have this problem, but after this much testing to have SAME problem... Incredible ... More updates: Since i have added modular fuel tanks, StretchyTanks relinquished control over available fuel types, and cycling through them does not change/exacerbate the problem/bug. Also i tested StretchyTanks in KSP 0.22 on Ubuntu LTS 12.04 on a Dell laptop (ie physical machine) by making a small test craft, doing usual modelling tasks and then saved it. Since i didn't bother to make RCSBuildAid work on linux version i transferred this craft file back on my main machine and there it was - a small but measurable torque/translation value. Also, when StretchyTanks are attached to central tank (which is right behind remote control pod root part), no issues durign editing. When i try to attach large girder to central tank an then attach ST tanks it starts bugging again. Also i have used SharpDevelop 4.4.1 to load a sln and build from source. Same problem. Here are some pictures And here is the craft in question, in different phases : ST direct attachment KSP ST re-attached to girders, no editing KSP ST attached to girders after editing

I agree with above, but for EVAs requiring more complex operations and/or toolsets, players should have available adequate equipement/parts : player should build a small repair-tug from RCS thrusters, RCS fuel, solar panels/ RTGs, reaction wheels, lights etc and it should have a surface attached toolbox part used for manual manipulation/repair and a large magnetic claw-like clamp for capturing and manipulation of large components used to position a component into place before performing component repair or installation.

Me, again.. SIGH. Really. I just built a first working catamaran-style LKO lifter SSTO that gets 98 ton payload at 150x150 orbit with overkill fuel left to deorbit back. Then i tried to resize it for more payload space and guess what ? It started weering off tarmac like crazy. I have RCS Build Aid screaming at me those red torque/translation vectors, but did i listen ? NO. I want to fly first, ask question later. Well, this is "later". So i did a little experiment and it showed something disturbing in SPH : -place a command part -attach to it some fuselage -turn x2 symmetry on -attach long girder radially -attach radial attachment point (or not, whatever) -attach stretchy tank -attach engine to it (any) -now press R and wiggle mouse while pointer is over tank, effectively streching and shrinking it back -check RCS Build Aid engine torque output, IT WILL GROW with each stretch/shrink. Even small error, with over 5 meganewtons of thrust will kill any craft It is late and i felt cranky, thus the extra blurb along with bug reporting ... Pleeease don't use full precision range available given by floats/doubles. Although nice on drawing board, it murders my crafts. I really don't look forward to using that old "structural fuselage". I guess this geometry error also affects editor when trying in symmetry mode to attach things and it refuses until either i make all parts in normal mode and then do symmetry placement or move camera around to "coax" it into placement. I just wanted to lower my part count, i guess this road ain't easy. More news on copy/paste front : if i attach radially something to stretchy tank, it will retain proper attachment nodes. If i attach another stretchy tank, he will have messed up nodes after copy/paste, but parent (that i clicked to copy/paste) stretchy tank's attachments will in this case also stay properly positioned. UPDATE : tried same test in VAB, it too suffers from same geometry-torque combo bug. UPDATE : I've built a basic symmetric test contruct with radial attachment point part and separately added two stretchy cones, each with it's own engine. Then i cycled through fuel types several times on only one of the parts, and rcs build aid engine torque output steadily increased. It seems that every time i change something with tanks, not only geometry but all other data on manipulated stretchy part is somehow irreversably corrupted. Anything short of direct intervention in craft file itself will not help the issue. Incredibly, same thing will happen with cycling through textures !? I'd thought i will never see entropy in digital construct, but there it is.

Here is the shot of random symmetry event, despite it's somewhat ephemeral nature it wasn't so hard to capture it. Aaand don't judge the book by it's covers, she flew even with stock parts, albeit hard on CPU because of 1500+ part count and it took some babysitting above 25 km. Once i delivered near 100t of deadweight payload to 73x73 orbit, left aftwerwards with nothing but fuel fumes.

I tried this and it refused to change type to structural fuselage. Tried two tanks to combine with pwing and put in subassembly, it worked. Though i can report a new oddity : when trying to make symmetry, sometimes it mirrored half takes some strange orientations. All i do then is move camera and try again. Not so bothersome, but may point some other underlying issue to be fixed down the road. About attachment nodes - i did once modding a stock part via cfg and have discovered that when editor takes part from library and places it in design space, that part becomes independent from it's source in parts library. I modded part's cfg several times, restarted KSP, reloaded vehicle and found it's component unchanged, despite the changes in cfg. This "disconnect" from library upon placement really does not help the develepment of procedural parts ...

Thank you for prompt reply ! I have tested my KSP with all other plugins deactivated and same thing happened. And thank you for the tip ! Keep it going.

As far as i see it, at time of this bug i had active plugins : engineer redux, procedural fairings, actions on the fly, kerbal joint reinforecement, rcs build aid, kerbal alarm clock and procedural wings (dyj procedural dynamics). Of these, in SPH editor only engineer redux, rcs build aid and procedural wings were used. Another thing i discovered : if copying tank (causing faulty attachment points) and then attaching it to something (on first try or several retries) fixes attachment points. I will tomorrow try to remove all other plugins to clear up any unwanted interference (i zip them up right where they are - no change in folder structure/settings and KSP keeps quiet about it )

I don't know if this was already reported, but when i try to copy tank part with "ALT" key (KI-1250) after stretching it with "R" key, it's attachment nodes are left inside part. Attachment nodes are close to center, as if they never moved beyond certain point. EDIT : I had an idea how to bypass this "feature". I have made two more KI-1250 tanks at their default sizes, attached my extruded test tank in between them, then made a copy of the whole trio. Attachment nodes failed as usual, but then i attached them to some part and deleted the additional tanks (with some more reattaching, since one of additional tanks was parent to my test tank). And voila ! Extruded tank had his nodes intact !

Here is what i mean "x-wing" symmetry mode. Normal radial "X-Wing" type EDIT: Ugh, i just realized i hijacked my own thread with this OT, i guess that's a price to pay when developing ideas...

Thank you !

I've read the description on spaceport hoping that it can add ability to set non-numerical values but no such luck. I was hoping that i could preset cross-feed status of docking ports, thus avoiding fuel drain from payload on launch.

This is also my idea behind de-symmetrizing. And also i thought of problematic situation where builder would select a part that has children and then whole hierarchy is copied to "real" parts, so any attempt later on add symmetrical geometry will end up on single selected part. Also, this could be avoided altogether if parts could have more than just even-spread part symmetry, but also have other modes (like the above "x-wing" style for example). Ability to rotate parts once set on their parent's nodes/surfaces would also greatly help creating perfectly matched part groups, personally it would help my SPH lifter designs. The "x-wing" alternate symmetry mode could be realised as this : builder selects as usual a symmetry count, target part and parent part. Now, by using a hotkey builder can choose to "squeeze" parts along a single axis perpendicular to symmetry axis, and then as usual use mouse to rotate this axis. This symmetry mode would for part placement assume not a normal circle, but an ellipse, where target parts would be closely "bunched" together at points of transverse diameter. I just realised this only makes sense for even-numbered symmetry, odd-numbered ones would leave one part "hanging". More advanced part symmetry already is essential when making any type of lifters since amount of power used is stressing components so much that any disecrepancy creates huge torsion forces (try making a catamaran-style SPH by manually aligning parts without using symmetry, then use RCSBuildAid and it will show you a quite large torsion vector - it is a pitty that it can't analyze a design and point to a part that causes this).

Add ability to convert symmetry part to real standalone parts, as if two were placed individually.

IDEAS Symmetrical cross-section tanks For now, tanks come as round, but why not have tanks and fuselages with 3,4,6 or 8-sided cross-sectional area ? EDIT : polygonal cross-section to snap other parts on flat surface. Xenon fuel Please add Xenon Fuel resource to available fuels. I admit i did not yet try to build ion-powered crafts of any size, but stock tanks look a little puny to me. Size Presets Add Size presets to parts to match stock parts (or more, as author sees it fit). Presets could be called with hotkey or GUI window that can be shrinked to single icon. Toroidal geometry Yes i know there are toroidal tanks, but may i suggest a new twist : besides having editable main radius and cross-section radius, also add arc length. This would allow creation of "pie-slice" parts or plumbing-like knee-joint parts. Ofcourse these would also have polygonal cross-section variant. Axial Alignement Markers By adding a small marker ring line at arbitrary point along part's main axis, builders can add part that snap EXACTLY to same position, without using SPH/VAB symmetry. Radial Alignement Markers Similar to the above, just for radial placement. Radial markers stretch along the entire main axis of part. Most useful if combined with above Axial Alignement Marker to create exact mount points, this means that when both marker options are combined, there are no marker lines anymore, only points. Any reasonable number is acceptable. Example All above options should be mixed to maximize variety. Think of hex-shaped 3/4 arc torodial fuselage with mounting markers at several points. Good for weird-looking space-stations, vehicles and other special purposes. Possible bug Also pay attention to potential bug when trying to use markers on polygon cross-section part, example 7 radial markers on 6-sided surface. It could be fixed by forcing marker radial count to match polygon symmetry count. In this case using radial markers has two consequences: - mount point can be created at any point where flat section of polygon is marked with axial marker line - or by activating radial marker with forced symmetry, thus cerating a mount point at exactly middle of flat section of polygon Alignement Marker Placement Modes : Free and Spread Alignement Markers could be arbitrarily placed along their respective axes or they could follow a even-spread symmetry. Yes this is a duplicate of KSP editor symmetry, but this woul`d work on toroidal parts. Example : along their main axis (which is not a straight line).

Damn ... Sorry

IDEAS Symmetrical cross-section tanks For now, tanks come as round, but why not have tanks and fuselages with 3,4,6 or 8-sided cross-sectional area ? EDIT : polygonal cross-section to snap other parts on flat surface. Xenon fuel Please add Xenon Fuel resource to available fuels. I admit i did not yet try to build ion-powered crafts of any size, but stock tanks look a little puny to me. Size Presets Add Size presets to parts to match stock parts (or more, as author sees it fit). Presets could be called with hotkey or GUI window that can be shrinked to single icon. Toroidal geometry Yes i know there are toroidal tanks, but may i suggest a new twist : besides having editable main radius and cross-section radius, also add arc length. This would allow creation of "pie-slice" parts or plumbing-like knee-joint parts. Ofcourse these would also have polygonal cross-section variant. Axial Alignement Markers By adding a small marker ring at arbitrary point along part's main axis, builders can add part that snap EXACTLY to same position, without using SPH/VAB symmetry. Radial Alignement Markers Similar to the above, just for radial placement. Most useful if combined with above Axial Alignement Marker to create exact mount points. Any reasonable number is acceptable. Example All above options should be mixed to maximize variety. Think of hex-shaped 3/4 arc torodial fuselage with mounting markers at several points. Good for weird-looking space-stations, vehicles and other special purposes. Possible bug Also pay attention to potential bug when trying to use markers on polygon cross-section part, example 7 radial markers on 6-sided surface. It could be fixed by forcing marker radial count to match polygon symmetry count.

First sorry about cross-posting, i wasn't sure if this thread is really a branch or countinues support. I tried to use 1m fuel tank and i have problem setting multiple swept wings along it's length, they tend to attach under odd angles. There is repetitive pattern along the length of a tank, but those points are far too apart to have useful amount of wings. Is there some kind of fix to cfg file that could help "straighten" out surface so that wings get attached perpendicular to tank's axis on any point along it's length ? It's vital to my SSTO craft's design to have swept wings placed close together.

Is this plugin still actively developed or do i need to switch to "continuation" version ? I tried to use 1m fuel tank and i have problem setting multiple swept wings along it's length, they tend to attach under odd angles. There is repetitive pattern along the length of a tank, but those points are far too apart to have useful amount of wings. Is there some kind of fix to cfg file that could help "straighten" out surface so that wings get attached perpendicular to tank's axis on any point along it's length ? It's vital to my SSTO craft's design to have wings placed close together.

Hi ! I just added this plugin to my 0.23 while trying in SPH to add small girders in 4x symmetry (so, VAB mode is inevitable) on radial surface of large RCS tank (750 fuel) and they just would not attach normally as they would in usual 4x symmetry in real VAB. They just want to stay at non-perpendicular angles no matter what, and stay offsetted tangentially from center (not "pointing" to center). I was hoping to use something other than 2x symmetry in SPH without switching to VAB but alas ... Maybe i did not follow instructions properly ? EDIT: I found that after rotating rcs tank in vertical position made the >2x symmetry in SPH worked. Also a few feature requests. Request 1 : Part alignement. Both translational and angular. The translational part alignement would help in building "proper" geometry, especially when it affects craft's CoT vector (look for RCSBuildAid, it really helps debug CoM/CoL/CoT issues). I often in SPH try to add two parts that have perfectly matched main axis (front/rear) coordinate. So far, i can only visually check if parts have same position, which is with "jittery" mouse control a tad hard, more on that later). Workflow (admittedly this is for SPH, in VAB it would work quite different, maybe polar coordinates ?) : - add part A, to be used as alignement target - add part B, to be aligned - add part C, attachment target for part B - set part A as translational alignement target, also set which axis (main, transverse, vertical) - select and move part B to part C, when part B is "close" enough (at some predefined "snapping" distance) it would "snap" to same axis position as part A, if part C to which part B is attached part ALLOWS it, otherwise it could break editor (i was able to break it several times on complex geometry, had to exit to space center and go back) - set part B in position as per usual workflow Example for above workflow would be adding multiple docking ports (normal size) to fuel tank, all aligned to same position on main axis. The angular alignement would work pretty same as translational, but it should allow user to add part to any parent part as long as parent allows this (again, trying to avoid breaking the editor). This also has consequence that it must "enforce" angle snap settings, ie if user has currently 15 deg snap and alignement target is 16 deg rotated, it must switch to 1 deg mode while alignement operation is active. Another problem is how to define a alignement root for manipulated part ? When part is in normal position (when selected from building icons) it can be attached to rotated parent and it will rotate too. So if this is not a big programming issue for you, user can be given option to either respect aligement of attached-to part center, root part center or even SPH center (same as freshly placed command part). This issue affects both translational and rotational alignement because of centering (user may not notice it for translational since rotational would probably be default). Another idea : user should be able to align part to be added to parent part as well. Example : add radial attachment to center of large grider instead of manually targeting (which causes part to rotate on flat surface). Also a choice to align to one or more parent part axes, maybe under a defined angle (maintain a 30 deg angle anywhere on parent surface). Request 2 : Editable camera rotation radius and position (partially implemented, yes). I think i'm not the only one annoyed when i need to look at certain part at close zoom level during construction and having to do lots of rotate/move/rotate/move/... just to manipulate or look at target part from different angle. Workflow : - add part A, used as manipulation target - define part A as camera target - rotate around part A at close zoom level - unlink part A from camera target (effectively return camera control to normal behaviour) Also, when user need to quickly do something somewhere else, there should be option to temporarily "bookmark" a part so camera could jump back to target part after user returns attention to edited part. Also, there should be an option to switch camera to part's "symmetrical twin" (or to next instance of it if >2x symmetry). One more : Add keyboard control of camera. This by itself is useless, even most of times won't have visible effect. BUT. I noticed when making changes to >500+ part vehicle, editor often "stalls" then resumes operation (yes, even 0.22 suffered from this despite user complaints back in 0.22), and it still records all mouse movement and clicks during "stall" causing camera to "jump" unpredictably. This more a bug of editor, but if keyboard control to camera translation is added, this issue could be circumvented for the time being. Request 3 : Part manipulation while attached to construction. I did not know how to call it Idea is to edit part position and/or angle AFTER it is attached to parent part. I often (don't know about others) have trouble when i try to move attached part, when i click it, it "jumps" so it's center moves to pointer (a normal editor behaviour with "fresh" parts, but still annoying with attached ones), ruining the placement. Workflow : - add part A, used as parent part - add part B, used as manipulated part - add part B to part A - select part B for editing (selection operation provided by editor tools) - precisely move/rotate part B Note that above operation may collide with translational alignement, but can be internally resolved : - set translational alignement target - begin editing attahced part to change it's position - edited part cannot "snap" to alignement target since it would cause it to detach from parent part (but if it can slide along surface to reach position, that's fine), this should not be point of confusion for user as long as alignement target and parent part are separated by more than snapping activation distance Request 4 : Precision editing. Oh how many times i was annoyed at editor when i moved a pointer just to move part a little bit, and instead it "flies" off on entirely different position ? Like chaning angles, if this can be manipulated with cursor keys, it would immensely help. Options to define/select amount how much part moves are also welcome.

And another info : right-click on popup icons for multi-select. That way you can display both debris and your ship at the same time, without the need to switch over and over again (another annoyance i was lucky enough to resolve right after finding this thread) !