Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
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
[RM2K3 DynRPG] Line of Sight plugin request
Uh... what prevents you from seeing down long cooridors with the current solution?
As for being able to watch through impassable walls (invisible, glass, whatever), this can be kind of done at the moment, by using the directional passable arrows in a way.
Only entirely impassable tiles blocks the sight, so as long as there's at least one passable arrow on the tile, it's possible to see through it.
As for being able to watch through impassable walls (invisible, glass, whatever), this can be kind of done at the moment, by using the directional passable arrows in a way.
Only entirely impassable tiles blocks the sight, so as long as there's at least one passable arrow on the tile, it's possible to see through it.
Introduction to pixel movement in rm2k3
It shouldn't pose to big a problem to add afterwards.
The way I imagine it, it would simply be a matter of adding some more branches in the event handling the collision detection.
The way I imagine it, it would simply be a matter of adding some more branches in the event handling the collision detection.
[RM2K3 DynRPG] Line of Sight plugin request
author=bulmabriefs144
It detects whatever you want it to detect. Stop being a naysayer.
author=bulmabriefs144
If you can get this one working, you don't need terrain detection, you just set the terrain zone as if there is a solid object in the way
You're kind of contradicting yourself here. Essentially he's right, you're not detecting any terrain, you're just working around it in a painful way.
author=bulmabriefs144
This is the equivalent of what you're doing.
I'm not sure whether this was just your way of introducing your method, or stating that your method is in practice equivalent with that of the tutorial, but if the latter, then it's still significantly inferior. The fact that yours is based on rectangular zones alone is a reason for this, as it prevents looking around corners in the same way without making multiple zones, for some obstacles quite many even. Also, the setup itself will end up making your method even more complicated than the tutorial solution the more you try to approximate it correctly.
For a certain kind of rooms and line of sight detection needed, your solution works fine, but for more general situations or room with arbitrary obstacles it works pretty poorly.
Nightowl
Anyone?
*crickets*
I made a tiny attempt at this. It's still has a few flaws (if you're standing on one of the "wall autotiles" you/the target becomes invisible for example), but I'm out of time again. Despite the flaws it should be usable to some extent though.
download
It's does stuff pretty much the same way the tutorial does, except that the plugin detects if the tile has been set to passable or unpassable and determines if you can see through the tile this way. The download contains a tiny demonstration showing how it can be used
Instructions on usage is contained within the ReadMe file.
Introduction to pixel movement in rm2k3
Yep, the way to point to an arbitrary event page is indeed very powerful. It allows you to execute commands related to "this->event" based on a variable. So by having a page in all applicable events doing "flash this->event red", I can just decide with call event with variable parameters which event should flash, something you couldn't do by default.
And the second power is how it easily allows you to locate events of interest being closeby, allowing you to only make computations for those events, which can be very helpful in terms of performance.
It also allows for greater reuse of code, since instead of assigning values from a specific event into some variables to do some computations, you can just take an event page in the event itself with "this->event" and store it into some temporary variable and just copy paste the page as is. This is basically what's being done in my TBS demo, where event graphics represent the movable area, and you might quickly need as many as a hundred of them.
Using the call event, you can simply "set event location" based on some temporary variables, copy paste the exact same page to all of these events, and then have one single event easily loop over all of these events.
There are so many uses of this that it's quite interesting how I've almost never seen it being used.
And the second power is how it easily allows you to locate events of interest being closeby, allowing you to only make computations for those events, which can be very helpful in terms of performance.
It also allows for greater reuse of code, since instead of assigning values from a specific event into some variables to do some computations, you can just take an event page in the event itself with "this->event" and store it into some temporary variable and just copy paste the page as is. This is basically what's being done in my TBS demo, where event graphics represent the movable area, and you might quickly need as many as a hundred of them.
Using the call event, you can simply "set event location" based on some temporary variables, copy paste the exact same page to all of these events, and then have one single event easily loop over all of these events.
There are so many uses of this that it's quite interesting how I've almost never seen it being used.
Introduction to pixel movement in rm2k3
but this whole system works by not using the hero event, how does stepping on events factor into this?
This can be simulated with a pp event checking if the image of the hero is standing on an event within a certain event id range, and then executing a page of the event in question.
If you're already doing panorama mapping, terrain id's would probably be more convenient though.
i just don't get the next step and how that would allow me to push the picture to anything other than outside the standard tile boundaries. would you have to define each point along the custom edge? so if you try and walk past that point, it stops you? or something.
Basically, you do a check bounded to the current tile you have.
e.g. if locally within one tile, y + x > r with r being the radius in question, then you can check if the hero image is in the lower triangular of that tile, and you simply set the coordinates in such a way that the image will be put back on the border of the diagonal in this case, i.e. along the lines of y + x = r. Exactly which x and y should be used should depend where you crossed into the local obstacle though, and might be subject to more checks, to get a more smooth walking along these rounded edges.
The example above would give a diagonal. You'd need to modify it for the different variants though, so you would normally need 4 different id's, one for each direction so to speak.
[DynRPG Plugin]Text Plugin
author=trance2
It seems like X and Y for pictures and for text is different, but I'm probably just imagining that.
That should not be imagination on your side, since the purpose of the picture is primarily for technical reasons, related to drawing order on the screen. Besides, there should be commands for move the text where you want it by inputting them manually. This won't affect the picture in any way.
I do have one question, though... is there a way to escape quotation marks? Like say you wanted something to read - Item Shop "Bottomless Gap" - with the quotes like that. I know you can't do it normally with this because as soon as the compiler sees a quotation mark, it's gonna go "oh hi end of variable" and move on and then crash because there's text where there shouldn't be text. So if you could escape the quotation mark, that would allow for actual quotes in the display text. ... if that's possible?
It shouldn't be impossible, but not neccessarily elegant either. Either way, for the time being, using single quotation twice ('')might be the best bet until something is done with this... which could take a while to be honest.
Introduction to pixel movement in rm2k3
This tutorial only touches pure grid shapes, since it's easier not to. I tried to just tell how to do the rather important parts first, while more aesthetical ones like rounded corners (if I get you correctly), would be something of later interest.
It's perfectly possible though. One way of doing it would be to use terrain id's, and then you could use a simple mathematical function to check if the player is within the object radius and then just "push" it out to the correct position.
There's probably some fine tuning which would be needed here, you should be able to create a number of shapes doing this, which is tinier than the typical grid size.
If you plan to have a lot, using events which you can step on might be a better idea (and would also avoid forcing you to do panorama mapping straight away, to embrace the usage of terrain id's)
It's perfectly possible though. One way of doing it would be to use terrain id's, and then you could use a simple mathematical function to check if the player is within the object radius and then just "push" it out to the correct position.
There's probably some fine tuning which would be needed here, you should be able to create a number of shapes doing this, which is tinier than the typical grid size.
If you plan to have a lot, using events which you can step on might be a better idea (and would also avoid forcing you to do panorama mapping straight away, to embrace the usage of terrain id's)
Trigonometry script for rpg maker 2003
Yes you can in a pretty similar fashion to how I'd detect bullet. I don't have a tutorial on that though. I can give you the general idea though, based on how it was done in Zero Base (which could be good as reference material, if not too cryptic).
The general idea is that you translate the screen coordinates into tile coordinates.
This is done by adding an offset to the screen coordinates, depending on how much the map is panned away from the upper left corner.
I typically do this by adding an event in the upper left corner, get it's screen coordinates and I subtract the screen coordinates of the bullets with that of this event, then add some tiny static value to fine tune to collision.
Once this is done, I get the tile coordinates of this position, and I use this tile coordinates to check if there's an event or terrain below which is an obstacle (similar manner to pixel movement tutorial), and then just check for those id's.
This works fine for non moving events. If they move however, you should check for multiple tiles, to take into account how rm2k3 handles updating tile coordinates of events, and then have a page in the event which can be called for a finer check only on that event if it's a hit. This is to make it more pixel accurate in terms of collisions while keeping it efficient.
A good idea would be to try to check four tiles around the navi sprite/bullet in such a way that most of the time, it would be close to the common center of those four events. This requires some tweaking with the values you add to the screen relative coordinates before converting them to tile based ones.
That's generally how it works
The general idea is that you translate the screen coordinates into tile coordinates.
This is done by adding an offset to the screen coordinates, depending on how much the map is panned away from the upper left corner.
I typically do this by adding an event in the upper left corner, get it's screen coordinates and I subtract the screen coordinates of the bullets with that of this event, then add some tiny static value to fine tune to collision.
Once this is done, I get the tile coordinates of this position, and I use this tile coordinates to check if there's an event or terrain below which is an obstacle (similar manner to pixel movement tutorial), and then just check for those id's.
This works fine for non moving events. If they move however, you should check for multiple tiles, to take into account how rm2k3 handles updating tile coordinates of events, and then have a page in the event which can be called for a finer check only on that event if it's a hit. This is to make it more pixel accurate in terms of collisions while keeping it efficient.
A good idea would be to try to check four tiles around the navi sprite/bullet in such a way that most of the time, it would be close to the common center of those four events. This requires some tweaking with the values you add to the screen relative coordinates before converting them to tile based ones.
That's generally how it works
Introduction to pixel movement in rm2k3
author=Link_2112
btw, the tutorial is kind of hard to follow. maybe it's just the way your word things and the way i understand things. i sometimes have to reread something to really get it.
This is probably more my fault and less your fault. It's typically a result of there being too many tiny details which needs to be conveyed.
This often gets tricky to present in a clean matter for me, unless rewriting several times.
On that note... I guess the tutorial hasn't been updated cuz I forgot about it. Also, my lack of sparetime has not been helping this matter either.
i'm working through this and i'm at movement 2 common event. i have directional animated walking. i'm using custom graphics and have a 5 frame walk animation. since i'm using more frames i assumed i would change the var-mod function accordingly. when i stop moving, it shows the first frame of the animation, which is not ok to use for a standing still frame. does your system later set up a standing frame or should i fix that now.
i was thinking of setting var-Animation Frame to something, like -1, when sw-Hero Moving is turned off. then when it calls the Animator event, there will be a branch at the top of the page code for the -1 var and it will show the standing frame instead of frame 1 of the cycle. does that sound compatible to future additions?
I'll have to go by memory on this one, since I don't have rm2k3 installed on my computer right now, but I think it worked like this. When there is no movement, the frame variable is simply being constantly set to the frame to be used for standing still, which would be 1 in the sample project I think. If the standing still frame is part of your walking frame, you could just change that 0 to whatever frame you'd want to use instead. This is actually what you'd do if it's not part of the walking frame as well, so in this case, going with -1 as you suggested should work perfectly fine.
Games - Tester
Games - Other
