Messages

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, 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.

[FOLLOW_EXACTLY]

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:

Code: ags

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):


However, if we use the above codes we actually have this:


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():

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.

Something like this?

[on_event()]

You don't need to call them in every instant of FadeIn and LeaveRoom. Instead, you may use on_event() for such purpose (you can even do different stuff depending on the room number). I'm not quite sure whether the current list of covered events are enough for this purpose and if not it's better to suggest adding more events to it.

Also, talking about internally supported transitions, you don't need to stick to one default transition all the time. You can always use SetScreenTransition() to override the global setting in-game.

Without the source we can barely make any suggestions. Moreover, as V2.61 is too old to be supported I wonder whether anyone would help with it now (even though I myself is still using the V2.6 branch).

I'm not quite sure, maybe the game files being on a shared drive could somewhat make the editor recognise the last user who accessed and edited the file a user other than the current user (i.e. you), that causes this problem. I have no knowledge on network drives, but if their operations are like, when you save/modify a file on that drive, you're requesting the file to be updated and then the networking software does the update for you (instead of you directly changing the file) this may happen. Someone who has more knowledge in this department may give you a better explanation.

What version of Windows are you using?

[event]

Well, I don't think it's unclear. As his original post mentioned, the problem was that on_mouse_click() called movingToXY() and at the same time movingToXY() would also call on_mouse_click(), and he was aware that in AGS you could only call a function that was declared before the current one. That's why he needed help.

I'm not quite sure about that, but I think it may be possible if you import the function that was declared later (better be movingToXY(), as on_mouse_click() exists also in room scripts) in the Global Script header, then the one declared first may be able to call the other (maybe not, if the header applies only to room scripts).

Otherwise, you may declare a variable outside of functions (e.g. move that event outside of the function) and use repeatedly_execute(_always() ) to check it and call on_mouse_click() here.

I cannot confirm this at the moment, but if you take a screenshot using DOSBOX's own screenshot feature you may get the shot in its original 8-bit glory, but as Khris mentioned, these games usually use dynamic palettes, so you probably couldn't get a universal palette anyway.

Alternately, when in the good old DOS days actually it was very common to use screen capture TSRs that would capture the screen it its entirety to a file when you press the assigned key. The best one I ever used was CAMERA.COM that came with the PC version of Deluxe Paint II Enhanced, but whether this is usable depends on whether these Lucasfilm games took full control of the keyboard.

The trackers actually has not been closed. It's just sort of abandoned and moderators who have access to update it are just too lazy to bother to do so.

This also depends on the spec of the system running the game though.

However, I don't see a benefit in using arrays other than Get/Set Pixels, apart from easier coding. Chances are, it's equally slow in using either of these representations, as what I know is, the colour values used in AGS' colour system DO NOT match the raw graphics data (except in good o' 256 colour mode), as say there're the annoying reserved colours #0-31 and that even in 32-bit mode you can only set/get colours in 16-bit resolution (I'm actually planning to make a new thread about attempts to improve this without breaking the current system, but I don't have time yet), so when you access an element from that array it's not likely be a simple read or write from a normal array, but instead the engine has to do the Get/Set Pixel route to Get/Set the values.

It won't work because you're checking whether stuff collide in the room Fade_In() event, i.e. it's only being checked once, and it's even just right after the object megins to move.

You need to check this in repeatedly_execute() instead, something like:

Code: ags

function repeatedly_execute(){
  if (IsTimerExpired(1)) {
    if (cindy_bones.IsCollidingWithObject(object[0])) Display("You've been squashed. It's the end of your journey!!"); 
    else Display("Congratulations! You escaped from the trap!");
  }
}

mouse.x and mouse.y use screen coordinates for obvious reasons. So, if you use scrolling rooms, make sure you write the destination of Walk() as GetViewportX()+mouse.x and GetViewportY()+mouse.y .

Note that for functions triggered by the same condition (such as on_mouse_click() ) the one in the room script will be executed, and then the one in the Global Script, so if you want to have the room script one override the global one, put a ClaimEvent() in the room one, so that the global version won't be executed afterwards.

How large is your room (i.e. is it a scrolling one)? Also, are the walkable areas complicated? (I find it odd that even WalkStraight() isn't that efficient here though.)

These pauses are most likely caused by the path-finder looking for a route.

let me be a little more clear on what i'm doing.

I tried this and it's not working in the room script.  The following code is at the top of room script:

Code: ags

function on_mouse_click(MouseButton button)
{
  if ((Alpha) && (Button = eMouseLeft)) {
     cNPC.Walk(mouse.x, mouse.y, eNoBlock, eWalkableAreas);
   }
}

Are you sure you copied this section of codes from your script or you just typed them here?

There're some errors.
1. Button or button?
2. Button == eMouseLeft

Also, make sure that Alpha could indeed be set to some non-zero value in the game.

You can actually add the function on_mouse_click() to the room script. It behaves the same as the global one. You can also use Mouse.IsButtonDown() to check whether a button is being pressed in some particular time (e.g. check it in repeatedly_execute() ).

I think preprocessing of the script in AGS' script compiler is limited, so that's precisely why it won't work, otherwise, things like int blah[2x4] and forward reference of functions should be possible as well.

You can make a dummy GUI with a listbox that's never shown and Fill it with the savegame names first. Then copy its content entry by entry (and cut off the date-time part) to another listbox that is actually shown on the GUI.

Something like:

Code: ags

lstDummy.FillSaveGameList();
lstReal.Clear();
int ii=0;
while (ii<lstDummy.ItemCount){
  lstReal.AddItem(StripDateTime(lstDummy.Items[ii])); 
  //Suppose StripDateTime() is a function that strips the date-time part from the savegame name.
  ii++;
}

(Depending on whether you want to keep the list of the original names. If you do not need them you can use only one list. After filling it with the names, just modify its content item by item:

Code: ags

lstReal.Items[ii]=StripDateTime( lstReal.Items[ii]);

)

What's zVerily?

It's the most awesome thing in 3-D modelling history but yet Blender never dares to support it.