Time Crisis 5 2 player

[Bommel24]

It is currently possible to install TC5Ever to play coop over lan. It also connects on localhost when you open two instances however only one instance can receive input at any time. Would it be possible to patch this? So you can have the second game on another monitor and push input from the second gun?

[argonlefou]

I'm really unsure about all of that... let's list the obstacles and what can be done to get to the desired solution (from the easiest one to the hardest one) :

1) DemulShooter is currently blocked to not run more than 1 instance at the time. -> This is can be settled in the specific case of local coop for TC5, I have control over the code

2) There is no way for DemulShooter to know, with 2 similar executables, which one should receive player 1 data and which one should receive player 2 data. -> This can be solved by adding 2 more different targets in DemulShooter (like tc5p1 / tc5p2) and force the user to make a whole copy of the game folder for P2, and rename both executables in a fixed way (like TimeCrisisGame-Win64-Shipping-P1.exe and TimeCrisisGame-Win64-Shipping-P2.exe) so that each instance of DemulShooter can hook a specific executable and send required data. I didn't try it so I can't be sure that renaming the binary wouldn't cause any issue, but in theory it shouldn't

3) Playing on 2 different screens : whereas DemulShooter can differentiate raw inputs for each gun, there is absolutely no way to know which one is running on wich screen and compute the corresponding final coordinates by doing the translation according to the game's windows size, screen resolution, etc.... Also, all Demulshooter's core input calculation is based on the Primary Screen arena. It's not meant to be used on a secondary screen -> I'm not so sure about it, as it has been a while but if I remember well, TC5 needs to run fullscreen on a 1920p screen (with 100% scale dislplay). So meaning that both screen need to match the exact 1920p resolution will override any calculation bug as there would be no differenced between screen1 and screen2. Now, the smallest change in video settings (beeing the screen resolution or the game window size) would make Demulshooter tofail to compute accurately P2 side. And changing the core part to add multi screen support for 1 specific use of 1 specific game is out of question.

4) Last but not least : TC5 can be run as a standalone or with Jconfig. It you're using the standalone situation, demulshooter is only handling axis and all the input system (buttons, trigger) is left untouched and handled by the game. Chances are very high that any mouse/lightgun buttons will be recognized in both instance of the game at the same time. -> I have not tried local coop but you can test the following (without demulshooter) : if a mouse (or any of your guns) buttons is working the same in both game (I think lightguns are working well in the menu screen, to test) = end of the discussion. You may end up giving good coordinates to each instance but buttons won't be handled by DemulShooter and you won't be able to properly use the guns separately

4b) You can still run TC5 with Jconfig, in that case DemulShooter will override trigger and weapon buttons information. But in that case, in theory, you should be able to make 2 separate copy of Time crisis folder and set both Jconfig with different inputs devices and not use Demulshooter at all (except for the need of outputs - but this is a different problem and much more easy to fix) IF rslauncher allows multiple instances to run at the same time (again, didn't test)

I'm open to continue the discussion if you can narrow down some point I mentionned up there, but it's not a path I'm rushing into. At least not in the public and supported version of demulshooter, but in worse case I can point out what to do if you (or someone else) want to fork it and play with the code

[Bommel24]

Wow thank you for the write up I guessed it wouldn't be easy.

1 and 2 are self explanatory and I did rename the exe with success so this should be a good way.

3. I think since the second player is on the second screen but lightguns of any kind I know always use coordinates on the primary screen (since the gun can't really know at which screen it's pointing (only that it is inside the border in case of the sinden) this shouldn't matter at all because DemulShooter already forwards the absolute gun coordinates to the Game and Game excepts to be on primary display.

4. I understand the difference and only have experience with the Standalone Version since you can change the ButtonConfigs via UnrealEngines ini files anyway (see my other issue).

I do not know alot about hooking into games and c code and I understand that this is a very specific use-case and it might be tricky to make the second game even accept input at all while the other one is in focus of the windows window manager. So if you allow it I would add a bounty to this issue (getting to work time crisis 5 local coop with two 1080p monitors, two sinden lightguns both games accepting input at the same time).

[argonlefou]

As for #3, your not right : DemulShooter does not forward absolute gun coordinates to the game (well....the game is doing that itself and that's why mouse is not working within the game), but is reading absolute coordinates from the Lightgun and then translate them to some desired "In Game" values. To do so I need to know the max raw values (which is easy to get from the device), the desktop resolution, window size, window location, and finally what are the max "In Game" values.

So even if you remove the fact that the gun pointing at screen #1 white borders will react as if it was pointing to the screen #2 border, there is no way for demulshooter to know which gun is used on which screen and so, if the settings are differents, what are the destopkresolution/window/size values to use in order to be able to translate coordinates

Again, in theory, using the same screen resolution and the same graphics settings should "override" that need, and I think this is the case currently with TC5 (1920x1080, 100%dpi)

As for #4 : Going with the standalone version, can any keyboard button can be used in the UnrealEngines ini files to replace mouse input by a keyboard button ? If you can differentiate inputs for both instance of the game, this should open possibility for demulshooter to send the corresponding keystrokes to the game based on the gun's mouse events. So blocking mouse buttons for TC5 + testing the ability to simulate gun buttons (if the game accepts it) can be a solution to that point.

There is no need to run a bounty, I know exactly what can be done for it to work IF it's possible at all (hence all the questions, I don't have a dual screen setup so you're my eyes on it) That I still don't know (again, IF it is possible) is either the change would be part of the github code or just a standalone compiled demulshooter for this specific use, with a specific setting on a very specific configuration...and no real user support from me.

(and as for your other ticket, I still couldn't re-setup the game to work on it for now)

[Bommel24]

Ah I see I misunderstood it then thank you for the explanation. Well then maybe you have to give demulshooter a command line argument for the second player screen offset like (-offsetX=1920 -offsetY=0). Demulshooter of course would always assume that the P1 Gun Device is pointing at screen 1 and P2 Gun is pointing at screen 2.

For #4 yes it is possible to change all inputs in game from Mouse to Keyboard or even DirectX Controller Buttons.

So sumarized if I now understand correctly Demulshooter would need to:

• have a seperate tc5 target for p1 and p2 with different targeted exe files each.
• assume that p2 targeted exe is on the second screen and transform P2 Gun Coordinates accordingly and send them to the game
• check if p1 or p2 buttons are pressed and forward them to the respective game (since only one game can be in focus at a time)

[argonlefou]

More or less. It's still not the correct issue for the coordinates but no need to run deeper into that, there's nothing to be done for it so either it will work correctly, or not

The last and biggest concern is now the one you mentionned yoursel : does the games will react to commands with no window focus.... Filling data with DemulShooter in memory of an unfocused process/window is not an issue, but depending on how the game is programmed it may need the focus to either accept buttons input, or just to refresh and display the new axis data received when in background.

I'm thinking of 2 tests to be done with your dual screen games running (both in fullscreen) : 1 - Both games in stage select menu (where the mouse cursor is working well), is the cursor moving on both windows when you move the mouse/lightgun without having to click & select the active window ? (may not be working if the game uses windows cursor position that might not give good value on screen #56 2 - With both games having different pedal buttons, in the 1st level gameplay : does pushing the corresponding keyboard key can move the players left/right on both screen without clicking or selecting any window ? (to test if the window needs to be selected and active to accept inputs)

[Bommel24]

Alright I made a few tests... First and foremost if one timecrisis game loses focus it automatically minimizes (because it's using exclusive fullscreen). This can be workarounded by setting Fullscreen=FALSE in DefaultSystemSettings.ini and then use somethin like BorderlessGaming to make the games fullscreen again.

For #1 no the cursor only moves in the active window. For #2 no only the selected window receives any input.

[argonlefou]

well then it's pretty much the end of the idea.....you won't be able to control a 2nd instance of the game if the OS and the game does not allow you to control it without beeing focused.

[Bommel24]

well i hope it's not I did a quick test with Autohotkey you can send keys to windows not in focus (don't know hot it works internally but you can see https://www.autohotkey.com/docs/commands/ControlSend.htm)

So basically with a ahk-Script like this (2356 is the processID of Time Crisis) you can send keys to the game and it registers fine:

NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.

; #Warn ; Enable warnings to assist with detecting common errors. SendMode Input ; Recommended for new scripts due to its superior speed and reliability. SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.

$1:: ControlSend,,1,ahk_pid 2356 return

or even

ControlSend,,1,ahk_exe TimeCrisisGame-Win64-Shipping-P2.exe

i know this seems to be a wierd workaround but it works pretty well when I test it

[Bommel24]

Basically with that knowledge I could build the system myself only thing Demulshooter would need to do is send the coordinates and allow two instances now right?

[argonlefou]

It's not necessary a "workaround", there are ways to send input directly to a process, it's a known thing from the OS. The unknown part is just "how that process is treating inputs", when focused or unfocused.

I'll try to compile a testing version in the next few days, don't know when exactly but you'll be able to run some tests with it hopefully

[argonlefou]

So, sending keystroke with DemulShooter to an un-focus TC5 window (pedal, shoot) I can make the game react to them successfully.

Unfortunatelly, and it was an issue when I first worked on this game, menus seem to be tied to the mouse handling : which means that cursor is not reacting without a mouse move, and - more importantly - fire button as set in the ini file is not shooting in menus or continue screen

So if you have a way to map a keyboard key for such a thing, this should help (i.e be able to play entirely without any mouse button pushed)...Overwise, I have some notes I wrote to replace mouse inputs in the game few years ago but this is a long shot and will take more time

[Bommel24]

Hi again, thanks for the update. I was not able to bind a keyboard key to menu but I'm able to send a click by doing another ahk like this: ControlClick,, ahk_exe TimeCrisisGame-Win64-Shipping-P2.exe,,LEFT

for mouse movement that's a different thing but could be bypassed by doing: MouseMove, 100, 500 for the left side or MouseMove, 1820, 500 for the right side option.

which would be a bummer but possible if nothing else works or another implementation would be too complicated (I have spare buttons on my cabinet so I could bind two buttons to navigate the menus and continue screen for each player).

So yes in theory it is possible to do everything without a mouse now

[argonlefou]

Not really conviced by that, I tried AHK like you did and key simulating via Demulshooter and got the same result : for pedals, the key is sent but the game does not register it like it's saying pressed. And other weird stuff like that...

I'm really starting to think that you won't be able to use 2 simultaneous TC5 window on the same system.

I don't know, maybe if you're able to set TC5 config and an AHK script do that you're able to really command both windows in a playable way (meaning: pedals working, shoot and menu validation) , it would be possible to use Demulshooter to handle axis data.

But buttons handling is impossible, as originaly stated when I first added srandalone TC5 in Demulshooter