Messages

It's on the skimbleshanks page. Scorpiorus.

Grim Reaper, now that we're looking at the right template :

There's a line in repeatedly_execute - it's line 88 in a new game, but if you've added code before that, I can't give an exact  number - that looks like this:

Code: ags

got_inv = character[EGO].activeinv;

I can't be bothered reading through the whole thing to figure out the sense of it, but it seems to change out of cursor mode 4 (UseInv) if got_inv is -1 (which should be the normal behaviour - like I said, can't be bothered working out the whole thing). When you don't have EGO as the player character, it doesn't update properly and you can't be in mode 4. (To me, it looks like the cursor changes to the Item for a split second then changes back - which would support this idea.)
Changing that line to:

Code: ags

got_inv = character[GetPlayerCharacter()].activeinv;

Works for me.

EDIT:
On a related note, it uses player.activeinv in unhandled_event. IIRR, the player pointer didn't update to when you change the player character before V2.7, so you might need to replace that with character[GetPlayerCharacter()].activeinv as well.

Since you're using mp3 audio, and AGS can handle crossfading between digital track internally (but not between midis), starting the 'new' track from the same position as the current one should allow a seemless transition between CASTLE REGULAR and CASTLE INTENSE (as you suggest in the second to last paragraph of the original post).
As I said, I don't really understand the iMuse thing, but I think that's what the module does.

Alternatively, you could use PlaySoundEx to add layers of sound, using different channels. However, I don't know if you're able to sync them to the current background track (actually, I'm pretty sure you can't), so it might not sound so good.

Would the AGSMuse module be of any use to you? It's meant to simulate at least some of the capabilites of the iMuse system - pretty much the ones you're asking about. I think. I freely admit I haven't got much of a clue what iMuse did, so I could be way off base here - try a forum search for iMuse for some more technical discussions, by people who actually know what they're talking about.

What the iMuse-based threads suggest is that coding a dynamic music system is far from beginner level coding, so this forum would be the place, if AGSMuse or those other threads aren't what you want.

Indeed.
The BFAQ entry also list what file formats AGS can import - if the sprites you've downloaded are jpg, for example, you'll need to re-save them as a valid format. (And probably edit them to get rid of artifacting and unnecessary colours.)

[was imported as]

How about something like this suggestion of InCreator's use a Room-sized graphic (assigned to an Object or Character) with an alpha channel, to overlay areas of light/dark. That's probably the best way to achieve leaf shadows, etc, as AGS' lighting system is strictly 'Mode 2' from your description (value at character/Object baseline is applied to whole sprite).

However, I think the manual actually means "Light levels only work when the character's graphic was imported as at the same colour depth..." When you import a 256-colour sprite (or a bunch of them from an flc) into a hi-colour game, they're internally 'upgraded' to hi-colour by AGS. That might not be the most acutate description, but I think the effect is the same - if you imported your sprites with the game set as hi-colour, lighting should work. The problem, AFAIK, would be if you imported all your sprites at 256, then changed the games colour depth. (Copying the sprite to clipboard, then re-importing it over itself should clear that up - time consuming, but not as bad as having to re-save and re-import everything.) Obvious thing to check, but have you enabled the 'Use Room area lighting' option (or however it's worded in your version) for Objects? And, is the Character/Object actually standing in the region, not just overlapping it?

I use a pale minimalist art style where the player's feet are not seen (so white ground must make feet white, grey ground make feet grey, etc.)

Why not jus make the feet transparent on the sprite? That way they're never seen, without having to change their tint repeatedly (which isn't simply done).

The reason there's been no updates here, is that I'm working with proskiier via PM to sort this out. We've got some semi-working code, but there's still some kinks to be worked out - once it's finished it'll be posted here for all to see, comment on, and generally point out that there's a much easier way of doing it...

you'd need to define a set of locations in each room for each inventory item to put ... Depending on an overall complexity of the game world this task may be not very trivial to accomplish.

If I understand proskiier right, this is only one room in the game - basically a trophy room for the Items you've recaptured - which makes it a whole lot simpler.

Might be too late, but you could also set up an on_mouse_click function in the room to capture eModeWalkto clicks on those Hotspots, e.g.:

Code: ags

function on_mouse_click(MouseButton button) {
  if (button == eMouseLeft && mouse.Mode == eModeWalkto) {
    Hotspot *H = Hotspot.GetAtScreenXY(mouse.x, mouse.y);
    if (H == hTop) {
      //prevent fall
    }
    else if (H = hBottom) {
      // Fall
    }
    if (H == hTop || H = hBottom) ClamEvent(); // Stops normal walkto click running
  }
}

As with KhrisMUC's suggestion, you'll also need to make a check that the player is actually falling first (in fact, I think you'd need to do that with Creator's code as well), as clicking the Hotspots too soon could have weird looking results.

OK, so many thiss floatng round, that I got confused about what this actually is ... However, I don't think you need to update this.X/Y after all. I think I see the confusion here - the cenx/y stuff, and AFAIK Gilbot's original suggestion, should be fed into DrawSprite, not used as dimentions for the rotated sprite. So try:

Code: ags

      this.temp=DynamicSprite.CreateFromExistingSprite ( this.Image.Graphic );
      
      int cenx = FloatToInt ( this.X ) + ( this.Image.Width / 2 );
      int ceny = FloatToInt ( this.Y ) + ( this.Image.Height / 2 );
      // Get the original center, based on the original sprite size and location
      
      // rotate
      if ( this.Angle > 0.0 && this.Angle <= 359.0 )
            this.temp.Rotate ( FloatToInt ( this.Angle ) ); // Rotate sprite, no resizing
      
      // draw the sprite
      Renderer.DrawSprite ( cenx - (this.temp.Width/2), ceny - (this.temp.Height/2), this.temp.Graphic );
      // Ges the new top-left coords, based on original center and current dimensions.

And Renderer.DrawSprite can stay as it is.

If this sorts it, the problem isn't that rotating sprites in AGS is unnecessarily confusing, it's that YOU'RE unnecessarily confused when describing it

What an odd question...

As Khris said:
In 2.72 and earlier, saving the game ('File' > 'Save game' or Ctrl-S) creates a compiled version, in the 'Compiled' folder. Alternatively, you can Test the game ('File' > 'Test game' or Ctrl-T) - which also saves it and creates the exe. In 3.0, it's 'Build' > 'Build EXE' or F7.

If you just want to be able to play the game at home, zip up the Compiled folder and send it to yourself (that should be in the manual, under 'Distributing your game'). If you want to be able to edit it, you need to zip up ALL the files in the game folder and send them - which seems like the most sensible thing if you're too tired to think straight, because there's less chance of losing something you wanted to keep. (Or NEEDED to keep, since this sounds like it's for a project rather than fun.)

Minor bug - can't see it reported anywhere, but apologies if I missed it.

The Object Y coord as reported in the Editor is wrong. The 'StartY' property seems to be the top edge of the sprite, while the Object.X script property and Object.SetPosition both still use the bottom.

[before]

Someone's missing something, but it's just as likely to be me... That psuedocode was a bit vague, let me phrase it better:
height/width are the dimensions of the currently rotated sprite. I guess that'd be this.temp before you reload this.Image (the original, unrotated graphic) and rotate it to the new angle. newheight/newwidth are the dimensions of this.temp after the latest rotation - so unless you haven't actually changed the angle they should be at least slightly different. (And if you haven't changed the angle, the existing center is still good, and the coords should cancel down to (x, y).)
x/y are the last coordnates you drew to. Again, I'd guess that that's this.X/Y - although you might need to update them when you draw the re-rotated sprite:

Code: ags

  this.Surface.DrawImage ( x, y, sprite_slot );
  this.X = x;
  this.Y = y;

EDIT:
Wait, are this.X/Y the center of the rotation, or the initial coords use in DrawImage? If they're the pivot don't update them, but you shouldn't be calling them directly in DrawImage. If they're coords for DrawImage you should update them, and can use them directly...
EDIT2:
Just seen the optional height/width parameters you use. Try leaving them out. Since you're starting the rotation from the original each time, the sprite won't just keep expanding as it would if you rotated an already rotated sprite, and it might be that it's resizing there that causes your problems (as SSH says, cutting bits off the sprite you might actually want). It should also mean that Gilbot's centering code will actually work. I swear, if it was that I'm going to scream...

[I]

Probably too obvious to be the answer, but:
I think Gilbot's suggestion would center the rotated sprite around (x, y), whatever you supplied for that (this.X/Y?), so there might be jumping from 'positioned at (x,y)' to 'centered at (x,y)'. Actually, wouldn't that jump 'up and left', not 'down and right'? So it might not be the problem after all... But if it is, you may need to work out the centerpoint of the original sprite first, then rotate the image and base the new coordinates on that.
[psuedocode]
cenx = x + (width/2);
ceny = y + (height/2);
Rotate();
DrawAt(cenx - (newwidth/2), ceny-(newheight/2));
[/psuedocode]

While this may seem overcomplicated for a newbie, is there really that much demand for sprite rotation? There's only one thread asking about it that I remember, from March '06. Oddly, you suggested looking up DynamicSprite.Rotate - if it's taken you this long to notice the 'glitch', it can't be that serious A lot of that thread was taken up with resolving much the same things you mention here, to the eventual satisfaction of the poster (not a newbie, I admit).

Also, adding a pivot wouldn't just be a DynamicSprite function, would it? The sprite output won't be any different with a different pivot, just the amount it needs to be offset by - which would be different for RawDraw-n sprites than for Objects, or Characters, etc. I'd say it's easy enough to module-ify the code once it works, and even neater with 3.0s Extender functions, so changing the way the engine works for such a specialised request is unnecessary. (Of course, that's just my opinion now - I'll probably regret saying that if I ever need it...) 
Clarifying that further rotations will be done to the already rotated sprite, screwing up the pixels, sounds fair enough. Although, honestly, that seems like a more logical behaviour than it going back to the original sprite.

Look up the RawDraw functons in the manual for more details, but as ProgZ says they're not really what you're looking for - you really need to have drawn your sprites and backgrounds before you can start using the RawDraw functions on them.

Sadly, there's no quick fix for art (and believe me, I've looked) and whatever you mean by 'boxy', the Critic Lounge is probably a better place to get help with it. (Or you could just embrace it, and say it's your style...)

According to the manual, the x, y and z values in that function should be floats, not ints (which is what the error message means, too). So, stick '.0' on the end of them (-15.0, -15.0, 60.0), and it should complie.

As I said that's pseudocode, it's not really meant to be used as-is, just to give you an idea of what's involved. What it does is move the character with the same ID number (not script-o-name or 'real' name) as the current ActiveInventory item into the current room, at the point the player clicks. You'd need to add something to change the Character's View so they look like the item , and maybe some check of where was clicked (so things aren't stuck floating halfway up a wall) - Hotspots or Walkable Areas might work for that. Even if you're using dedicated Characters (so cTv is only used in that room, as a TV), you might want to change their appearance based on where they are in the room (e.g. they look different on a shelf facing left than they do facing fowards) - again, the Hotspot or Walkable area would help you set that, but you'll need to store what View/Loop - and you need some way to get which Character represents which Item. Custom Properties will probably help there - give each Item a property with the ID number of the Character to use, and do something like:

Code: ags

int CharID = player.ActiveInventory.GetProperty("ToUse");
character[CharID].ChangeRoom(player.Room, mouse.y,mouse.y);

Or, if the Item Characters started from character[20], for example, you could do:

Code: ags

int CharID = player.ActiveInventory.ID + 19; // First item ID = 1, + 19 = char 20, etc
character[CharID].ChangeRoom(player.Room, mouse.y,mouse.y);

Again, sorry to be so vague, but a lot of the final code would be based on how you want the Bedroom to be set out - without being certain of that, I can only give general suggestions or risk forcing features on you that you don't want/need. If you want to talk about the details in PM, so as not to spoil too much about the finished game, go ahead and contact me. Despite what you may be thinking, once you get the details of what you want clear it really shouldn't be that hard to do - there's a fair amount of code involved, but none of it's that complicated (mostly ChangeRoom and SetView stuff, with a few extra variables thrown in).

will I have to make the whole room walkable so that iTV can get to the location or will the changeroom command take care of that

Unless you choose to use them to mark shelves, desktops, etc (and Hotspots would be better for that, IMO), or so the player can wander round looking at his trophies, you don't need to include walkable areas. ChangeRoom will place the Item Character at the right location, and they don't need Walkable areas to just stand somewhere, only if they're actually going to be walking on them - and I don't think you'd want your TV doing that...

Sorry to be so vague, but there's just a whole bunch of things that MIGHT need to be taken into account, depending on how you've got things set up, but don't HAVE to be. So, it's not easy to give a single definitive code you can use...

The spacebar thing isn't really relevant to your question - all the ClaimEvent function does is stop other conditons from happening (i.e. it'll stop any Global script from running). Actually, you might not even need ClaimEvent - it depends on your Global script - the on_mouse_click bit is the important part.

AGS has InputBoxes too, so you could for example do:

Code: ags

String Temp = Game.InputBox("Do you want to pick this up? (Yes/No)");
if (Temp == "Yes") {
  cWhatever.ChangeRoom(-1);
  player.AddInventory(inventory[cWhatever.ID]);
}

But, it might be easier to do this with a GUI (see SupSuper's Confirmation GUI module, for example).

Rooms can have their own on_mouse_click functions, so you could use that along with ClaimEvent to basically make the whole room a Hotspot. GUI code would basically just be an InventoryWindow object on the GUI and eModeUseinv, same as using Inventory on anything.

I guess the code would be something like (pseudocode):

Code: ags

// Room script for Bedroom
function on_mouse_click(MouseButton button) {
  if (button == eMouseLeft && mouse.Mode == eModeUseinv) {
    character[player.ActiveInventory.ID].ChangeRoom(player.Room, mouse.x, mouse.y);
    player.LoseInventory(player.ActiveInventory);
    ClaimEvent();
  }
}

But don't quote me on that...

How many items are you talking about?
The obvious solution is to use Characters to represent the Items - V2.72 has a limit of 300 Characters, and 300 InvItems (3.0 has no limit on Characters, and still 300 Items). You could either have dummy Characters to represent items in that room, or change Views and use conditions in Character interactions to use existing characters, as Items in that Room. Setting Character coordinates within a room is easy, and then you'd just need a variable to store what Items you've got to place in your room.

The short answer is, as you've probably realised, yes but you'll have to duplicate the commands for each 'version' of the character. You could probably move most of your code into custom functions, to save you having to type all of it out over and over again.

Really, it of depends on what sort of 'behaviour' you mean. Some things (like movement) might be better dealt with by the Character Control module, for example; there was a question asked a while ago about having multiple characters react the same way to clicks (here), which you could probably adapt if needed; and so on. So, the long answer is 'Probably, but what exactly are you after?'

I spotted a few typos in my code, which I've corrected now. (I lost my original version and when I retyped it, I forgot to pass myHotspot.Name into the common_hotspots functions.)

That was just to minimise typing. I expect to have a couple of hundred lines in the function,

Ah, right. I make excessive use of copy/paste and the autocomplete, so that never occurs to me. However, if you want to miminise your typing a bit more, how about declaring the common_hotspots_(whatever)s as Strings instead of functions, and having them return the text to be said, e.g.:

Code: ags

String common_hotspots_lookSay(String name) {         // 'String', not 'function'
   if (name =="house") return "this looks like a house"; 
   if (name =="tree") return "this looks like a tree";      // etc., etc.
}

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 player.Say(common_hotspots_lookSay(myHotspot.Name)); // Otherwise, get the generic response.
  }
  // ... Etc
}

That'd trim a little more off your work.