Messages

Hmm, stuck again.

Spoiler

You need the code for the keypad-protected door. Try looking in the file cabinets to find a clue to the code

[close]

what do you do at the beginning of day 2?

Spoiler

First of all, head back into the bathroom and read the newspaper

[close]

Also stuck in Day 5, got the number plate but I can't find Yoshi what do i do??

Spoiler

Try asking the desk sergeant at the police station

[close]

I'm stuck at Day 5:

Spoiler

I actually just mentioned to Grundislav that there should be a visual hint for this puzzle. Try looking at the left computer in the office.

[close]

No I haven't? Tried to put no-one to translate

Spoiler

I'm not sure which day you're on, but you need to visit the widow twice, once with Alice and once without. Both times wearing the disguise. Have you read the days' newspaper yet?

[close]

I've got the hook from the acquarium, looked around Osaka I don't know what to do next?

Spoiler

Have you returned to the widow's house in the village yet?

[close]

what do i have to do with the dead guy's body now I'm in the japanese lady's house in the village?

Spoiler

If you haven't clicked the hand icon on the CSI kit in the inventory to open it, do so now. Then click the syringe on the dead body

[close]

Another solution, which might be easier to implement (but to be honest I don't have a clue if it actually is):

RawDrawImage(int x, int y, int slot, optional int baseline)

To rawdraw a sprite, but only the part of it which wouldn't been hidden behind a walkbehind if its baseline was set to a specific y coordinate.

This may be a strange request, since personally I have several workarounds. It's just something that would make it way easier for other users should I release my ShadowBox module to the public:

RawDrawWalkbehind(int walkbehind, int color)

The function would RawDraw a mask of the walkbehind area filled with a color set by the user (usually 63519). It's purpose would be to assist in other RawDraw and DynamicSprite functions.

Edit: Possibly there should be third parameter to decide whether the walkbehind should be drawn in positive or negative (fill the walkbehind area, or everything but the walkbehind area).

Looks good, but I'm wondering about the positioning of the pocket. In some of the animation frames it looks like it's below the knee! I wear pants similar to these, and the top of my pocket is mid-thigh while the bottom edge is knee height.

Except for this, I love the style of the character.

Well, technically you're not supposed to SEE the light source itself, that must be handled as an object. However, if you set the optional int lensflare value to 1, you will get an effect of the light shining into the camera.

I haven't been this disappointed since the Tierra guys pulled that mean prank about having released a speech pack for KQ2.  It was a 25MB download for Christ's sake - and I just spent four hours downloading it on my 28k dial-up connection before discovering the truth. That's just so immature ILuvBJs, grow up please!

This is the most brilliant news. For a long while I've secretely been contemplating switching to the WinterMute engine, since its scripting language seems so much more intuitive than that confusing Interaction editor. Not to mention the walkbehind and pathfinding tools. So this is just perfect.

May I suggest though that the maximum resolution is raised to 1600x1200? 1024x768 is far from enough for a modern day adventure game. And also, have you considered joining forces with the TADS developers to replace the current parser functions in AGS?

CJ, this is truly a great day in adventure game history.

Spoiler

Or maybe it's rather about the other dimension beyond the cell. Remember, the guy isn't stuck there forever, only till someone else comes along. But I'm sure that other place is something quite difference than the paradise it's made out to be.

[close]

You forgot one variable type.

char: Short for character, holds a numerical value of 0-255. Each value also represents an ASCII character (a letter, number or symbol).

Thanks for the reply, CJ! And you're totally right, my current attempts at freeing/assigning DynamicSprites on save/load IS quite the mess, so I'd be happy to get rid of those functions - with 50 savegames it's not going beyond 200MB anyway, and most people have that much free space on their HDs.

So you're suggesting that I don't delete dynamic sprites when saving? That would surely make coding a lot easier, but I considered it a bit sloppy. You're right that it would be the easiest solution though, and I wouldn't feel as bad about using it if it's suggested by Pumaman himself .

My current savegames are 3 MB when using dynamic shadows for one character, without any other effects going on, so I was afraid what would happen in more intensive situations. But perhaps it's because the RawSaveScreen() buffer is also stored within the savegame?

I'm using a lot of DynamicSprites for effects in my game. For that reason I've had to write commands to delete all these before saving, so they won't be bloating the savegames. However, since the 'savegame with screenshot' function grabs the screenshot at the moment of saving, any DynamicSprite that I've deleted before saving won't show up on it. In some cases this even means the player character missing from the screenshot.

So what I propose is a slight expansion of the save function:
SaveGameSlot (int slot, string description, optional int screenshotslot)

For the screenshotslot, you could then specify a DynamicSprite.Graphic, that you grabbed before deleting the other dynamic sprites. However, and this is the small hitch in the idea, the DynamicSprite for the screenshot would also have to be deleted at the moment of saving, but after being stored as a graphic within the savegame. So the SaveGameSlot function would have to handle the deletion of this single DynamicSprite itself. Would that even be possible?

This isn't too hard to code around (although it does mean that all actully mean that all lines must be called in dialog_request). I wonder actually whether it wouldn't be more effective to expand AGS' general dialog functionality than adding more single-purpose features: What if it was possible to specify a (user made) function that all lines of dialog were parsed to automatically as the line was said? This would allow for much customizability without use for constant dialog_requests.   Something like on_dialog_said(String dialog, int characternumber). This would allow us to show the dialog String in any way we want, change the color according to the character saying it, showing dialog portraits wherever we want etc.  Of course dialog_request would still be used for running any dialog-option-specific action.

As for Radiants suggestion for a solution, the main problem is that LucasArts speech doesn't allow antialiasing.

So, just my imagination then 
Thanks for the reply CJ!