KAZESUI'S PROFILE

To be honest, not really.
On the assumption that this plugin is the cause, that'll be a little bit surprising, since it wasn't made with optimizations for intel.

I'm not certain, but I imagine a possible culprit would be some quirk of the compiler, which is fairly restrictive when it comes to DynRPG which might mean that there's not too much to be done anyway.

You should be able to do this using the DynText plugin, but keep in mind that this does not work with the typical text box command. Pretty sure this can be done with the textbox as well, but I don't know of a plugin which does that, meaning you'd likely have to code the plugin yourself (involves programming in C++).
Keep in mind that DynRPG itself doesn't come with any such functionality, you need to download plugins separately after patching the maker with DynRPG (and the official version is incompatible with DynRPG)

That said would logically give you the 100th item in the database, not the item with value stored in variable of id 100. To do that you'd likely want to do something more along the lines of

author=McBick
That is what I have been using them for, but it is weird to me that I don't have to define them as an int, string, or elsewise.

As mentioned, the compiler automatically considers them to be integers (unless other specified, though limited to being some integer type variant, e.g. no float or string).

author=McBick
Do you know if there is a way to play animations from DynRPG, specifically during battle? This is the only thing I can find for playing animations in battle:

RPG::AnimationInBattle->isAnimationPlaying = true;
RPG::AnimationInBattle->currentAnimationId = n;

This does nothing when executed though.

Nope, do not know how to use the native battle animations. If I felt the need to use animations in the default battle system, I would probably just use RPG::Image directly, though that would be tricky on a potential non-savvy end-user, as you'd lose the battle animation generation interface.

The conventional way of doing this would be to use onSaveGame and onLoadGame callbacks and the functionality within it to save the data to files, assuming your data is save game specific.

You could use the text plugin source given on page 2 of this thread as an example of how this functionality can be used.

If this gives a headache and you can convert the values into integers, you could just store them directly into the RPG::variables, or you could even store in at actors which are only used as variable deposits, as then the ingame load and savegame functionality should take care of it and you just need to query these values directly from the database upon loading a gamefile.

author=McBick

std::map<int,RPG::Image*> images;
images[0] = RPG::Image::create();
images[0] = RPG::Image::create(); //A crash should happen here
RPG::Image::destroy(images[0]);

From what I studied this should not work. At least from my understanding you can not declare the same key twice, but perhaps I misunderstood this?

You're half right. That you cannot declare the same key twice is true, but a declaration of the key is actually only done the first time. If you would use the "insert" method, it would probably have failed, but not when using the subscript operator (the square brackets). What actually happens is that when you use this, it will first check if a key exists for they key you give, and if it does not exist, it will create a key. This is what happens the first time, but the second time it just gives you access to the pointer variable without trying to create another key.

author=Kazesui
You do not need the std::map data structure to use the if check. To be honest, if you have two static images which you use and you don't loop through a for loop anyway, it would generally make sense to give them more specific names and use them directly as a variable

Yes, I have learned this upon cleaning up my code. I have kept the map structure only for any HUD text now, but have since changed the objects for the window graphics to each have their own variable.

author=McBick

author=Kazesui

RPG::Image* image;
image = RPG::Image::create();
if(!image) //Error cannot convert image from RPG::Image to type bool.
    image = RPG::Image::create();
RPG::Image::destroy(image);

I'm not sure how this is supposed to work as the if condition will always be false and the destroy function will always be called immediately after creating the Image. Also this does not compile.

You sure you remembered to make "image" an RPG::Image* rather than an RPG::Image? While I don't have a compiler to validate with at the moment (or rather, I don't have one compatible with DynRPG), I'm pretty sure this should compile.
Also, the code was just for demonstrative purpose rather than being something which can actually be used. I was simply trying to make sure you didn't think you needed the map data structure to make the if statement work (which in this code example should be perpetually false, as you say).

author=McBick

std::map<std::string, RPG::Image*> myImage;
std::map<int, RPG::Image*> myText;
if(!myImage["winStats"])
    myImage["winStats"] = RPG::Image::create(320, 64);
if(!myImage["winParty"])
    myImage["winparty"] = RPG::Image::create(320, 64);
...
if(!myText["winStats"])
    myText["winStats"] = RPG::Image::create(160, 16);
...

I have no destroy functions as the code will never create multiples of the same Image objects.

I'm going to assume that the std::maps are global and that the ifs are within a callback function (I believe it should crash if this was all global). There's no need for the if statements at this point, since the keys can't exist at the point of the check, and as long as you're not using a callback which is called multiple times (which you shouldn't anyway for something meant to be allocated once like here). Apart from that, as mentioned, this should be fine.