Quasi's Sight and Movement Scripts

spiritseekerpsp

Villager
Member
Joined
Jun 21, 2014
Messages
9
Reaction score
4
First Language
English
Primarily Uses
Hey everyone! I've been beating my head against the proverbial wall for a few days regarding this, and have reached out to Quasi, but I figure in the meantime why not see if I can get help anywhere else. 

Quasi has a very nifty sight script: http://pastebin.com/iEXJg6x6

In order to use it, it requires his movement and core sciripts:   Movement   & Core

Alright.  Needing a line-of-sight script, I came across Quasi's, and I really enjoy it. Implemented it into my current project, and it works wonders.  Allowed me to remove a ton of unnecessary variables, switches, and events from my stealth maps, and I also like it because it's extremely easy to use. 

The issue came after I sat down and tried to do a runthrough of my demo to ensure the script didn't change anything that it didn't need to, and that's where my problems begin.

I'm seeing two separate ways of going forward, and as long as it gets solved, either way works.

The first issue is when I use the scripts as-is, with these config settings: 

GRID = 1SMARTMOVE = :bothMIDPASS = falseDIR8 = trueDIAGSPEED = 0PLAYERBOX = [24, 16, 4 , 16] EVENTBOX = [24, 16, 4 ,16] VEHICLES = { :boat => [22, 22, 5, 9], :ship => [22, 22, 5, 9], :airship => [22, 22, 5, 9] }EVENTFREQ = 32The issues I'm having are with event movements. Whenever I have an event do a move route, they end up moving pixel by pixel. For example, in one map I have a character enter from the bottom, move up a bit to bypass a wall, move right, then up again.  With the script on, he walks in, goes up a few pixels, slams into the wall, then stops, almost as if he's only moving one pixel for each move command.   As far as I can tell, the EVENTFREQ parameter is meant to alleviate that, and at 32, events treat each movement command as being sent 32 times, and therefore move 32 pixels.  For whatever reason, my events do not do that.  If I can figure out how to get events to move properly, the pixel movement is quite nice and tight.

Now, I actually at first had never intended to use the pixel movement, and set the parameters to be as close to VXA vanilla as possible. The sole reason for the inclusion of the movement script was to gain the ability to use the sight script.  Here are the settings I use when aiming for vanilla:

GRID = 32SMARTMOVE = falseMIDPASS = trueDIR8 = falseDIAGSPEED = 0PLAYERBOX = [32, 32]EVENTBOX = [32, 32]EVENTFREQ = 32When using these settings,  events move just fine. I then encounter a host of different issues.  In the demo I've attached, you'll see these issues crop up on the map I tested on in my original project, the sample map AbandonedMineBF1.     With vanilla settings, if you try to walk around, you end up getting caught on the bounding boxes, and half of the tiles are unwalkable for no reason.  The worst part is, if you walk up onto a raised platform, you can then walk straight off the top of it, no collision at all.

If anyone can assist me on getting this to work, either vanilla OR pixel movement style,  I would be incredibly grateful

The issue occurs even in this blank project, and with all the scripts at the bottom of my script list in my old project. 

If there's anything else I left out, or any further clarification I can provide, please let me know. I'd really rather not have to shelve this sight script due to the movement script being so difficult.

-spiritseekerpsp

Data.zip
 

Attachments

Quxios

Veteran
Veteran
Joined
Jan 8, 2014
Messages
1,055
Reaction score
781
First Language
English
Primarily Uses
RMMV
Hey there! Sorry the late reply, for some reason the contact form didn't send the email and only stored it to the db which doesn't notify me.

First of all, does that view of sight version even work with the up to date movement? pretty sure they didn't work together xD.  I have an updated view of sight that I haven't put up yet since I'm trying to rewrite some of the math to make it faster to see if I can make the sights pixel based instead of grid based.

For the events, when you use EVENTFREQ to 32, that only changes the that the event come to stop every whenever his move is the 32nd pixel.  But if you want to use GRID = 1, then instead of using move down, up, left, right in move route, you should use qmove(direction, amt, multiplicity) (just noticed my movement post doesn't mention multiplicity)  so you can do something like:

qmove(2, 5, 32)

and that will move the event down 5x32 times, which is well just 5 32 tiles (Only if you're in pixel grid!)

As for the bounding box, thats because you made the box to big, since all tiles are inside a 32x32 box.  Meaning you won't be able to enter some tiles even though it looks like there's a lot of space, but you box takes the full tile box and has a collision. You should try the box setting I have in the script header for big grids:

[22, 22, 5, 9]
 

spiritseekerpsp

Villager
Member
Joined
Jun 21, 2014
Messages
9
Reaction score
4
First Language
English
Primarily Uses
Quasi, you are the actual best.  The qmove function does exactly what I need it to.   In my project, I'm using Core 0.4.9,  Movement 1.3.1, and Sight 0.8, and Sight still worked like a dream.   I'll definitely be looking forward to the new script too.   

I have one followup question.  For random movement (which I plan on keeping separate from other events to avoid the "stuck box" issue),  is there a qmove direction for that, or should I just pull a random number before they move, then execute a qmove with the direction equaling that random #?  
 

Quxios

Veteran
Veteran
Joined
Jan 8, 2014
Messages
1,055
Reaction score
781
First Language
English
Primarily Uses
RMMV
That's weird since that sight was before I added in tile collisions so it should see through tiles, unless you're using the region boxes.  

I can't really remember but I think I fixed the random move stuck issue in 1.3.1 but I didn't remove the tag since I didn't do much testing. I still need to work on random a bit more cause random move ( with grid 1 ) makes them go all over the place lol.  But your idea of using qmove for random might work! At the moment there isn't a number you can put for a random direction .
 

spiritseekerpsp

Villager
Member
Joined
Jun 21, 2014
Messages
9
Reaction score
4
First Language
English
Primarily Uses
Indeed, it does see through tiles, but I've been working around that by using events to block LOS well enough to have it be playable in a sense.   I did discover the issue with random move,  they move all crazily in one pixel increments. Very indecisive NPCs
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Profile Posts

I really need to stop thinking there are new freebies just because someone made a new post in the freebies subforum lol.
AND just like that..... I got STEAM DLC up and working! YES!
Game making is like a marathon, except the last 1/4 is more like sprint... a very long and intense sprint.
Finally got to finish the demo for my project!
Another week has gone by. Maybe you made changes to your project/s. Maybe you didn't. Nonetheless, THAT IS NO EXCUSE TO NOT BACK THEM UP O_O!

Forum statistics

Threads
93,440
Messages
912,433
Members
122,964
Latest member
AZAIKING
Top