I don't know whether this has been fixed in V3.2 as I'm not checking due to the stupid installer, but I think this problem is still here, judging from the change log.
It seems that, say when you let character B follow character A (with
FOLLOW_EXACTLY set at least), some of the settings for B will be taken over by those of A's.
This is sometimes not desired, as we may need to control those properties ourselves for some reasons.
One typical example is to add a shadow below the player character (this isn't what I was going to do, but I think it's easier to explain this problem in this way) and say we draw a black oval shape as the shadow and assign a view containing this sprite to a character. In this case, we need these:
1. The shadow should follow the player at exact position and should be placed behind the player.
2. In fact the shadow should be behind
everything, including objects and other characters.
3. The bottom edge of the shadow sprite should be placed a bit
below the player's feet.
So, under this logic we may do something like this when a room loads:
cShadow.FollowCharacter(player, FOLLOW_EXACTLY, 1); //1
cShadow.Baseline=1; //2
cShadow.z=-7; //3
We expect the result would be like this (the key is an object):
(http://i488.photobucket.com/albums/rr249/gilbot/correctshadow.png)
However, if we use the above codes we actually have this:
(http://i488.photobucket.com/albums/rr249/gilbot/wrongshadow.png)
Turns out the
Baseline and
z properties (and possibly other properties as well) of cShadow are being overridden by player's, so 2 fails as the key is drawn behind the shadow and 3 fails also as we see the bottom edge of the shadow just touches the character's feet.
So, I tried to enforce the settings by putting the last two lines of the above codes into
repeatedly_execute_always() and it didn't
seem to do anything. HOWEVER, ironically, when the game is paused (such as bringing up the icon bar in the default interface) these properties are (temporally) set and the display is correct (I guess this is because the characters are not moving, so that tyrant behaviour of
FollowCharacter() is not triggered).
Possible solution:
From the manual entry of
FollowCharacter():
Quote
If you use FOLLOW_EXACTLY, then EAGERNESS has another meaning. If you pass 0, CHARID will be drawn in front of CHARTOFOLLOW; if you pass 1, it will be drawn behind.
Clearly, in the above example
EAGERNESS has to be set to 1 for the shadow to appear behind the player. However, this is not enough as we want it to be behind everything, not just the player.
To avoid breaking existing codes I'll suggest adding the choice '2' to
EAGERNESS of
FollowingCharacter() when
FOLLOW_EXACTLY is used, in which case properties such as
Baseline and
z won't be overridden.
Don't use FollowCharacter, just set the shadows x and y coordinates to the players coordinates - with whatever offset value you need to place it properly (multiplied by scaling factor) - in the repeatedly_execute_always. Much less hassle in the long run.
Edit: Sorry, I read too quickly. Thought your example was an actual problem you were having. In any case, I think it's better not to use FollowCharacter for this kind of thing - even though I agree it should be possible. I just accepted sometime around 2003 that FOLLOW_EXACTLY was kind-of broken and have used my own workarounds since.
Note that as I mentioned before I was not using this for the shadow effect. I just raised it as an example to the problem.
I found this problem because of this (http://www.youtube.com/watch?v=gTJ0tUqPKBs), which was meant to be a joke in one of the recent threads. It is actually a large scrolling room, and the "game" continuously grabs the portion of the background around the player and stores a distorted version as a DynamicSprite. What you see in that clip is that I actually used an object and changed its position to match the current Viewport in repeatedly_execute_always(). The problem is that it doesn't work so well, as when the Viewport follows the character's movement the characters is actually still moving after repeatedly_execute_always() ends, so that the Viewport is still being changed at last moment before actual render of the screen, making the object shaking and not snapped to a fixed screen position (it may not be instantly obvious from looking at that clip). I've tried also changing the Viewport according to the player's position, but the obvious drawback is that now the player shakes.
Overlays and GUIs are good as they use screen coordinates and so they could be snap-fit at fixed positions of the screen but they're not applicable in this case since they're always drawn in front of stuff (of course, it's possible to have me just draw the player sprite on top of the DynamicSprite and use this as an Overlay to cover up the whole screen, but this is not an elegant solution, especially if there're a certain number of objects on-screen at a time).
So the last resort is to use a character, as FOLLOW_EXACTLY in FollowCharacter() would just move the stalker sprite at the right time to keep it in-sync with the player (and thus the Viewport). However, this has to be placed behind everything and clearly its bottom edge has to be the bottom of the screen. Theoretically this could be done by setting the baseline as high as possible and setting its z value to -120 or something (if the screen height is 240), but because of the limitation mentioned it just could not be done.
The fix I'm regularly using is to simply have a dummy character with the same graphic and coordinates as the (invisible) player character, again updated in rep_exec, so all the coordinates in rep_exec are the same despite any character movemement between then and rendering (which, to be honest, I still don't understand why the engine handles that way). Of course that would also require the ViewPort scrolling to be done in rep_exec.
Interesting work around, at least you don't need to draw any other objects this way, but still it's a bit inconvenient.
This is "by design", but yes I think it should be controlled by an option that allows you to decide whether this behaviour happens or not.