Messages

What caught my eye.

1. The UI assumes there's only 1 cursor mode all the time and never changes. Instead of setting cursor images for all built-in cursors, you could set it only for one (I'd vote for mode 6: Pointer).
Also, disable all modes except chosen one in game_start:

Code: ags

mouse.DisableMode(eModeInteract);
mouse.DisableMode(eModeLook);
... etc ...
mouse.Mode = eModePointer;

In GlobalScript:
1. You do this in repeatedly_execute:

Code: ags

if (gInventory.Visible)
{
    player.StopMoving();

Is it what BASS did? I don't like it, because that will be very annoying during action sequences. Though, I guess, user can remove this line.

2. Maybe make constant/macros instead of hardcoding "12" pixel edge which triggers inventory right in the function body?

In custom module:
4. The huge "if (!IsGamePaused())" condition block that covers all function body. This is a matter of personal code style, though I would suggest to make it instead

Code: ags

if (IsGamePaused())
    return;

This will reduce nesting level making code more clear to user.

5. "if (mouse.Mode == eModeUseinv) " condition will never be true, because you never set mouse.Mode. Instead, you can just test "player.ActiveInventory == null", or "!= null". This refers to both "if (button == eMouseLeft)" and "else if (button == eMouseRight)" blocks.
6. This, and merging al location types will produce the code:

Code: ags

if (GetLocationType(mouse.x, mouse.y) != eLocationNone) 
{
    if (player.ActiveInventory == null)
        ProcessClick(mouse.x, mouse.y, eModeInteract);
    else
        ProcessClick(mouse.x, mouse.y, eModeUseInv);
}

7. You are using "inventory[game.inv_activated]". IMHO that's bad. Although that may work, "game.inv_activated" is an obsolete variable, and also old-style code (also it is not very obvious how engine sets it).
I'd suggest to just use InventoryItem.GetAtScreenXY, it might be little slower, but it is a click handler, therefore does not matter really. Also you call GetLocationName anyway, and with GetAtScreenXY you'll get InventoryItem pointer with Name and everything. You won't need to compare names too (comparing strings is slowest operation of all, except only getting object under mouse), you will simply compare pointers:

Code: ags

InventoryItem *item = InventoryItem.GetAtScreenXY(mouse.x, mouse.y);
if (player.ActiveInventory != item)
    item.RunInteraction(eModeUseinv);

8. I don't think it is good to add "data == theGUI.ID" condition when you check that player clicks on gui. There may be other guis too, and the item should probably be deselected anyway.

9. I think it is simplier to test "if (button == eMouseRightInv)" in "on_mouse_click" to make player LookAt inventory item, rather than in "on_event". This way you won't need to test which mouse button is down, nor which Control is clicked.


//--------------------------------
EDIT:
I suggest to nullify info label at the start of mouse_click. Otherwise, the label text will stay on screen while player talks / does blocking actions.

Hahahahahahahaha 

BTW, you forgot to turn Debug mode off.


Version 2 should have a room and two animated characters.

Another quirky way to write this.

Code: ags

#define MAX_CHOICES 3;
String choices[MAX_CHOICES];

game_start()
{
   choices[0] = "paper";
   choices[1] = "rock";
   choices[2] = "scissors";
}

...

computerChoice = choices[Random(MAX_CHOICES - 1)];

Do I understand correctly that you are using GUI from "Default" template unchanged?

Create a new game with default template. Go to project tree GUI node, click on every GUI item with right mouse button, and choose "Export GUI". This will let you write all guis to files.

Then go to your real game, right click on GUI node and choose "Import GUI...". Load all the files you created previously.

Also, for the future: make copies of your game as you make progress. There are more terrible ways to screw up everything.

I still don't understand why everyone keeps scripting different actions for Talking and Interacting when using 2 click interfaces if the actions never overlap.

I really think Talk To should be abandoned in favor of Interact for simplicity's sake.

I agree completely. If the UI style assumes that there's only one type of activity with any kind of object possible, then there should be only one interaction type.

Yeah...
http://www.adventuregamestudio.co.uk/forums/index.php?topic=47530.msg636458612#msg636458612

I don't like it when user API is changed too often.

Which is ironic given your predisposition to implement new changes the pre-AGS 2.7 (a.k.a., "wrong") way now in hope of changing them later (based on the rationale that it will be "easy") in favor of implementing them in the post-2.7 ("right") way in the first place.

No...
There's already a certain style existing, which may be bad, but it does exist. If we add a new property or function of same (bad) style we will increase the amount of "bad" elements, but we will keep the language in the same form. If then we decide to rework the language, we may plan it thoroughly and split all those functions and properties to separate classes.
If, however, we add those elements in a new style, we have to decide which class/namespace they go, which may be difficult for we do not have a thorough plan about those classes yet. This may require to change their syntax/naming again later.
That's the simple reason I am reluctant to do this.
Okay, this might be my personal psychological issue... I won't deny that. :p

Regarding requests, there are numerous times when people were struggling to implement custom speech in their own way, and had troubles, for example, with playing voices. If custom speech styles were implemented, they could use standard Character.Say functions with custom speech rendering/behavior.

Again...

I don't know that I've ever actually even seen it requested.

Where are these "numerous times" that people have "[struggled] to implement custom speech in their own way"? Off the top of my head, I can't honestly think of a single example. You mentioned playing voices... I don't understand. Voice speech is a built-in feature...

Oh, come on.
http://www.adventuregamestudio.co.uk/forums/index.php?topic=48244.msg636457955#msg636457955
That's one asked 15 days ago. Sorry, I won't search for more, but such topics appear every now and then.
Also custom speech (as it is made now) makes it difficult to use Dialogs: you have to call your custom functions from dialog scripts instead of using common dialog syntax.

But in the particular example above, a single property was able to sufficiently replace three parameterless functions.

This left me puzzled. Which property and "parameterless functions" are that?

but are custom speech rendering methods really a priority request? I don't know that I've ever actually even seen it requested.

No, they aren't priority, I am just trying to think in advance... I don't like it when user API is changed too often.
Regarding requests, there are numerous times when people were struggling to implement custom speech in their own way, and had troubles, for example, with playing voices. If custom speech styles were implemented, they could use standard Character.Say functions with custom speech rendering/behavior.

[E:]

The proper way of naming properties should be more like an adjective (describing the current state) rather than a verb (action):

Code: ags

bool Game.SpeechPortraitOffsetsEnabled;

This is consistent with other built-in properties, and makes it clear that it is a property describing (and by being writable, changing) the current state.

Although, really, is this particular property even necessary? After reading the discussion about how it's implemented, it seems reasonable to have it, but I agree with Ryan's logic that the offset properties themselves are named misleadingly.

I am not sure what to choose, hesitating between -
SpeechStyle.*
SpeechStylePortrait.*
SpeechStyleSirra.*
also it may be set by properties, or function.

There's no certain plans for the future of speech styles, so this feels like a random selection.



E: I was trying to figure out how engine may let user to customize speech styles, and I thought it is possible to make it similar to custom dialog options rendering: you make an instance of some SpeechStyle class and few functions with built-in names, like start_speech, render_speech etc, that take SpeechStyle pointer to your object as parameter.
In such case it should be SpeechStyle with few built-in properties and array of custom properties (similar to characters etc).

if (GetLocationType(mouse.x,  mouse.y) != eLocationNothing)

I approve this code .

The last king of Scotland?

Correct.

I apologize for double post, there's something I did not notice in your script at first examination.
Now I clearly see you have a mismatching brackets issue, and your condition blocks are messed up.

First, there's extra opening bracket you do not need, at line 3 (I am refering to line numbers in your posted code, obviously, not the ones you have in actual script).
Then, you forgot to put a closing bracket for "else if (button == eMouseRight)" block. Just add a closing bracket between lines 31 and 32.

This mistake is probably a result of bad indentation at certain places in your code, you just need to align the text everywhere and you will easily see what's wrong.

There's a BASS template released recently, that may do what you want: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48441.0 (may save you some time)

On your problem, did you make a LookAt event handler function for your character(s) same way as you did Interact handler functions?

Well, I found this "voice lip sync" in code... the engine code is messy at the speech part. Can anyway provide any small project to test how lipsync works? I never did that lipsync thing myself.

Okay, maybe next time.
Of course, you may still find connection anywhere if you try hard .

What are the chances that you can include a way to use Pamela with Lucasarts speech?

I don't even know what Pamela is.

Anyway, that depends on how time-consuming that would be to do. There is a number of factors. First, I hoped to release this version as soon as possible, because it takes too long already (it's been 2 years since last official AGS release). Second, I have a number of tasks with high priority that I'd really want to complete. I am struggling to find time to work on these . Perhaps someone else would like to work on this Pamela thing? in which case it is theoretically possible to release an update, like version 3.3.1, a bit later.

E: Picture delayed...

Okay, bit of a tough one, this. Again, you need to also work out the link to the previous one:

Err... are there some new rules? It seems I missed something.
Should I post? Or should I post the movie linked to previous one?

Well, if you have a backup, I'd suggest you to replace the room which gives this error.

Otherwise, I don't know if you will be able to load the room in the editor... Maybe you can try to open only script and copy it somewhere, then recreate the room.

What AGS version do you use?
Were there any errors in the editor recently during the compilation or saving the game?

There's certainly a corruption of room file (*.crm), I think.

Yes, the small room like that can't take so much.

Might be a corruption in game data too. Did you imported a project in other editor version recently? What will happen if you run "Rebuild all files" command from menu?