Messages

Well, your functions are in the wrong order for AGS (you're calling them before they're defined) - that doesn't really matter here, but it'll cause proplems in the game. character[EGO] could be shortened to cEgo, or player if they're the player character, but otherwise it doesn't look too bad.

One thing: In your description it sounds like you want to say either the Custom Property text (lookSay, useSay, etc) or the common_hotspots_(whatever) text, but the current script would display both. What about something like:

Code: ags

Hotspot* myHotspot;

function common_hotspots_lookSay(String name) {         // long list
   if (name =="house") player.Say("this looks like a house"); 
   if (name =="tree") player.Say("this looks like a tree");      // etc., etc.
}

function common_hotspots_useSay(String name) {      // like 'lookSay' but many objects never get used
   if (name =="house") player.Say("I don't think I'll disturb the people who live there.");
   if (name =="tree") player.Say("I don't feel like climbing trees right now.");
}


function generic_hotspots_click() {         // called from the global script mouse click
  myHotspot = Hotspot.GetAtScreenXY(mouse.x, mouse.y);
  String Temp;
  if(mouse.Mode ==eModeLookat) {      
    Temp = myHotspot.GetTextProperty("lookSay");
    if (Temp != "") player.Say(Temp); // If there IS a custom lookSay response, use it.
    else common_hotspots_lookSay(myHotspot.Name); // Otherwise, get the generic response.
  }
  else if(mouse.Mode ==eModeInteract) {  
    Temp = myHotspot.GetTextProperty("useSay");
    if (Temp != "") player.Say(Temp);
    else common_hotspots_useSay(myHotspot.Name);
  }
}

I removed the maySay function, because I wasn't quite sure what it did, and merged the name-checking bit into the common_hotspots_(whatever) functions. Hopefully, this should still work as you want, if not just put maySay back.

And SSH beat me to linking his MultiResponse module, so I'll just agree with him...

Not really an AGS technical question, so I'll shift it to talk and chat.

Sorry I can't really help, except to suggest you try the All the paint programs you'll ever need.

It's not "Denver, The Last Dinosaur", by any chance? I'm sure that had skateboarders and/or BMXers in, and I was young enough to think that was cool.

EDIT: And now I have a vaguely remembered, probably wrong, version of the theme stuck in my head. Terrific.

Wait, does making the other person cry mean "mega win for me", or have I lost now?
These rules are too confusing. Let's just agree that Dexter kicks ass and share the avatar, shall we?

(I like the alternating Dexters down the sides the last few posts. Awesome, and kind of creepy.)

But I was using it first, so I win. (Anyway, mine's more mysterious looking, and therefore cooler. Double win )

There's an extra step you have to take, to make it work now. While you used to be able to access the frame directly with SetFrameSound, you now have to make a ViewFrame pointer to the frame and use the ViewFrame.Sound property. The example in the manual is pretty clear for the first part (making the pointer), although it only shows getting the property, not setting it.

Basically, instead of:

Code: ags

SetFrameSound (1, 2, 0, 25); // Set Frame 0 of Loop 2 of View 1 to play sound25

You'd now use:

Code: ags

ViewFrame *frame = Game.GetViewFrame(1, 2, 0); // Create pointer to Frame 0 of Loop 2 of View 1
frame.Sound = 25; // Set frame's sound to 25

To change multiple frame sounds, you need to update the pointer and repeat:

Code: ags

ViewFrame *frame = Game.GetViewFrame(1, 2, 0); 
frame.Sound = 25; // Same as above
frame = Game.GetViewFrame(1, 2, 3); // Now setting Frame 3 of Loop 2
frame.Sound = 25; 
frame = Game.GetViewFrame(1, 2, 6); // And Frame 6
frame.Sound = 25; 
//etc

Somebody asked a noobish question, somebody else answered it, and then a mod locked the topic stating that question was not allowed to be asked, and kindly RTFM.

Since I was that moderator, I feel I should address this. The rules in BTQ are pretty clear on RTM-type questions:

A lot of beginners' questions on this forums have to do with very simple things, and most often it can be found in the main manual itself. So don't get upset with us if we simply tell you to read the manual and lock your thread.

...

From now on, if any of us are reading a thread that has an obvious answer and if we can tell that you haven't read any of the rules or the resources below, we will simply lock it. We shouldn't have to clean up after you guys if you very well know where your topic should go and what it should (and shouldn't) contain.

If a threadstarter doesn't seem to have read the manual/BFAQ/forums, the thread will be locked. This isn't descriminating against newcomers, it'd be the same for anyone. It just happens that newcomers are more likely to ask those kinds of questions.
IIRR, the rules used to say 'we will delete without warning' - that was harsh, and encouraged further needless posts (re-asking the question, and asking where the original thread went). With a lock, the poster gets their answer, it's more likely someone searching in the future will find their answer, and useless threads can't be revived and drop off the first page. What's unfair about that? Without a 'don't do this again' post the poster mightn't realise WHY they've been locked, which would seem more like arbitary and unfair overmoderation, IMO.

If another forum seems more approriate, of course it'll be moved there, but some excessively n00bish questions (n00b to differentiate from newb, which we all were once) just don't belong anywhere, as far as I'm concerned.

GetPlayerCharacter() is obsolete in newer versons (2.7 and on). The player pointer will update to the current player character, for commands like player.Say, player.Walk, etc, and player.ID should be used if you need the character number.
invCustomInv has it's Character ID set to -1 in the editor - that means it updates to the player character too, so you don't need to use CharacterToUse. (If you make your own Inventory GUI, you can set it to use -1 as well.)

Ralkai, Character.SetAsPlayer is in the Manual (Mirek basically copied the entry here, so I won't link it), and this question is answered in the BFAQ. Please check in those places, and search the forums, before posting.

Writing your own functions to avoid duplicating code all over the place pretty much is the normal way of things in AGS - that's one of the reasons the ability is there. (In so far as there is a 'normal' way in AGS, at least.)
It's also easier to trace bugs if your code is more centralised, and AGS is pretty good about telling you where they are, anyway.

What you're after wouldn't be too hard (well, this part won't - it's an ambitious project you're planning), so don't let that worry you. You'd just need a function to check a value (to see whether you clicked a Tree or an NPC, for example), and the Cursor mode (for what interaction to run) - which is pretty simple - and some way of running that function - which could range from simple (like calling it from the 'Any click' interaction) to slightly trickier (use Custom Proerties and a bit of fiddling in on_mouse_click or unhandled_event to handle it automatically). Since this is kind of off the original topic of the tread, feel free to PM me, if you want to discuss it further. (Or start a new thread when you've got some actual code, of course. Hopefully, by that point you won't be as new to AGS, and not as unsure about what's possible.)

To expand a little: The 'grey bar' (gStatusline) is nothing to do with when gIconbar appears. To change that, or any 'Mouse Y-pos' type GUI, you need to change the 'Popup YPos' value of that GUI. This is in the manual, under "Editing the GUIs":

The "Mouse YPos" option means that the GUI only appears when the mouse vertical position moves above the y-coordinate set with the "Popup-YP" option.

In a defaul AGS game, it just so happens that the height of gStatusbar is the same as gIconbars Popup YPos - but the two aren't really related.
Also, if you don't want gStatusbar interfering with you map screen, why not turn it off when you enter that room, and on again when you leave? (GUI.Visible can also stop Y-Pos GUIs, like gIconbar from appearing in that room, too.)

If it's for 'cutscene' style animations, where you don't need player interaction, why not just use full screen flcs? I think the 'Don't clear screen' option will get rid of the 'flash' you mentioned (which I've heard of, but never seen myself, so I can't be sure).

One suggestion for working around the sprite limit, though. Since you say they're mostly small sprites, what if you import them as several frames on one sprite, and use the DynamicSprite functions to crop them down on the fly? I'm not sure what the processing time would be, particularly when you're talking about 1,000s of frames, but it might be worth a try. Even if you only do 2 to a sprite, that halves the number you'll need. (Howevr, this is entirely untested, so don't hold your breath. It might just cause more problems.)

Or, of course, you could use less frames

This sounds like a confusion of vocabulary to me, and since I'm kind of obsessive about details, I'd like to clear that up.
You don't seem to want a 'global object' in the AGS sense of an actual thing that can move between rooms, but rather a way to call the same code from multiple locations without having to duplicate it. To make an AGS Object (like you'd create in the 'Objects' pane of the Editor) that can move between rooms, Characters are the way to go. For the second thing, not so much.
I suppose you could set a Hotspot/Object/whatever's 'Any click' interaction to cTree.RunInteraction(mouse.Mode), I don't think you'd even need cTree to be in the Room it was called from, and it'd run the code as defined in a single place (the Character interaction functions in the Global script). However that's really no different from just making your own function and calling that - which it sounds like you're doing already - except that it means you waste a bunch of characters.

If you post the code you're currently using, and why you think it mightn't be as reliable as you'd like, we could maybe suggest ways to improve it if needed.

What are you using this for? Is it background animations (crowd movements, etc)?
Flics don't HAVE to be streched to fit the screen (read the manual, which you already should've done) but even so wouldn't be particularly good for that. The flc would be played centered on the screen, but without transparent areas so it hides everything around it (if you use the 'don't clear screen' option, or with a black border if you don't). Additionally, they're blocking animations, so you wouldn't be able to DO anything while they're running.

If you can tell us why you need animatons with so many frames, we might be able to suggest workarounds - but the most obvious answer is likely to be "use less frames"...

Remember, the zombie is more scared of you then you are of it.

You're thinking of bears.

Read the manual: SetWalkBehindBase. (E.g.: SetWalkBehiendBase(1, 200);.)

For what you're after here, though, maybe it'd be easier to include a little extra on the bottom of the background graphic, and use SetViewport to stop it scrolling past a certain Y value? That way you wouldn't have to worry about setting baselines 'outside' the Room, continuous scaling of characters would still work, etc.

You'd probably be better doing them as seperate games, IMO. You could make a connecting, front-end game, and link them using RunAGSGame. Might take a bit of creative working around - but almost certainly less than trying to cram tham all into one huge game. (And would have the added bonus of making them individually playable - wouldn't have to download every sinlge update, just to play though one.)

Or try a forum search .. this was just asked about a week ago (well, 9 days).

OK, here's the most obvious problem with that code:

Code: ags

player.ActiveInventory=InventoryItem.GetAtScreenXY(mouse.x, mouse.y);
character[EGO].AddInventory(player.ActiveInventory);
Mouse.Mode=eModeUseinv;

Remember, you can't set as Active an Item the player doesn't have, which is what you're still trying to do. You need to add the Item THEN set it as active. Try:

Code: ags

Item *Clicked = InventoryItem.GetAtScreenXY(mouse.x, mouse.y);
character[EGO].AddInventory(Clicked);
player.ActiveInventory = Clicked;
// Cursor mode automaticaly changed to eModeUseinv when ActiveInventory is set

Also:
* Do you really want to set the newly-added Item as active? You don't have to, to 'select' the Item from the shop, is there some other reason you're doing it?
* Is there no check for "Are you sure you want to buy (whatever)?" (or even whether the player can afford the item)?

There was a Coding Contest about Trading as well, maybe you could get some ideas from there?

By default, AGS treats a eModeInteract click on an Inventory Item as 'set this as the Active Inventory' - and you've discovered what happens if you try to set as Active an item the player does't have. The most obvious solutions would be: change the Cursor mode to someting other the eModeInteract (and stop the player being able to change back while the shop GUI is open) or make the Merchant character the player Character while you're in the shop.

I haven't so far found a way to assign script on an inventory box click

Do a forum search for 'Handle Inventory clicks in script'. The manual is a bit vague, but it's been dealt with enough times that you should be able to find a decent description somewhere. (But just not using eModeInteract is much easier...)
If you've already got 'handle inv clicks in script' checked and didn't realise (e.g. from some template/tutorial), you should be able to edit the on_mouse_click function to react to what GUI is open, so it doesn't generate the error you're getting

but that way i wouldn't be able to just have one GUI and only give the Merchant different goods in each room, i would have to design many GUI's

Not quite true. You could set up conditions to change the Button graphics before opening the GUI (changing the 'stock' of the store), and within the Button Control functions to sell different items based on some other variable (Room number, Button graphic, etc), so it'd behave in a similar way to using an Inventory window. The Inventory method would be a LOT easier, though...

How to handle changing rounds... There're a couple of fighting game engines available already (e.g this one, Gord's Template a few posts up, or these Coding Contest entries) - they probably won't be exactly what you're after, but they should give you a few ideas.

[else]

RandomBoundaries() is an Advanced Randoms function, yes. However, you're not actually doing anything with it - you just have RandomBoundaries(1, 10); on a line by itself. It looks like you might be trying to set a random value for door_defense, which would be lockpicking(RandomBoundaries(1, 10)), but at the moment it just generates a value which is ignored.

Anyway, if that's all you're using from the Advanced Random module, having the module might be a bit redundant. As Khris shows in the lockpicking function, it can be replaced with 1 + Random(9); (In fact, I'm pretty sure all the function does is return min + Random (max-min);.) Of course if you're using the other advanced features elsewhere, you might as well use RandomBoundaries since it's there.

And Random definitely is in the manual.

One thing about Khris' code - unless I'm misreading it, the Display("This door is already unlocked."); line will also run if the door IS locked (i.e. " You failed to pick the lock" "This door is already unlocked" - which might be a bit confusing). Make it else Display("This door is already unlocked.");, and that should clear up.