arrays and there creative use.

[Fippy]

Ok I have a problem that maybe somebody could give me an idea or 2 on.

I currently have an array that is being used to keep 2 different sets of data in.

$a(1,X) is a list of player names

$a(2,X) is a list of text commands, like cast, move

$a(3,X) is a list of spell names

$a(4,X) is a list of targets

If a player send me a tell my script first checks he is on the listy of player in $a(1,X) if he is the tell is parsed for certain command strings.

a string may look like this
cast sow me

so my script then adds cast to $a(2.X) expands sow to "Spirit of Wolf" and adds it to $a(3,X) and expands me to the players name and get his id and adds that to $a(4X)

This all happend in the chat event sub.

My main loop checks the command queue and casts the top one, removed it from the list and then moves the others up one.

But the is very messy since i need to maintain the integrity of $a(1,X) Any ideas on a better way of maintinf seperate lists or am i gonna have to ask plaz for another array variable.

Fippy

[Casper]

It looks like you're trying to play with arrays when you don't need to. You're not populating your array elements with any type of persistance so don't bother with them.

1) Make a function that returns whether you can take requests from the player making the request.

2) Make a function that returns the type of operation that is being requested; e.g. cast, move, etc...

3) Make a function that gives you the spell gem location of the spell the player is requesting.

4) Now make functions for your operations.. For example, DoMove, DoCast, etc..

5) Call your DoXXX functions with the information obtained/parsed from your functions 1-3 above.

Psuedo-code example:

Main
{

while( TRUE )
{
WaitForNextRequest
}

}

WaitForNextRequest
{
Variables nAccessOk, szOperation

Receive Command_String

Call DoesRequesterHaveAccess
if( nAccessOk == FALSE ) then return

Call GetOperation
if szOperation is not supported then return

Call DoOperation( szOperation )
}

DoOperation( Variable szOperation )
{

if( szOperation == "Cast" ) then DoCast
else if( szOperation == "Move" ) then DoMove
[ etc... ]

}

DoCast
{

Variable nSpellSlot
Call GetSpellSlot
if nSpellSlot is not valid then exit the subroutine

Select the target for the spell
Cast spell in slot nSpellSlot

}

DoMove
{
Variables nX, nY

if the target can be selected then get the target's x,y in nX and nY
if the target is x,y then retrieve it in nX and nY

Handle moving to nX and nY

}

It's much more readable and easier to maintain this way. Try not doing something new just because it IS new. Evaluate whether it's the best design before deciding on your architecture.

The WaitForNextRequest function above most likely is your event handler - triggered when a new message is received directed to you. The string that you receive is the input to your parsing functions.

Enjoy...