If you're up for playing around with code, I can point you in the right direction:
The Game_Player class has the methods
check_event_trigger_here and
check_event_trigger_there which are called to see if any events have been triggered on the player's current square and the one in front of him, respectfully. You can call these like so:
Code:
$game_player.check_event_trigger_here([1,2]) #Check "contact with player" and "contact with event" events on the current tile
The function
Kernel.pbSlideOnIce in PField_Field is what gets called whenever the player slides on the ice. There's a double loop inside it which moves the player forward while on the ice. You could conceivably put the above code in the outer loop, after the
event.moving? loop, and break if that function returns true.
I don't know what side effects, if any, may come of doing something like that, so make sure you test it thoroughly.
---
As to your other question,
I'm under the impression that's a function of RMXP and can't be changed, but I could be wrong about that. It does that to make sure off-screen events aren't taking up processing power when they don't have to.
EDIT: I
am wrong about that: the Spriteset_Map script section, line ~290 in the
update function makes a call to
in_range? to see if the player can see that sprite before updating it. You could comment that call out, but I warn you that that undoubtedly
will cause problems with performance, especially when near connected maps. You could also add another check OR'd onto the end of that if statement to test specifically for certain sprites, so they always update.
If you're not down with coding, move your events onto non-icy ground. :j