MacroQuest64

Array and Array2... any way to implement arrays of unlimited dimensions, and declare an array(#). So array(1) would be your basic list, array(2) a "table", array(3) a "cube", etc.?

I can visualize a three dimensional array of mobs, and a macro that sorts them into the array based on con color and "named" vs. "unnamed".

prints @param0

Is this correct?
print the first parameter.
Hangs like a mo' fo'. One of the search argument routines is broken.

dont_know_at_all wrote:

Code: Select all

/sub main
/echo @param0
/return

prints @param0

Is this correct?

Yes, variables are case sensitive, and unnamed parameters are Param, not param

dont_know_at_all wrote:

Code: Select all

/sub main
/call sub2 @param0
/return

/sub sub2(param0)
/echo @param0
/return

Hangs like a mo' fo'. One of the search argument routines is broken.

Ok, that's semi-bad... logically its: "@param0" doesn't resolve so it leaves it as "@param0" and passes it in
now, sub 2's /echo: replace "@param0" with the value, which is "@param0", and PMP then reparses the line,and replaces it again ;(

I'll have to think more on how to "fix" this...

Plazmic wrote:Yes, variables are case sensitive, and unnamed parameters are Param, not param

Yikes.

Also, it seems a bit slower. My bard run-in-circles macro is definitely not a circle anymore. I'm not sure how to debug this....

All variable lookups are string based. It'd be even slower if vars weren't case sensitive.
The fix to that recursion issue will probably slow things down a tiny bit more. since I'm going to have to check the contents of the variable when it's deferenced for any variable dereferences.

Fixes in test:
Recursive dereferences.
/for doesn't work unless var is all lowercase
Plus sign (+) changes into a @

It all works now I think... I wrote a fairly extensive uservarstest.mac that is included in the diff I sent DKAA...
Stay tuned for the official word back that the zip is updated ;)

Plazmic wrote:All variable lookups are string based. It'd be even slower if vars weren't case sensitive.

But it's always been a string lookup more or less. I think there is something really inefficient going on.

I'm only getting like four course adjustments per cast time, which means it takes nearly a second to do some simple math and a doevents on a PII 450. I'm going to add some more spew and see if I can figure it out.

CVS and zip are updated.

is it possible to set up an array of timers? I what to be able to time multiple buffs.

Pseudo-code:

dont_know_at_all wrote:But it's always been a string lookup more or less. I think there is something really inefficient going on.

No, before we parsed 1 char, and did an atoi, and referenced an indexed array...
Now we walk a linked list strcmping each varname against the one we want to dereference...

dont_know_at_all wrote:I'm only getting like four course adjustments per cast time, which means it takes nearly a second to do some simple math and a doevents on a PII 450. I'm going to add some more spew and see if I can figure it out.

That does sound slow, but if you are in #turbo mode, it would be 4 frames per second, unless your code is overloaded with /doevents, which could be part of the slowdown (inefficient code?)

Turbo is off. I will play with that...

With turbo off, each /declare command will eat a full pulse cycle.
That would explain some slowdown...

DKAA noticed a memory leak if a macro does any /calls
I found leaks in both /return and EndMacro()
There will be a minor update tomorrow when I'm sober.

Got the diff.

CVS and zip file are updated.

Currently if I set an array ie..

/declare test array
/varset test(1) "testarray1"
/varset test(2) "testarray2"

and then try to echo it

/echo "test(1)"

it shows as "test(1)" in the echo...

This happening for anyone else? Are arrays still broken atm? I've tried everything under the sun to make this work but it doesn't seem to work no matter what I try. I've made sure the cases are correct as well.