spearsp

Thank you. I've moved the issue to the AFBW forum and shared the crash dump on dropbox.

I'm also running into problems with this mod, getting an AV as soon as I open the controller dialog. I couldn't find a way to upload the crash log here, so I've shared it in dropbox. Any guidance would be appreciated. Thanks

Thanks for the quick response. This didn't work for me: I get an access violation as soon as I try to open the controller dialog. I picked up something from the forums about copying a DLL from the System32 directory to the plugins folder in KSP, but that didn't make any difference. Any idea how to move forward with this?

Hi Sorry if this is a repeat, but all I've been able to find is the joystick not mapping at all, instead of just missing two axes. My problem: I cannot map throttle and rudder in the settings. It is only seeing pitch and roll inputs. If I select the Yaw input and then activate the rudder, it doesn't respond. If I move the stick left/right or forward/backward, it does pick it up, but just not on yaw or throttle. I know that they're working on the joystick, because I can see the results in the game controller test, and the stick works fine with FlightGear. My environment: The stick is a Saitek Cyborg Force. It is calibrated in Windows. I'm on Windows 10 (64), running the latest release of KSP (downloaded and reinstalled yesterday, in an attempt to fix the problem), unmodded. I installed using the Windows installer. Any help would be appreciated. Thanks

This issue is not unique to KSP - thousands of games before this have had to overcome similar issues. My 2c is thus: Multiplayer does NOT equal MMO. Most of the objections I've read are MMO issues, and KSP frankly doesn't fit the bill for MMO in any form, and never will. The most we can possibly expect from multiplayer capability is being to share a LAN game with mates, either using one player's machine as the host or a server hosted on a separate machine on the LAN. So the issues of Trolls, for example, don't apply here - if your mate sitting next to you goes and crashes through your station, slap him upside the head and don't invite him next time. Mods are easy: The server instance, whether it be a player's instance or dedicated host, dictates the mod setup. Any player connecting must match the installed mods and KSP version exactly, otherwise it refuses to connect because of incompatible mod versions or KSP version. Same as minecraft. End of discussion. There can only be one universe, which is that of the server. The server owns the universe and everything in it. If you disconnect, you are no longer in the game. Timewarp is easy - I can't believe there's so much hype about this. The server dictates warp, and all players are subjected to the same warp speed. A voting system determines which players are wanting to warp. If all players want to warp, then the warp factor is set to the lowest warp requested. Bear in mind that 99% of the time, players are going to be either in the same room, or connected via a voice link so they can talk to each other. Same applies to reverts: If one player messes up really badly and wants to revert, the remaining players get to vote on whether or not to permit the revert back to a certain point in time. If they all agree, then the server rolls back to the desired point for the universe (i.e. all players). I haven't looked at DarkMod yet, but intend to have a good look at it once it is patched for 1.3.1. I'm just engaging this discussion because I see that the current custodian of DarkMod also has a day job and cannot maintain it anymore. In all honesty, I'd only ever want to join a game with my son or with friends, so we can interact a bit with each other on missions, or help each other build a station.

In that case... The contracts are too insular and easy to cheat. Let's start with the latter: Build an orbital station that has power and an antenna, and support for 5 Kerbals. If I have two such contracts, I can satisfy the requirements of both with a single station. Once I have established an orbit and satisfied the first contract, I can then take the same station and move it to a different orbit to satisfy the next contract. This exploit could be overcome by not automatically completing the contract, but actually clicking on the contract to hand over control of the active vessel to the agency, at which point you no longer have control over it - or if you destroy it or move it, you lose the credits and science points you received for the contract in the first place. Insular contracts - this has been mentioned before. Making the contracts build on one another. For example: 1. Create an orbital station around Kerbin, that has power, an antenna and a docking port. The station must be able to support 5 Kerbals. 2. Upgrade your orbital station to support 10 Kerbals. 3. Upgrade your station to include capacity for 20k LFO. 4. Refuel your station with at least 20k LFO. Difficult to do without SSTO but still possible. 5. Upgrade your station to include a docking port Snr, so it can be used as a staging station for missions to other planets. With the help of the contracts, you now have a station that you can use for staging. The next contract involves assembling an interplanetary transfer vehicle with xxxx delta-V, and make the contract very difficult indeed to accomplish without assembling the parts in space. Again, the IPTV can be formed of multiple contracts, or a single contract in multiple parts. For my last mission to Duna, my IPTV consisted of a core and two fuel pods, and my lander had 3 engine nacelles, all of which were assembled in orbit. This, however, only works if the pieces don't get stuck together with the docking port bug, which I previously reported. The career mode serves both as a motive to do things you wouldn't try if you were just playing around with the sandbox, and also as a training tool. On this point, I think the contracts and the tech tree do a good job - trickle feeding you parts and giving you contracts that can be accomplished with the parts you have. Some of the contracts are just whack - why would anyone care if an SRB works on an escape trajectory from Kerbin? Same-vessel collisions: I make ample use of quantum struts, and I don't feel that I'm cheating with this. In the real world, if I put a 300 ton pod into an SSTO cargo bay, docked at one end, the pod does not fall through the floor of the cargo bay. I would have rubber blocks on which it can rest until it gets into orbit. The only way to make this work at present is with quantum struts, because as soon as a sub-assembly becomes part of a ship, all of the parts of the same vessel are able to move through one another. Are they ready for 1.0? They've all but met their targets in .90, and given some work on the contracts and a few bug fixes, I think it's ready. I think some more thought should be given to how the mods are to be included in the game. There are a lot of mods out there that are exploits, but many of them I think should be included. B9 I use extensively, so I do with MechJeb, procedural tanks, FAR, TCA Fuel Balancer, docking port navigation camera, and NavHud, since the kerbals, having discovered space travel, have not yet figured out the intricacies of a compass. I'd be inclined to say we need sub-contracts to develop certain parts or part packs, which are looked up from online resources. B9 Aerospace offers to do some development for you, at a cost. If you accept, you pay them and you have access to the parts pack. However, the parts that are offered as part of the game need to be moderated, such that the obvious exploits do not offer easy cheats to the serious player.

I've had a few odd glitches, moving from a sandbox mode to testing the gameplay. 1. Docking ports. I do a lot of assembly in orbit, launching modules via SSTO and docking pieces together. Quite frequently I have modules that I cannot undock again. Particularly annoying when I want to leave mothership in orbit and want to bring the science modules back to the surface. 2. Falling through the surface of the moon, especially when the lander is on an uneven surface. I land on the moon, and then go EVA to a waypoint for a surface sample. Then I come back to the lander. When I get to within about 200m of the lander, or if I try to switch to it, it has magically sunk slightly, leaving it's landing legs below the surface. The lander then accelerates towards the center of the planet. Happened on Mun, Ike and Duna. 3. Sometimes unable to quicksave. Seems to be related to on occasional bug ignoring mouse clicks. Only recovery is to restart - cannot save, go to space center, etc. This has happened a few times in the past month. The gameplay itself was a pleasant surprise. I believe it still needs considerable work, but that is a topic for a different thread. The gameplay in general is looking very promising.

I see I'm not the only one who's run into this. However, I've tried everything, and I'm still not getting my lander to separate from the carrier. I've spent an inordinate amount of time getting this together in career mode, building the ships up from flat-pack parts, brought up from the surface in 3 loads on an SSTO space-plane with a 40m cargo bay. I decided to swing past Mun and Minmus, and complete the outpost missions on the same trip, and that's when I got stuck. I'd appreciate it if someone can tell me where I'm going wrong here. I've tried this workaround, as well as followed instructions on the "Can't Undock Bug" thread, but the problem is, I can't determine what the parent is supposed to be, because it doesn't seem to be referenced anywhere. I also have a feeling that part of my problem is that the various modules aren't individually named - they all took the name of the SSTO load they are brought up on. I've uploaded my quicksave to https://www.dropbox.com/s/hfe0tgrt3x799v9/quicksave.sfs?dl=0. An image of my setup: https://www.dropbox.com/s/78ev2z0xliq4g9s/Stuck%20docking%20port.jpg?dl=0. Following from the nose backwards, the ports that are jammed are the first ports you see down the center-line of the ship. In running the latest update of .90 on Windows 7, if that helps. The UIDs for the docking ports that I'm struggling with are: 1872071175 (Carrier) 3517598418 (Lander) Thanks Desperate! Edit: It ALWAYS happens that after I've made the post, I make one last ditch attempt at following the instruction to the letter, and it then works. Thanks all the same!!!!

I have now updated my Intel graphics drivers - same result. I'm running Windows 7. I'ts not a showstopper for me, because I can still run it windowed, but would be nice to get it sorted out. If it helps, if I change to full screen from within KSP, after it's loaded, it goes into full screen on the laptop's screen, in spite of the fact that I have the external screen set as the primary display. My next step is going to be to install it on my HD laptop, which has an NVidia display adapter, and try the same thing. I'll let you know the outcome of that.

I'm getting the same thing. I've just come back to KSP after a bit of a break (trying to find that elusive work/wife balance). Ran the patcher to get everything up to date, and confirmed that I'm running the latest version. At this point, I had no mods installed. I'm running Windows 64, using the 32 bit version of KSP downloaded from the KerbalSpaceProgram.com site in zip format. The error seems to occur specifically with multiple displays enabled, with KSP set to display in full screen. I have tried every combination of the two displays (primary and external) and KSP in windowed and full-screen mode. With KSP in windowed mode, it starts up without a problem regardless which monitors I have enabled. In full screen mode, it works with either of the monitors enabled, but not both. I have noticed that the display settings do not seem to take effect immediately, so I struggled to find a pattern at first. If you set the display to window mode (disable full screen) using the launcher, and then launch, it initializes in full screen, hangs there for a few seconds, and then starts loading in Windowed mode. Same also occurs in the other direction: Enable full screen using the Launcher, and then run it, and it initializes in the previous mode, and then starts loading in full screen. The full crash log folder has been uploaded to https://www.dropbox.com/s/dbczplqp2rl5w6e/2014-10-22_185222.zip?dl=0

I'm getting the same thing, in a similar environment, and I'm no novice when it comes to rendezvous and docking. Likewise, I have a 3 part vehicle - SSTO launch vehicle, orbital transfer vehicle and lander. I decouple the OTV from the launch vehicle, and transfer to Mun, leaving the launch vehicle in orbit around Kerbin. Once in orbit around Mun, I decouple the lander from the OTV, and land. Then take off and re-establish orbit, and rendezvous with the OTV. First time round, I had a remote guidance system on the OTV and Mechjeb on the lander. As soon as I decoupled, the OTV accelerated away from me. I aborted the flight and restarted without the remote guidance system. This time, when I decoupled, it didn't do anything strange. However, once I got to within 2km of the OTV after landing on Mun, the relative speed jumped (instantaneously) from 1.0 to 280, and the relative speed on the navball seems to be out of whack. If I click REL- on Mechjeb, however, it does point me in the right direction. I managed to get to within a few meters of the OTV, but it keeps accelerating away from me at about 1m/s/s. Docking is impossible. I considered the possibility that it might be trying to target something else, so I unselected and reselected the target. When I unselected the target, there was no target selected, so that does not appear to be the problem. When I reselected the target, it went into the same state. I have repeated this several times, with the same results. Any ideas? Mods installed: B9, Quantum struts, FAR, Proc. Fairings, Kerbal Joint Reinforcement, Mechjeb, Laser guidance system, Stretchy tanks, Tac Fuel balancer. OTV and Lander use parts from B9, Mechjeb and stretchy tanks. EDIT: I have removed Exsurgent engineering, Firespitter, proc. Fairings, Kerbal Joint Reinforcement, KineTech Animation, ResGen and the laser guidance system from the game, and the symptoms have gone. I'll post here again and on the offending plugin's forum once I've established who the culprit is.

I don't entirely agree with your logic. Torque will always occur on a plane, whether you're working in 2 or 3 dimensions, and I am certain that if a solution satisfies all three axial planes, that it is a valid solution. When I'm trying to balance a plane by eye-balling it, this is effectively what I'm doing - checking that it is balanced from the left, from the top and from the back. However, that said, it's not you that I need to convince, but the results of the solution. And even once I have the Maths all worked out, I have no idea what sort of algorithms I'm going to use to combine the planes into a workable solution. Whether or not this is the right approach for this problem remains to be seen. I am hoping that by the end of the calculation, I will end up with a set of simultaneous equations resolved as a ratio that each engine must contribute to the overall thrust in order to maintain equilibrium, but I'm not seeing a way of doing this without using a brute force approach. I'm afraid I've stalled on this for the moment: Demands at work are astronomical at present, but I plan to spend some time on it next weekend, when things have quietened down a bit. Any idea what has happened to KerbCom Avionics? He seems to have fallen off the grid.

Very helpful - thanks. You see, I would never have got that. So I've drawn lots of pictures and looked at this from several angles, and am slowly coming up with a plan. It occurred to me, pondering the pictures, that if you can resolve the forces in each plane (XY, XZ, YZ), then the calculation becomes a whole lot easier. This seems to be the most intuitive approach. Still working on common sense rather than Mathematics, it also occurs to me that: 1. If a solution cannot be found that satisfies a balance on all three planes, then there is no solution. 2. Where there are engines perpendicular to the plane, they have no effect on the torque on that plane. In other words, a solution on the XY plane may have multiple values, or "Don't Care" elements, where engines are parallel to the Z axis. Using the Euler angles in the thrust transform, you can determine the engine's angle to each axis. This is an assumption - please correct me if I'm wrong. I really cannot get my head around quaternions. If Euler angles (A; B; C) are the angles around the (x; y; z) axes respectively, then the force applied on the XY plane by an engine can be calculated as Thrust * CosA * CosB, where C is the direction of the resulting vector on the plane. We can then continue the torque calculation in 2D space, which renders the problem down to high-school mathematics. The approach, then, is to solve each plane, skipping engines that are perpendicular to the plane in the calculation of the required adjustment. Then take the resulting values and check that the net torque is still zero on all three planes. If it is, then there is a solution, otherwise there is not. By way of example, take a space plane with two engines symmetrically mounted on the sides of the fuselage, below the center of mass. I'm working on the assumption that Z is the direction of travel, X is horizontal across the direction of travel and Y is vertical. On the XZ plane, then (i.e. looking top down), there is a solution: As long as the engines have the same thrust, the net torque will be zero. Since the engines are parallel to the direction of travel, there are no forces on the XY plane, so all solutions will work. On the YZ plane (side view), however, both engines contribute torque in the same direction, so there is no solution. Add another engine to the top of the fuselage. Now, there is still a solution on XZ, although the 3rd engine has no effect on torque, because its thrust vector goes straight through the center of mass. The other two engines still need to apply equal thrust to maintain balance. XY still has no forces. on YZ, the combined torque from the first two engines need to offset the torque from the new top engine. There is a solution on YZ. Then go back to XY and XZ, and make sure that the solution found for YZ hasn't thrown off the balance in one of the other two planes, and we're set. Any thoughts?

With a long and sordid history in vehicle tracking and GIS systems, it is not as hard as it looks. But I need some help getting there: 1. I've managed to find the CoM on the Vessel, but have no idea how this is represented in Vector3. Is this just an x;y;z array? 2. For the life of me, I cannot see how to find the position and orientation of a part wrt the rest of the vessel. 3. I'm also struggling to find out the direction of thrust for the engine. I've read elsewhere that the thrust is along the z-axis, but how does this work on engines like the B9 VTOL engine, or other engines whose thrust vector can be altered in flight? I'm going to get cracking on the maths in the meantime. This may take a couple of days...

I'll PM my craft file to you. Basically a shuttle, with two B9 SABRE engines on a rotatron, slightly aft of the center of mass, and two pure turbine engines surface-mounted just behind the nose. I'll ping Mechjeb about this. You never know. ZRM's solution is much closer to the mark, but there are several issues with it: He's not using a solution for individual moments of torque for each engine, because it does not support engines orientated along any axis - they need to be offset. This makes his solution unusable in my designs. The second problem is that there appears to be no way to override using differential thrust on the engines as a phased array for the gimble. That's a really nice concept when using rocket engines, but fails hopelessly when using turbines. Also, ZRM appears to have retreated, so I don't know when he's going to be updating KerbCom for .23 and multi-mode engines. I am busy studying your code. I'm about halfway through, although it is hard reading code when I don't entirely understand the context and my C# aint that strong, although I did manage to find some documentation on the forum. My plan is to find some stock code online to calculate torque moments about a point, and then see how this can be implemented in the code. I'm happy to help you with the maths - it's just that C# is not my language. I'll let you know my findings.

That's great - thank you. It is looking a whole lot better: The menu options are now available in mixed-mode and fixed mode engines. I encountered the following issues: 1. Direction depends on all engines having the same direction of thrust. Is it not possible to pick up the direction of thrust for each engine, and calculate the moment of torque on the center of mass for each engine from that? 2. It is doing something strange when there are more than 4 engines. I put 6 engines onto 2 Rockomax 64 tanks, almost evenly distributed. The center engines run at minimal thrust (around 20%). I expected the center engines to be maxed out, with either the engines at the back or the front maxed out, and the remaining pair reduced to establish the balance. 3. Mechjeb vessel info is showing max acceleration and current acceleration in the order of micrometers, which does not happen without the plugin. I have not had enough to test further, although I have found that engines mounted at a slight angle seem to go haywire: I cannot keep the vessel balanced, no matter what RCS thrusters I have installed. I have no idea what sort of information is available from KSP, so I'm not sure if this is possible or realistic: Instead of working on a trial-end-error basis for the individual throttle control for each engine, is it not possible to calculate the required thrust to net out torque, based on the current maximum thrust? If the current maximum thrust is, say, 160kN, and you need it to be 80kN in order to establish a balance, then setting the throttle for that engine to 50% should get you spot on? I guess what I'm trying to ask is: Is the relationship between throttle and thrust linear, based on the engines maximum thrust for a given speed/atmospheric pressure?

I look forward to it, with baited breath.

Is there a way to set the limits of movement? I'm thinking primarily of the VTOL rotatron here, where I have to eyeball it carefully to get the engines vertical. It would be nice to be able to set the min/max limits - in degrees for rotary parts and meters for linear parts.

Yes - you need to switch to the StretchySRB continuation, which you can get from http://forum.kerbalspaceprogram.com/threads/57422. He has added solid rocket boosters and conical tanks, along with about a hundred new textures (okay maybe about ten). The conical tanks can be cycled through various shapes as well, so you can create a smooth curved fuselage with them. I'm now using these tanks for my SSTO craft, almost exclusively. This will not fix the issue you are having with your wing attachment problem, and the texture on the tanks is purely graphical. I have the same problem with all tanks (Stock, B9 and Stretchy), where wings attach at a strange angle. With nothing else attached to the tank, it seems to be fine, but it seems that if there is anything attached to the tank behind the point that you're trying to attach the wing, then you can't attach it at the right angle. My workaround for this is to attach the wings from the front (pain in the backside), or to use surface mode (by pressing C) (also a pain in the backside, but better than the alternative).

This works nicely for turbine and rocket engines alike, but doesn't seem to work on the multi-mode engines, such as the stock rapier engine or the B9 Sabre engines. Any chance of adding support for these?

Downloaded and tested - same results. I deleted the original StretchyTanks folder in GameData and copied the new one over, so I'm sure I replaced the whole thing. So this evening I plan to do a fresh installation, and then add the stretchy tanks and see if I get the same results on the stock wings. Then test with B9, and then add mods one by one until I find the culprit. It seems that I'm the only person this is happening to, so it must be something specific to the combination of mods I'm using. I'll keep you posted, and hopefully have a craft file or two to upload once I'm done. EDIT: This is only happening on the B9 HW21 Heavy Wing and the SW Wingtips from B9. It is doing the same thing with the Mark3 Procedural Wing. The B9 modular wings seem to be fine, as do the stock parts. I have tried with a clean installation, adding only stretchy tanks and B9, and it still does the same thing. Stretch the tank, and try to attach something to the wing near the leading edge. B9 R4-0c Stretchy tanks from the above link as of this morning. Kerbal Space Program - 0.22.0.351 (WindowsPlayer) OS: Windows 7 Service Pack 1 (6.1.7601) 64bit CPU: Intel® Core2 Duo CPU T9600 @ 2.80GHz (2) RAM: 8093 GPU: NVIDIA Quadro FX 2700M (2280MB) SM: 30 (Direct3D 9.0c [nvd3dum.dll 9.18.13.593])

I have run into a problem using these tanks with the B9 wings. I have built an SSTO fuel carrier, using the B9 Aerospace pack, procedural fairings and stretch tanks. With the wing attached to the surface of the tank, I can attach things like engines and air intakes to the surface of the wing. Then I stretch the tank a bit, and try to attach another engine to the wing, and while the wing is still visible, the engine just won't attach. However, it can attach to a space about five meters below the wing. If I detach the wing and then reattach it, it fixes the problem. Stretch the tank again, and the problem recurs. Reattaching the wing is not always an option, since it consists of a combination of symmetric and asymmetric components. I have been able to reproduce this without the procedural fairings. I have not yet tested with the stock wings, and I have not tested if this occurs only if you stretch the tank to which the wing is attached, or any stretchy tank in the assembly. Has anyone else experienced this? Are there any workarounds?

Excusing my ignorance - I have just started playing with this mod, and the implications are VAST. I'm waiting with baited breath for a procedural cargo bay and heat shield, which have already been discussed, but that's just the cherry on the already substantial cake. This has unleashed some serious creativity, not being bound by the limited shapes and sizes of parts in the store. What would be the possibility of using this exact model to create procedural fuel tanks? Maybe have a different shroud type for a fairing that is full of fuel, so that we can create fuel tanks that match the profile of the plane? I've played around with the stretchy tanks mod, and they're great from the perspective of being able to size tanks according to their application and apply a texture, but they only support strictly cylindrical shapes. With this mod, my designs have become much more organic and aerodynamic, and the application for cylindrical tanks increasingly limited. Admittedly, there are workarounds using both stretchy tanks and procedural fairings, but the ideal would be to have the entire fairing chock full of fuel.

Really? Have you managed to get this to work? I tried this and found that the fairings would only attach to an interstage adaptor or fairing base, so refused to attach to the hinge. I tried all of the hinges - same problem.

This works great - thank you. At least, it works very well for rocket engines. I am still struggling to get it to work right with turbine engines. With 4 engines around the centre of mass, it seems to have the engines on one diagonal following the throttle, and the other two running at about 10% - can't imagine why it is doing that. It would be nice to have a "simple" mode, that merely attempts to keep the thrust vector from the main engines through the centre of mass, without attempting to follow the controls or interfere with the RCS. Turbine engines do not respond well to sudden rapid changes in throttle. Keeping the thrust vector through the centre of mass shouldn't require much adjustment, and the craft should then be easy enough to control with RCS.