This adds a basic reimplementation of the Unicode struct with its constructors and unsigned short conversion operator. Other functions are significantly large and will be added in later pull requests.

I can confirm that the functions, with the exception with the default constructor closure, are generated with the exact same code in Visual C++ 6.0. In VS 2019, The default constructor closure does not generate unless the Unicode::Unicode(unsigned short) constructor is declared with __declspec(dllexport). In addition, the default constructor closure generates the exact same code if the same constructor is also declared inline.

Otherwise, the code behaves exactly the same as vanilla Diablo II.

D2Common.0x6FDB64A0 and LoadItemStatCost Now they seem to work properly, however the STATLIST_InsertStatModOrFail_6FDB7690 and D2Common.0x6FDB5830 functions are not working properly.

STATLIST_InsertStatModOrFail_6FDB7690 it's wrong in some ISC, example: Cold Skill Damage % D2Common.0x6FDB5830 it has a problem with the Auras. The auras of nearby friendly units do not share it with other friendly units (disabling it works perfectly).

These changes add the Unicode::strlen function. The function behaves similar to what is expected for a strlen function, with one notable exception. If the supplied string pointer is NULL, then the function returns 0.

When the function is compiled with Visual C++ 6.0, the binary is the same as 1.10f.

This adds a reimplementation of the CRC-16 calculate checksum function, D2Lang.Ordinal10005. The lookup table is replicated 100%, and each of the 4x4 matrix sets are described in comments. My own quickly written tests external to this repository confirms that the function outputs the exact same checksum as the vanilla 1.10f D2Lang.dll, when fed the same input.

These changes simplify ordinal 10515 for better readability.

For documentation reference: This function appears to be a free/dealloc function for D2UnitStrc starting from a StatList marked STATLIST_TEMPONLY.

• i tested the function it doesnt work and you error 2 is gdwBitMasks[nState % 32] -> gdwBitMasks[nState % 31]

bool bStateMaskDisguise = pStatesTxtRecord->dwStateFlags & gdwBitMasks[STATEMASK_DISGUISE]; Fix bool bStateMaskNoSend = pStatesTxtRecord->dwStateFlags & gdwBitMasks[STATEMASK_NOSEND];

• i fixed the code my way and it works Link

The errors remain exactly the same.

This was added that LoadItemStatCost does not read the OPs 0/8/9/10/11 that correspond to the same OPs that fail with the STATLIST_UpdateUnitNewStat function and STATLIST_InsertStatModOrFail

(As a side note, LoadISC from the pre-bulk changes version worked fine (it's the one I'm using))

Sorry for my slowness, I still haven't finished rearranging all my code, it's very long and I didn't check even half of the D2Moo functions (corresponding to ItemsFunctions, DRLG, Path and Missiles). The good news is that I have made several fixes to the Path and Skills functions to make them work much better (and in some cases, to work directly).

And with Statlist I can't fix those errors.

I also don't have enough time to repair all the maximum details, but I would like to get it since it is very useful to handle all the statlists to try to expand them a bit with some custom code (in addition to expanding the ISC OPs which are also very useful)

These changes add the D2Lang.Unicode::toUtf function. The function converts a null-terminated string of USC-2 encoded characters into a null-terminated UTF-8 string.

Vanilla bugs are documented and workarounds are documented.

My own testing confirms that the function works similarly to its vanilla counterpart. The file scoped sgUtf8ConvertTable is confirmed to be the exact same structure when the default pragma pack is used. Pragma pack is used due to an error during the compilation process, but can be ignored using pragma pack, because the variable is not exported outside the file scope.

//D2Common.0x6FDC0FC0 (#10436) int __stdcall UNITS_GetFrameBonus(D2UnitStrc* pUnit)

This feature has timing issues in "hth" mode when the character dies.

Verified with Sorceress.

The head of the Sorceress goes "crazy" and does not show the proper location as she walks after dying.

Possibly it is related to an internal function, I have not verified exactly which one, although my suspicions point to this other:

//D2Common.0x6FDB30A0 (#11013) void __stdcall D2COMMON_11013_ConvertMode(D2UnitStrc* pUnit, int* pType, int* pClass, int* pMode, char* szFile, int nLine)

From Conqueror on the PK discord:

There are more bugs I discovered in 3 DRLG functions //D2Common.0x6FD85A10 DRLGPRESET_ParseDS1File Doesn't control MonPreset ID properly The Objects I rewrote it completely to implement Extended Object in my Mod, this works fine, still adding more than 150 objects per act. So for this part the function is perfect. In MonPresets the error is that it does not correctly calculate the ID for SuperUniques, NPC and Champion / Unique monsters

I'm currently moving structures from the centralized headers to their own headers, which will help since we won't have everything in just a few files. This is obviously taking quite some time, hence why I open this WIP pull request.

I'm also taking the opportunity to change int => int32_t, short => int16_t.

Current names for fog functions are not good (especially memory allocations functions are named with client/server, instead of D2Alloc(Pool). (Fog.#10042 and and Fog.#10045)

Right now I did not choose the way we want to support mods for the D2Moo integration. In the long term, I think the best option is to use a fork of D2Moo, but it's not necessarily simple to migrate from an existing mod (for example using D2Template) as you would have 2 different patching methods.

In my opinion this should be a discussion with other modders / community, so I listed a few ideas, their advantages and drawbacks in the following table.

Please give your opinion!

| D2MOO as | Method | Integration with existing mod | Ease of update | Can share includes | Compatible with D2Template | Can easily change implementation of an ordinal | Mod redistribution | Can contribute/share easily (bugs) | Is own project bugged or is it D2Moo? | |------------|------------------------------------------------------|-------------------------------------------------|--------------------------|--------------------|----------------------------|------------------------------------------------|-------------------------------------------------------------------------------------------|------------------------------------|---------------------------------------| | subproject | Configure CMake to use your own patch files and .def | medium | easy | only unpatched | +/- | yes, but only from the original dll pov | D2Moo launcher + .dlls | yes | easy to know | | subproject | Import D2MOO .dlls and patch the functions you want | easy | easy | only unpatched | yes | yes, but only from the original dll pov | Whatever you already had | yes | easy to know | | subproject | Link D2Moo statically | medium | easy | only unpatched | yes | yes, but only from the original dll pov | Whatever you already had | yes | mostly easy to know | | fork | Fork D2Moo and work directly on it | needs some transition (start by importing dll?) | easy, might need resolve | all | +/- | yes | D2Moo launcher + .dlls (OR simply .dlls if we use forwarding DLLs for unpatched ordinals) | yes | just need to change branch | | source | Copy paste (please don't) | "easy" but leads to lot of issues | hard | copy-paste... | yes | depends on your project patching facilities | ? | no | no |

The original game as a lot of bugs, and we need to decide what to do about it. Since D2MOO's main objective is to implement the vanilla game, we must keep the code of those bugs, and document them. We could probably still fix them, and use a macro for such code to enable/disable fixes.

I'm adding a new Label for bugs reported that might have an impact to modders, but were already present in the original game, thus not due to D2MOO.

Such bugs must be both labeled and reference this issue.