Now that I have had more time to think, I would like to point out that of the 5 admins, they have made 147 posts in the past 2 months and two of them made more than twice the posts of the other two combined.
DJ_Omnimaga made 822 posts.

On other forums that I have been a part of, there are usually at least to or three very active admins and admins are among the most active users. Currently two of the admins are pretty active on the forums (and so would be more noticeable to users that cannot access IRC), so that is good, but DJ_Omnimaga is by far the most active/experienced member on the site.

   the fundamental difference between "L1" and "GDB1" is that the first is a pointer to a static position in RAM that is guaranteed to be usable to any program that wants it while that program is running (this is not strictly true of the other "Ln" pointers, but it's the same basic idea) while the second is a pointer to a position within your program. when you "store a value to GDB1", axe inserts the data directly into your program somewhere at compile time and returns a pointer to its position within your program during run time. it would technically be possible to do the same with "L1", but storing data to that location at compile time would be completely useless. it would only exist on your calculator, not the calculators of anyone else who may want to run your program, and it would be overwritten on your calculator as soon as some other process decided to store data there. thus, axe ensures that "L1" can only be written to during runtime. what this means is that, in order to accomplish what you want, your data has to first be stored somewhere else (which could be inside your program, in an external appvar or program, or anywhere else on the calculator) and then copied over to the chunk of RAM starting at L1 for manipulation there.
   it is also possible to write to "GDB1" during runtime. bear in mind, though, that these pointers are pointing to a spot within your program itself, meaning that, if you write to an area outside of the space allotted for data at compile time, you will end up overwriting other things, including possibly even rewriting your own code as it executes. also, if your program is being executed directly from RAM, or if you are using a shell with writeback enabled, any changes you make to your program during runtime will be permanent, meaning that the next time the user launches your program he will be left using the values generated the last time it was run.

EDIT: syntax for the Copy( command, which you can use to copy a chunk of data into the space at one of the Ln vars
Copy(BUF) token: conj() Copies the 768 byte buffer to the main buffer. Same as Copy(BUF,L6,768)
Copy(BUF1,BUF2) token: conj() Copies the 768 byte buffer BUF1 to BUF2. Same as Copy(BUF1,BUF2,768)
Copy(PTR1,PTR2,SIZE) token: conj() SIZE bytes starting from PTR1 are copied to PTR2 onwards. 0 is not a valid SIZE.
Copy(PTR1,PTR2,SIZE)r token: conj() SIZE bytes ending at PTR1 are copied to PTR2 moving backwards. 0 is not a valid SIZE.

here are a few things

yes, this section is for showing off your projects, while the other is for asking for help.
speaking of which...

^indeed. moving...

"marginal to none" means "there was a preference recorded, but it was so small that it is either marginal or can be attributed to error and marked inconclusive"

i'm glad you found them useful, but please don't bump old topics without adding anything useful and|or particularly relevant to the topic (known as necroposting). it clutters the new posts list and propogates potentially outdated information.