KAZESUI'S PROFILE

@bulma
Sorry, but you're post shows massive lack of understanding of how stuff works.
To suggest that loops should be avoided is stupid, inefficient, tedious and even more bug prone.

Your argument about loops being bad for old computers is downright bullshit. If you don't terminate a loop after you're done with it, or loop without ever stopping it, then yes, of course it's bad. But that's not a fault of the loop, that's a fault of the coder being an idiot.

Good code saves space, but the space saved by conserving rm2k3 variables is utterly trivial. Even if you set the variable array to 9999 you're not even using a single Mega Byte... which pretty much means it's going to have no impact on performance whatsoever, and any other increase in size as a result of this is also totally trivial, so exactly WHY is it so important to be saving variables, when adding a few can make life a lot easier, make stuff more readable, or even add more flexibility to your code, which is argueable far far more important for the code.

As it stands, pointers in combination with loops allow for much more flexibility, which could only be compensated by massive use of branches, which is way way more inefficient. THIS hurts the usage of old computers.

Also, yes, typically, programming languages tell you to avoid using labels, which is a good advice for novices. However, this isn't necessarily worth much if you don't really understand WHY they can end up being bad. Just having read that they are more prone to cause spaghetti code just doesn't cut it.
The problem with labels is that they can make code more unreadable, or even be totally confusing if you abuse them.

However, rm2k3 does not have proper control structures, and if done right, like shown in my examples, or even in the example of Trujin, which isn't bad either, it's not that much spaghetti. It retains readability, sometimes being even more so than whatever alternative you might be facing by trying to just avoid labels, because you don't understand the concept.

Another thing, Common events does not speed up code, it actually slows it down!
in terms of performance, you don't want a million common event calls. You do this for the sake of reuseability, easier maintenance, less bug prone and for keeping it more readable. Also, it can cut down the size of the set of event instruction, which is actually linked to the performance in terms of memory usage... however if you experience a considerable boost because of this, its most likely because you're doing something horribly wrong in the first place.
You should of course use them, but not for performance, and not just for the sake of using them either. If the code isn't reused at any time other than once in that particular event, it's most of the time better to just keep that code there, rather than to move it out to a common event.

And finally, your last example... Having it run as a parallel process just won't cut it for more demanding real time systems.
if you need to do 60 iterations in a loop, it would take A FULL SECOND for the loop to finish. That's just not acceptable. If you're doing lot of hit collision checks by this kind of loop, you'd get all kind of faulty data, because what happens on the screen will never be checked in time in the actual event. Not to speak of how immensely unecessary it is to have an event which does absolutely nothing except cost cpu time be running. If anything, you'd want to only let that common event be active when a switch is set ON.

All in all, you're primarily listing up bad advice, rather than good ones.

You are of course very right, there's a lot of personal flavour going here, this having been written more in my flavour of course. That said, my looping style isn't just based on preference, it's actually slightly more efficient than yours as well (in rm2k3 that is, which is an important distinction here).
In rm2k3 it costs one instruction cycle less. The bigger the content of the loop, the more negligible that one instruction cycle becomes, but for tiny loops with lots of iterations, it can become rather noticeable. Of course, this will rarily be a problem unless you're working on some heavy system (a moderately complex real time system, like an advanced ABS for example).

Among the goals of my little article/tutorial here was to combine some coding style with efficiency, not so much about merits of different styles. If I was focusing more on how to code to keep it readable, clean and organized, I probably would have drawn some comparisons to show how it can be done differently yet still good, which would make quite some sense, considering I used to use your looping approach before as well, before switching to my current style.

Storing a string like this into another string in the dll isn't that hard. The problem arises when you want to display this string somehow. The easiest solution would probably to have an extra hero as temporary string storage, so that you can access it by \n. "NameOfVariable" is by this probably better changed to ID of the hero used as a string storage.

(Basically, works like a glorified cout. It should use the message
box, (since @text seemed to need a picture, which disqualified it from effective use because battles don't allow pictures)

There's a patch for adding picture support in battles.

I'm not entirely sure what you want to do here. you call it "SetInt" which would imply you want to change a given value (which is at odds with you saying "draw from"). It sounds like you want to store an entire object of type condition/item/whatever, but that only makes sense for further work on it in the dll, otherwise you'd rather extract the relevant values you're interested in.

Given how one of the tutorial patches basically draws icons above the actors showing their different Conditions, this should be fairly possible to do. Again, you'll need a way to read the answer though, requiring you to choose a switch id or something to read the return value.

If the SkillNumbers are referring to ID's of actual skills, this can prove tricky since most data of the skills have not yet implemented into the SDK. Alternatively, you might be able to somehow swap the current action of an actor with a "random one", but I don't know how to do that yet, and it would probably require quite a bit of time in terms of playing around to figure it out, if at all possible.

Again, I don't know exactly. It should be all means be perfectly possible, but the effort and approach required is questionable, and these kind of stuff tend to take a lot longer than anticipated once started on, so yeah..

...Something like RPG::Monster or RPG::Actor getName (), then RPG::getItemName, getSkillName, and getConditionName too. But stored in some kind of container, that can be used later.

This is essentially the same as the first one

I was assuming you had installed the Code::Blocks version which came with MinGW (the almost 100 mb big binary file). I don't recall there being any separate installation parts using this, and this would give you a MinGW folder inside your Code::Blocks folder (probably located under Program Files). If you merely swap the existing folder there with the one in the link from my previous post, that should magically fix your problems (no additional installation or anything, just a matter of cut and paste).

Well, if you use coding terminology without knowing what it means, then obviously you're going to get different answers than what you expect.

OnComment itself is a callback which is triggered whenever a comment line is "executed" in the maker (given that it has the dynrpg patch). Whatever effect you get out of using a plugin and comment commands is not a callback, neither is getMonsterID for that sake (Does it even exist? Closest thing I can see in the documentation is the DatabaseId member of the Monster Class).
Whatever is supposed to happen once a comment is read is up to the developer of the plugin to decide, so of course you won't find details on this on the documentation page.

getItemName is a "function", which you can only access directly by actually coding a plugin in C++. If you want to use it, the minimum requirement is that you're able to write a few lines of code in C++ and manage to compile it properly into a dll. If you can do that, then it shouldn't be too hard too hard to create a plugin with custom a comment command yourself which pretty much does what you describe.

Looking at some C++ source codes from existing plugins can probably help you in your quest here, in terms of how to utilize the onComment callback to make comment commands.