Rairun

It's actually a very well documented script, but obviously it doesn't teach you how to use RPG Maker itself. I'd recommend reading some tutorials to learn the basics first. But to answer your questions: Unless noted otherwise, always insert scripts under Materials, above Main. You can make script calls from within an event, just like you can tell it to display text, play a sound, etc. Script calls allow you to run RGSS3 code directly instead of relying on the pre-made options RPG Maker makes available. You just have to click the button for script calls and write the code when prompted. Note that, with this script, you're supposed to make script calls from within a Set Move Route command. So you create an event, add a Set Move Route command, and find the button to run a script line within it.

Thank you. It'd be great if you could look into it eventually. The main reason why I use Quasi Movement isn't actually pixel movement. Yeah, the movement is well-made, but I was already using Victor's script + a few patches to make it work properly. The real reason why I moved on to Quasi Movement was his implementation of collision maps. It's an amazing resource for those of us who use parallax mapping.

I just went ahead and bought it. The discount for Effectus users lured me in. I probably won't use Invenio any time soon (I use Quasi Movement, and it isn't compatible), but I wanted to test it in a fresh project. Good job. (If possible at all, a compatibility patch with Quasi Movement would be amazing, but I understand why it probably won't happen. Either way, I wanted to show my support.)

It means the sound file starts playing at 0 volume, and then gradually gets louder to the desired volume over a specified amount of time. RPG Maker already has a fade out feature, which is the exact opposite: the audio becomes gradually quieter instead of stopping abruptly.

Ah, it's a shame that Invenio won't be compatible with Quasi Movement. How come you don't recommend using it with Effectus, though? After a few minor changes, it seems to work OK. My largest map, which is something like 60x60 and contains a lot of parallax layers, runs at 60fps using a i7-4710MQ processor at 2.50GHz. When I throttle the processor to 1.50GHz, I get 40-45fps - which is indeed slower than the 45-50fps I used to get with Victor's Pixel Movement. The thing is that I'd always get hiccups when scrolling the screen with Victor's script, EVEN at 60fps. With Quasi's script, there's a hiccup every now and then, but not nearly as often. But what made me change over to Quasi was the collision map. Maybe that's what makes the whole thing a tad bit slower, but it gives you a lot more control. tl;dr are there any issues if you use Effectus + Quasi Movement that I'm unaware of? My map still doesn't have a whole lot of events - do you expect some of your lag-reducing features to be compromised?

I haven't used this script in a while, but as far as I remember, you shouldn't use a 0 before the map number, e.g. use ground9-1.png, not ground09-1.png.

Hey! I'll prepare a demo soon. Meanwhile, I found a bug (not a compatibility issue) that crashes the game even if Effectus is the only custom script. To reproduce it: 1. Create a project and add the Effectus script. 2. Set MAP_SCENE_WINDOW_IMPROVEMENTS = true (the crash doesn't happen if it's set to false) 3. Create two maps and add a door from the first to the second. 4. Start the game. Open the main menu, close it, and notice that there is no error. 5. Transfer from the first map to the second and don't move. If you move for a bit, or interact with an event, the crash won't happen. 6. Open the main menu (or any custom scene you've made). When you close it, you get the following error:

Massive thanks for this. I particularly love the waypoint(x,y) call. If you don't mind, I made a minor modification to improve the call: def process_waypoint_command sx = distance_x_from(@waypoint[0]) sy = distance_y_from(@waypoint[1]) unless @locked # Added this line to stop the event from moving when interacted with And then, of course, I added another "end" between lines 381 and 382. The waypoint call worked very well, but I wanted NPCs to stop to talk to the player when interacted with, and then resume their route.

Windows 7 64bit here, and it doesn't work either.

It helped a little bit - not as much as 10fps (a drop that I somehow failed to reproduce last night), but it's better. One of the good things about this script is that it has finally allowed me to isolate what was causing some graphical stuttering when walking (which happened even at 60fps, and mostly when the screen was moving along with the character). Previously the problem was caused by the clock + regular events around the map + possibly victor's anti-lag + unknown causes. By fixing the clock and the lag from regular events, and also doing away with Victor's Anti-lag, I was able to isolate Victor's Step Sounds AND the animated parallax river I had as part of the problem. I managed to fix the river, but the step sounds had to go for now. Maybe I will edit the script so that the audio is played by the MCI Audio Player instead of the RPG Maker audio engine. It might help. By the way, I've came across two Effectus quirks that might be worth documenting: - I think someone else has mentioned this in this thread, but when you have two competing autorun events, one of them will fail to run at all or will suddenly run many minutes after entering the map. The default engine solves this conflict somehow. SOLUTION: be careful with your autorun events. No need to have two at the same time. - I have a common event that checks a TIME variable (0 == night, 1 == twilight, 2 == sunrise, etc.) and instantly applies the proper tint and changes the shadow overlay opacity (via a comment call to Victor's Fog and Overlay script). I call this event whenever the player opens a door to a different map. FADEOUT -> TRANSFER -> COMMON EVENT -> FADEIN. This used to work perfectly, but now the common event is only run AFTER the fade in, so the player can see the map without effects for a split of second. I copied the contents of the common event to the door event, and it still happens. SOLUTION: create a parallel event in the destination that calls the common event and ends with "Erase Event". Anyway, I'm looking forward to the Pixel Offset functionality - I believe it's the last feature I need to implement. Then I can move on to proper game design and writing. EDIT: Unfortunately, I've found a couple more bugs/incompatibilities, one of them game-breaking. (1) Collision with Victor's Pixel Movement seems to work perfectly when the player moves towards an event, but when an event moves towards the player, it will only stop when it's already on top of the player, getting both of them stuck. An event moving towards another event seems to collide properly, though. This bug makes me unable to use Effectus at all - it really does break a lot of mechanics I had created. (2) Victor's Fog and Script Overlay script only works if you use the Display Rounding Error fix by Neon Black. The problem here is that, although the parallax map behaves normally, the rounding error isn't actually fixed (you can see sprites displaced by 1 pixel sometimes). Also, even if the rounding error were fixed, I'd like to use the more efficient solution included in Effectus instead. EDIT 2: I managed to fix the collision error on my own by commenting these lines out: #-------------------------------------------------------------------------- # * Detect Collision with Character. [REP] #-------------------------------------------------------------------------- # def collide_with_characters?(x, y) # super || (normal_priority? && $game_player.collide?(x, y)) # end Please do let me know if this interferes with the lag-reducing features, though!

Thank you! Yeah, I know all custom scripts should go below Effectus. I only tried putting them above it to know what had been causing lag. I narrowed it down to the clock display because it was the only thing about the Game Time script that Effectus broke (when Effectus was placed below it), and the lag was fixed when it was broken. Anyway, I haven't had time to test it yet, but am I right in assuming that the clock was updated every frame (thus causing lag), and the code snipet you've just provided checks whether the time has changed before redrawing the window's text? On a side note, when the scripts were in the right order, the lag persisted even when the clock was set to invisible. Strange. I suppose the script was processing it every frame even when it wasn't displayed? I'm just curious, really - I'll test the fix tonight. Again, I really appreciate it.

OK, I got it! And I've playing with it for a little while now. My situation is this: when my laptop is plugged in, the processor runs at 2.4MHz. When it's running on battery, it goes down to 1.4MHz max. I like to unplug it when testing my game to make sure it will run on most computers. Initially, I saw no gains in relation to Victor's Anti-Lag script (which already represented a significant boost from 20fps to 40fps). It was exactly the same. However, by selecting the "Only Parallax Maps" option, I gained something like 9fps, going up to 49fps. Very good. Then I decided to place the Effectus script below ALL the other scripts I was using. My game was, of course, severely broken. As I moved the other ones down one by one, I achieved a playable game at 60fps. Once again, excellent. The framerate does drop down to 50fps sometimes, depending on how the character is moving, which I believe is a result of Victor's implementation of pixel collision. If there is a fix for this, that'd be great. Now I only have two issues: - This Pixel Offset script is not compatible at all (the offset sprites look like they are falling down the screen). - If I place Basic Game Time below Effectus, it works perfectly, but I lose 10fps. If I place it above Effectus, it still keeps time and saves it to a variable, but the on-screen clock crashes the game. If there is a way to have the clock on screen without it being so resource-hungry, that would be great too. I don't use any of the tint features, so that's irrelevant to me.

Has this issue ever been properly addressed? Is it still current? That is a known problem with Victor's scripts, not Effectus. I can provide a fix for that if it is still present after adding Effectus. Ah, I've never experienced an actual FPS drop while walking diagonally on my PC, but I do notice a minor fluttering effect on the graphics. I always assumed it was a minor glitch in the way the graphics were redrawn. A fix for that would be excellent. But anyway, thanks for the info. I will buy the license when I get home tonight.

Thanks for replying so quickly! The only thing I still worry about is this: Has this issue ever been properly addressed? Is it still current?

I'm thinking about buying a license very soon, but I want to make sure it works with Victor's Pixel Movement, Diagonal Movement, and Fog and Overlay scripts. I also need it to work with Vlue's Eventing: Fine Tuning - more specifically the waypoint(x,y) script call - and Dynamic Sound Emitting Events. I'm working with many more scripts, but as far as I can tell, an anti-lag script shouldn't intefere with any others. I think these are the ones I need to worry about. I'd really appreciate any help you can give!