spearsp

Members
  • Content Count

    30
  • Joined

  • Last visited

Community Reputation

3 Neutral

About spearsp

  • Rank
    Launch Vehicle Activist
  1. Thank you. I've moved the issue to the AFBW forum and shared the crash dump on dropbox.
  2. spearsp

    [1.5.*] AFBW Revived (Joystick & controller mod)

    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
  3. 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?
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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!!!!
  9. spearsp

    Access violation

    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.
  10. spearsp

    Access violation

    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
  11. spearsp

    Problems with orbital rendezvous

    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.
  12. spearsp

    [1.4] Davon Throttle Control systems mod [v087]

    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.
  13. spearsp

    [1.4] Davon Throttle Control systems mod [v087]

    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?
  14. spearsp

    [1.4] Davon Throttle Control systems mod [v087]

    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...
  15. spearsp

    [1.4] Davon Throttle Control systems mod [v087]

    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.