Yes. Another option to override it is to switch flight assist off.
Binding the “Ship accelerate forward / Main engine thrusters” key (Default “W”) to a button on the throttle would make sense for situations when you want to go over the limit.
Alternatively Third party tools could also be used to map the 98 to 100% of the throttle to a key, might be a useful behavior for some players. (I think some Throttles even have such a thing built in for games that have “emergency engine power” and such. I don’t think it should be part of the game as it can be quite confusing to know what is happening and why the ship doesn’t hold its speed and stabilizes anymore.)
When I floated the idea of ‘throttle quadrants’ or ‘gears’ in the HUD thread, it was to go along with the idea that speed should be controllable by throttle setting. The idea was that zero to lightspeed was too big a range to control with ‘one throw’ of the throttle arc, so cutting it up into 4 or 5 gears would make speed control easier.
Right now, there are already 2 ‘gears’: warp drive, and not.
Maybe it would be easier to do this way:
Since the game itself imposes speed limits in the atmosphere and as you approach a planet or what not in warp, do away with the ‘warp drive’ concept and just allow throttle to control speed setting. The computer will automatically limit your speed (sort of an auto-safety) the way it does now, and the turbo button can still be used to exceed a safety limit.
That way, throttle at 0 = 0, while throttle at 100% = lightspeed. Throttle at 50% = 150,000 kps. You can see the issue with this: controlling your speed at the low end will be problematic to impossible in terms of small variations, hence the ‘gear’ concept. (A 1% change in throttle postion would equate to a change of 3000 kps! That’s the ‘too big for one throw’ issue I mention in the first paragraph, above.) Alternatively, you could use a logarithmic throttle scale but my guess is that would be hard to code. (Or maybe not, I don’t know enough about it.)
I know the impulse will be to say that this is almost how it’s set up right now, but the problem is that the control scheme leaves no way to effectively use a throttle controller that I’m aware of. (Unless I’m missing something fundamental. The beta doesn’t recognize my Saitek controller without me programming/binding things on my own.) What I don’t want to have to do in game is set speeds with the keyboard. I want to be able to put the throttle at 50% and be in the middle of whatever ‘speed range’ the game is set up for, whether it’s zero-max speed or the mid-range of some intermediate ‘gear’. (Computer controlled speed limits nothwithstanding)
Flavien mentioned in the other thread that he uses a HOTAS system. I’m curious as to how he has his throttle set up to use in-game. (?)
Why dont you just bind the throttle axis to shipZ?
That way you can have the throttle at 50% (zero speed) and increasing/decreasing the throttle accelerates/decelerates your current speed (works on target speeds too).
I suggest you visit us over at discord Infinity Community Discord Server and we can help you set up the way you would like it … because it seems most of what you are suggesting is already in the game and it’s just a big misunderstanding.
Auto assist speed setting (Also called throttle here sometimes) does that. Already in the game.
Auto assist speed setting is logarithmic and can be bound to a throttle. Already in the game.
The game does not (yet) recognise or auto set the bindings according to whatever controller is connected. Many games don’t do that. I suggest you focus your posts on what actually seems to be your point here.
If you wish for your setup to be something that should be auto recognised or at least preconfigured you can create a binding .xml file and maybe it will be considered to be included as a default.
Even though it’s formidable to try to project and suggest your understanding of how you think it should work we would welcome it if you put in some effort to see how much work it would be to create the setup you would like with the tools already available now.
This way I-Novae can evaluate if it is worth the effort to change something to the flight model or the binding system.
Due to the way you formulated your posts it is hard to discern what exactly you want due to you suggesting different ways of achieving what you want instead of further describing what you want. Filling in the gaps myself though I would suggest following setup:
Do what Palybenni suggested and set your throttle to “shipZ”.
After spawning set the “speed range” to your liking by using the number keys. Do this once after every spawn and you should have the behaviour that you want.
You can do the same after entering warp to achieve the same behaviour while in warp.
Give it a shot. If it turns out to be too tedious you can surely suggest the ship remembering its setting or some switch somewhere. Alternatively you can use third party tools.
I want to remind here that people who fly flight assist off also have to switch off flight assist after every spawn. As well as when entering warp, the speed setting is always set to maximum even though me and some other do not prefer that as it makes tactical warping more tedious. i guess it is done this way to help new players get arround, one less step to “increse speed setting”.
Just putting this here to show that there are other such nuisances in the game.
I also want to add that I am really glad that I:B does not auto recognise controllers. I have about 3 controllers connected to my computer at any time.
I think mouse and keyboard being default is sufficient with easy access to “enable” controllers as wished. The current way it is solved in the game launcher I find a refreshing change to most games and a positive and superior solution with its manual assignment of what actually is Controller 1 to 4.
I think a wide range of default binding or general bindings that need to be adjusted only slightly would be sufficient.
Edit: Thinking about it again I have to say that it would be more optimal for new players that the current system stayed the same (bar the suggestions I made lately) but yes, in fact, the default, on first startup the game chooses what controller should be in slot one. The default bindings should be set to Primarily Mouse and keyboard and on the Secondary optimised and preconfigured for either joystick or gamepad (depends on what new players use more).
As long as the options we have now remain and are not overwritten every game start I am fine with that and agree that that would help reduce precious “dead time” before a new player can experience the great gameplay.
Just the usual few things… making it easy for xbox gamepad users to get set up and going, including those 3rd party xbox like gamepads with lots of extra buttons and paddles (hope to have one, one day). Gamepad rumble, well designed of course. Maybe force feed back one day for FFB joysticks and Hotas.
External space elevators on space stations, work crews out doing repairs welding and stuff. More life and activity around land bases with track ways and day to day ore mining and refinement processes going on. Work crews, work drones (space) and land vehicles (land) that can be killed, blown up and all sorts of nasty space decompression fun and games if your close enough to see it.
Done so it only shows when you get close enough, certainly for the space stations when your chasing thru the station struts close to the hull. And, of course fluffy white volumetric clouds and mist and fog, and volumetric layers making up the large gas giant planets.
Okay, finally had a chance to dig back in and play with this throttle thing a little more.
Mapped the throttle to the ShipZ axis as someone suggested. Realized after startup I’d tried that already and nothing worked right, so I played with it a little more. Discovered 2 things:
In order to be able to set a ‘steady’ throttle setting, you need to click the ‘automatic throttle’ box in the launcher.
I had an inverted axis problem. This can be fixed by going to the far left column of the key bindings page, where the column is labeled ‘Reverse’ Double click on the ‘no’ to change it to ‘yes’ and voila- problem solved.
My only suggestion is that when the game is released, please make sure directions on how to do these things are included in the manual. It has realistically taken me a couple of HOURS (in total) of screwing around with the beta to get the whole HOTAS thing programmed and working in some usable fashion for this game. This was a couple of hours spent before I could even really try the game. That’s a high frustration factor, right there. Every game’s UI is a little different, and what is totally intuitive in one game or setup is nearly impossible to figure out in another. The devs create the UI for their own games in the first place, so to them it’s child’s play- it’s not to everyone else.
The game needs a HUD pitch ladder!!! Again, my suggestion would be for it to ‘auto-activate’ when the altimeter reading on a planet first shows up. When the altimeter clicks off, the pitch ladder should as well.
On the planets, the atmospheric effect could stand to be a little ‘thicker’, for lack of a better word. By that, I mean its not uncommon to be at local noon near the surface, look up, and see stars up there above that canopy of blue sky. Same thing at all altitudes less than about 12000 meters.
Again, purely cosmetic- doesn’t affect gameplay at all. Just my latest two cents.
I’ve noticed a ringed planet in lots of screenshots. Can’t seem to find one in-game. Was this a feature that was removed, do I have a graphics issue, or am I near the wrong gas giant? (Can’t find any more of those, either.)
Rings, asteroid fields, and oceans are temporarily disabled due to either performance and/or gameplay considerations. For example it’s currently impossible to navigate an asteroid field without dying because you will hit a little rock you can’t see with so much kinetic energy you will explode. There’s also the issue of performance when doing a bazillion collision detection checks if a major battle is taking place within an asteroid field. We’re working on adding them back in before we release the game.
In the demo, the action takes place on and around the moons orbiting this one gas giant. Just to see if it could be done, I accelerated to lightspeed towards the sun and actually flew past it before turning around and coming back- I wasn’t sure if it was an in-game object or just a ‘light source’ that you could see but never reach. (I didn’t try to run into it)
That said, will there be any more planets in this solar system when its all done, or just the one gas giant and moons we have now? Thanks.
What you can see in game right now is what we call a “Battlescape”, aka. a point of interest in the solar system with a planet and a bunch of moons ( the gas giant here is the planet, the rest are actually moons orbitting around it ).
It wouldn’t be too hard, technically, to add more planets. It takes roughly a day of work to design and create a new planet. In a week or two we could easily add 5-6 Battlescapes, each with a bunch of planets + moons. We haven’t done so yet because 1) we need to prioritize the work to be done, and we still have various gameplay features missing from the game and 2) if the solar system was even bigger, we wouldn’t have enough active players to complete matches in a decent time.
As we approach Early access and the player population hopefully ramps up, we’ll add more Battlescapes with more planet types. Eventually we’d like to end up with 300-400 players per server and 6-8 Battlescapes, for a total of maybe 15-20 planets/moons in the solar system. If the game gets really popular, upgrading the server to 1000+ players isn’t totally out of reach ( but will require server optimizations and more work ).
Some additional feedback:
The screen shake effect.
I get that it adds to the action feel of the battles, but its too much in my opinion.
The current screenshake has the view shaking a good 50% of the time in big battles, making it almost impossible to aim.
I would like the screen shake to be a different effect for that reason. Instead of just shaking everything the effect should just shake the cockpit model, not the whole view or the hud.
Similar to the cockpit here:
Also in capship or third person mode, there should be no screen shake.
Also another suggestion:
In capital ship mode, the freelook button (ctrl) is unused. It should be used to lock the current direction of the turrets, so that we can look around in cap ship mode without dragging the turrets to the backside just because we wanted a quick peek.