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)
[RMVX ACE] LARGE EVENTS & COLLISION DETECTION
Posts
Pages:
1
StormCrow
2877
StormCrow
View playlists
CloseSo, the "Event Touch" trigger does not function for large events that "know" they're more than one tile big. I'm using GubiD's Large Events System for Ace. The script works in most regards: it increases the number of tiles an event will respond to for Player Touch and Action Button triggers, but Event Touch will never trigger. This is frustrating because I am making a game where you are chased by big monsters. If you stand still, the event can run into you until the cows come home and not trigger. If you walk into it, it triggers. I checked another project to make sure that Event Touch works in general (it does), and I removed the comment that "told" the event how large it was, and it was able to track me down and kill me just fine (as long as I stood still: Yanfly's Event Chase Player script is slightly wonky). But that meant it was behaving as a 1x1 Tile event instead of a 3x3 tile event in terms of running into stuff (so you couldn't, for instance, go into a narrow space to escape from it).
Anyway, I can work around this, but if anyone has any experience with getting large events to have proper collision detection in VX Ace.
(I'm getting the large monster graphics from Pioneer Valley games character sets. Some of the monsters are freaking insanely huge.)
Anyway, I can work around this, but if anyone has any experience with getting large events to have proper collision detection in VX Ace.
(I'm getting the large monster graphics from Pioneer Valley games character sets. Some of the monsters are freaking insanely huge.)
Stop tiling, and learning how to zone. Also, too many people in VX onward seem completely reliant on scripting and do not understand the fundamentals. LEARN THE FUNDAMENTALS. Your engine can already do alot of stuff. That's why I still use 2k3 even though most people moved on.
1. Go to variables, and set to parallel process or a common event the following variable. PlayerX, Set Hero X. Then PlayerY, Set Hero Y. Got it? Good.
2. Now, make the following. If PlayerX > (number), Player X < (number). Look at the map, and you'll figure out how it works. X increases as you go right (2k3 at least).
3. Don't use else statements. Trust me, it will become a mess. Instead it should look like this:
<> If PlayerX > (number2)
(outside the second number)
End
<> If PlayerX < (number1)
(outside the first number)
End
(Put these first so they check before the others)
<> If PlayerX > (number1)
<> If PlayerX < (number2)
(these are nested)
End
End
4. With me so far? Well, to make a box is hard, because the system doesn't like to handle a ton of conditions stacked inside each other. So, what we're gonna do it cut and paste, move the above inside a common event. Now, add a switch that shuts on and off, and an end event processing, so it will exit. It now looks like this:
Common Event: Check for Zone (Make this first, and I'll explain later)
<> Call Common Event: CheckForX
<> Call Common Event: CheckForY
<> If WithinX is ON
<> If WithinY is ON
<> Switch WithinZone, ON
(both must be on to be in the zone)
Else
<> Switch WithinZone, OFF
Else
<> Switch WithinZone, OFF
End
<> End Event Processing
Common Event: CheckForX
<> If PlayerX > (number2)
(outside the second number)
<> Switch WithinX, OFF
End
<> If PlayerX < (number1)
(outside the first number)
<> Switch WithinX, OFF
End
(Put these first so they check before the others)
<> If PlayerX > (number1)
<> If PlayerX < (number2)
(these are nested)
<> Switch WithinX, ON
End
End
<>End Event Processing
5. Repeat a similar process for CheckForY. You should have a general region where it's possible to enter without getting caught, but it you hit an area where both are wrong you get caught.
6. Btw, zoning can get complicated. You can use variables instead of values, and you can do stuff like line of sight.
1. Go to variables, and set to parallel process or a common event the following variable. PlayerX, Set Hero X. Then PlayerY, Set Hero Y. Got it? Good.
2. Now, make the following. If PlayerX > (number), Player X < (number). Look at the map, and you'll figure out how it works. X increases as you go right (2k3 at least).
3. Don't use else statements. Trust me, it will become a mess. Instead it should look like this:
<> If PlayerX > (number2)
(outside the second number)
End
<> If PlayerX < (number1)
(outside the first number)
End
(Put these first so they check before the others)
<> If PlayerX > (number1)
<> If PlayerX < (number2)
(these are nested)
End
End
4. With me so far? Well, to make a box is hard, because the system doesn't like to handle a ton of conditions stacked inside each other. So, what we're gonna do it cut and paste, move the above inside a common event. Now, add a switch that shuts on and off, and an end event processing, so it will exit. It now looks like this:
Common Event: Check for Zone (Make this first, and I'll explain later)
<> Call Common Event: CheckForX
<> Call Common Event: CheckForY
<> If WithinX is ON
<> If WithinY is ON
<> Switch WithinZone, ON
(both must be on to be in the zone)
Else
<> Switch WithinZone, OFF
Else
<> Switch WithinZone, OFF
End
<> End Event Processing
Common Event: CheckForX
<> If PlayerX > (number2)
(outside the second number)
<> Switch WithinX, OFF
End
<> If PlayerX < (number1)
(outside the first number)
<> Switch WithinX, OFF
End
(Put these first so they check before the others)
<> If PlayerX > (number1)
<> If PlayerX < (number2)
(these are nested)
<> Switch WithinX, ON
End
End
<>End Event Processing
5. Repeat a similar process for CheckForY. You should have a general region where it's possible to enter without getting caught, but it you hit an area where both are wrong you get caught.
6. Btw, zoning can get complicated. You can use variables instead of values, and you can do stuff like line of sight.
If you want to check between two values, which involves player position, I'm pretty sure you can use CONDITIONAL BRANCH with the script option. Though, if the idea is to compare the player position to an event's position that has a size grater that the default size, there should probably be some kind of reference to the event in question. So, the example here might look something like...
...that? I'm just not 100% sure of what to add/subtract to the x/y coordinates so that the actual size of the graphic would be considered. I suppose, in the end, we would need to know the size of said graphic. Probably something to do with $game_map.events[id].character_name and $game_map.events[id].character_index?
*Edit: Actually, maybe we want the event's position to compare against the player's position? So, maybe more like...
...that? I dunno. Would need to test profusely.
*Edit2: Wait a sec. The x/y position that we're getting is based on tiles. Pretty sure this is the case in respect to the scripts I'm talking about, and the event-commands bulma is talking about. We need to modify the position in pixels. Probably? Not 100% sure. Even if I was, I'm not quite sure how to do that, but, I feel like it should be possible. I just don't know how off-hand.
;_;
$game_player.x > $game_map.events[id].x - ? || $game_player.x < $game_map.events[id].x + ?
...that? I'm just not 100% sure of what to add/subtract to the x/y coordinates so that the actual size of the graphic would be considered. I suppose, in the end, we would need to know the size of said graphic. Probably something to do with $game_map.events[id].character_name and $game_map.events[id].character_index?
*Edit: Actually, maybe we want the event's position to compare against the player's position? So, maybe more like...
$game_map.events[id].x - ? > $game_player.x || $game_map.events[id].x + ? < $game_player.x
...that? I dunno. Would need to test profusely.
*Edit2: Wait a sec. The x/y position that we're getting is based on tiles. Pretty sure this is the case in respect to the scripts I'm talking about, and the event-commands bulma is talking about. We need to modify the position in pixels. Probably? Not 100% sure. Even if I was, I'm not quite sure how to do that, but, I feel like it should be possible. I just don't know how off-hand.
;_;
StormCrow
2877
@bulmabriefs: Actually, I already know how to create a solution/workaround using events, but it's more labor intensive and less elegant. As for the labor side of things, I'm working like a maniac on this game for an event that ends in four days so I'm trying to cut corners wherever I can to actually get it done. I don't mean to be rude, so thanks for spelling out that event logic, that looks like it took time. (I'm pretty good on the fundamentals: I've been around since 2k3 was brand new.)
While I am curious about what you mean and would like to read up on it some time, I don't think that it's mandatory for every dev, or even every serious dev, to not use tiles.
@Marrend: thanks you, I'll fiddle around with that if/when I have the time. It's a dilly of a pickle.
Stop tiling, and learning how to zone.
While I am curious about what you mean and would like to read up on it some time, I don't think that it's mandatory for every dev, or even every serious dev, to not use tiles.
@Marrend: thanks you, I'll fiddle around with that if/when I have the time. It's a dilly of a pickle.
I think I did something with mouse clicking (don't ask, it's a stupid concept), and for pixels, you had to do something like RelativeX and RelativeY (it's the pixels relative to the current position on the the screen.
However, two things about this method. You still are basically boxing the thing in, but this time in relation to scrolling up and down the screen, which is super good for pictures and such, since pictures are actually using relative x/y, but super super horrible for any zone that is based on a fixed location, so NO you wouldn't use pixels. Two, I think I tried using relative x/y as a continuous process, using a lantern, and it sucks. It basically lagged alot on slower computers.
Also, he said tiles, and it's clear he wants a sort of booby trap hole. A heads-up, sometimes the method I explained earlier doesn't work. That there's some sort of lag. If that's the case, fiddle around with it. Maybe you'll need to have all four (x and y conditions) nested inside the same thing, rather than two double nested conditions? It's been awhile since I did this, but I do remember sometimes this fails miserably.
Marrend's solution is basically my solution in scripting. Bottom line, you must learn how to basically put a number in between ranges. What I mean by zoning, you're creating a range of numbers in a sort of zone.
The problem is, well, I tried to do C++ (that's what dynRpg uses for 2k3) coding to basically do the same sort of scripting, making a sort of constant X/Y tracking, and sometimes the scripting doesn't take. This is why it is all-important to learn to solve the problem in rpg code first, then use the script when there is either a functional reason why not (in 2k3, this is stuff like the monster's condition can't be checked for because the code doesn't implement this) or if the code takes 200 lines, when the script simplifies to 4 lines.
However, two things about this method. You still are basically boxing the thing in, but this time in relation to scrolling up and down the screen, which is super good for pictures and such, since pictures are actually using relative x/y, but super super horrible for any zone that is based on a fixed location, so NO you wouldn't use pixels. Two, I think I tried using relative x/y as a continuous process, using a lantern, and it sucks. It basically lagged alot on slower computers.
Also, he said tiles, and it's clear he wants a sort of booby trap hole. A heads-up, sometimes the method I explained earlier doesn't work. That there's some sort of lag. If that's the case, fiddle around with it. Maybe you'll need to have all four (x and y conditions) nested inside the same thing, rather than two double nested conditions? It's been awhile since I did this, but I do remember sometimes this fails miserably.
Marrend's solution is basically my solution in scripting. Bottom line, you must learn how to basically put a number in between ranges. What I mean by zoning, you're creating a range of numbers in a sort of zone.
The problem is, well, I tried to do C++ (that's what dynRpg uses for 2k3) coding to basically do the same sort of scripting, making a sort of constant X/Y tracking, and sometimes the scripting doesn't take. This is why it is all-important to learn to solve the problem in rpg code first, then use the script when there is either a functional reason why not (in 2k3, this is stuff like the monster's condition can't be checked for because the code doesn't implement this) or if the code takes 200 lines, when the script simplifies to 4 lines.
Pages:
1
