If I remember correctly the Joystick message is shown when someone didn't use the correct patch, or didn't delete their setup.dat file prior to launching the game. Its effectively an error message. When it's displayed legitimately it should disappear when a joystick is centered. (EG's web site holds updated details on this 'bug').

EG also mentioned that the original 3rd button code was lost, but he said he'll look into possibly adding new code to support it.

Although this Dehacker version for Witchaven is welcomed, I find it fairly useless as EG will be fixing the problems with EGWH1 in the next release. I believe he has replaced the mouselook code already with what he used in EGWH2. (Ken S mouse code).

EGwhaven v1.0 is now out! This marks a major release with some long-planned features and should be generally more stable than prior releases.

Updates to both versions:- RULES.CFG. This allows some of the optional fixes and a few other tweaks to be adjusted per GAME folder.- GAME parameter now correctly maintains separate savegame sets for each GAME directory.- Mouse movement and mouselook fixes/improvements.- Monsters no longer get locked in insane repeat-teleporting loops.- New configuration program for control setup and preferences. Keys to cycle through potions can be remapped.- .MAP file not found is now a clean exit rather than a hard crash.- Better framerate fixes.

Updates to EGWH2:- MAPNAMES.CFG: Level titles are now external and customizable.- Fix to an error which caused intermission screen issues if WARP was used.- Fixed a regression in EGWH2 versions 0.5 through 0.7 that crashed the game if too many sounds played at once. (Activating Nuke outside Cirae-Argoth's ziggurat was an effective way to trigger this).- Level numbers greater than 15 can play background music.- Fixes to end-of-level scoring to make it more accurate, especially on small levels with few items/enemies.- Argothonian Clansman hit detection fix. On-target strikes will no longer erroneously miss them when they're in mid-swing of the sword.

Hi! Just tested your latest release of EGWH1 and 2, almost everything is perfect now, thanks!Mouselook works (EGWH1) - but much worse than in WH2. Normal mouse h-head movement nearly between 7-8, but it's still slow and unbalanced. But anyway, it's seems game code related, it's ok and better than no mouselook).Movement sliding and unnormal acceleration now completely fixed in both. Cool!Strife movement (both in EGWH1-2) now faster as they should be - excellent, but the main current problem - you cannot strife right after you strife left - tried single buttons, tried ALT+moving left-right - the same problem, looks like it's broken somewhere in the code, so it's stucks somehow. Originally you can easy strife right-left, now it's impossible. If you can, please fix it .Also - weapon attacks in EGWH2 - much-much slower than it should be, so it's much harder now to play. Just compare to egwh v0.5 and original. Should it be so?

With the mouse look, it should be working the same in both games? If you're noticing a difference you could try checking the EGPREF.CFG files (they're plain text) and making sure your mouse sensitivity values are set the same in both before I'd consider this a possible bug.

Strafing, I think I see what you mean, it should immediately cancel momentum and go the other way instead of slowing and then reversing?

Weapons should swing at the same speed in both games, if the weapons slow down a lot that's an error, and seems to be an issue that can occur when the system isn't keeping up with the game's demands (it only happens to me if I run EGWH2 on my DOS PC, in SVGA mode). What sort of conditions are you running it in, and are you using 320x200 or 640x480 mode? I couldn't find any differences in the timing code so it may be something elsewhere (like in code that only triggers in SVGA mode) that's doing something it shouldn't. However SVGA mode does work correctly in DOSBox on my main PC so system conditions must play into it somehow.

>With the mouse look, it should be working the same in both games? Nope - there is significal difference in both games. But still slower than perfect. Perfect was in your EGWH2 v0.5

>If you're noticing a difference you could try checking the EGPREF.CFG files (they're plain text) and making sure your mouse sensitivity values are set the same in both before I'd consider this a possible bug.I used the same EGPREF.CFG for both games.

>Strafing, I think I see what you mean, it should immediately cancel momentum and go the other way instead of slowing and then reversing?Yes, of course. Currently it's works only as move stucking, so you cannot use zig-zag run movement to evade shootings. In original game code as i remember it worked fast and cancelled the movement, or just worked much faster...

>Weapons should swing at the same speed in both games, if the weapons slow down a lot that's an error, and seems to be an issue that can occur when the system isn't keeping up with the game's demands (it only happens to me if I run EGWH2 on my DOS PC, in SVGA mode).Yes, svga mode, but i compared to original and v0.5 - it was much faster. Monsters and game are at the same speed, hero movement - MUCH slower (normal), swinging and even switching weapons - slower 1.5 times (i can even see it as lower FPS)..

>What sort of conditions are you running it in, and are you using 320x200 or 640x480 mode? 640x480

Also look how wh1dehacker fixed "Increase horizontal turn speed" - it makes it much smoother additionally to changing X mouse speed - so i thinks it's very recommended to change in your port code. And compare also how mouselook worked in original game AND ESPECIALLY at your EGWH2 v0.5 (mouselook was perfect there) - it was much smoother, currently in your port it's too slowed down like "mouse smoothing" and vsync is turned on in some games.http://f1.s.qip.ru/cMfvXn9i.pnghttp://f5.s.qip.ru/cMfvXn9j.pngAs i see it changes some 04 value to 02, so it's much smoother 2x.

pagb666 wrote:The game's framerate seems "capped", BUT if i open the map it runs smooth as silk. Also empty slots in the potions UI flickers when I open the map. Even when setting the viewport to full screen, the game will run at ~20-25fps until I open the map. Weird. Any ideas? A bug? Something on my end?

Corak wrote:Yes, svga mode, but i compared to original and v0.5 - it was much faster. Monsters and game are at the same speed, hero movement - MUCH slower (normal), swinging and even switching weapons - slower 1.5 times (i can even see it as lower FPS)..

After a bit of probing, these seem to be at least partially related problems. It turns out that the game code spams unnecessary refreshes of the status bar graphics every game loop as long as automap mode was turned off, which is why turning the map on improves it. This is more of a problem for underpowered systems which is probably why it doesn't always manifest.

Fixed code for the next version will call the status bar updates only when they're actually needed, as it should be, which should improve the matter. Why the effects of this are so much worse on newer EGwhaven versions is still under investigation, though.

Thanks! Now almost everything perfect! Good timing (but still i think it's too far from perfect speed, and weapon speed is not good too, anyway it's playable), strife movements - good, perfect mouse speed in both versions!Just tried to test gameplay, and completed 1st level. Even recorded it (almost not played 2nd game especially with normal movements, so tried new tactics):https://youtu.be/sqfth7F8Y8g1. The pink heaven in some room looks like a sprite, not parallax ceiling:http://picsee.net/upload/2017-10-24/5a48f2e10b17.pnghttps://youtu.be/sqfth7F8Y8g?t=11782. Cannot move forward/backward and fly up/down (to fly+move), need to push down Fly button first and only then press move button, not any other way.

3. Some monsters (armored knights) need to take alot sword slashes (nearly 50-100 hits), dont know if it's normal, they killable, but too long compared to the other types.

Also it seeks video files right in game folder, but not in "SMK" folder as it was located on CD

Looks like a map error rather than a code one. Aside from a couple of WH1 maps I haven't addressed those much yet. This one doesn't occur in the copy of the map that's on any of the CDs I have though. Is it from the Les Bird site (which had some files that were different) or some other source?

Corak wrote:2. Cannot move forward/backward and fly up/down (to fly+move), need to push down Fly button first and only then press move button, not any other way.

Seems that typical fly up/down is put in an else condition of checking forward/back movement for look-flight. Probably an easy fix.

Corak wrote:3. Some monsters (armored knights) need to take alot sword slashes (nearly 50-100 hits), dont know if it's normal, they killable, but too long compared to the other types.

Some enemies, especially armored ones, do have higher HP, also it is multiplied on higher skill settings (I think skill 2 should be considered "default" for this game). Do you mean 100 HP, or actually swinging the sword at them 100 times? The former sounds normal, the latter shouldn't be happening though.

Corak wrote:Also it seeks video files right in game folder, but not in "SMK" folder as it was located on CD

Well, yes, allowing ranges outside of what the game originally allowed is going to look strange. I can probably have it clean up the background area to get rid of the ghosted bars, but the bar going off the screen if you set it that high is what it is. At least it doesn't crash the way Doom would.

Corak wrote:About mouse smooth speed to compare:https://vk.com/doc-65855514_452841214In v0.5 mouselook and camera was much smoother, the only problem was movement sliding and movement hyperspeed

And what is this file supposed to demonstrate, exactly...? I have the game and all old versions of the port on hand already. v0.5 mouse code has some bad issues with mouse sensitivity on my machine (can't fine tune it, either too slow or too fast). If the problem is just related chunkiness/smoothness rather than turn speed though I may have a solution for that, but I'll have to test it a bit more to be sure.