KAZESUI'S PROFILE
Search
Filter
+++ DynRPG - The RM2k3 Plugin SDK +++
Judging by the documentation, it ought to be as simple as storing the ID's of the equipment before the class change, and the just setting the weapon ID's back to the stored ones right after the class change.
example for hero 1:
Highly depends on the sophistication needed for the line in sight. As you probably want the plugin to take the terrain into consideration (not to see through walls), it's a tad more complicated than just doing some very simple variables operations.
It's not very tricky, and I had actually planned on doing such a plugin (just slightly different), but alas, time hasn't exactly been on my side.
example for hero 1:
short weaponId = RPG::actors[1]->weaponId;
...
let class change happen
...
RPG::actors[1]->weaponId = weaponId;
author=bulmabriefs144
Nightowl, if you know how to write a plugin, this shouldn't be much more than making four variables and having hero X/Y match up to target X/Y, and switching something on if it does.
Highly depends on the sophistication needed for the line in sight. As you probably want the plugin to take the terrain into consideration (not to see through walls), it's a tad more complicated than just doing some very simple variables operations.
It's not very tricky, and I had actually planned on doing such a plugin (just slightly different), but alas, time hasn't exactly been on my side.
Coordinate less than zero or negative
@gadesx
Are you referring to "wrapping"? i.e. there are no edges on the map?
If so, then these errors, would probably stem from how screen relative coordinates work differently once these are into play. Basically then, there are no negative coordinates anymore, just like with tile coordinates.
This could quickly lead to bugs if you try to move pictures around by similar means as you would in a map without wrapping.
That's the thing though... it IS possible, though seemingly not very practical.
Are you referring to "wrapping"? i.e. there are no edges on the map?
If so, then these errors, would probably stem from how screen relative coordinates work differently once these are into play. Basically then, there are no negative coordinates anymore, just like with tile coordinates.
This could quickly lead to bugs if you try to move pictures around by similar means as you would in a map without wrapping.
author=LockeZ
You're wondering if it's possible to move the hero to a spot that doesn't exist? ...obviously the answer is no
That's the thing though... it IS possible, though seemingly not very practical.
Coordinate less than zero or negative
In theory, there is no problem in having negative coordinates. It just means that it's counting towards to other side of whatever axis is being used.
For rm2k3, tile coordinates are given from 0 to whatever size of the map you're using (minus one), so the entire map is always defined with positive numbers.
Technically, its perfectly possible to have minus coordinates as well, though it would be of limited use as it's not on the defined map anymore (as stated above).
Under normal conditions, this would mean that you're hero is gone, and that you can't move anymore though.
For screen relative coordinates however, minus coordinates are perfectly common. It just means that those coordinates are left &/or up of what you can currently see on the screen.
For rm2k3, tile coordinates are given from 0 to whatever size of the map you're using (minus one), so the entire map is always defined with positive numbers.
Technically, its perfectly possible to have minus coordinates as well, though it would be of limited use as it's not on the defined map anymore (as stated above).
Under normal conditions, this would mean that you're hero is gone, and that you can't move anymore though.
For screen relative coordinates however, minus coordinates are perfectly common. It just means that those coordinates are left &/or up of what you can currently see on the screen.
Pilar problems, Please help!
[DynRPG]Blending Modes
Update:
a bug was ironed out, which would make regular pictures not work properly under certain circumstances. Also, transparency is now also supported for the blend pictures
a bug was ironed out, which would make regular pictures not work properly under certain circumstances. Also, transparency is now also supported for the blend pictures
Minimap Plugin
Yep. It's reads the mapfile and chipset details to return the passability directions of all the tiles on the map, and generates an image based on this
End Event Process
No, not really. End Event Processing is a pretty good translation of what it does, which by no means limits itself to parallel events.
calling the command ends the rest of the event from being executed,
basically
means that variable 0001 will remain 1, as the second variable operation is never executed. This can be useful when combined with branches, if you don't want the rest of the event to be executed if certain conditions are met.
calling the command ends the rest of the event from being executed,
basically
var oper: 0001 set 1
end event processing
var oper: 0001 set 2
means that variable 0001 will remain 1, as the second variable operation is never executed. This can be useful when combined with branches, if you don't want the rest of the event to be executed if certain conditions are met.
+++ DynRPG - The RM2k3 Plugin SDK +++
I can't see anything in there which should cause a compilation error (compiles for me), but I know that the picture folders in my projects at the very least only use the singular form, meaning unless you have some other version of rpg maker or using an extra folder you'd have to write "Picture\White.png" to avoid a runtime error.
[RM2k3] Accessing Stats in Battle
author=bulmabriefs144No, this would crash. There is no format for this outside of looping over all the actors
But if I were to use RPG::Actor::defenseDiff += 30 (if I wanted the entire party to get a nice bonus), this would be the right format? That is, it wouldn't crash?
...I can't tell you how long I've spent wondering when to use Actor instead of actors. The latter is given examples,
()int zackHp = RPG::actors[1]->hp;
but not the former.
You use the Actor class if you want to keep track of a particular Actor without having to look up it's index all the time.
example:
RPG::Actor* alex = RPG::actors[5]
This is convenient, but not neccessary. You can totally disregard using the Actor class and just use actors instead for it to work, which is already an array of Actor.
By the way, this is more or less how you access in battle, if not to increase stats (to check them). Don't reassign the actor (RPG::Actor, RPG::actors to the left), reassign an int/string/whatever storing the value in a temporary (placing RPG::actors to the right). Then do something like this.RPG::variable[(paramParse commenting, or specific variable, or config system)] = zackhp;
it's hard to understand what advice you're trying to give here. There's no reason to take a detour of storing the value into a temporary variable when
RPG::variable[number] = RPG::hero[1]->hp
author=Travio
... and that was exactly what I was wondering, if there was a way to do it, and of course DynRPG presents a way to do exactly what I need. <3 Now, I'll just have to patch it in and do a little bit of coding work to see if it plays nicely on the bosses (and maybe, just maybe, do it on some of the random encounters as well, so you can't just Auto your way into beating them).
Just to make sure you've noticed this: From what I can see in the documentation, the stat diff only applies to the heroes, i.e. not monsters. So what you'll have to do is decrease the stat of the party members to give the illusion of the monsters growing stronger. I also assume that the changes you do there are of the permanent kind, so you'll have to keep track of how much you've changed it during a battle such to reset it to the original stats afterwards













