WC4 Remake

Hi again,

First sanity check is the first time I've heard of that bug. I can replicate it but it doesn't seem to be related to the issue.

When I played the demo I was lucky enough to have the stick itself picked up as the first detected controller. I might have gotten the first eight buttons thing slightly wrong (the weapon release button on the stick is button 20 but it was bound just fine) but not all buttons bind correctly or at all, which is the issue regarding the buttons. The buttons I noticed did not bind correctly are the hats. Some of the hat switches do bind, bind as "None-" (or some other weird name) or do not bind at all. Some other non-hat buttons, i.e. the pinky switch, also exhibit the same or similar behaviour. I haven't been able to bind any throttle or rudder pedal inputs.

My controllers are all separate devices. If you're asking about a screenshot of my devices in joy.cpl:
View attachment 12773

Devices show up in dxdiag as follows:

Device NameVendor IDProduct ID
WINWING JOYSTICK BASE2 + JGRIP-F160x40980xBE48
WINWING THROTTLE BASE2 + TGRIP-F160x40980xBE37
MFG Crosswind V20x16D00x0A38


Thanks, that gives me a lot to work with. I can guess what the issue is with most of them is, the interface was originally built around gamepads and will need expanding for your stick.

Why only one joystick is getting recognised is something of a mystery.

If you could hit the properties button and show the page it opens it’ll let me know what axes are used by your devices.
 
Can you try overwriting your wingiv.exe with the one in this zip and let me know if it fixes any of your issues.
 

Attachments

The properties tabs in joy.cpl don't show all the buttons past 32, so I added some shots from SimApp Pro as well. The base of the throttle's buttons are ID'ed past 27, though they don't clearly say which button is which.

Also, the zip file is being picked up as a virus?
 

Attachments

  • joycpl-tgrip.png
    joycpl-tgrip.png
    22 KB · Views: 53
  • joycpl-jgrip.png
    joycpl-jgrip.png
    21.5 KB · Views: 63
  • simapppro-tgrip.png
    simapppro-tgrip.png
    406.1 KB · Views: 67
  • simapppro-jgrip.png
    simapppro-jgrip.png
    351.4 KB · Views: 65
Thanks for the images. I'm pretty confident this should fix your button mapping issues.
Are you sure the virus warning wasn't just a "this isn't regularly downloaded" warning? I ran a virus scan and nothing turned up.

Here it is on google drive; your anti-virus software may be happier about this as google runs a virus check on everything you upload:
 
It's picked up as a virus by Windows Security, the Google Drive link is also picked up as one.
 

Attachments

  • wacatac.png
    wacatac.png
    178.1 KB · Views: 52
I've tested locally with bitdefender and windows defender, both show it's clean.
Reading around sometimes it's the fact that it's been zipped creates a false match for trojans.

If you still get the warning I'll have to submit a false positive message to microsoft; no idea how long it takes them to clear that up.
 
I think it's being flagged as a false positive, I tried scanning it with some other scanners and it seems fine, just not with Windows Security.

I tried the modified WingIV.exe:

- Still cannot pick up the other controllers, but it seems to be able to pick up most of the other buttons on the flightstick now, including all of the hat switches.
- However, certain inputs such as the paddle switch or the trigger lever (the black lever thing just above the trigger) have strange behaviour, i.e. if I bind the paddle switch to autopilot then it always holds down the autopilot button or presses it repeatedly. I don't know if this is an innate issue with the way the flightstick's paddle/lever itself works (they do both axis + button inputs simultaneously) or if it's an issue with the game.
- Even if I unbind all joystick controls, if the joystick is selected as the main controller the briefing text is instantly skipped as if a button is already being inputted.
 
I think it's being flagged as a false positive, I tried scanning it with some other scanners and it seems fine, just not with Windows Security.

I tried the modified WingIV.exe:

- Still cannot pick up the other controllers, but it seems to be able to pick up most of the other buttons on the flightstick now, including all of the hat switches.
- However, certain inputs such as the paddle switch or the trigger lever (the black lever thing just above the trigger) have strange behaviour, i.e. if I bind the paddle switch to autopilot then it always holds down the autopilot button or presses it repeatedly. I don't know if this is an innate issue with the way the flightstick's paddle/lever itself works (they do both axis + button inputs simultaneously) or if it's an issue with the game.
- Even if I unbind all joystick controls, if the joystick is selected as the main controller the briefing text is instantly skipped as if a button is already being inputted.

Thanks, that's all been helpful.
I think the second issue is probably down to how some of your extra buttons are mapped. It'll be hard for me to add support for the misbehaving buttons without access to that hardware; but for the issue of skipping the briefing screen I can make it so that only buttons you have bound for the flight controls will cause it to skip.
At the weekend I will make a debug exe that spits out some debug information to try and get to the bottom of why your secondary controllers aren't getting recognised.
 
Would you mind trying this one?


From looking at your screenshots I think I know why your throttle might have been getting ignored as a joystick.
 
That WingIV.exe picks up my throttle and rudder pedals now, thanks! Also the briefing screen is now working correctly with the joystick set up as the main controller.

Now that I've tried the demo with the throttle and pedals as well, another suggestion came off the top of my head. Would it be possible to do advanced sensitivity settings adjustment for joystick axes? (i.e. deadzone, saturation, min/max range, sensitivity curves, etc.) I know some controllers do this at a driver level as I used to use the Saitek X56, but not all controllers do. I also think it would be less of a headache to be able to adjust sensitivity settings at the game level.
 
That WingIV.exe picks up my throttle and rudder pedals now, thanks! Also the briefing screen is now working correctly with the joystick set up as the main controller.

Excellent, thanks for testing.

Now that I've tried the demo with the throttle and pedals as well, another suggestion came off the top of my head. Would it be possible to do advanced sensitivity settings adjustment for joystick axes? (i.e. deadzone, saturation, min/max range, sensitivity curves, etc.) I know some controllers do this at a driver level as I used to use the Saitek X56, but not all controllers do. I also think it would be less of a headache to be able to adjust sensitivity settings at the game level.

Hmmm... it would be non trivial to add to the UI and we already have a lot on our plates.
A text file for advanced options like that would be possible though if there's a call for it.
 
Any new release to test?

I love your enthusiasm but not yet :)
I was working hard towards the deadline for the demo so I'd have free time when our third kid arrived, that's happened and I've only just survived paternity leave (also finally had to bite the bullet and learn to drive and that's taken up atleast half my days).
I do want to try and get a patch out this year; largely just the exe you see above but with a few extra fixes and the German version of the trailer.

Next release will be low key, the demo again but with some extra features.
Simultaneously I have already started a little work getting the missions of the full game running. We are thinking of releasing the Tyr campaign first to help find any issues and act on any feedback - but no date on that yet.
 
Wow, the original source is so tiny compared with the overall video, I suspect YT-compression may be adversely affecting it. The black-and-white version, before the corruption effects, looked okay to me but the corruption effect works too. It reminds me of the communications between the Rebel pilots and Yavin base in A New Hope - if I recall correctly the original movie had clear voice when the pilots were off-screen, later editions added a distortion effect (in-story lore explained this as a means of disguising identities, I believe).

BTW, from the very beginning I've enjoyed and admired how all these updates have quotes appropriately sprinkled throughout. I appreciate the effort.
 
Wow, the original source is so tiny compared with the overall video, I suspect YT-compression may be adversely affecting it. The black-and-white version, before the corruption effects, looked okay to me but the corruption effect works too. It reminds me of the communications between the Rebel pilots and Yavin base in A New Hope - if I recall correctly the original movie had clear voice when the pilots were off-screen, later editions added a distortion effect (in-story lore explained this as a means of disguising identities, I believe).

BTW, from the very beginning I've enjoyed and admired how all these updates have quotes appropriately sprinkled throughout. I appreciate the effort.

@Wedge009, you have no idea how lovely it is to hear that someone noticed that our titles are quotes from the game dialogue (wherever possible) - every time I write an article, I scrub my brain trying to think of salient lines from the game, then make heavy use of the CIC's holovids archive to make sure I get the line right 😂 Thank you for making my day! I think @Pedro started us down that route on one of the earliest articles.

Thank you for the positive feedback on the corruption/glitch effects. They're currently a sadly-needed means-to-an-end, and very much a work in progress. I've been getting a lot of YouTube comments/DMs/messages on Discord about their implementation - it's an understandably contentious topic, with around a 50/50 split between people thinking it works and people having reservations. I'd like to take this opportunity to assure people who are critical that, like everything else we show in articles and releases, it's all first-pass. We're literally showing you our progress as we come up with it. Most things are just stepping stones along the path to release and will almost certainly change before we push anything playable out to the public.

With the ever-changing and advancing nature of deep learning/AI, it's entirely possible that, next month, I may have a method on hand to clean up the original comms perfectly. It's also possible that will never happen. Whatever the case, I'll keep tinkering until I find the best balance possible.
To all those who have sent positive comments about the glitch effects, thank you :) To all of you who voiced concerns about their appearance, as stated above, this is just a step along the way to release.

Looping back to your message, @Wedge009, I did edit and render that preview video at 4K - so if you're watching the video at 1440p/1080p yes, the original video will look even more dinky than it already is. On a similar note, I'd encourage people to watch that video at full-screen on a desktop (and force it to play the 4K stream if you can - even if you're viewing at a lower resolution). The scanlines and glitch effects will get totally boned on, say, a phone or if you're watching the video on an inline player :)
 
But of course, I should think it was obvious so I'm surprised no-one else has remarked as such to you folks but it's great. There's limited material so understandable if it can't be kept up indefinitely, but it's been fun reading them thus far.

In the heat of the action, I doubt we're going to spend much attention on the video comms. But from my perspective at least, I don't mind either option - the last cleaned-up step before the addition of the corruption FX or after.

And yeah, I was watching full-screen on a desktop but my main monitor is 1440p - the source does indeed look closer to their up-scaled counterparts when I viewed the 2160p version.
 
Back
Top