Messages

Ah, balls, you're right. Basically, it doesn't draw the graphic ss to object[0]. The rest of it does work. Apologies for being very melodramatic, sometimes I get carried away on these things... :S

Thanks!

EDIT: Okay, this is very odd. I started an entirely new game at 1024x768, and it worked fine when called. Unfortunately there was nothing in the other 1024x768 game to have interfered in any way (they were both made in the same version of AGS and neither interfered with the imported script). My apologies if I'm wasting time (which I'm beginning to feel I am ) it just seems really strange...

Hello All!

I think there's a hidden (or possibly obvious, I just haven't seen it) rule to Dynamic Sprites which I'm not quite twigging. I wrote a piece of code that curiously refuses to work when exported to a game which has a 1024x768 resolution (it was written and tested in a 320x240 resolution) BUT if I export it into a 320x240 game, then increase the game's resolution to 1024x768, it somehow works! Although I did choose the option to change the size of the GUIs upon upgrading in size, that shouldn't make too much difference.
The code is:

Code: AGS

//At top:
DrawingSurface *d;
DynamicSprite *ss;
// Somewhere else
ss = DynamicSprite.Create(Room.Width, Room.Height, false);
//Then, called every cycle from repeatedly_execute_always (after the rain is moved and created)
void DrawRain(){
  d = ss.GetDrawingSurface();
  int i;
  if(CurrRaindrops > 0) d.Clear(); //This is to clear the drawing surface so no overlapping takes place
  while(i < MaxRaindrops){
    //blah blah
    d.DrawImage(rain[i].x, rain[i].y, sprites[i2].s[rain[i].Collided].Graphic); //Draws the right sprite onto the drawing surface (and therefore ss)
                                                                                //Variable i2 is defined within the loop
    i ++;
  }
  object[0].Graphic = ss.Graphic; //object 0 has a position of (0, Room.Height)
  d.Release(); //Cos it's good to do ^_^

The code works, but seemingly not when imported into a game of the size 1024x768 directly. Does anyone have any ideas? I know I can just start a new game at 320x240 and change the size from there, but I'd like to know what is causing this...
  Thanks again!

Dat unresolved quotation mark...

Despite having been here for a while, I've never, ever used viewports before, so unfortunately I can't be much specific use. However, I'm guessing shifting it from the camera's original position has something to do with it...in the manual, under SayAt, it states:

NOTE: This function does not support Whole-Screen speech.

I'm guessing what you'd have to do is to add a Viewport factor when calling SayAt, something like:

Code: AGS

cFeynman.SayAt(cFeynman.x + GetVieportX(), cFeynman.y -350 + GetViewportY(), 400,"Okay..."); //Could be this...
cFeynman.SayAt(cFeynman.x - GetVieportX(), cFeynman.y -350 - GetViewportY(), 400,"What did you want now?");//Or this...

Again, take all this with a pinch of salt, it's perfectly possible that you have to take away the Viewport, not add it.
Unfortunately I'm in a bit of a rush, but I hope one of those solutions does it (again, apologies if it's a waste of time, I've never used Viewports before)

As far as I can see, it's because you're calling return when changing the button width, which terminates the function at that point.

Code: AGS

if(Button15.Width == 1){
  Button15.Width = 5;
  return; //EG here!
}

You also have instances of calling return before this (lines 2159 and 2187), although I guess they don't execute when you tested it.

Hope that helps!

Although this is probably not the most efficient way, what you could do is re-call the SayBackground command every loop from repeatedly_execute_always (or Rep_Exec for a room). Something like:

Code: AGS

//AT TOP OF GLOBAL SCRIPT, OR BETTER YET AS GLOBAL VARIABLES
bool SpeakWhileMoving = false; //This is to check whether the character should be speaking at this point, and what
String Words //What he should say
//OTHER PLACE:
SpeakWhileMoving = true;
Words = "Hello there everyone!"
cCharacter.Move(x,y,eBlock,eWalkableArea);
//IN GLOBAL SCRIPT
function repeatedly_execute_always(){
  if(SpeakWhileMoving){
    if(cCharacter.Moving) cCharacter.SayBackground(Words);
    else SpeakWhileMoving = false;
  }
}

!UNTESTED!

The problem with this is that the text will remain on screen for much longer than it needs to. One way to combat that would be having 'station points' (in no ways an official term, just made up on the spot), and to make sure the character is saying nothing when he needs to not be talking

Code: AGS

//OTHER PLACE:
SpeakWhileMoving = true;
Words = "Hello there everyone!";
cCharacter.Walk(x,y,eBlock,eWalkableArea); //whilst talking, station point 1
cCharacter.SayBackground(""); //Make the speech nothing
SpeakWhileMoving = false;
cCharacter.Walk(x2,y2,eBlock,eWalkableArea); //This bit in silence, station point 2
//IN GLOBAL SCRIPT
function repeatedly_execute_always(){
  if(SpeakWhileMoving){
    if(cCharacter.Moving) cCharacter.SayBackground(Words);
    else SpeakWhileMoving = false;
  }
}

!TESTED!
Again, timing is going to have to be fine-tuned, as the text appears on screen longer than expected. But I hope this works out!

I just made the exact same error...going on about walkable areas and such

You can use Text Parsers to do this.
I would have a GUI with one or more labels where you can enter the responses to the text the user types, and a Text Box (with no border - you can set this in the options pane of the text box) where the user can type.
It will take a little experimentation to get the look you want, but hopefully it should work out fine

I dunno is this'll help: try setting the co-ordinates you want cCharacter2 to go, so:

Code: AGS

cCharacter2.ChangeRoom(3,200,200)

it ay be that he HAS changed room, but sits in an awkward place...

this is a very hasty reply, so it's probably not the issue - my apologies if I am wasting time

It looks like it would work, but it may help to simplify a bit:

Firstly, having:

Code: AGS

if (Letters_Collected == 9) {
        Ending_Collection=1;
                }
else {
        Ending_Collection=0;
                }
//then:
if (Ending_Collection == 1) {
    //endings
}
else if (Ending_Collection == 0){
    //endings
}

is essentially the same as:

Code: AGS

if (Letters_Collected == 9) {
    //endings
}
else {
    //endings
}

Unless the variable Ending_Collection is affected by other code, which it doesn't seem to be. You can 'cut out the middle man' entirely (I know it has a family...but shh, efficiency calls )

Secondly, if you find yourself having multiple conditions which result in the same thing, it's good to find a way to combine all of them into one statement. For example:

Code: AGS

else if (gun_loaded == 0) {
                if (toy_car == 0) {
                        //Start Ending 3
                                }
                else if (toy_car == 1) {
                        //Start Ending 3
                                }
                else if (toy_car == 2) {
                        //Start Ending 3
                                }
                        }

All three conditions lead to the same ending. You know that if the value of toy_car is greater or equal to 0 and less than or equal to 2, then ending 3 will play. So you could condense the line into:

Code: AGS

else if (gun_loaded == 0 && toy_car >= 0 && toy_car <= 2) {
    //Start Ending 3
}

Although seeing as the value of toy_car seems to be either 0, 1 or 2, you can skip that entirely and put:

Code: AGS

else if (gun_loaded == 0) {
    //Start Ending 3
}

And, as gun_loaded can EITHER be 0, OR 1 (from the impression I have), then as you have already tested to see if it's 1, you don't have to test again to see if it's 0:

Code: AGS

if (gun_loaded == 1){
    //Either ending 4, 2 or 1
}
else{ //you don't have to test whether it's 0, as it can only be so if it isn't 1...
    //Ending 3
}

Also on a quick note: if something is only ever either 1 or 0, it's good practice to turn it into a boolean variable

So simplified, disregarding the bit about booleans, the code could look something like:

Code: AGS

if (Letters_Collected == 9) {
    if(gun_loaded == 1){
        if(toy_car == 0){
            //Ending 4
        }
        else if(toy_car == 1){
            //Ending 2
        }
        else{ //You don't need the condition - if it's not 0 or 1, then it's 2, so you only need to put 'else'
            //Ending 1
        }
    else{ //again, if gun_loaded is not 1, then this clause executes anyway, so only put 'else'
    //Start Ending 3
    }
}
else {
   if (gun_loaded == 1) {
      //Start Ending 3
   }
   else if (gun_loaded == 0) {
      //Start Ending 5
   }
}

I've shifted the bracketing in terms of indentation a little - it doesn't really make any difference however (I just find it clearer that way)

Hopefully this'll simplify the depth of logic a little You can always check which bracket belongs to what under 'edit -> match brace' (or Ctrl-B)

Sure, whet you could do is check whether the string is longer than the original, and then just substring the last letter, switching a boolean value in the process to make sure nothing is re-substringed, something like:

At the top of the script

Code: AGS

bool switch;
String message;

then in game_start:

Code: AGS

message = "Enter a save name"; //this'll allow you to change the message whenever you want without mucking up future code

then when making the gSaveGame GUI visible:

Code: AGS

switch = false;
txtNewSaveName.Text = message;
gSaveGame.Visible = true //etc etc

The in repeatedly_execute_always():

Code: AGS

//to test whether anything has changed in the text box:
if(gSaveGame.Visible == true && lstSaveGamesList.ItemCount > 0  && txtNewSaveName.Text.Length != messsage.Length && !switch){ //17 is how long "Enter a save name" is, change it as required...also "!switch" is the same as "switch == false"
  switch = true; //if the player writes anything longer than 17 characters, we don't want THAT to substring, so change the value of switch
  if(txtNewSaveName.Text.Length > messsage.Length){ //if the player has typed a character
    String s = txtNewSaveName.Text.Substring(messsage.Length,1); //remember, substring starts from length - 1
    txtNewSaveName.Text = s; //so it'll be the character the player types
  }
  else{ //if the player has used backspace
    txtNewSaveName.Text = "";
  }
}
if (gSaveGame.Visible == true && lstSaveGamesList.ItemCount > 0  && (txtNewSaveName.Text == " ") {//this check will prevent space being pressed at first
  switch = false; //switch this back so further checks can be made
  txtNewSaveName.Text = message;
}

Keep the restriction you already had and bingo! This has been tested, so should work here to. There's probably more efficient ways of doing it, but that's my solution - hope it's what you were looking for

Sure, you could check whether the String returned is blank before you pop up the Y/N GUI:

Code: AGS

if (lstSaveGamesList.ItemCount > 0 && txtNewSaveName.Text == lstSaveGamesList.Items[lstSaveGamesList.SelectedIndex]) {
  if(txtNewSaveName.Text == "") Display("fill in save name please (or some-such)");//Start New Bit - check whether the string is ""
  else{
    gOverwriteYN.Visible = true;
    gSaveGame.Clickable = false; 
  } //End new bit
}//I've done stuff to the brackets because I'm OCD about layout, change back if you want :P

That should hopefully work. You cooould avoid an empty string with multiple spaces by changing this line:

Code: AGS

if(txtNewSaveName.Text.Truncate(1) == " ") Display("fill in save name please (or some-such)");//important it's " " not ""

Although that's being VERY nitpicky

Both are untested, but should work fine

Doesn't this:

Code: AGS

invOverlay1 = invOverlay1.CreateTextual(20, 20, 400, Game.SpeechFont, 10, "");
invOverlay2 = invOverlay2.CreateTextual(20, 40, 400, Game.SpeechFont, 12, "");

validate both overlays? This would explain why your first two conditions when adding an inventory item don't execute.

Hope this solves it!

Here's the offending line:

Code: AGS

gGui1.Visible = false;
gRestoreGame.Visible = true;
lstRestoreGamesList.FillSaveGameList();
mouse.UseModeGraphic(eModePointer);
gIconbar.Visible = false;
gGui1.Visible = true; //HERE!!!!!!!

This should solve it. Using a find and replace for terms which MAY contradict a command which isn't working is often a good way to spot these

EDIT: Beaten by Icy

You can re-use the same timer whilst incrementing a variable to determine what part of the conversation should be played. For example:

Code: AGS

int turn;
function room_Load()
{
  SetTimer(1, 120);
  turn = 0; //if you want the dialog to start from the beginning every time the room is loaded, include this
}
function room_RepExec()
{
  if(IsTimerExpired(1))
  {
    if(turn == 0)
    {
      cDiceNerd.SayBackground("blah blah blah");
      setTimer(1, 280);
    }
    else if(turn == 1)
    {
      cWandNerd.SayBackground("blahhhh");
      setTimer(1, 150);
    }
    //etc etc.
    turn ++; //this is universal to all instances of dialog, so put here
  }
} 

This isn't the most efficient way of solving the problem, but it should work nicely

How do you mean active pointer? Does the pointer mouse mode not respond to any clicks?

in your global script, is there an on event function citing the "eEventEnterRoomBeforeFadein" event type? something along the lines of:

Code: AGS

function on_event (EventType event, int data){
  if(event == eEventEnterRoomBeforeFadein){
    //stuff
  }
}

Stuff in here may slow your game down (especially if there are blocking functions! - I'd check for those in Room_Load() as well...) it shouldn't actually be there unless you put it there though...

How does your game run the rest of the time? Normally or is it quite sluggish?

If you want the mouse cursor to change when it moves over the GUI, use GUI.GetAtScreenXY(x,y). This approach will mean it's in repeatedly_execute(), but I can't really think of another function to put it in, since AGS has to constantly check whether the mouse is in a certain area... 
something like:

Code: AGS

function repeatedly_execute(){
  if(GUI.GetAtScreenXY(mouse.x, mouse.y) == gGUI && Mouse.Mode != eModePointer) { //you'll want to check whether the mouse mode has already been changed...no point doing it twice!
    Mouse.Mode = eModePointer;
  }
  //probably other code
}

Where "gGUI" is the name of your GUI

Hope this solves it

Hello Brinsk, welcome to the forums

The answer to all of those are yes: it's all do-able. How familiar are you with the engine though? I'd recommend getting a good groundwork first before going on to more complex things like the driving. The youtube tutorials by densming are an excellent way to get started. Things he doesn't cover will also be in the manual (pressing F1 in the editor will bring it up) and searching the forums will hopefully answer most of those questions.

To answer some now:

Code: AGS

cCharacter.SetAsPlayer();

will make cCharacter the playable character

And you can change the View of the character whenever the player clicks on the wardrobe with

Code: AGS

cCharacter.ChangeView(ViewNumber);

You can use text parsers for text commands, although I've never actually used them

Good luck and have fun

[GlobalScript.ash]

Hello Gribbler!

For the first problem:
show_restore_game_dialog() is not a universal function and only really works in GlobalScript.asc first you'll need to export it. in GlobalScript.ash write

Code: AGS

import function show_restore_game_dialog();

and the LOAD hotspot should work fine!

There are two ways of combating the second problem:

The first is to simply deactivate all the Mouse modes apart from the pointer mode, and set it to that. so maybe in the room script something along the lines of:

Code: AGS

function room_Load()
{
gInventory.Visible = false;
gIconbar.Visible = false;
Mouse.Mode = eModePointer;
Mouse.DisableMode(eModeInteract);
Mouse.DisableMode(eModeLookat);
//etc etc
}

The second way I preffer more as it's a little more elegant: You could merely check in the function that handles the way you change modes (I assume it's right click, so the function would be on_mouse_click() in GlobalScript.asc) to see whether the player is in Room 1, and block the appropriate expression accordingly. It'll look something like:

Code: AGS

function on_mouse_click(MouseButton button) {
//some stuff including an if statement if I remember right...
  else if (button == eMouseRight && player.Room != 1){ //checks whether the player is in room 1, and if so will stop the expression from executing
    mouse.SelectNextMode();
  }
}

which should stop your mouse mode from changing until you leave the menu

Hope that helps

EDIT: Onker got there before me
  Although merely setting the mouse mode to pointer doesn't solve the issue (for the second bit), as the modes can still rotate.