Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsKAZESUI'S PROFILE
Close
Search
Filter
All
Game Pages
User Statuses
Math Problem
Actually, you can do that quite simply by using screen related coordinates instead of tile ones. When you take screen related x coordinate of the hero, and its less than 0, you're heading to the left, and if it's above 320 to the right. Then you just pan the screen and you keep using screen related coordinates
Math Problem
then offsets should be sufficient.
When you're the top left point, you'd take the hero coordinates and subtract them with an "offset x" and an "offset y" which are both 0 at the top left point. when you move one "point" to the right, you update the "offset x" variable with +20, so that it now subtracts 20 from the hero x coordinate each time you're trying to get the coordinates.
When you're the top left point, you'd take the hero coordinates and subtract them with an "offset x" and an "offset y" which are both 0 at the top left point. when you move one "point" to the right, you update the "offset x" variable with +20, so that it now subtracts 20 from the hero x coordinate each time you're trying to get the coordinates.
Math Problem
In that case it's not so weird that you find it hard to explain, because unless you somehow invent negative tile coordinates in the maker, the mod variable will always be 0 or higher.
I'm also still not sure what you're grid is like, maybe you could show pictures/drawings there as well?
I'm also still not sure what you're grid is like, maybe you could show pictures/drawings there as well?
Math Problem
if as you say variable 0001 = 41 and variable 0002 = 27 then you will indeed end up with grid x = 3 and grid y = 2, so the error is likely to lie elsewhere.
Care to explain more precisely what you're trying to do btw? Like where does the numbers 41 and 27 come from for example. And what's the point of the "Mod" variables?
Care to explain more precisely what you're trying to do btw? Like where does the numbers 41 and 27 come from for example. And what's the point of the "Mod" variables?
Static Events [2K3]
not entirely sure, but for the "graphically ornamental" collection of events, you should remove everything on the first page (i.e. dealing with collision detection) and just keep the move event command which turns phasing off, and the variable ID + 1 and call for the next event.
In the sample project the upper row of the big objects, which is "above hero", should be similar, since they weren't supposed to cause collisions.
In the sample project the upper row of the big objects, which is "above hero", should be similar, since they weren't supposed to cause collisions.
Static Events [2K3]
You do remember to set the pointer values back to 21 and 41 before calling the reset event location page, right? If not, then it's probably just some other small mistake which is hard to find just by guessing.
and no, with the current set up, you can't just check if the obstacle switch is off, because it's the move with phasing on which allows us to find out if there's an obstacle in the way. You can't include the rest of the bit in that page either, cause you need to a 0.0 wait for the coordinates of the event to update to the tile they're heading for. And that's the point, we're checking the terrain ID of where the events are "heading".
Of course, there are alternative ways to go about it, where you could check for obstacles first by manually adding a value to the coordinates of each event to the next one and check it this way before assigning a move command. It would probably have been slightly more complicated though, but there are definatly other ways to go about it, while still using similar principles
and no, with the current set up, you can't just check if the obstacle switch is off, because it's the move with phasing on which allows us to find out if there's an obstacle in the way. You can't include the rest of the bit in that page either, cause you need to a 0.0 wait for the coordinates of the event to update to the tile they're heading for. And that's the point, we're checking the terrain ID of where the events are "heading".
Of course, there are alternative ways to go about it, where you could check for obstacles first by manually adding a value to the coordinates of each event to the next one and check it this way before assigning a move command. It would probably have been slightly more complicated though, but there are definatly other ways to go about it, while still using similar principles
Static Events [2K3]
Yeah, they are used as pointers. If you check the variables you'll see that variable 0021 is called ObjectX, and 0022 is called ObjectX and so on. So by setting the variable X pointer to 21, I can directly access variable 0021 by using the "index" functions in the variable operations menu. add 1 to the X pointer variable normally, and I can now directly access variable 0022. These are all needed so that the position of the object can be restored if it happens to "crash" into an obstacle upon being pushed
If you've looked closely, you'll see that the same values are used for moving both of the set of events (i.e. the big objects) have X Pointer set to 21 and the Y one to 41. This means if you push one stone and then go and push the other, the coordinates stored, will be overwritten, while if you look in the teleport event, the X pointer is first set to 21 and later to 31, which is because you need to store the coordinates of all events at any time to be able to put them back to their previous location when re-entering the map.
This means that for your 7 objects of 12 events each will need to make space for 84 variables for X coordinates, and 84 for Y coordinates.
A nice thing with pointers though, is that you don't need to actually extend the array in the editor to use more variables. If you only have 100 variables in your variable array in the editor, you could still set a variable to 101 and use it as a pointer to store a number in variable 0101. So for tidyness, you could choose to use variables outside of your array since you'll need as many as 168 variables for coordinates alone.
If you've looked closely, you'll see that the same values are used for moving both of the set of events (i.e. the big objects) have X Pointer set to 21 and the Y one to 41. This means if you push one stone and then go and push the other, the coordinates stored, will be overwritten, while if you look in the teleport event, the X pointer is first set to 21 and later to 31, which is because you need to store the coordinates of all events at any time to be able to put them back to their previous location when re-entering the map.
This means that for your 7 objects of 12 events each will need to make space for 84 variables for X coordinates, and 84 for Y coordinates.
A nice thing with pointers though, is that you don't need to actually extend the array in the editor to use more variables. If you only have 100 variables in your variable array in the editor, you could still set a variable to 101 and use it as a pointer to store a number in variable 0101. So for tidyness, you could choose to use variables outside of your array since you'll need as many as 168 variables for coordinates alone.
Befuddle Quest 2: Charmed & Dangerous!
You beat it like this link
Static Events [2K3]
Does it have the same restrictions as the one of the char expand for rm2k? If so, then it would probably still be of limited use (as long as I've understood the restrictions correctly).
Static Events [2K3]
In the sample project, it basically works like this:
1. We start by storing the current coordinates before moving the events.
2. We assign all events a move command with phasing on
3. We do a 0.0 wait because this is how long it takes for the event coordinates to update to the tile they're heading (eventhough it doesn't look like they have moved yet).
4. We check the terrain ID at the same position as all the events. If any of them is on a terrain with ID 3 or higher, it triggers a collision and activates a switch.
5. If the collision switch is on, we call on the page which changes the event location back to the coordinates we got before moving the events, if not, we do nothing and the events will move normally.
So basically, the reset position only resets back the position before you tried to push it. This is because we need it to be phasing to allow it to move onto terrain which is an obstacle to be able to get it's terrain ID (at least for this method, there are alternative means to go about it as well).
So when you leave the map and come back, the objects will be restored to their original positions, like regular events.
writing some code to store all the coordinates and set the objects back to the locations they were when you left the map wouldn't be so hard at this point though.
it's just a matter of calling the page which store event coordinates, and change the starting value for the coordinate pointers, and then use the same starting values for the pointers and call the reset position page of the events when you go back to the map.
And yeah, if moving them happens by simply bumping into them, the changing it to "on collision with hero" should be all you need to change on that front.
here's a slight modification of the sample
1. We start by storing the current coordinates before moving the events.
2. We assign all events a move command with phasing on
3. We do a 0.0 wait because this is how long it takes for the event coordinates to update to the tile they're heading (eventhough it doesn't look like they have moved yet).
4. We check the terrain ID at the same position as all the events. If any of them is on a terrain with ID 3 or higher, it triggers a collision and activates a switch.
5. If the collision switch is on, we call on the page which changes the event location back to the coordinates we got before moving the events, if not, we do nothing and the events will move normally.
So basically, the reset position only resets back the position before you tried to push it. This is because we need it to be phasing to allow it to move onto terrain which is an obstacle to be able to get it's terrain ID (at least for this method, there are alternative means to go about it as well).
So when you leave the map and come back, the objects will be restored to their original positions, like regular events.
writing some code to store all the coordinates and set the objects back to the locations they were when you left the map wouldn't be so hard at this point though.
it's just a matter of calling the page which store event coordinates, and change the starting value for the coordinate pointers, and then use the same starting values for the pointers and call the reset position page of the events when you go back to the map.
And yeah, if moving them happens by simply bumping into them, the changing it to "on collision with hero" should be all you need to change on that front.
here's a slight modification of the sample
Games - Tester
Games - Other
