oakdesign

Just to give an Idea what Gremlin looks like and how it works. The image is an example of my profile if I use my xbox 360 controller as an input for SB 1 the XBOX 360 Controller is the physical device that is used 2 the Vjoy is a virtual device that is the one that gets selected in SB 3 the physical x axis of the ministick is mapped to the virtual x axis of the vJoy device 4 that allows me now to apply multiple things to the axis that is used by SB, one of them is using a response curve in my case I flatten it around the center so it is possible to have finer adjusted inputs on slow turret movements and accelerate toward the end of the phyisical movement where fine inputs are not as much needed Another benefit is that I can assing multiple functions to my xbox 360 buttons and triggers and basically control every part of the tank depending on the current view position without even having the need for a keyboard

You can use joystick gremlin as a software between joystick and SB. JoystickGremlin is the tool in the flightsim community to apply curves to joystick axis or remap functions that a simgame would not offer itself I personally use it with SB to remap 3 input devices joystick ganepad and button box to a single virtual device seen and used by SB

@Jartsev thank you for the advice. Email sent

I just recently upgraded my Licence from 4.1 to 4.3. I encountered that I can't start SB anymore. After reinstalling SB and CM the error persits. Did some research on the Wibu support side and came across a entry that the Firm_counter has been set to 0 due to a Debugger Detection. As the PC I have SBinstalled is running as my work PC as well I have to Debug quite a lot of stuff as a profesional Software dev. Might have happend that SB was running minimized and Debugger accessed a memory area attached to SB, if so than this happend not intenionally. Is there a way to get the Licence running again?

Have there ever been thoughts to include it at least partially into PE to allow PE users to build interactive "Desktop interior inputs"?

In terms of resitance that's exactly why I will go with the FOC motor driven design. In that way it even SB itself provides no FFB data it would be possible to adjust, gain current levels to achive even different resitance or change FOC algorithms like like constant or spring or damper force. Switch button assigment is usually the least issue as it can be either directly set in the controller firmware, depending on the used libraries, or remapped inbetween controller driver and game with tools like JoystickGremlin or UCR (personally I'm more the JG guy to build mappings or combine multiple controllers into a single virtual one). Maybe I'm missguided but haven't I read that that isn't the case anymore? But still I personally use joystick.h and keypad.h libraries for arduino driven HID devices where hardware wiring is not depended on the final DX assignment Having served on the Leo2 for quite some years, I know how it should feel. still trying to figure out a way to get the operation mode. Having build some quite extended physical sim gear for flight sims that all provide some kind of interface to interface the sim with physical hardware would be great to have something like that in SB. The simplest interface I know of is for example the BMS flight sime that just provides some data through windows sharedmemory pages

As I'm currently designing a gunner controler as well, but with a different approach, so get the mechanics and software first and design the handle itself after all hardware parts are sourced. So what's your approach on the mechanics. Rotational Springs, or spring cam or motor driven direct/belt/drive train?

Even so my first protoype works it doesn't fullfill my requirement in terms of haptic feeling. Decided now to go for a full motor driven approach for a force feedback controller. First part are source and starting to write the controller firmware while in parallel starting to draw the mechanic in CAD. Optical Rotary encoder will give precision of 12bit. The axis will be driven by 12V Brushless 775 DC motors. Next step will be starting to write controller code to simulate a constant force feedback based on handle position to overcome the non existant SB force feedback interface

Prototype works, but resolution with the way to map gyro data to vjoy axis is nah ... at best 6 bit is usable with some curve fine tunings but not to my liking. Back to drawing board now I think I go the full way with DC motors and constant force feedback and use the wireless screen only for Helios and create input profiles https://youtu.be/apYyVN_W9Ro?si=wMGdNNaS5EDkKVtB

Cant' speak for the M1 only the Leo2 which I spend quite a few years in. Reloading from the hull you need to be in a safe position as it the turret needs to be turned. In terms of loading from hull to ready rack much of the already said the same applies the same, just that only the Loader now has to do the lifting. As he has to basically get dow on his knees to get the shell out of the hull storage tthan turn around while standing up and store it in the ready rack. The reloading here heavily depends on the physical skill of the loader. The best ones I had where the small but bulky ones. But still it's not done in a second. The upper rows you can get out quite easy but the lower rows can get real fiddely. Don't have the exact numbers anymore but would say my best loaders took them 4-5 minutes for the pure reloading not taking into account the pre and post tasks. Restoring an empty ready rack is worth at least some time of gym workout

I always wanted to have a more gunner controller like input device. Having spend some time on the "real" simulator again over the past 2 years, I now decided it's time to something done. For the moment I have finished my POC phase and am on the way of building the first prototype. So from the Hardware side im using: torsion spring loaded mechanism that I ripped out of a sim racing steering wheel for X rotation (left right) torsion or dual spring mechanim on a shaft for Y rotation (up down) for a maybe future V2 version already sourcing parts to replace the spring mechanism DC motors, basically a constant force feedback version Android 10" tablet gyrosensor for the positioning, and touchscreen for button and keyboard inputs Not decided yet might add some real physical buttons to the handles, but would require the device to be wired On the software side: Freepie apk for Android to send gyro sensor data to the PC (the way any racing game on a mobile works, rotate device for steering, tilt for acceleration) Opentrack with freepie input and vjoy output to receive the sensor data and translate to axis movement of the vJoy virtual device SpaceDesk Server Client to convert the Android device into a secondary PC monitor Helios (mainly used in flight sim to build virtual cockpits on touch devices) to be run on the tablet and providing virtual buttons and switches. Physical buttons might be added during prototyping Joystick Gremlin to map everything together onto a single virtual HID device that is then used in SB as controller The POC testing with my phone as gyro sensor went better as expected. It feels just more natural and even without dialing in response curves fits my liking more than the joystick and/or gamepads that I have tested/used so far. Will post more progress once mor of the 3D printing is done

count me in

Works still on mobile but not desktop browsers

So CO is running 4.268 hope anyone else as well until tomorrow 😉

Question as 4.268 has been announced to be available withing the next few hours, do we stick to 4.267 or run on 4.268?

B66 please

Same on the Leopard. But for sleep rest turret would either have been fixed in 11:40 position to allow gunners legs to be spread to the drivers hull compartment. More likely to be at 6 o clock with the gunner TC resting on the motor with the gun and a tarp as tent. In both positions turret would have been locked In the end in terms of safety while operating the tank counting the incidents / injuries encountered In any of the units I served I would rather say the driver is the safest place.

apart of some of these basically nothing on the Leopard 2 Spend 12 years on that thing and can't remember a single driver-turret incident

If the Waypoint is set to something other than "none" the AI will remain on that waypoint with the given tactic. If you want them to procees onto a route attached from that waypoint you set a Embark if and tell them under which condition they should move on. All the concepts are IMHO very well explained on the wiki https://www.steelbeasts.com/sbwiki/index.php?title=Moving_Units_On_Routes

B13 please

Even on a real simulator depending on the mission I had occasions to call out to my gunner: Kick him, cause the driver felt asleep 😃

2/2B Please

As requested by some users after last kanium session I recorded the process of setting up a Autohotkey Script that set's up 3 keybinds in order to activate push the CITV buttons in M1A2 TC F3 view. It got a bit lenghty as I just recorded the full process and trying to explain the whole process instead of just providing the script as I tried to keep the script as simple as possible and there fore it need some prework, mainly identifying the position of the buttons on screen in F3 view. This position can differ due to screen resolution or multi monitor setup. But just for the sake for those already using AHK or ant to see the script ;Press ALT e mouse will move to given screen location and perfom a Left mouse click !e:: KeyWait Alt ;Position of the CITV Man Auto Button in F3 view Click, 349,123,Left, 1 ,D Sleep 100 Click, 349,123,Left, 1 ,U return ;Press ALT f mouse will move to given screen location and perfom a Left mouse click !f:: KeyWait Alt ;Position of the CITV GLOS in F3 view Click, 349,272,Left, 1 ,D Sleep 100 Click, 349,272,Left, 1 ,U return ;Press ALT i mouse will move to given screen location and perfom a Left mouse click !i:: KeyWait Alt ;Position of the GPS GLOS in F3 view Click, 349,389,Left, 1 ,D Sleep 100 Click, 349,389,Left, 1 ,U return

Currect only in planing phase or in mission editor.

They would automatically dismount and the APCwould even retreat back to a hull down position. But the issue is that the dismounted have tactics none set once dismounted and no way to change that as far as I can say, therefore they would not engage any enemy they are facing. As I personally currently get into how to best implement scripting into OPFOR I'm now more into do it in a more micromanaging way with very short legs for the APC/IFV and then conditional dismount and embark if for the infantry