MacroQuest64

I'm having problems getting MQ to run more than 3 or 4 minutes at a time. When I first log in, everything seems to work, macros run, /who works etc. Abruptly, my eqw window closes.

I've done the following steps
1) full checkout from cvs into a new directory
2) unpack detours.exe and copy detous.lib and detours.pdb into \detours\lib
3) full Release mode rebuild

When that didn't work, I tried rebuilding detours.lib on my machine, and then doing a full rebuild on MQ, and that still didn't work.

The only thing I can possibly see as being different is that my VS.net has not been updated with any service packs (can't, since I'm using it at work and baseline VS.net is what all developers are using.) Sorry if this was addressed elsewhere, but I haven't seen it: do I need to be using service pack 1 in order for this to work?

Another possibility is the system I'm running MQ/eqw on. It's XP with service pack 1 and all recent updates.

Thanks for any help...

My system exactly equals yours: baseline VS.NET install, XP SP1 with all updates. Everything works as it's supposed to. I know this doesn't really help you per se, but it at least confirms that your system is capable of compiling/running MQ. :) At the moment I don't have much else constructive to add.

Thanks for the reply, Clawed. At least I know that it *should* work =)

One thing it would help to know is if you are compiling a Release or Debug build.

Get the latest CVS again -- Neal found a bug where I wasn't covering up the memcheck3 detour correctly.

I'm compiling release versions of all 3 projects.

/sigh, gotta get the CVS again and add all my custom code back in... gets annoying after like 8 successive CVS commits in a few days.

I updated from CVS this morning, the only update was eqlib.cpp

After rebuilding, I still get the same problem...EQ shuts down with no warning after about 3 minutes.

I'll try building a debug version next, to see if I can get any useful information on the problem.

I know how you feel Clawed. I've just been using Windiff to find the changes, then copying them over to my custom version. Takes a while (especially since I have some huge changes), but since the CVS code changes are mostly just in the memcheck areas it's been taking less and less time.

See my thread in the developer forum about a plug-in system. I think this would alleviate all our problems with source forking. (Well probably not all of yours, since you tend to strip down the code a lot too.)

A plug-in system has been under discussion for quite some time now, just hasn't been anyone willing to tackle the problem.

And yeah, I strip out stuff I don't use or never found a use for. A lot of it seems to be PvP stuff I don't need.

The other major change I make is moving things around into multiple sub-directories. Just easier for me to find what I'm looking for, and makes it easy for me to upgrade header and library files from SDK's as they are released. For example, made it very easy for me to fix the whole dinput.h problem by simply moving a new version into my EQLib/inc directory. Also lets me include precompiled detours.h and detours.lib.

A plug-in system has been under discussion for quite some time now, just hasn't been anyone willing to tackle the problem.

Well, I am willing to tackle the problem. 8)