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)
HOW IS THE 'GET LOCATION INFO' COMMAND SUPPOSED TO WORK? AND A FEW MORE RANDOM QUESTIONS. [VXA]
Posts
Pages:
1
karins_soulkeeper
View playlists
CloseI have quite a few questions that I think don't deserve an individual topic for each, so I just clumped them up into one.
As in title, how does the 'Get Location Info' work? I couldn't figure how to get this command to work, so I just used three separate variables to store Player X, Player Y, and Map ID (as seen in action here.)
I can't really understand it, and the help file doesn't help much.
Also, what does the 'Enemy Transform' and 'Enemy Appear' do? Do they change the troop your currently battling, or something?
And finally, is it possible to change the position of the 'Choice' window? If yes, then which line in the script should I modify?
I found it (I think). Is it this one?
Sorry if these are pretty dumb questions, but I just had to ask.
Thank you!
As in title, how does the 'Get Location Info' work? I couldn't figure how to get this command to work, so I just used three separate variables to store Player X, Player Y, and Map ID (as seen in action here.)
I can't really understand it, and the help file doesn't help much.
Also, what does the 'Enemy Transform' and 'Enemy Appear' do? Do they change the troop your currently battling, or something?
I found it (I think). Is it this one?
def update_placement self.width = [max_choice_width + 12, 96].max + padding * 2 self.width = [width, Graphics.width].min self.height = fitting_height($game_message.choices.size) self.x = Graphics.width - width if @message_window.y >= Graphics.height / 2 self.y = @message_window.y - height else self.y = @message_window.y + @message_window.height end end
Sorry if these are pretty dumb questions, but I just had to ask.
Thank you!
Okay, for number one:-
You designate a variable to contain the information in. That variable is the one you'll refer back to when you need to various info. Let's call it GIMME.
There are various choices. We'll get to them and what they do in a moment. The last parts are 'Direct Designation' (DIRECT) and 'Designation with Variables' (VARIABLES). DIRECT allows you to check a specific tile of your choice. VARIABLES allows you to check based on the X and Y points of two variables tracking an event or the player.
Basically these tell you what to check - either a specific tile or where an event/the player walks.
Back to the choices then.
The first is Terrain ID. These are the numbers given to the tiles under the Terrain choice in the Tileset Database tab. You can give certain numbers to a tile to dictate what kind of tile it is - say all grass tiles are given 1, all forested tiles are 2, desert tiles are 3, water tiles are 0...
When you use this setting it will check what terrain number the event/character is on at that time and record it in GIMME.
The second choice is Event ID. This is the number given to an event by default. You probably know that you can rename an event. You can always check the number of an event after this by clicking on it in event mode and looking at the bottom left of the engine. It will have the Event ID as well as the name.
This choice allows you to see if the event/player is standing on an event and records the number of that event in GIMME.
The third, fourth and fifth choices I've no idea.
The sixth is the most useful one, Region ID. You can add a region number to a tile by using the Region tool while mapping (F7). This choice allows you to record the number of region applied to the tile that the event/player is standing on.
You designate a variable to contain the information in. That variable is the one you'll refer back to when you need to various info. Let's call it GIMME.
There are various choices. We'll get to them and what they do in a moment. The last parts are 'Direct Designation' (DIRECT) and 'Designation with Variables' (VARIABLES). DIRECT allows you to check a specific tile of your choice. VARIABLES allows you to check based on the X and Y points of two variables tracking an event or the player.
Basically these tell you what to check - either a specific tile or where an event/the player walks.
Back to the choices then.
The first is Terrain ID. These are the numbers given to the tiles under the Terrain choice in the Tileset Database tab. You can give certain numbers to a tile to dictate what kind of tile it is - say all grass tiles are given 1, all forested tiles are 2, desert tiles are 3, water tiles are 0...
When you use this setting it will check what terrain number the event/character is on at that time and record it in GIMME.
The second choice is Event ID. This is the number given to an event by default. You probably know that you can rename an event. You can always check the number of an event after this by clicking on it in event mode and looking at the bottom left of the engine. It will have the Event ID as well as the name.
This choice allows you to see if the event/player is standing on an event and records the number of that event in GIMME.
The third, fourth and fifth choices I've no idea.
The sixth is the most useful one, Region ID. You can add a region number to a tile by using the Region tool while mapping (F7). This choice allows you to record the number of region applied to the tile that the event/player is standing on.
Liberty, I don't get how this is more efficient than just having 3 variables and a par-proc event to do the same job (which, for me, is easier).
Why? Because here's what I understood from your explanation: To properly use 'Get Location Info', I need to either tag every single passable tile with a unique Terrain ID/Event/Region ID to get the location info of the player.
Like say, I have a GameOver scene that has a 'Retry' option. I'm going to need to store the player's last position; so that when the player does retry, I can set a transfer event and he'll be whisked back to the area where he previously was.
Or I have a DeBug map that you can access from anywhere (like in the game I linked). I'll have to store the player's position prior to his transfer to the DeBug map, so that when he decides to go back, he'll be back to where he came from.
But I think I'm missing something here...
Why? Because here's what I understood from your explanation: To properly use 'Get Location Info', I need to either tag every single passable tile with a unique Terrain ID/Event/Region ID to get the location info of the player.
Like say, I have a GameOver scene that has a 'Retry' option. I'm going to need to store the player's last position; so that when the player does retry, I can set a transfer event and he'll be whisked back to the area where he previously was.
Or I have a DeBug map that you can access from anywhere (like in the game I linked). I'll have to store the player's position prior to his transfer to the DeBug map, so that when he decides to go back, he'll be back to where he came from.
But I think I'm missing something here...
It's less of a back-and-forth thing and more of applied to that map.
Think of it this way, with the region version you can set a certain region to do one thing, while another does another thing altogether. For example, using this I created an event that made a random chest appear in certain parts of a map using only the overall parallel process to place the events and the chest events themselves.
I can also use the same thing to create a series of spawn points for monsters, to create a boulder pushing puzzle, to check if an NPC is standing in a certain spot or not, to create a check to see if the hero hits the edge of the map with only one event, use one parallel process to check for interaction with objects for a single map, create a sliding puzzle, create a checkpoint system... the possibilities are practically endless as long as you have enough imagination.
Of course there are certain things it can't do, like the things you mentioned, but that's why you have those other commends.
Think of it this way, with the region version you can set a certain region to do one thing, while another does another thing altogether. For example, using this I created an event that made a random chest appear in certain parts of a map using only the overall parallel process to place the events and the chest events themselves.
I can also use the same thing to create a series of spawn points for monsters, to create a boulder pushing puzzle, to check if an NPC is standing in a certain spot or not, to create a check to see if the hero hits the edge of the map with only one event, use one parallel process to check for interaction with objects for a single map, create a sliding puzzle, create a checkpoint system... the possibilities are practically endless as long as you have enough imagination.
Of course there are certain things it can't do, like the things you mentioned, but that's why you have those other commends.
I forgot your other questions! XD
Enemy Transform is pretty self-explanatory. In the case that you want to replace one enemy with another - as though it had transformed into another monster - you'd use this command. Think final bosses with more than one 'form', for example.
Enemy Appear is also pretty self-explanatory. Useful for those enemies which 'call' other enemies to appear. So, for example, a wolf that calls more wolves to the battle.
Enemy Transform is pretty self-explanatory. In the case that you want to replace one enemy with another - as though it had transformed into another monster - you'd use this command. Think final bosses with more than one 'form', for example.
Enemy Appear is also pretty self-explanatory. Useful for those enemies which 'call' other enemies to appear. So, for example, a wolf that calls more wolves to the battle.
Pages:
1
