Jump to content

Leopard

Members
  • Posts

    335
  • Joined

  • Last visited

Reputation

177 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, pondering on the precision control mode, the thing you toggle with CAPS LOCK and makes the pitch/roll & yaw indicators go between blue and orange. I can <i>read the current mode</i> easily enough with myMode = FlightInputHandler.fetch.precisionMode; however while FlightInputHandler.fetch.precisionMode = myMode; is accepted it doesn't appear to actually work, presumably this is set elsewhere. Does anyone know where the ability to set this mode lives? many thanks
  2. Have found a fix for this, the problem appears to be related to how the messages are sent to the game. It seems when you send them in the code they join a stack and are sent as when possible. so my code adds a message to activate the SAS then immediately adds one to set the mode, because its a stack if the activate message hasn't gone this means the mode message will be sent first. the game logs back this up showing the mode message arriving first, doing nothing as SAS is inactive, then the activation message arriving which sets SAS on in its default mode. the fix in the Arduino code is reasonably simple. firstly call mySimpit.activateAction(SAS_ACTION); and then immediately set a flag variable but do not try to set the mode, then in your message handler wait to see if you get an SAS mode change notification, and within that check to see if your flag variable is set - if so now call the code to set the mode, then clear your flag. this makes sure things happen in the correct order. this could be sorted in the library but to be honest this isn't a massive issue once you are aware of it and I don't think it will occur with other controls as SAS seems to be the only one you switch on/off and separately set a mode for
  3. having a play with this more now the decent joysticks have arrived, I've got a button hooked up and a red & green LED for the SAS mode can activate and deactivate SAS, read the state back, very nice and very useful. however the game always sets SAS to the default "heading hold" mode, I'm trying to change this but so far having no luck, e.g. I think the following should work but it doesn't mySimpit.activateAction(SAS_ACTION); // turn on SAS - this works uint8_t dat[1] = {AP_PROGRADE}; // Select Prograde Hold mySimpit.send(SAS_MODE_MESSAGE, dat, 1); // Set SAS mode - this bit does not work I can read back the current mode and available modes just fine, I would expect the above to turn SAS on in heading hold if prograde hold is not available, but even when it it the mode doesn't change. the doc suggests "The payload should be a single byte, possible SAS modes are listed in the AutopilotMode enum.", which is what I think the above is doing. presuming I'm doing something wrong but not sure what it is?
  4. I'm hoping regardless of the game mode to play it using a custom made controller deck, as such really hoping KSP2 is able to support a serial interface - nice if built in but guessing part of a modification later
  5. downloaded this and currently fiddling with some basic examples, seems very easy to use. only have a crude joystick but have some actually useful ones on order so will be playing more soon. Q: is it possible to get the current craft acceleration? only really asking as I was fiddling with KSPSerialIO, though these seems a lot more flexible and usable, just curious on acceleration to port one of the examples over. testing currently using two altitude levels, which is working nicely Excellent work
  6. KSP 1 has three game modes, sandbox, science and career suggestion, why limit it to three? have a scenario system and pick the scenario you want in the scenario you set the starting parameters, have/not have funds, science, what tech is unlocked, what tech tree to use. in effect you could start with the classic three, but maybe also stuff like sandbox where you already have bases on mun, minmus & maybe Duna (or the KSP2 versions obviously), some orbital stuff - in effect start part way through the game to cut some of the grind or just go play elsewhere makes career mode a bit more interesting as it could be a bit more focussed, e.g. a more detailed "early years" tech tree, or starting further on, you have a fair bit of tech available, go colonise somewhere random though, but the point is to make adding this stuff later easy because its modular from the get go
  7. a game shouldn't be collecting anything to violate personal privacy, it shouldn't need to know enough to do that in order to run, I highly doubt this install of KSP knows for example my real name, because I've never told it that information. its also worth noting my original point was an observation, thats what I was doing on that day, watching mechjeb crash things even I could get to orbit, indeed I only use it to automate things I know works - its currently acting up, so I'm not using it as much. to dat no Kerbals have been lost, due to the craft having suitable abort mechanics, a few payloads get wetter than intended but thats because uncrewed craft don't get the abort options. I'm treating it as an in game system failure and working around it. and no, you don't have to work with things as they are or we would all still be living in caves somewhere thinking this "fire" stuff was far too risky and we had managed without so far. I've worked with systems where humans are responsible for gathering data and making reports, and where they are just responsible for instigating the report, the second category gathers more information but also a lot more consistent information, and more people make the reports - make it easy to get the information and it happens, make it time consuming, especially in a game, and you will get a lot less feedback and it will likely be a lot more variable - e.g. in what people call individual controls and events
  8. Or, I could just play the game, if people want logging and bug reporting from normal game players its easy build the logging and reporting into the damned game. I have no idea where the log files would be, how to extract the appropriate bits etc either - nor do I fancy creating yet another log in for an online bug reporting tool for the main game - just add it, the ability to open a menu and say "report bug", screen shot with maybe a very basic tool for annotations, a box to enter some text and away you go. you want bug reports, make reporting them easy
  9. today I haz been mostly.. watching Mechjeb fail to reach orbit, several times, in a craft even I can get to orbit, not had a problem in 1.10 so suspect is just one of them things. also watched mechjeb tell me I was orbiting Eve when orbiting Kerbin and refuse to plot a transfer node, then when it did plot one it utterly failed to execute it properly (as in Pe ended up near the orbit of Moho failed) after that I thought "meah" and put the same craft into Eve orbit myself manually, it lacks the fuel to get back but thats a muck up on my part
  10. I tend to use basic, but overengineered launchers, I like elegant ones, I end up with clumsy ones
  11. restarted with 1.11 a few weeks back not that long after it came out, have to say I'm liking it for giving something to actually do when you get somewhere, and once you have a cluster of ground bits, a reason to go back and add more since they actually do stuff - and do stuff a probe cannot yet do. note tried the on orbit assembly stuff as yet, but can see it being useful to upgrade older craft at a lower cost than sending a whole new module
  12. pondering, inhtegrate the bug tracker into the game - won't catch crashes (though a watchdog crash reporter could), but will make saving instant game state, mods, versions etc easier - with a screen grabber and maybe simple highlighting tool?
  13. visited Dres a few times, its the furthest out I have taken a Kerbal and returned them safely, its not exactly exciting but then most of the places you can go to are a bit the same - go, tick the same SCIENCE! boxes, return game needs more randomisation of whats actually at various places, and a few more reasons to actually go to some of them, rare resources or something thats actually useful
  14. i like the idea of resupply missions, but also that you, the player, are at the cutting edge - get to the point where you have flown that refuelling tug a few times and then able to "automate" it and forget about it, the game not doing things you can't for you, but allowing you to automate the bits you have done. I like mechjeb in career mode, by the time you have it you can do what it does reasonably, its then just helping - something similar where say when you have plotted a few transfers to other worlds yourself you get to automate them, but only about as efficiently as you did yourself you still need to design the fuel tug and fly it, and say how often to fly it
×
×
  • Create New...