Eastern Front Patch 2.2.2.0 news

Hello comrades,

It has a while since the last announcement happened, and we have been literally offline since last year Christmas week... but now we have returned! Thanks to Cope who had fixed our FactionFix.dll, he really did an outstanding job; thanks to Relic and Smoking Gun Interactive as well because they have been supporting us since that patch released around Christmas!

If someone wonders what was the problem and what was needed to do every time Cope updates our DLL, you can read it here:

Copernicus wrote:
As requested, here are some details on what is actually causing crashes. This may be somewhat technical.

As you may be aware, in the past EF had problems with recrewing weapons. This is because CoH is hardcoded to only read capture squads for the 4 basic factions from team weapon entities. If you try to capture a team weapon with a Soviet squad, the game will crash because it cannot find the appropriate entry in the RGD (and subsequently runs into invalid memory sooner or later).

What I did back then was writing a custom DLL FactionFix.dll which for all purposes acts like the original game DLL (WW2Mod.dll; in fact it just forwards any calls to that DLL) but does some in memory patching, i.e. it changes some parts of the code in the original DLL. The code that is changed is the code that controls which squads are spawned when a team weapon is picked up. Whenever a non-standard faction tries to pick up such a weapon, my code jumps in and calls a certain ScaR function that returns the RGD-path of the appropriate squad. (To get the actual Lua-state of the ScaR-instance, I make use of Corsix' LuaExtCore.dll.).

Everytime a patch containing more than just balance changes is released, there is a chance that the address of the code that is to be patched has been changed. If parts of the DLL have been recompiled, it is even possible that parts of the fix have to be rewritten: Because we only have the binary files (i.e. the compiled code), my code needs to seamlessly interface with x86 assembler (which I very much like). Unfortunately that means, that if the compiler thinks it is better to put some value that was in some register EAX last time around into EBX this time, I have to rewrite parts of the code and spend sometime reverse engineering the data flow. These are all things that can be done rather quickly (even if some engineer at Relic decides that what has been an __stdcall up to v2.601 should be a __thiscall in 2.700).

The ugly part is if things do not work out immediately: This stuff is impossible to debug; without proper debug symbols even the stack traces of DMP-files are bogus and most applications totally don't like being debugged. Furthermore, debugging without any source code is tedious and not fruitful (especially when you are working with a system where you do not even have the faintest idea what most of the functions actually do!).

So what I currently have is the following:
I have updated the DLL accordingly and I have noted that besides some changes in the offsets, WW2Mod.dll has not been changed in the parts relevant to this patch. Still, the patch is not working as intended: Sometimes it works, sometimes it crashes, and sometimes it does not even allow a weapon to be recrewed (the cursor does not change into the right symbol and no action is possible). This (in a way) is the worst case scenario: My code seems fine (it is the same as for the last version and it worked for that one), but the behavior is somewhat non-deterministic. Sometimes you can capture a weapon, yet other times it won't work (using the same squad type and weapon type). If the game was crashing consistently, I could just look at where it is crashing and backtrace from there. But it does not.

I am not sure what causes this behavior. I have already witnessed similar behavior when I only patched an irrelevant part of the code (swapping two independent opcodes). This could indicate that some kind of memory protection mechanism is employed, yet I am not willing to believe this (why would it show that specific behavior? Why wouldn't it just crash all the time?). Non-determinism in behavior may also be indicative of multiple threads using the same code with non-thread-local data, but I highly doubt that because my testing setup was fairly isolated and it seems unreasonable to distribute the game logic to different threads, at least for this specific case. Another possibility is that I am missing a new piece of code that was inserted, but I was unable to find anything.

As you can clearly see, this problem is specific to mods that have additional factions.

To clarify another thing: I am not getting paid for this. Nobody here is getting paid for anything. And even if you did, you would not be entitled to anything because quite obviously, you did not pay for anything ;).

We released a small patch containing the new compiled DLL that will fix the crashes when playing with the New Steam version of Company of Heroes. Also, due to popular demand, we will release a patch that will make the mod compatible with 2.602 (Old Steam version or Retail). But remember, while this is a small assistance for those who don't want to play it in the new version, we don't offer support for it so, play it under your own risk.

We intended to release more content and balance changes, but we still need to finish the new models and to test more the balance changes, so we expect to release a new patch in the next two weeks, three at most, featuring all the content we have shown in pictures in the past weeks. But we certainly have changes that no one expects for Ostheer and Soviets.

So, the plan right now is:

1) To release the new DLL so everyone can enjoy Eastern Front. Changelog here.

2) To finish the pending models and balance changes and release the big patch.

3) Start working on the reward Command trees for Soviets and Ostheer.

Problems with the download? Look here.

Want the compatibility fix for 2.602? Look here. Mirrors: SpeedyShare MediaFire.

This Weekend we will talk about what you will see in the next patch so, stay tunned because we are back in business!

Thanks for downloading and continue to enjoy,

Archaic Entertainment Team