Wait, then making a lot of instances and then destroying them could ultimately lead to a crash?

I create and destroy thousands of lists in a minute. Am I fucked up?

Instances aren't a concern until you create at least 10m-100k=9.9million of them, at which point they start overlapping tile ids. It's unknown whether this would really be problematic, though, as I've never heard of anyone doing it before.

Realize that if you create 10 thousand instances a minute, it will take 990 minutes, or 16.5 hours, before you reach the 9.9m point.

If you create 10 thousand lists a minute without destroying them, it will take 10 minutes before you reach the 100k point. If you destroy every list you create, you will never exceed the 10 thousand mark for IDs, because the IDs get recycled.

I've seen it trow me errors when I load objects with lists inside. I just don't know ehat the heck is going on inside there.

No, it's erroring because ds_lists (and other data structures) are not saved, and thus, when you load and try to access your old ds_list, it is now gone. According to the GM Manual in the section for Data Structures (which you've clearly taken the time to read):

Please note that data structures and their content are not saved when you save the game using the actions or functions for that. If you use data structures and want to allow for saves you have to create your own mechanims for that.

I'm not sure where Brett got the idea that tile IDs start at 1,000,000... I believe that may be where tile depth starts.

I believe he's actually correct. Tile IDs start with 1,000,000. This is the way I have documented them, and this is the way LGM handles them (with the exception of defragging prior to r453, due to a bug)

Another thing: what is the "then" keyword for? Is it completely useless or is there a use-case for it?

I'm not aware of any use-case for it. As far as I'm aware, it's basically just to make the syntax compatible with other languages like BASIC (including Q-BASIC and VisualBasic) and Pascal. As far as ENIGMA is concerned, I'm sure it is defined thusly:

Code Select Expand

#define then

Actually objects start at 0. Instances start at 100,000. Rooms start at 0, etc. If you create a new game, and add 1 of every resource (Sprite, Object, Room, etc), they will all have ID 0. It distinguishes them because you would never use them interchangeably in a function. For instance, it wouldn't make sense to give anything but a sprite to draw_sprite. Likewise, for functions which *could* use them interchangeably, such as creating textures, instead it has different functions for each resource type.
ds_list also starts at 0, because it would never make sense for you to use it interchangeably with another resource.
I don't know why tile IDs start at 10m, but instance IDs have to be separate from resource IDs, because in-code, you may reference an object's variables (e.g. object0.x) or an instance's variables (myInstance.x), which is interchangeable code with completely different expected results.

MahFreenAmeh, or to whom it may concern,
Any chance we can get an alphabetized version of the list?

r383

I just corrected a bug where the last argument is written as a Java Object, rather than the argument value.

Resources should now write their name, or default to the number if they don't have a name for some reason. Colors should output as hex: #bbggrr (can be left as integer, if desired). Arguments that are guaranteed to be string will have "" around them. action_show_message is not one of these. Boolean "0" and non-zero will be replaced with false and true respectively.

action_show_message and other D&D actions which can take either strings or expressions (for instance, action_show_message) will be left alone for now because I'm not sure of their behavior. Test each of these lines individually, for instance:
string(x)
Hello World

A possible workaround could be special surrounding characters, such as ``, which ENIGMA would have to handle explicitly.
`string(x)` would become "0"
`Hello World` would become "Hello World"

Code Select Expand

ERROR in parsing engine file: this is the worst thing that could have happened within the first few seconds of compile.
             /
            |    |
             \    \
      |       |    |
       \     /    /     \
    \   |   |    |      |
     | /     /\   \    /
    / |     /# \   |  |
   |   \   *    `      \
    \    /   =  # `     |
     |  | #     ___/   /
    /   _`---^^^   `. |
   |  .*     #  =    | \
     |  =   #      __/
    .\____-------^^  `.
   /      #         #  \
  |   =          =     |
  \___    #     #___--^
      ^^^^^^^^^^^

  #define __GNUC_PREREQ(maj, min) \
((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
Not found: __builtin_huge_val
In file included from SHELLmain.cpp: Line 78, position 4: In #if expression at position 23: Expected operator at this point
code snippet: /OpenGL/GSsprite.h"
#elif ENIGMA_GS_OPENGLES
#in<<>>clude "Graphics_Systems/OpenGLES/OPENGLStd.h"
#in
------------------------------------------------

Also,

Code Select Expand

ismavatar@mct060d-ubuntu:~/enigma-dev$ pwd
/home/ismavatar/enigma-dev
ismavatar@mct060d-ubuntu:~/enigma-dev$ make clean
cd CompilerSource && make clean
make[1]: Entering directory `/home/ismavatar/enigma-dev/CompilerSource'
rm -f ".eobjs/*"
rm -f "../libcompileEGMf.so"
make[1]: Leaving directory `/home/ismavatar/enigma-dev/CompilerSource'
ismavatar@mct060d-ubuntu:~/enigma-dev$ ls CompilerSource/.eobjs/
bettersystem.o          ext_iteration.o             parser.o
cfile_parse_macros.o    eyaml.o                     parse_secondary.o
cfile_parse.o           file_find.o                 pcs.o
cfile_pushing.o         gcc_backend.o               references.o
checkfile.o             handle_letters.o            skipping.o
collect_variables.o     ideprint.o                  string.o
compile_common.o        JavaCallbacks.o             syntax.o
compile_includes.o      keyword_operator.o          template_handlers.o
compile.o               macro_functions.o           textfile.o
cparse_components.o     main.o                      type_resolver.o
cparse_shared.o         module_write_backgrounds.o  varnames.o
cpmain.o                module_write_sounds.o       write_defragged_events.o
crawler.o               module_write_sprites.o      write_event_code.o
darray.o                object_storage.o            write_globals.o
event_parser.o          output_locals.o             write_object_data.o
expression_evaluator.o  parse_and_link.o            write_room_data.o
externs.o               parser_components.o
ismavatar@mct060d-ubuntu:~/enigma-dev$ tail -5 CompilerSource/Makefile

clean:
-$(CREMOVE) ".eobjs$(SLASHC)*"
-$(CREMOVE) "$(ONAME)"

ismavatar@mct060d-ubuntu:~/enigma-dev$
because rm -rf doesn't like having quotes around the location.

I'll fix that when I get a chance.

The mplay functions are largely being replaced with a more robust system. Most of the function names are different, which is why these functions are not showing up as implemented.

Redundancy of dissolving broken systems never hurts. It's like running kill -1 followed by kill -9 on a process.

Might also be nice to include a return type.

Enigma will. He asked about GM, though, which doesn't distinguish between double and int.

Feel free to do all the GM functions, since that's the goal of Enigma. Or if you'd like, just do only the implemented GM functions. Eventually there will be a number of additional enigma functions which we'd like to have documented as well, but I wouldn't just go with the current function list, since any number of those could disappear at any moment.

I'm in favor of including the argument type as well.

o I agree that some generated help would be needed, thou I still think it should be local in one way or another.

This is what I'm in favor of as well, because not every user has internet access, and it can be annoying when a program needs to contact the internet for something.

For now, you're welcome to document the already known GM functions.

\MinGW\bin\mingw32-make.exe

Java can't find it. I don't know what Java uses to make system calls, but it's apparently bad at life. Could you try to remedy that?

Even I can't make heads or tails of that location... Maybe if you omit the \ or something?
I believe Java uses its own path variable to determine where to find things. Obviously, make isn't going to be included in that path. As far as that URL goes, I'm at a loss.

Also, RetroX seems to have taken over the updater and make on Linux from me with his install script. He's had me disable my calls to the SVN and Make if the OS is Linux. In a way, this is similar to many Linux programs that are included in the linux repo (e.g. canonical), which have their update button grayed out because the repo handles updates for them.