Messages

Here's a thought. Mood comes down to style to some extent, so instead of pedantic descriptions, do more of a fragments of consciousness approach:
"elaborate patterns ... fading" of some old wallpaper.
"rough, and somehow comforting to touch" of a tree (specifically the bark where you touch).
"whoever lived here ... their personality feels still present." of the comfy chair in an old abandoned house.

In a given area, the incidental interactions can contribute to the general ambience or mood.

And you can still have humour that plays off the feel that you're trying to create.
For example, the character is alone, but feels watched, and so relieves the anxiety by acting as though someone else is there. "Oh, after you." stepping back from a door and gesturing before using it. "Anyone else for tea?" while making tea. That could be both funny and unsettling, as the player doesn't know it's coming, and has a moment of trying to figure out what just happened.

Thanks!
but... -.- ... I don't suppose you'd care to tell us what clue led to the correct question. o:
[edit (after entering password): Arrgh!]

Me likey. But rather than elaborate on that , critical comments below.

Spoiler

Bugs:
Final spell can be cast just by having the crystals.
Also, I had the same disappearing crystal problem, in a version uploaded after it was supposedly fixed.
Not bugs:
I read the book and saw the intro, so I already knew of two solutions to the start. But one of them didn't appear to work at first...
LOOK AT the doorknob?! Why would I want to do that when I can already SEE the keyhole itself?
Okay, so I get an unexpected bonus this time, but should I really click on everything with every mode.
(Maybe I should, since I have a spell and a party trick left over that I can find no use for.)

And yes, that last spell doesn't fit normally, reversed, or by questioning which way is really up for the image, or whether the image is inverted during projection. Actually, the rules exclude many possibilities.
I think they need to be more precisely defined and adhered to for a system of magic.

[close]

Also tried reading the room as pseudo-characters (equating "..." in Hood's statement with the 3 pictures).
That was either wrong, or I just wasn't seeing as intended.

(If I understand correctly, this was posted in the correct forum by Lionheart. So no flames from anyone else for it being moved here, kay?)

It means that your code is not understood by the parser, this is usually because of syntax.
For example,
all of your statements should end with ";" EXCEPT those ending with "}". This rule also applies to the last statement within braces ("{}"), thus you can't drop the last ";" in a block either.

As it's only line 3, I wonder whether it might be incorrect commenting or invalid variable declaration.

If you can't figure it out, show us the line (and a few each side for context).

The easiest way to drag the pieces would surely be to move the object clicked on in step with the mouse while the button is down.
As for deciding whether they are in position, you could test each piece individually after each drag, and decide whether it's within the target area just by using its coordinates. Then automatically make it pixel-perfect when they are all close enough to be considered solved.
Just remember that the object coordinates are the bottom left of the graphic, so you have to offset your target areas if you want to give the player some slack.

Sorry, I don't have time for ready-made code right now.

Ahh... It all makes sense now.
[edit: Well, to some extent. I'll have to do some more experiments to convince myself that the higher magnitude differences can be eliminated by rounding.]

I haven't dabbled in this area, so I have no suggestions. Although now that the problem has been posed it's going to linger in my thoughts for a while, so something might occur to me.

I've just finished a function for computing angles which I intend to use to make an angular displacement map for the entire screen. If there's anything in it, I'll send complete source (and screenshots. My function is pretty slow).
I have an image of the first test already, but I'm going to redo it with a clean room.

[edit]
Tests are done. I will find somewhere to post everything next.
(Actually, it wasn't so much the functions that were slow as having to put Wait(1) in the deepest loop.)
[edit2]
Done.

I think that you may get away with 1x1 walkables for which you can set the different scales. Alternatively, (and I'm guessing there's a reason that this won't be suitable) use that room as the basis for your sprite sizes.

First, I'll apologize for possibly going a bit far in the sarcasm area.

When I finish work I'll edit this post to include some sincere attempts at alternatives. Then I'll say nothing more on the matter.

[edit]
Three for each case, in order of preference.
1) per frame.
DUR, GP_FRAMEDURATION
RPT, GP_FRAMEREPEAT
CYC, GP_FRAMECYCLES
2) per animation.
"Animation lag", int 'lag'.
"Slow animation by", int 'slow'.
"Stretch animation by", int 'stretch'.

It is certainly more than that. It's about 16px in the room in which I first noticed it, and the test program shows variable but large exclusion zones around the walkable perimeter.

This test was just a centred circular walk area with the character centred and given each point on the 320*200 boundary.

I have a more informative test in mind when I can get the time to write it.

I don't entirely believe it myself, which is why I'm checking; there could be something odd about my coding instead.

Spoiler

The bookshelf was fun, but if there's some hint in it I must have missed it.

Walkie-talkie=paperclip? When I ran out of things to try, I used the walkie-talkie on the wardrobe, and Sam said "I'll just use this paperclip..."

Maybe that's what you mean by the bookshelf. I'll have to check.

[close]

It all started when I noticed that, whenever a non-walkable end point was used, the point reached was always to the left. Not the nearest, or in some symmetrical relationship with the end-point's x, the left.
So I wrote a test program, and sure enough it always tends left and|or up (depending on angle).
In addition some points actually exchange relative positions, e.g. the walk-to of the left end-point is to the right of the walk-to of the right end-point.
The ratio of perimeter-points to found end-points was about 10:1 in my test, but it wasn't really suited to measuring that.

I was also getting the hang of scrolling rooms at the time. Now I haven't done a proper test for this, but it seems to be much slower at coping with the above situation.

I'm not saying that anything has to be done about it, these are just some quirks that tech folk might want to be aware of -- or possibly misconceptions that I can be corrected on.

Fortunately, ogg is superior to mp3 8)
(unless you have to transcode from mp3   )

In that case,
SetCharacterBaseline(JUMPER,character[JUMPER].y+height);
where height is derived by the same calculation that your 3d enviroment uses, and which tells you where in space the character is.
This will have to be updated continuously, and the default behaviour will not be applicable often enough to bother with.

[three word label]

Well, I'm going to persist, persevere, endure, prolong, lengthen, extend, dally on this anyway.

This time, arranged by sense.

1) Animation frames.
editor: Views>(each individual frame)>"SPD"
script: GP_FRAMESPEED
How can a frame even have a speed? It has a duration only. In this case "wait", "delay", "stay", "keep", "pause", "hold", even "time", or changing one's point of view, "repeat", would make more sense.

2)Animations.
editor: Characters>"Animation speed"
script: Animate[Object|Character]<Ex>
In this case, "delay" is ambiguous. But, "speed" is not intrinsic to the commands themselves anyway, merely the word you've chosen to describe it with.

"Animation speed" doesn't have a tooltip in v2.56d, and there's no need to create one saying (to quote the manual) "Here speed means...". You could try a three word label instead.

We are adding time. I know language lets us down a bit here, but "slow", or "prolong" are descriptive enough, and there's no need to insist on a one syllable noun here.

...but then again, TEH 5p33d r0X0rz!!!111oneONEone :

character[ENEMY].room=-1;

Baseline is for the 3rd dimension. To keep it on the same plane, use
SetCharacterBaseline(JUMPER,character[JUMPER].y);
to fix it in place before the jump, then
SetCharacterBaseline(JUMPER,0);
to resume automatically sticking to the character's feet when back on the ground.

To my knowledge there's only-
Graphical editor:
Characters>"Animation speed" (directly beneath "Movement speed")
Views>"SPD"
-and script counterparts-
Animate[Object|Character]<Ex>
GP_FRAMESPEED

Not as bad as I thought, but enough to add a burden of doubt to every instance until I actually set out to research which was which.
I see this particular error a lot, so I pretty much assumed the worst on first sight.

AGS Help*>Text script functions>Character functions.
AnimateCharacter will likely suit.

*Use program menubar or just open the .chm file.

The character interaction editor is prolly the easiest way to trigger it.
Under the appropriate interaction, have something like,
MoveCharacter(EGO,character[ENEMY].x,character[ENEMY].y);
while(character[EGO].walking){Wait(1);}
if(AreCharactersColliding(EGO,ENEMY)){AnimateCharacter(EGO,attackViewNum);}

That may not work as is (I haven't tried that sort of thing myself), and isn't very realistic, but it's something to fiddle with.