No cameras (yet), only IMU-based with neck simulation (although I doubt it is not enough since you are strapped inside the cockpit anyway). Planning a massive release soon (testing out the remaining bugs), so probably something will change (mostly focusing on custom map support and better visuals and gameplay atm)...
Sorry, guess I forgot to add the empty folder to the archive. Create "di_config" in the game's directory if it tells you it can't save the file. Also do forget not: "DI SAVE" saves the device profiles, stack-bound (e.g. the same joystick bound as device 0 and device 1 are two different profiles - so better initialize them with their most expected priority beforehand - say, connect pedals with "DI INIT 3" as you'll likely use them at the end of the stack, overwriting everything below), while "CONF.STORE" is needed to save the actual stack in your user prefs (so later you could combine various sticks without having to reconfigure them).
I guess I should, although I need to get one first :) A little busy atm however, and first I badly want to do some tweaks to the particle system controller (almost finished in fact, will allow to fit things tighter by generating systems of a lower quality whenever the one requested does not fit into the buffer instead of skipping them altogether in this case - this is a neat touch for the lower-end GPUs where you would just limit the buffer without the need to set the effect quality that carefully).
Well, slowly getting it to run (hope to finish till this weekend) and got a few questions. At the moment I got the enumerator and the binder running, able to attach basically whatever is in the DI-standard joystick structure. The actual control, response curves etc are ready as well, and I'm mostly cleaning the stuff up. Unlike the XInput support from the current build, the DInput will not be multiplexed, but will be additive instead (as, opposed to how a gamepad can be used to control a real-life drone, and can be used as a complete control device here therefore, a flightstick may lack the ability to do several things unless in conjunction with a keyboard). And, FIY, yes - the selected device can be registered for future use, where it will start automatically (not really portable tho I guess, as stores the device's GUID) - the layouts are portable however, as are stored in separate tiny files named after each device.
Now, for the questions. So far I made it select a single device (for which it loads the control map as well, which you can edit in-game) and run like that, e.g. the keyboard is always available, mouse available whenever the axis pair meant for the yaw and pitch is not bound completely (for an obvious reason), and discrete, axial and POV controls, should they overlap, will be properly combined (yes, you will be able to bind a button as, say, strafe left, an axis for horizontal strafe and a POV switch to both strafe and ascend/descend all at the same time, and any combination of those will be correctly parsed). Should I leave it like that, or do I have to (won't really take that long I guess) make a control stack as well, allowing to assign and use a few DI devices at once (in this case you'd have to assign devices like #0...#something, where the layout of device #1 overrides the one of #0 in case of a direct overlap - say, if both are bound as "axis X", the one from #1 will be used, but binding one to strafe_x, and the other to strafe_left button is still combined - and so on)?
Also, about the deadzones. Should I rely on the DI ones, or have an own dead-zoning in software instead (atm I only tried the latter, just like with XI)?
i think second examplel would be better so users can make a profile of multiple controllers easily. I use an arcade stick for strafing,l rudder pedals for moving forward/backward and anything else for flight stick.
many controllers offer third party software to configure deadzone, but it would be better to configure the deadzone in the game.
Guess should be fine by now - the current build runs a stack of 4 devices (guess the biggest sane setup would be two sticks, pedals and... don't know, some switch pad, maybe? - can't think up anything else so 4 feels just right) added by "DI INIT #". The binding mechanism is mostly the same as before, all four are saved for the later starts using CONF.STORE. Yeah, yeah, overlap priority, dynamic disconnects and manual pause included :)
Wauw this project has come far. I never noticed that there was a command screen haha. I like the arena tunnel. I would really like to see a targeting system much like in star citizen. Like when your cursor moves and the ship then follows :)
Oh :) Although completely optional, the command system is a very immersive part of this one, mostly being like a configuration interface for your war machine. And yes, you can actually customize the heck out of it.
For Star Citizen, I actually never played it. Is the targeting feature there working like "you put the crosshair where you want to face, next the ship aligns with it (returning one to the center of the screen)"? I can try, by the way you can check the "MOUSEDELTA" on/off command which makes the mouse input become more FPS-style (still retaining some inertia because it would feel weird othrewize).
Thanks, tho I feel somewhat lost at the moment :) I initially planned on a somewhat straightforward Space Invaders clone with a few environments and bosses (and pre-defined waves), yet after adding the random waves it felt... more fresh? Guess they should stay as they fit that "evil AI" plot, also clearing some of them gets pretty tricky at times (took me quite a few restarts to deal with some of them: as you have noticed, they reset if failed to clear damage-less) - yet the whole concept becomes less clear this way.
Thanks, glad that glorious waste of time didn't turn out to be that much of a waste after all! Yeah, the gameplay is pretty much short at the moment, was too busy with the other stuff like improving the physics, maximizing the performance and, later, the PSVR support. Now, with those solved and finished the next step will be adding a new enemy type and a few new waves, later some more environment options will likely be added. However even now it still may be pretty fun and relaxing if added a "-hardcore" switch to the calling shortcut (or by the same-named option in Config), making to the last wave becomes pretty challenging this way. Another fun thing is to type "L OFF" in the in-game console (after all the lights start up), or "AUDIO ON" (for the latter I'll soon post the tweaking program as well, one syncs with your currently playing audio for some cute lighting effects).
← Return to game
Comments
Log in with itch.io to leave a comment.
is there headtrack support?
No cameras (yet), only IMU-based with neck simulation (although I doubt it is not enough since you are strapped inside the cockpit anyway). Planning a massive release soon (testing out the remaining bugs), so probably something will change (mostly focusing on custom map support and better visuals and gameplay atm)...
could not get DI profiles to save in-game
Sorry, guess I forgot to add the empty folder to the archive. Create "di_config" in the game's directory if it tells you it can't save the file. Also do forget not: "DI SAVE" saves the device profiles, stack-bound (e.g. the same joystick bound as device 0 and device 1 are two different profiles - so better initialize them with their most expected priority beforehand - say, connect pedals with "DI INIT 3" as you'll likely use them at the end of the stack, overwriting everything below), while "CONF.STORE" is needed to save the actual stack in your user prefs (so later you could combine various sticks without having to reconfigure them).
Do you have a plan to support Directinput controllers, because many HOTAS joysticks or 6DOF joysticks are directinput.
I guess I should, although I need to get one first :) A little busy atm however, and first I badly want to do some tweaks to the particle system controller (almost finished in fact, will allow to fit things tighter by generating systems of a lower quality whenever the one requested does not fit into the buffer instead of skipping them altogether in this case - this is a neat touch for the lower-end GPUs where you would just limit the buffer without the need to set the effect quality that carefully).
Well, slowly getting it to run (hope to finish till this weekend) and got a few questions. At the moment I got the enumerator and the binder running, able to attach basically whatever is in the DI-standard joystick structure. The actual control, response curves etc are ready as well, and I'm mostly cleaning the stuff up. Unlike the XInput support from the current build, the DInput will not be multiplexed, but will be additive instead (as, opposed to how a gamepad can be used to control a real-life drone, and can be used as a complete control device here therefore, a flightstick may lack the ability to do several things unless in conjunction with a keyboard). And, FIY, yes - the selected device can be registered for future use, where it will start automatically (not really portable tho I guess, as stores the device's GUID) - the layouts are portable however, as are stored in separate tiny files named after each device.
Now, for the questions. So far I made it select a single device (for which it loads the control map as well, which you can edit in-game) and run like that, e.g. the keyboard is always available, mouse available whenever the axis pair meant for the yaw and pitch is not bound completely (for an obvious reason), and discrete, axial and POV controls, should they overlap, will be properly combined (yes, you will be able to bind a button as, say, strafe left, an axis for horizontal strafe and a POV switch to both strafe and ascend/descend all at the same time, and any combination of those will be correctly parsed). Should I leave it like that, or do I have to (won't really take that long I guess) make a control stack as well, allowing to assign and use a few DI devices at once (in this case you'd have to assign devices like #0...#something, where the layout of device #1 overrides the one of #0 in case of a direct overlap - say, if both are bound as "axis X", the one from #1 will be used, but binding one to strafe_x, and the other to strafe_left button is still combined - and so on)?
Also, about the deadzones. Should I rely on the DI ones, or have an own dead-zoning in software instead (atm I only tried the latter, just like with XI)?
i think second examplel would be better so users can make a profile of multiple controllers easily. I use an arcade stick for strafing,l rudder pedals for moving forward/backward and anything else for flight stick.
many controllers offer third party software to configure deadzone, but it would be better to configure the deadzone in the game.
Guess should be fine by now - the current build runs a stack of 4 devices (guess the biggest sane setup would be two sticks, pedals and... don't know, some switch pad, maybe? - can't think up anything else so 4 feels just right) added by "DI INIT #". The binding mechanism is mostly the same as before, all four are saved for the later starts using CONF.STORE. Yeah, yeah, overlap priority, dynamic disconnects and manual pause included :)
Wauw this project has come far. I never noticed that there was a command screen haha. I like the arena tunnel. I would really like to see a targeting system much like in star citizen. Like when your cursor moves and the ship then follows :)
Oh :) Although completely optional, the command system is a very immersive part of this one, mostly being like a configuration interface for your war machine. And yes, you can actually customize the heck out of it.
For Star Citizen, I actually never played it. Is the targeting feature there working like "you put the crosshair where you want to face, next the ship aligns with it (returning one to the center of the screen)"? I can try, by the way you can check the "MOUSEDELTA" on/off command which makes the mouse input become more FPS-style (still retaining some inertia because it would feel weird othrewize).
Yes, that was what I meant, I will give it a try :D
I really like where this is going, I can not wait for an actual game with the stuff that is implemented already :D
Thanks, tho I feel somewhat lost at the moment :) I initially planned on a somewhat straightforward Space Invaders clone with a few environments and bosses (and pre-defined waves), yet after adding the random waves it felt... more fresh? Guess they should stay as they fit that "evil AI" plot, also clearing some of them gets pretty tricky at times (took me quite a few restarts to deal with some of them: as you have noticed, they reset if failed to clear damage-less) - yet the whole concept becomes less clear this way.
Not much gameplay so far, as you said, but absolutely awesome mechanics. And the laser machine gun! Damn some cool particle effects!
Thanks, glad that glorious waste of time didn't turn out to be that much of a waste after all! Yeah, the gameplay is pretty much short at the moment, was too busy with the other stuff like improving the physics, maximizing the performance and, later, the PSVR support. Now, with those solved and finished the next step will be adding a new enemy type and a few new waves, later some more environment options will likely be added. However even now it still may be pretty fun and relaxing if added a "-hardcore" switch to the calling shortcut (or by the same-named option in Config), making to the last wave becomes pretty challenging this way. Another fun thing is to type "L OFF" in the in-game console (after all the lights start up), or "AUDIO ON" (for the latter I'll soon post the tweaking program as well, one syncs with your currently playing audio for some cute lighting effects).
Any chance you can upload a direct download?
No problem, also GD seems a little laggy today :)