I'm reading this excellent book. I considered to use steering behavior in our MMORPG game server project.
but if we use it all,it would consume a lot of cpu time which would be unacceptable for a server project.
does any one have any experience on this topic?How could I find a proper way to use steering behavior in MMORPG server?
You write the search algorthim as an iteration, with adjustable resolution and trigger(s).
If two objects are more than X apart the search doesn't run at all unless there is a special trigger. If you haven't been "spotted" there is no need for an enemy to search and so they usually just walk a defined set of waypoints called "pathing".
So movement especially for NPC's or bots usually have two different behaviours being "pathing" and "searching". Often there is also a way to get "unspotted" and NPC's/BOTs may be leashed to some co-ordinate. If they get more than some distance from the leash point they will drop "seaching" behaviour and resume "pathing".
The trigger whatever that is usually establishes the "target" and it is at that point the search AI kicks in. The game design thus far made sure searching is used sparingly.
Now when the search algorthim kicks in, it sets a resolution grid based upon how far the target is away. You don't need a fine grid for a target far away. So you will have a raycast which you run to each point on the grid. So when target is a long way away you still only get a small grid just they represent a big distance. That is the bit your code you currently have probably doesn't do and so you have a huge grid when the target is a long way away.
So now with your grid you run the AI search algorthim to work out what direction to move to the target allowing for walls etc. If the target is a long way away the direction will only be rough but that is all it needs it will fine up as it gets closer.
The problem you probably have with the AI search they have given you is the grid is massive and it gets bigger and bigger the further a target is away.
I don't know how to do what you want with heap but there is an obvious way to make the program more deterministic which is to pre-create the dialogs just held in a storage array not in use. It is really dangerous to be creating anything so significant off an event.
When you get a message you call your little routine to pass you back the first free dialog which you load and use. When it's finished you put it back in the pool.
It's a lot easier to avoid such problems by changing behaviour to determinstic rather than chase the bug itself
That is how windows is designed to work. The best bit if you don't use the HasString flag you can just send the pointer in to the text which saves copying and moving the text.
If you have a dialog coming up a lot you are expected to do it that way or via the dialog template system so you don't fragment the hell out of the memory. Common dialogs works that way you know FileOpen, FileSave etc. CreateDialogIndirect function (Windows)[^] Creates a modeless dialog box from a dialog box template in memory
All you have to do is insert your changes to the text etc via the message system using the control ID's, put it into the desktop or your app and then set the dialog modal and viola it looks just like what you are doing now.
I don't have a problem creating the odd dialog on the fly but if it comes up a lot try and at least use windows the way it was intended.
The debug thing uses a similar trick but into a multiline text window. They change the malloc stub to post the text messages to the multiline edit window.
The heap corruption indicates that you have an out of bound memory write access (e.g. writing to an array beyond it's size). Running out of memory indicates that you are allocating a lot of memory but not freeing it.
For modeless dialogs follow these adviceses:
Create a variable and initialise it (assigning NULL or using new)
When the dialog should be created the first time check if the variable is NULL and call new if so
Create the dialog
When finished with the dialog, call DestroyWindow()
If the allocated memory is not needed anymore, delete it and assign NULL to the variable
When the variable goes out of scope, delete the memory (e.g. in the destructor of the class holding the variable)
I suggest to check your code for the above (each new must have a corresponding delete, and each CDialog::Create must have a corresponding CDialog::DestroyWindow).
Because the memory corruption is a severe error, I suggest to find the source and fix it first. Use a debug build. Then you don't need the GFlags. They are for debugging executable files where you don't have the sources.
If you know the code portions (or have a guess) where the heap corruption occurs, you can insert some AfxCheckMemory[^] calls to check the C++ heap.
it is after do the create of the dialog and populate the control including allocating via new a Richedit and streaming data to it that something goes wrong all storage is allocated via new
A common error for such cases is forgetting to append a NULL char to the received data before passing them as string and/or forgetting to allocate the additional memory for the NULL char.
Get a resource explorer (search the web for one) to find out which resources are contained in the DLL. If you refer to the DLL for the Solitaire game shipped with older Windows versions it will contain only bitmaps.