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
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
STATIC EVENTS [2K3]
Posts
King of Games
View playlists
CloseOk so I am coding a puzzle where you move big objects, comprised of multiple events. (12 for each object) This is easy enough, but I am trying to concoct a way to make it so the events moved (with move event command) stay on that specified tile without the tedious method of assigning x and y vars to every event (each object is 12 events and there are 7 of them) and then change event location for every event to its assigned variables.
I've thought of a couple ideas like maybe trying to use cherry's big charaset patch, but as far as I know that only works for 2k. Pictures could potentially work but appear above hero layer. (I've thought of temporarily converting the hero to picture as well but it seems gratuitous) Panos wouldn't make sense. I wish I could use a memorize placement command for events other than the hero.
Anyone wants to kick theories about this?
I've thought of a couple ideas like maybe trying to use cherry's big charaset patch, but as far as I know that only works for 2k. Pictures could potentially work but appear above hero layer. (I've thought of temporarily converting the hero to picture as well but it seems gratuitous) Panos wouldn't make sense. I wish I could use a memorize placement command for events other than the hero.
Anyone wants to kick theories about this?
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
Use events for the southern row of tiles, and make all the other rows be a picture? Then if the hero is standing to the south of the object his head will be above it. That would be more complex than just using a picture, but simpler than using 12 events (maybe).
I thought there was a version of the big char set patch that worked with RM2003. Or you could convert your game to RM20XX, which I think also allows it.
I thought there was a version of the big char set patch that worked with RM2003. Or you could convert your game to RM20XX, which I think also allows it.
Kazesui
5797
There is one way to do this in a reasonable way using events for all of the graphic,
utilizing a kind of recursive event calling along with the use of pointers.
This means it'll take some time to set up the first big object, but the 6 others would go rather fast.
The gist of it, is that you let the big objects consist of all 12 events, which you let have a number of pages, with the top one dealing with interaction from the player. Important here is that the event ID's all form a consecutive sequence.
For example, let each event set "this event's" coordinates into wherever two pointer variables are pointing (one for x and one for y).
We'll call this page by setting a variable Event ID ptr to the first ID of the events in the big object, and a variable Event page Ptr to 1, since we want to access page number 1, when the use the event call by variables function.
The event page executes and stores the coordinates, we increase the event ID ptr by 1 and make the same event call. In the event with the highest event ID, we remove the event call to mark the end of the recursive chain.
And in the end, we now get a way to store the coordinates of every event in the big object easily, which is easy to copy paste to make new big objects to do the same, since the code is fairly generic. (just have to mind removing the event call for the one with the highest ID).
Using the same method, you could easily use change event location to replace all events in the big object easily by a similar call, as well as use move with phasing as well as terrain ID to determine if there's about to come an obstacle under any of the events.
here's a sample which shows it in practice: sample
(might help make more sense of the stuff I've mentioned so far)
utilizing a kind of recursive event calling along with the use of pointers.
This means it'll take some time to set up the first big object, but the 6 others would go rather fast.
The gist of it, is that you let the big objects consist of all 12 events, which you let have a number of pages, with the top one dealing with interaction from the player. Important here is that the event ID's all form a consecutive sequence.
For example, let each event set "this event's" coordinates into wherever two pointer variables are pointing (one for x and one for y).
We'll call this page by setting a variable Event ID ptr to the first ID of the events in the big object, and a variable Event page Ptr to 1, since we want to access page number 1, when the use the event call by variables function.
The event page executes and stores the coordinates, we increase the event ID ptr by 1 and make the same event call. In the event with the highest event ID, we remove the event call to mark the end of the recursive chain.
And in the end, we now get a way to store the coordinates of every event in the big object easily, which is easy to copy paste to make new big objects to do the same, since the code is fairly generic. (just have to mind removing the event call for the one with the highest ID).
Using the same method, you could easily use change event location to replace all events in the big object easily by a similar call, as well as use move with phasing as well as terrain ID to determine if there's about to come an obstacle under any of the events.
here's a sample which shows it in practice: sample
(might help make more sense of the stuff I've mentioned so far)
Hmm, this is very interesting. The project def helps me visualize the idea. So basically, when teleporting out of the map and then back on to it, you would have to move event location to the x and y pointer vars, while constantly changing them to the previously recorded coord vars? The reset on teleport part confuses me. (resetting to the location that the hero designated, not where the objects were originally placed.)
Also the trigger would be just arrow keys instead of action key but that's just setting the top page to touched by hero.
Also the trigger would be just arrow keys instead of action key but that's just setting the top page to touched by hero.
Kazesui
5797
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
In a few days I probably be able to provide you something like a CharExpand patch for RM2k3, using the DynRPG SDK which I'm currently developing.
Now it's up to you whether you want to wait for that or not.
Now it's up to you whether you want to wait for that or not.
Kazesui
5797
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).
Well, if a picture would work (as you said at the beginning), this would definitely work too for you. If you need collision checking for all tiles occupied by the big event (instead of only the middle bottom one), we might also find a solution with the new system, since we could create empty events somewhere on the map and then have them automatically moved to the right position.
Hmm, well Kazesui's method seems to work, which is a genius setup btw. I've never used the old big chara patch, so I don't know the restrictions or where the 'real' event is.
I'll try implementing this demo method, and if it doesn't work out the big chara patch would probably be ready by then and I can use as backup. Depending on the passability options, (top row above, bottom row below, middle rows same level) there wouldn't be a need to map events following the big char event I don't think. Or maybe it would be necessary to use a combo of both methods.
Btw I'm using Aten's David patch, which just replaces the rpg_rt, assuming this new big chara patch does the same thing, it would override those modifications.
I'll try implementing this demo method, and if it doesn't work out the big chara patch would probably be ready by then and I can use as backup. Depending on the passability options, (top row above, bottom row below, middle rows same level) there wouldn't be a need to map events following the big char event I don't think. Or maybe it would be necessary to use a combo of both methods.
Btw I'm using Aten's David patch, which just replaces the rpg_rt, assuming this new big chara patch does the same thing, it would override those modifications.
Aten's David patch, as far as I know, uses a normal RPG_RT where he has just used my Hyper Patcher 2 to increase the picture limit, so this is not going to be a problem. (The picture limit is 2000 with the new patch anyway.)
Alright I tried to implement the demo method. After copying the code and reading over the explanations I get the concept now, and understand why it works. I do have one question though:
In the 'Move Big Objects' event, you set the X pointer to 21 and Y pointer to 41. Where do these values come from?
Basically what's happening is the multi event big object is 'disappearing' after the terrain check turns on the obstacle switch.
(Oh, I see, they point to the value of that var. But those vars weren't set/used before, right?)
In the 'Move Big Objects' event, you set the X pointer to 21 and Y pointer to 41. Where do these values come from?
Basically what's happening is the multi event big object is 'disappearing' after the terrain check turns on the obstacle switch.
(Oh, I see, they point to the value of that var. But those vars weren't set/used before, right?)
Kazesui
5797
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.
Hmm that is interesting. My problem is the Object coords aren't getting recorded so when the pointer references them, it reads the value as 0. I'm trying to figure out why this is, since I've checked the code over and it seems to match completely.
Here is another question though, could I simply make a branch on the move event page (p.4) to check if the obstacle switch is off before moving, and then only record the coords at teleports?
Here is another question though, could I simply make a branch on the move event page (p.4) to check if the obstacle switch is off before moving, and then only record the coords at teleports?
Kazesui
5797
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
Oh ok, yeah the problem was incorrect variable functions because sometimes the text looks the same in the editor even though it is a separate function. Like value/reference show as value in the actual script.
Anyways it works now. However, there is one minor thing, the lowest row of objects is set to below hero because it doesn't take up the entire tile. When the big object hits the collision switch and you try to move it again, the hero gets stuck on that row and can't move.
This doesn't happen when the bottom row is set to same layer as hero. Any idea why this happens?
Anyways it works now. However, there is one minor thing, the lowest row of objects is set to below hero because it doesn't take up the entire tile. When the big object hits the collision switch and you try to move it again, the hero gets stuck on that row and can't move.
This doesn't happen when the bottom row is set to same layer as hero. Any idea why this happens?
Kazesui
5797
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.
I got this working perfectly man thanks for the help.
Hypothetically how complicated would it be to prevent 2 big objects from colliding with each other? (out of the 6 big objects, there is only one instance of overlap, so I might just design around it, especially since each big object is designated to move only within its terrain type.)It would be easy if 2nd layer/events could have terrains set to them. Prevent event overlap makes the objects unmovable.
Also, Cherry, lemme know when the big chara patch for 2k3 comes out, it will be useful for the future.
Hypothetically how complicated would it be to prevent 2 big objects from colliding with each other? (out of the 6 big objects, there is only one instance of overlap, so I might just design around it, especially since each big object is designated to move only within its terrain type.)It would be easy if 2nd layer/events could have terrains set to them. Prevent event overlap makes the objects unmovable.
Also, Cherry, lemme know when the big chara patch for 2k3 comes out, it will be useful for the future.
Kazesui
5797
Ah, I guess I might have forgotten to adress that issue. It shouldn't be very hard to solve though. To do it, add a "get event ID" right after the "get terrain ID", and then check if the value is = 0, which means no events is in the way. If not, just switch the "Obstacle in the way" switch on and end event processing.
If you use events for graphics or whatnot which should be passable, you ought to make the event ID's of all big obstacles as well as any other impassable obstacle sequential, so that you can check for all of them with two branches, i.e. if event ID is higher than the lowest event ID and less than the highest.
If you use events for graphics or whatnot which should be passable, you ought to make the event ID's of all big obstacles as well as any other impassable obstacle sequential, so that you can check for all of them with two branches, i.e. if event ID is higher than the lowest event ID and less than the highest.
That theory makes sense, but in order for it to work correctly, wouldn't I have to add 1 to the temp coords around the borders of the object so it doesn't check the ID of itself?
Kazesui
5797
I should probably have tried to add the modification. So much stuff which is easy to forget. Yes, you're completely right, and that makes the whole deal slightly more difficult than I originally thought.
What I've used to do up to now is to move events who are checking for other events on their ID to somewhere (usually coordinates 0,0) check for event ID's and then afterwards back.
The event needs to be removed before it can check for Event ID's otherwise you'd risk it overlapping with an event with lower event ID, which it won't see cuz it only returns the highest event ID on the selected tile.
just moving the event, checking for event ID's and moving it right back will not be visible for the player as long as there is no wait's in between.
Doing this, you'll have to reset the event location to the position stored in coordinate variables set before and then you'll need to move the events again... I think. I'm not sure whether the events will remember the previously issued move event after having been moved with change event location.
That's the theory at least, might very well be more details I've forgotten in there though
What I've used to do up to now is to move events who are checking for other events on their ID to somewhere (usually coordinates 0,0) check for event ID's and then afterwards back.
The event needs to be removed before it can check for Event ID's otherwise you'd risk it overlapping with an event with lower event ID, which it won't see cuz it only returns the highest event ID on the selected tile.
just moving the event, checking for event ID's and moving it right back will not be visible for the player as long as there is no wait's in between.
Doing this, you'll have to reset the event location to the position stored in coordinate variables set before and then you'll need to move the events again... I think. I'm not sure whether the events will remember the previously issued move event after having been moved with change event location.
That's the theory at least, might very well be more details I've forgotten in there though
