KAZESUI'S PROFILE

Doing Super Programming
on Super Computers
for Super Performance
The Curse of Cpt. Lovele...
Nautical-themed cephalopod-pirate-based action-shmup.

Search

Filter

Steam VX Ace Giveaway - Part 2 (Makerscore challenge) - Winner announced!

Currently
3161

Steam VX Ace Giveaway - Part 1 (Tagline challenge) - Winner announced

RMN: WIP
RMN: 1 silver for your doughnut
RMN: Rad Mutated Ninjas
RMN: It's all in the maker
Rho Mu Nu
RMN: A befuddeling place
RMN: Stay, Play, Review (and develop too)

Introduction to pixel movement in rm2k3

It does not have to strictly be the same size, but depending on what you do, you will face certain problems. For example, the hit collision is done by checking tiles corresponding the 4 corners of a tile. If you increase the size to height/width to be more than 16 pixels, you will not be able to properly track if there's a tile blocking the movement. To compensate for this, you would have to add another point (or more, depending on the increase in size) such that the largest distance between two points doing hit detection are never more than 16 pixels apart.

If you decrease the size too much, this should not give too much of a problem in terms of static terrain, but might give trouble in terms of detecting moving once, if the move sufficiently fast. If you have a very thin hit collision box, and you move quickly towards an event moving towards you, it's not unthinkable that you'll be able to walk right through each other. To handle this one, you'd probably have to calculate where you would be moving, and start calculating stuff "inbetween frames". A bit more difficult than the previous problem

Those would be the main 2 concerns that would pop up into my mind, could be some others which I'm overlooking at the moment though.

+++ DynRPG - The RM2k3 Plugin SDK +++

author=bulmabriefs144
which didn't seem to be explained anywhere in the many many DynRPG tutorials I read over and over. Having example codes for each would be a great help...)


The reason why there isn't is because the tutorials assume you know C++, which is a pretty reasonable assumption to make in this context. You're troubles isn't with DynRPG itself, but rather with the language.

As I told you long time ago, and Cherry now as well. You should take another look at some C++ tutorials (preferably ones noted as introductory ones), and then just go through it and make programs not related to DynRPG in the first run to get down the basics, in particular pointers and classes, which seems like something you keep struggling with.

' . ' and ' -> ' is actually the same thing, except that the latter dereferences a pointer before trying to access the member.
that is RPG::hero->x is equivalent with (*RPG::hero).x.
It's not a matter of one is for variables and other for methods (what you called commands), and this is the kind of stuff which is "fairly" basic C/C++ knowledge. If this sounds cryptic to you, then you should, as said, go read some tutorials. It's simply the best way rather than just trial and error. Experimenting like you do should come once you've aquired the basic concepts needed

[DynRPG] CMS Tools: Save Cleanup

author=bulmabriefs144
If a plugin stores C++ variables, rather than RPG variables, this is usually the case. Alot of stuff is fine, because it stores them only to use them immediately. Like running a process, would be fine, but not making global variables usually.


You seem to be confusing things. If the most recent upload of KazString is up to date, then it does not store anything into the .dynfiles. You would typically have to use the onSave callback to make use of those files (your own dynstore.txt is not a .dyn file, just to be sure that's clear).

It sounds to me like you believe global variables get stored into those files automatically. They don't. No variable gets stored into a file without explicitely being told to do so, as it would be horribly inefficient to store temporary data like that in a file every time you change them.

Most likely, the errors you think comes from removing the .dyn files comes from something else completely.

[RM2K3 DynRPG] Line of Sight plugin request

not really a namespace problem. RPG is the namespace, and that's it. What you don't know is the correct syntax.

int x = RPG::hero->x;
int y = RPG::map->events[id]->y;


This is should be about what you have to do to get the tile coordinates of either the hero or an event, with "id" being a variable with the eventID of interest stored in it.

[DynRPG] CMS Tools: Save Cleanup

The images containing the text drawn on screen is normally stored "in the plugin" itself while running, and thus any data which is therein is then lost as soon as you close the game.
So what the text plugin does is that it upon saving the game stores any text object given in the plugin into the savefile, so that these will reappear while loading the game.

Of course, this only affects you if you actually ever have any text object shown on the screen while trying to save the game. If not, then you won't notice any difference

[DynRPG] CMS Tools: Save Cleanup

I'd like to add that the Text Plugin makes use of the .dyn savefiles, and the DynVarStorage Plugin seems to be using them as well. I believe there were a few others as well, though I don't recall which.

So if anyone is using the text plugin to make your own custom menus where you can save, deleting the dyn savefile, will erase all the text in the menu upon trying to load the game again.

[RM2K3 DynRPG] Line of Sight plugin request

I've experimented with auto targetting for ABS systems in the past (pre dynrpg), and it's perfectly possible as well, probably even a bit easier with the line of sight plugin working its magic.

If you're capable of using pointers, you could keep track of how many enemies are within your range, and then switch between them using the shift button or so (which is what I did back then).
You could also just target the closest one (just a matter of doing computing distance between all enemies with line of sight), but that could probably get annoying as well if you have to enemies very close which it keeps alternating between. Eeny meeny mo could get quickly annoying unless you add a button to switch enemies (given that it locks on the enemy once chosen though)

[RM2K3 DynRPG] Line of Sight plugin request

author=bulmabriefs144
Oh, hell, nvm. I'll look at your source code, and figure out how to fix the variables in mine. Only, you don't have any source that I can see, so I still dunno how to compare to the x/y of the Hero.

If you didn't understand the tutorial, the source won't be of any help to you at all. There's not a single comparison being made towards any x/y of the hero or any of the events.

Watching through impassable terrain is still possible in the way I described above.
Also, there's a larger risk of making errors with these zones of yours. Rather than wiping, you should just copy a map to test it out whether it works out, and if not, just delete the map, and keep working on the old one. Also, since the only thing happening upon being in the line of sight is a switch being turned on, you're still able to check if you're in some kind of safe zone.

Anyway, the probable reason why your code isn't working is cuz you check for
EventY >= EventLosX1
rather than
EventY >= EventLosY1
(3rd condition in your if statements)
didnt look too through the rest though, so dunno if you have more bugs in there

edit: You edit your posts quite frequently. And yes, I find it good that you're trying to complete it, since you've first started it anyway. It's the right attitude towards learning something, which is always a good thing to have.

Once you're done with it though, you'll still have to face that it is a rather tedious method to use, despite the effort having been put into making it. Also, rather than accepting my code, you could try to take another look at the tutorial, or google similar stuff online to get it explained by people who are better at explaining than me.
I cannot do anything but to really recommend learning a few mathematical stuff, especially trigonometry, for anyone venturing down the more technical road of game making.