Reply To: MWEdit
Ugh…those includes in common may be an issue. I’m trying to avoid using WinSock entirely as MWEdit doesn’t use any kind of network code and that would cause unneeded bloat. Can be added if needed, though, if things can’t be whittled down enough.
Unless I’m mistaken, shouldn’t WinSock 2 be used after the basic Windows header so it overrides the old version? Of course, as we know, most OS-specific code is arcane to me as I rarely work on code that needs to interface directly with the underlying system.
Common will be rewritten eventually. The large integer union looks like an artifact from the days where 64-bit numbers were a novelty and can probably be replaced with std::uint64_t or std::int64_t. As for the other stuff, that’ll need some additional investigation.
Trying to get the Windows code working properly is beginning to get a little discouraging. 🙁
Edit:
Just opened a task item to fix the loss of precision in the UI code. We have stuff like this:
pEnchantData->MagMax = (short)(std::atoi(Buffer));
Here’s the struct for it:
typedef struct {
short EffectID;
byte SkillID;
byte AttributeID;
long RangeType;
long Area;
long Duration;
long MagMin;
long MagMax;
} enchanteffect_t;Essentially, it’s converting the string first to a 32-bit integer, then casting it as a 16-bit integer, and finally storing it in a 64-bit integer. This sort of thing occurs frequently in the code. That could cause some issues. Ideally, we’d convert the string directly to the correct type so that all data is properly preserved. We’ll want to investigate things to determine the correct integer types and change the code accordingly.
