Arokhslair.net

Posted: **Sat Jun 23, 2018 4:40 pm**

Well, as far as OpenDrakan is concerned, I don't see a problem - since it can be distributed as a game mod, and require the original Drakan.exe to run.

In any case, because of it's nature, OpenDrakan already requires all the other Drakan files to function; adding an extra dependency on Drakan.exe would be pretty trivial (even if it doesn't actually use Drakan.exe for anything, because why would it?).

EDIT:
On an unrelated note, I've finally narrowed down the issue with some levels not loading on clients when they're running on a dedicated server.

Apparently, it only ever happens if the dedicated server is running on an Intel CPU; never happens on AMD!

Posted: **Sat Jun 23, 2018 6:06 pm**

Mechanist wrote: ↑Sat Jun 23, 2018 4:40 pm
EDIT:
On an unrelated note, I've finally narrowed down the issue with some levels not loading on clients when they're running on a dedicated server.

Apparently, it only ever happens if the dedicated server is running on an Intel CPU; never happens on AMD!

That is good to know. Interesting, but great that we figured a huge issue out.

Posted: **Sat Jun 23, 2018 10:09 pm**

Sorry if I am reading you wrong but I appreciate everything you have done.

Thanks!

I feel like the last line comes off a bit harsh, unless I am reading you wrong.

It wasn't directed at any specific person, I merely wanted to make it clear to everyone reading to not expect any more miracles when it comes to AiO Patch at this point in time. I've read that line somewhere and it struck me as more original than something like "live with it!".

I didn't think that it could come off as harsh. Either way, the reality of situation is that Drakan is a quirky game and the state in which developers left it doesn't make it trivial to make improvements to it.

I know you have done this on your spare time and trust me if I could fix these things I would. It just never fell into my talent house.

I find programming in general really tricky and cryptic. It seems you gotta figure out a lot on your own. And given the lack of source code for Drakan, I'm surprised about the number of fixes that somehow made it into this patch. Like, I actually did this?

Drakan did come far from when the development started to when it was released. I remember watching some old gameplay video, was it the one showcased on E3? Someone mentioned it, linked it on this forum. One more year in development at least would be very beneficial.

Sorry if I or someone upset you.

Nah, I'm cool.

It was really hot on the day I wrote that post though!

Oh and in regards to this part, I actually do not see the point to remake something that can get shut down. I understand the nature of the remakes, but I do not offer my resources to those because there are potential legal implications with those.

I was actually referring to OpenDrakan - the open-source re-implementation of Drakan's Riot Engine, not OpenOOTF - the remake in Unity remake. There shouldn't be any legal implications with the former. Similar projects are being actively worked on today, eg. OpenMF and OpenRW; the final result would be opendrakan.exe, the alternative to current Drakan.exe, which, when finished, would let you play original Drakan exactly as you would with Drakan.exe (minus the bugs), assuming you own the original game as it depends on its data. It will take a while though and we might get older in the meantime (or not see its fully functional release at all), especially if more knowledgeable programmers don't hop on board. Here's the list of game engine recreations on Wikipedia.

unfortunately within my skill set I can work on drakan maps in the riot level editor and I have a talent for map design.

Yeah, just programmers are needed for this. But in the end, programmers can add more features that can be cleverly used by map makers. I always wondered how you and the others have found their way around the editor.

Well, as far as OpenDrakan is concerned, I don't see a problem - since it can be distributed as a game mod, and require the original Drakan.exe to run.

It would be drop-in replacement for Drakan.exe.

Drakan.exe by itself is not very useful neither, need both executable and the data to make the magic work.

In any case, because of it's nature, OpenDrakan already requires all the other Drakan files to function; adding an extra dependency on Drakan.exe would be pretty trivial

Dependency on Drakan.exe would be redundant as the dependency on data files is perfectly sufficient for all intends and purposes. You can play Quake III with ioquake3.exe (or any other unofficial executable) without having to have original quake3.exe in the folder. Since both original data and executable originate from the same source, it can be assumed having access to data means you "own" the game one way or another. The practical difference is that data files are copyrighted in most cases, unless stated otherwise, while executable may not be, especially if it's unofficial and developed from ground up.

Apparently, it only ever happens if the dedicated server is running on an Intel CPU; never happens on AMD!

That's an interesting observation. It could be just occurring on certain models/models from certain generations.

Can you try setting DisablePerformanceCounter=1 in Arokh.ini and tell us if it makes any difference? It's a rather strange option I implemented only because I've read on the internet about strange behaviors of QueryPerformanceCounter/QueryPerformanceFrequency functions that supposedly occur on certain CPUs. Disabling them will use timeGetTime instead.

That's the only CPU related thing I can think of. Maybe it actually does something if all stars align properly... My two computers are both AMD and the one game I have that has CPU related bugs is Pro Rally 2001. They tend to show on (certain?) AMD CPUs as freezing on the load screen. The game does the number of CPUID queries, which I haven't figured out myself. The guy behind nGlide says the bug is connected to timing and the issue disappears after making the code skip those CPUID queries.

The first patch that was made actually just faked the CPU vendor string, so the game thought it was running on Intel even if you had AMD and that apparently solved it for some people. It didn't work on my Phenom II X4 920 until I found and disabled the function call that does all those queries.

Posted: **Sun Jun 24, 2018 4:14 am**

UCyborg wrote: That's an interesting observation. It could be just occurring on certain models/models from certain generations.

Can you try setting DisablePerformanceCounter=1 in Arokh.ini and tell us if it makes any difference?

Thanks, I'll try that.

(EDIT: Tried that. Makes no difference whatsoever.)

We did some other testing in the meantime yesterday, and there was another interesting conclusion that we reached:

Running on an AMD CPU (both x86 and x64 OS) - works fine;
On an old Intel Atom, x86 OS - fails to load certain levels;
But on a Celeron 925 with x64 OS, it also works perfectly fine - despite this CPU supporting the exact same instructions (MMX, SSE, etc.) as the Atom!

Posted: **Sun Jun 24, 2018 3:30 pm**

OK, so I tried modifying Drakan.exe to make the CPUID queries never branch at the "Authentic AMD" check, thus fooling it into thinking that Intel = AMD.
This only required changing a single byte; making it compare a string with itself, so it'll always succeed.

Unexpectedly, that resulted in serious brokenness - suddenly it was no longer reading settings from the correct Drakan.cfg, causing the GUI graphics (as well as the text font) to be seriously mangled; as well as some other settings being changed from what they should be.
That happened despite running the client on an actual AMD machine, where it shouldn't even make any difference!

I suspected that the dinput.dll does some checksum checking on Drakan.exe. Apparently, indeed it does.

The most likely culprit is around this point:

Code: Select all

67003870   68 84790067      PUSH DINPUT.67007984                     ; ASCII "DllMain: Invalid Drakan.exe"

But I tried setting breakpoints in that general area (especially where the actual checksum calculation call is made from), and they never triggered.

For reference, here's what the CPUID queries returned on both systems (AMD = works; Intel Atom = causes dedicated server brokenness in levels like Auropolis):

AMD:
CPUID 0x00:
EAX 0000000D
ECX 444D4163
EDX 69746E65
EBX 68747541

CPUID 0x01:
EAX 00600F20
ECX 3E98320B
EDX 178BFBFF
EBX 02080800

CPUID 0x80000000:
EAX 8000001E
ECX 444D4163
EDX 69746E65
EBX 68747541

CPUID 0x80000001:
EAX 00600F20
ECX 01EBBFFF
EDX 2FD3FBFF
EBX 10000000

Intel Atom:
CPUID 0x00:
EAX 0000000A
ECX 6C65746E
EDX 49656E69
EBX 756E6547

CPUID 0x01:
EAX 000106CA
ECX 0040E39D
EDX BFE9FBFF
EBX 00020800

CPUID 0x80000000:
EAX 80000008
ECX 00000000
EDX 00000000
EBX 00000000

CPUID 0x80000001:
EAX 00000000
ECX 00000001
EDX 20100000
EBX 00000000

Posted: **Sun Jun 24, 2018 6:14 pm**

OK, so I tried modifying Drakan.exe to make the CPUID queries never branch at the "Authentic AMD" check, thus fooling it into thinking that Intel = AMD.

The results of the queries after AuthenticAMD check are never used, it just checks for support of Extended 3DNow! instructions and two other things. Whether that code runs or not doesn't make any difference in program workflow. The only purpose of that entire function is to check whether CPU supports 3DNow! instruction set. It's done before comparing "AuthenticAMD" string. 3DNow! has been deprecated for years and is not present on any modern CPU, apart from two instructions, PREFETCHW and another variant of prefetch instruction I don't recall from memory. Drakan uses PREFECTHW in one loop on the client-side, just a pointless micro-optimization at best. If you start Drakan.exe with "-no3dnow" parameter, it won't be used neither.

I suspected that the dinput.dll does some checksum checking on Drakan.exe. Apparently, indeed it does.

Intentional so the DLL doesn't interfere unless it's loaded by EXE it's designed to patch.

But I tried setting breakpoints in that general area (especially where the actual checksum calculation call is made from), and they never triggered.

Drakan.exe is dynamically linked to dinput.dll at load-time, so its DllMain function runs before Drakan.exe's main function. Maybe your debugger doesn't set breakpoints yet at that stage.

(EDIT: Tried that. Makes no difference whatsoever.)

So the issue is elsewhere. Still, If you want to try another timing related thing:

Code: Select all

bcdedit /set useplatformclock true

And to undo:

Code: Select all

bcdedit /deletevalue useplatformclock

Both commands go to administrative Command Prompt and require reboot to apply. Another thing that's been thrown around on the internet, an urban myth? This one's actually supposed to help with in stuttering games or it may just make things laggier.

If the timing is the issue in the first place. Seems odd to me. 0 A.D. game is coded to be able to use multiple timing sources and the QueryPerformanceCounter and timeGetTime aren't at the top of the preferred list. HPET is. Though QueryPerformanceCounter must rely on either TSC, HPET or something else, depends on the system.

Turning on useplatformclock supposedly sets HPET as the only clock source.

Posted: **Sun Jun 24, 2018 7:03 pm**

After many hours, I finally tracked down the problem!

All that CPUID stuff was just a red herring after all, just like you said.
The real problem was that there's some sort of race condition caused by setting the priority of Drakan.exe to anything above Normal on Intel CPUs!
Well, on Intel Atoms at least, since that's the only Intel I have.

I feel foolish! I haven't been paying attention!

BTW, thanks for the help anyway

EDIT: I've done some more testing - it is a timing issue of some sort, just not in the way we expected.
Setting priority to "Above Normal" makes Auropolis load occasionally.
Running on Normal priority, it loads correctly most of the time.
Priorities below Normal don't help.

On AMD, the server works and Auropolis loads OK, even with the priority set to Realtime.

Posted: **Sun Jul 08, 2018 8:26 pm**

This is most aggravating. So it turns out that it's not actually related to CPU type at all.
The first sign of trouble was when on my new AMD server (with cable Ethernet connection, no wireless), Auropolis worked for me - but not for everyone else

The next step was to take the old Intel Atom server and connect it via cable, instead of wireless

exact same behavior as with the AMD server.

Further testing with dummynet to cause artificial packet delays revealed that (additional) packet delays as low as <10 ms are sufficient to prevent Auropolis from loading.

I've attached the capture output from Wireshark (logged on the server side) - the first 2 connection attempts were successful (I quit the game after a few seconds), the 3rd attempt was unsuccessful (stuck on 99% load).
192.186.0.102 is the server, 192.168.0.101 is the client.

Look for a packet with a length of 686 - this appears to be the critical packet that tells the client to actually spawn the player after the level is otherwise done loading.
In the unsuccessful connection attempt, that packet had never been sent, for whatever as-of-yet not understood reason.

Posted: **Wed Aug 01, 2018 8:30 pm**

Interesting. Unexplainable bugs tend to be a common thing with Drakan. Another one for a clever hacker I suppose. Would require deciphering the context from the mess of assembly instructions. Any volunteers? No...I thought so.

I have some unreleased files, just making things look neater under the hood. Really miniscule and not really changing anything in practice. I might add portable mode in the future, so the game won't write to registry. And add the option to save games under specialized Saved Games under Vista+. Still not quite 100% if anything could break regarding this since the game uses ANSI paths and the function to retrieve is Unicode only. Hopefully, conversion is safe. I guess even localized Windows versions still use common english names for user folders and they just appear named differently in Explorer. Doesn't take much actually, but I'm taking things really casually and slow so...Also, somebody turn off the summer, the heat is nuts!

Posted: **Thu Aug 02, 2018 11:43 pm**

Published new minor update.

Posted: **Fri Aug 03, 2018 12:12 pm**

Google drive shows V2.136 which is same version number I have on my site - is the version number the same but the file has changed?

Posted: **Fri Aug 03, 2018 4:20 pm**

No, you have 2.135 on the site. I just always update the link for this website in OP.

Posted: **Fri Aug 03, 2018 4:31 pm**

OK updating file on my site now

Posted: **Mon Aug 06, 2018 7:33 pm**

I managed to fix that inventory glitch with being able to place wider items outside its boundaries. Uploaded new version as usual.

Posted: **Mon Aug 06, 2018 8:03 pm**

UCyborg wrote: ↑Sat Aug 24, 2013 8:35 pm
Added 2 active 'hitting intervals' for 'left' special attack.

Removed 'stuck in block' bug.

Ok, since you clearly know your way around the weapon/attack handling code, I could use some help here.

I found a bug (probably a very old, well known one) in multiplayer today, while messing around and testing a map I was working on.
It seems like the kind of thing that wouldn't be too hard to fix - but I'd rather not reinvent the wheel, when you could at least point me to the right general area of code.

Bug description: It's possible to hit another player several times in a single weapon swing by changing the equipped weapon in mid-swing, dealing much more damage than usual.
This is actually a combination of at least 2 different bugs in the weapon handling code - but the root cause is due to being able to switch weapons in mid-swing.

Severity: High (the effect is game-breaking when it's used against another player).
Priority: Low (not known to have been exploited in regular multiplayer gameplay... at least, as of yet).

Steps to reproduce:

Make sure that the mouse scrollwheel is set to change weapons (as it is by default).
Load a suitable multiplayer Ground or QoD map on a dedicated server - it has to be a map in which it is possible for Rynn to obtain at least 2 different "Hand Weapon"s (that is, the majority of non-Duel maps).
One player (the attacker) needs to have at least 2 "Basic weapon"s in their inventory, but no bows or magical crystals {see notes 1 and 2}.
It does not matter what the other player does, or equips.
Position both players next to each other, and have the attacker swing their weapon at the other player {see note 3}.
While attacking, rapidly scroll the mouse scrollwheel to keep changing weapons in mid-swing.

Expected result:
The weapon swing continues as normal, hitting the other player exactly once per each attack's "hitting interval" - and any attempts to change the currently equipped weapon have no effect until the attack animation ends completely.

Actual result:
Rynn changes the weapon she's holding several times in mid-swing (once per each click of the scrollwheel?).
Every time she changes the weapon {see note 4}, it registers a new hit on the other player - and each hit deals its usual amount of damage, as well as any other effects it normally causes {see note 5}.
With typical multiplayer weapons, if executed "correctly", this bug easily deals enough damage to kill (or at least severely wound) a player in one regular weapon swing {see note 6}.

Notes:

For best results, none these weapons should have any effects that cause the other player to be staggered or pushed backwards.
Haven't tested it with either a bow and/or a magic crystal in the inventory, but it's very likely they would prevent the bug from occuring, and/or crash the game in the process.
Haven't tested with combos, but I expect the general behavior in that case to be similar to what happens with the regular attack.
Possibly only once for each weapon that hasn't yet scored a hit during this particular swing. Haven't tested it in such detail yet.
If the player gets staggered or pushed outside of the attack range, it's very likely they will not receive any further damage from the current swing.
Given that many MP weapons already deal massive damage when used in a combo, I fully expect the combo variant of this bug to be devastating in its damage output.
This bug also occurs in the singleplayer mode. Haven't tested this in much detail either; it's possible the exact details are different from the multiplayer variant though. In any case, this bug's severity in singleplayer is "Low" - since it's unlikely to occur frequently in normal gameplay, (generally speaking) acts to the player's benefit, and doesn't aggravate any other players.

Arokhslair.net

Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch

Re: Widescreen hack and some other fixes aka AiO Patch