Messages

AFAIK, ListBoxes can't have multi-line items, so you can't get the wrap-around effect you want you want. I tink you'll need to split the longer lines of text into shorter ones that fit the ListBox. You could write a custom function for adding items to the ListBox, that automaticaly splits too-wide lines into multiple entries.

Code: ags

function AddItemWrapped(this ListBox*, String text) {
  if (GetTextWidth(text, this.Font) < this.Width) this.AddItem(text);
  else {
    String TempItem = text;
    while (GetTextWidth(TempItem, this.Font) > this.Width || TempItem.Chars[TempItem.Length-1] != ' ') {
      TempItem = TempItem.Truncate(TempItem.Length-1);
    }
    this.AddItem(TempItem);
    text = text.Substring(TempItem.Length, text.Length-TempItem.Length);
    this.AddItemWrapped(text);
  }
}

(Use in place of ListBox.AddItem. Quickly tested - works OK, but might not be what you want.)
That, or work out line lengths and split them yourself...

The problems I can see here are that you won't be able to check/manipulate items as easily - you won't know if a given item needs to be combined with the lines before or after it to get the full text, how much of the text is in each 'line' (without testing the game and checking), and obviously deleting items becomes harder as well (if you remove item[X], do yu have to remove item [X+/-1] as well?). I'm not sure how you'd simply resolve these, sorry.

Where exactly have you put that code? AFAIK variables, including structs, have to be set in a function or at declaration, which isn't really practical with Structs... Just having them 'loose' in the script (as it looks like you've got) would probably kick up that error. The 'structs and arrays' example kind of mentions this, the one you quoted obviously doesn't but it still applies.

I think KhrisMUC's code can be adapted to give you that, as well. If I understand it properly, it works out the 'steps' the bullet has to take between the start point (e.g. player coords) and the end point (e.g. mouse coords) based on a certain speed (which I guess is distance covered per frame). Someone feel free to step in if I'm talking complete rubbish here...

If you only work out the first 'step' then, with the right 'speed' value, you should have your finite ray, right? (Assuming that means 'a line to a point that is part way along the line from A to B'.) I think you'd need to move part of KhrisMUC's 'shooting code' section into rep_exec, so the start and end points are recalculated each time the line is drawn. I'm not sure how having 2 constantly refreshing DrawingSurface features (the bullet and the line) will interact together. It might just be a case of getting the condition nesting right (so they don't refresh each other out of existance), or it might just look a little - well - wonky

Unless they're not two separate features, and the line IS the bullet? That would be easy enough to do, just draw the line as between the current position (bx,by) and the previous one (bx-dx, by-dy), or calculate 2 new floats for a shorter distance (similar to how dx and dy are calculated in the 'shooting code', but with a value less than speed. (Very little of which will make ANY sense, until you've looked over KhrisMUC's original code.)

Unless I'm misreading KhrisMUC's code, it already calculates the new position for cBullet every frame in rep_exec (adjusting the location*) rather than working out the end point up front and moving there directly (a continuous line).
So, all you need to do is draw your bullet at the current position (bx, by by that code) then the next frame remove it and draw it at the new coords. I think you'd need to make a second DrawingSurface, containing a 'clean' copy of the background image, and restore to that to remove the bullet between frames. (Or, a Character would be easier .)


*Or did I misunderstand your post and this refers to the 'removing the bullet between frames' part (without which, yes, you would be left with a continuous line along the bullet's path)? If so Sorry, and hopefully the rest of my post is more use.

How about a 'Help Wanted' type of thing: putting writers, artists, developers, musicians, whatever together? Like the 'Recruit A Team' and 'Offer Your Services' threads but on a larger scale, and maybe not restricted to AGS projects only. You could also give them a place to collaborate after they've met up - host 'meetings' via private discussion boards, share concept art, etc. I'm not sure how do-able that'd be, or how you'd build the reputation needed to get people joining, but it's the only suggestion I can think of...

Is KhrisMUC's answer to a similar question from Mirek any good to you? (Second reply - first post linked for context.) It takes the bullet on a path from the player's location, to the mouse, and beyond until it leaves the screen (or hits something presumably). It uses a Character rather than surface.Draw, but it might give you a starting point for working out the coordinates needed.

Nope, no need. This is pretty much exactly what UseModeGraphic was made for - it doesn't change the mode, just the graphic - and UseDefaultGraphic sets it back to normal. No need to store the 'normal' graphic or anything, provided you use both commands.
Now, if you wanted to set eModeWaits cursor to the current mode and back again you'd need a variable, something like

Code: ags

int TempCursor = mouse.GetModeGraphic(eModeWait); // Store eModeWait graphic
mouse.ChangeModeGraphic(eModeWait, mouse.GetModeGraphic(mouse.Mode)); // Change eModeWait to current mode graphic
DIsplay("Hello.");
mouse.ChangeModeGraphic(eModeWait, TempCursor); // Change eModeWait to current mode graphic

Personally I don't think that'd look as good, though. Still, matter of preference.

You could try setting the current cursor mode's graphic to the Wait graphic before Display commands, and then back afterwards

Code: ags

mouse.UseModeGraphic(eModeWait);
Display("Look at me!");
mouse.UseDefaultGraphic();

('displaying a "wait" cursor temporarily' is actually the example given for UseModeGraphic in the manual.) It might get fiddle-y to do it for every single line, but for longer 'conversations' between the narrator and the PC it'd at least avoid the cursor switching back and forth. (You could write a custom function to handle it instead of using Display - but then you'd have to change every line you've already written.) A similar work around would be to use mouse.Visible to turn the cursor off during those exchanges.

Changing Display commands to cNarrator.Say (or a custom function as mentioned above) would mostly be a simple case of find-and-replace. The only exception I can think of is if you're displaying variables in the text (Display("You have %d gold." player.InvetoryQuantity[iGold.ID]);), in which case you'll need to use String.Format: cNarrator.Say(String.Format("You have %d gold." player.InventoryQuantity[iGold.ID]));. So, a bit of work, but not quite as bad as having to re-write everything. (And a Character doesn't have to be in the current room to speak, AFAIK, so you don't need to worry about making them follow the player.) Of course, it's a matter of preference, too - I think the Display box would look better than disembodied Character speech, but that might just be me...

So, where and how bad is the lag, exactly? Both Hotspots or just one?

You just need to use PlaySound and Random.
It's easiest if the sounds you want to play are numbered consecutively (sound1.mp3, sound2.mp3, sound3.ogg, etc) then you just need

Code: ags

PlaySound(4+Random(4));

Which'll select and play a random sound between 4 (4+0) and 8 (8+0). Or more generally: PlaySound([number of first sound] + Random([number of possible sounds]);
If the sounds aren't consecutive, just set an int to the random number and use a bunch of if ... elses

Code: ags

int ToPlay = Random(4);
if (ToPlay == 0) PlaySound(27);
else if (ToPlay == 1) PlaySound(56);
//... Ect

Im sure its very easy to code but I just got to the point of learning to make one sound file play lol.

Yeah, this is pretty easy stuff, even if you are just starting out. Get comfortable with what you do know before How I figure things out is to just read through the manual and actually try things out - even if you can't get it working, you can show what you've tried which (when you get to more complicated stuff) might give people a better idea exactly what you're after. At least you won't be posting questions that you can answer yourself less than 10 minutes later...

What am i doing wrong ?

Importing them one at a time - that's not how importing masks works. Put ALL your walkbehinds on the same mask, then import it once. If you used the right colours (or just got lucky) that's all you'll need to do (AGS takes the number of the Walkbehind from the palette number of the colour used). If they import with the wrong walkbehind in the wrong place (where you wanted walkbehind 2 is walkbehind 8, etc) just go through and re-colour them with the Fill tool. (Same procedure for Hotspots and Walkable Areas.)

Ah, OK. Happens to the best of us  
For that matter, you could use hotspot[0]'s interactions - it covers every part of the screen not filled with another Hotspot, so you don't need to 'waste' one just for this. You'd still need to include the Walkable Area check, but otherwise that way would work fine. The one downside being, you'd have to add the interaction to every room...

EDIT:
Actually, could you use unhandled_event, in the Global Script, for this? You'd need to do a Hotspot.GetAtScreenXY check, but that's not too bad. I still prefer my way, though.

I was thinking 'dangerous to the player character' dangerous, rather than 'could introduce bugs' dangerous. Should've explained it better.
For example, if your game had interactions triggered by the PC walking over a region then having them start walking when the player didn't mean for them to would be frustrating to say the least - and if that accidental movement could cause the PC's death, would probably count as a good reason to stop playing the game and never go back. Provided the player knows that any click on an area they could reasonably walk to will make them walk there - or if your game doesn't have any @!*king annoying boobytraps in the first place - it's not really a problem.

Speech, I think, counts as blocking (especially if it's unskippable the way you've got it set up), so it's going to display the 'waiting..' cursor whether you've got an actual Wait() command in there or not.

Try using mouse.ChangeModeGraphic() to make the Wait mode cursor less conspicuous (i.e. look like another mode), or even mouse.Visible to make it temporarily invisible.

Oh if it's just for a one-off interaction, then yeah, my way is probably overkill. I thought you were after a more general money system, sorry. Hopefully you can pick something of use out of it anyway...

Walkable Areas don't have interactions, do they? Or am I misunderstand what you mean by 'the Any Click script'?

I think you'll need to alter the on_mouse_click function to act as if eModeWalkto was used in that case. For example

Code: ags

  if (button == eMouseLeft) {
    if (GetLocationType(mouse.x, mouse.y) == eLocationNothing) ProcessClick(mouse.x,mouse.y,eModeWalkto);
    else ProcessClick(mouse.x, mouse.y, mouse.Mode);
  }

Should treat all mouse clicks not on an Object, Character, Hotspot or GUI as eModeWalkto clicks. You might want to add an extra check in there that the click was on a Walkable area (&& GetWalkableAreaAt(mouse.x,mouse.y) != 0), otherwise the character will try to get as close to the click as possible which could be more annoying than having to change modes - or even dangerous, depending on your game.

Another option is to have right-click act as a 'default' interaction (Walk-to if clicked on nothing, Talk-to Characters, Look-at Objects, Use Hotspots, etc).

[Timer only]

Or, if it's just for that one scene, try SetSkipSpeech(2); - which is the same as Timer only in General Settings, but won't annoy people with non-skippable speech through the whole game... (For Display commands, I think game.skip_display = 2; is the equivalent.)

Couldn't you just disable Walk mode for that scene? (mouse.DisableMode(eModeWalkTo);)
I don't know how it'd work with, for example, Hotspot walkto points - I think they'd still make the player walk, unfortunately - but it seems a little less ... workaround-ish than turning off the walkable area under the player.

Having an item for each amount of coins seems like a waste of Items, to me. Why not just have one (iGoldCoin) and use player.InventoryQuantity to check how many they have? You could rename the item (InventoryItem.Name) as well as changing the graphic. To make things easier, I'd make a couple of functions to handle the changes for you

Code: ags

function AddGold(int GoldToAdd) {
  while (GoldToAdd > 0) {
    player.AddInventory(iGoldCoin);
    GoldToAdd --;
  }
  if (player.InventoryQuantity[iGoldCoin.ID] == 1) iGoldCoin.Name = "1 Gold Coin";
  else iGoldCoin.Name = String.Format("%d Gold Coins", player.InventoryQuantity[iGoldCoin.ID]);
  if (player.InventoryQuantity[iGoldCoin.ID] <= 5) iGoldCoin.Graphic = 31 + player.InventoryQuantity[iGoldCoin.ID];
  else iGoldCoin.Graphic = 37;
}

function AddGold(int GoldToLose) {
  while (GoldToLose > 0) {
    player.LoseInventory(iGoldCoin);
    GoldToLose --;
  }
  if (player.InventoryQuantity[iGoldCoin.ID] == 1) iGoldCoin.Name = "1 Gold Coin";
  else iGoldCoin.Name = String.Format("%d Gold Coins", player.InventoryQuantity[iGoldCoin.ID]);

  if (player.InventoryQuantity[iGoldCoin.ID] <= 5) iGoldCoin.Graphic = 31 + player.InventoryQuantity[iGoldCoin.ID];
  else iGoldCoin.Graphic = 37;
}

Then, you only need to use AddGold(5); LoseGold(1);, etc, and everything is handled for you.
NOTE: This assumes you have graphics for 1,2,3,4 and 5 coins in sprites 32-36 (31 + amount of coins held), and a generic graphic for 'more than 5' as 37. I recommend you keep the graphics in consecutive slots like this - it's easier to code like above, than having to jump all over the place - but you can have as many as you want/need. And obviously, it doesn't matter what sprite numbers they are, just change the code as needed.
NOTE 2: Untested. I'm not sure what'll happen if you try to lose more gold than you've got, but it'd be easy enough to add a check to prevent that if it causes problems...

Try

Code: ags

  if (player.ActiveInventory != null) {

game.inv_activated is: a) an int value, not an InventoryItem (the ID of the Item), and so can't be null (-1 might work, though); and b) the last item CLICKED ON, not the current 'active' Item (I think it includes 'Look At Item', 'Talk To Item', etc, interactions).
(Pre-v2.72, player.activeinv is the way to go...)

EDIT:
Alternatively, the method you already have for referencing the Item - inventory[game.inv_activated] - can be null, but as I said isn't actually the ACTIVE Item, just the last clicked...