KAZESUI'S PROFILE

Not really :x
Youtube pretty much raped the video quality, but the interesting thing here is not to be able to spot the heat source and sinks themselves, but rather how they emit and absorb heat around themselves. You can see a kind of black surrounding the black blocks, which gets bigger when both black blocks are close, making the area surrounding them colder, especially when the red heat source is further away :x

One scenario where this could be applicable could of course be some hero emitting heat, and being able to use this to melt ice and whatever, but also needing to seek warmth to not freeze to death. I'm also thinking about a 2 player board game where you'd try to make the board as cold or warm as possible by placing sinks and sources on the board (one player would be for warm, the other for cold). No idea how well this will work in practice though yet.

It will be @updated, I'm just a tad busy at the moment, and the code slightly messy for fixing quite a few of the things.
As for the bug you found, it should already have been written in the readme, that the first slot in the database won't work... anything beyond should probably have worked, but I'm not all to surprised to see trouble there to be honest.

The reason for this is... some mysterious shit in rm2k3 simply. For some reason, sometimes, where the name of the tileset as well as it database name just gets messed up for some arbitrary reason. I was always able to at least read the tileset filename from 2nd slot and upwards, and simply assumed it was okay, but there might just be bugs there still, and I cannot guarantee I will be able to fix them.
At best, I might include a way to manually load the tileset file by specifying the name yourself.

As for the second bug, will have to look into it. It does sound strange indeed.

Yes, the patch mentioned is for rm2k only... and even if it DID work, it probably would have no effect with this plugin, since I'm loading the charsets from the project directly and treating them on the assumption that they are formatted correctly in accordance with rm2k3 style.

And now I see what you mean. Most likely, I will add in a manual scaling option for sprites/chars when I get time ( along with manual offset changing ). That ought to to solve the problems I suppose.

@not erasing images, this is a known issue, and some of it will get fixed (i.e. when using erase event). Dealing with erasing images for otherwise inactive events (due to switch manipulation) is probably going to prove more difficult though.
For those I'll simply have to suggest having a lower page which is just empty.

another alternative is simply to send the events somewhere unreachable to make them disappear. I haven't tried this myself yet, so I'm not entirely sure if this will cause a crash of any kind, but moving an event to negative coordinates out to be an effective way of "erasing" the events for the time being.

@transparency, it's not weird for you to have trouble with this since transparency was never implemented. Semi transparency might be something I won't be implementing for a while (i.e. very low in terms of priority on the growing todo list).

@bmp, nope, it only reads png. On that note, why would you want to use bmp to begin with?

@disappearence, hmm, I guess it's simply going out of the drawing bounds I've set up. I guess I can make this customizable. It's something which is in there to ensure the performance, since there's likely to be a lot of stuff which does not need rendering. This is probably the reason why people have been able to put as much as 2000 events onto a map without it lagging. It'll go on my todo list as well.

@tile substitution, it does not work and will not work, since I don't have access to how the map is stored internally in the engine. I get by, by loading the chipset and the actual map file, and then creating an image buffer where I redraw the entire map as described in the map file. As such, any real time changes to the map itself is not possible. Or well, that is if you want the properties that comes along with a tile change. The graphic is fairly easy to change, and there is already some unfinished code in the source for the sake of implementing this, just know that any terrain id or passability setting will not change along with the graphic.

@add_sprite not working, are you sure you're linking the sprite to the "correct" event id?

@is_mode7_rendering, will check that,

@large chipset tile sprites, uh.. how large?

@parallax, if you want a automatically scrolling panorama, you will for now have to do this with pictures. Disable the background, and put use pictures beneath the mode 7 rendering picture to simulate your own background. The SDK does not give access to the panorama image and it's properties, so including it somehow in the plugin is pretty much out of the question.

@change sprite crash, weird. This is a bug, and I think I know what the cause is. Will look into it and fix it once I get the time to.

@static sprite rotation, The SDK does not provide enough data on event settings that I can find if it's set to "fixed graphic". As such, the easiest way of doing this right now would be to either edit the charset such that all angles show the same sprite, or to use @add_sprite.

@disappearing event, only way to do that at the moment is to remove map wrapping. This is a problem caused by how rm2k3 don't like negative screen coordinates when the map is wrapped, and turn it to positive ones instead (meaning your map gets sent waaaaaaaaaaay over to the right side instead).
I haven't found a good solution to this problem yet, unfortunately.

@refresh, ... it should refresh immediately, unless the command is somehow causing lag.

@bg crash, probably one of the old known bugs with DynRPG (the old version). add an extra comma after the filename should fix this. This is something that applies to every command in every plugin which ends with a text parameter. This is fixed in the new version, but..

Yeah, I'm familiar with the problem you are talking about, but not the cause.
You could try simply creating another new project, and then add plugins one by one, to see if and when the problem happens. This is likely to be a bug with the new DynRPG version, and I have had it happen while trying to create plugins with the updated SDK as well.
Typically, I was able to get around it by making a new project, patching this clean project with DynRPG, and then taking it from there, and once it was fixed, I didn't get the error again. But as said, I'm not sure what causes it.

Personally, I'm not sure I would say coding a custom battle system from scratch would be much easier Ruby than it would be to just event it. Of course, this is if you'd actually need something new, where you cannot just modify the old to accustom whatever system the person has in mind. Coding it in ruby would probably be a bit less tedious though.

I do wonder if you really are up for the task though, especially given the "not good with pictures" statement of yours. It's almost certain that you will want to use pictures for your system, a lot even.
Either way, assuming you're going for a menu driven system still, you could start by looking up tutorials on doing custom menus first, as they're going to be an important part of your battle system
here's one on a general menu:
CMS tutorial
and here's one on an item sub menu
Item menu tutorial

For the latter, and many many other aspects of a battle system, you will probably want to know a lot about pointers, so if you don't already know too much about them, you should look them up as well.
Pointer Tutorial

Since you've already aquired DynRPG, the DynText Plugin is probably going to do you a lot of good for a battle system, as it will allow you to show text for your menus, as well as numbers for damage and whatnot.

Something worth considering as well would be DynPEC, as it allows you to turn pictures into spritesheets, which you can then along with comment commands use for conveninet animation of the sprites. Will be in particular good for bigger enemies, as it would be easier to work with pictures than event graphics to deal with those.

If you can handle all of the tutorials above, I also have a project you might want to have a look at. It's a project containing a pretty old wip ffx-esque cbs intended for a tutorial. Only thing is that it was never finished, and as such, there's not a lot of description going on.
It is somewhat simple (for a cbs anyway), so it could be worth something in terms of reverse engineering. Only if you're interested of course.
I suppose that would also give a slight idea of what kind of work would go into a cbs.