Messages

If you look in your game folder there should be a number of files, amoung these you should find these..

  ac2game.dta
  acsprset.spr
  backup_ac2game.dta
  backup_acsprset.spr

Use WINZIP or someother file compressor to make a copy of the entire game directory.  Then copy backup_ac2game.dta and backup_acsprset.spr to  ac2game.dta and  acsprset.spr respectively.  If this isn't helpful I don't have any other ideas.  Perhaps some other folks here can be of further help.

Most of us normally make zip files on a regular basis, so that if something like this happens we have somewhere to go back to.  Remember to do this in the future.

Good luck,  I hope the auomatic backups are there and in good shape.  

Cheers

   

Heh, them Canadians and their liberal immigration policies, no wonder they are havin trouble with aliens  

Whenever selecting sprites, with few exceptions, MAIN is the default folder.  Normally one must then navigate to a folder and then select the desired sprite.  Would it be posible for the folder from which the previous sprite was selected to be set as the default folder.  IMHO this would make many tasks much more efficient.  

Look for  these functions  in the help file
  AnimateObject()
  AnimateCharacter()

Underscore characters can't be used to form GUI names.  Is it possible to remove this restiction or is it necessary?

I have a small suggestion that would perhaps help this process along and perhaps also make the demo easier to understand.

Would it be a good idea to use the RunAGSGame() mechanism to launch the various things in the Games factory?  IMHO, there would be several advantages:

1.  People would be able to work simultaneously on their respective parts of the demo.  

2.  It is perhaps easier to understand several small demos that illustrate specific points or techniques, than it is to understand one giant demo that attempts to illustrate everything.

3.  This, I think would work particularily well in demonstrating how different types of GUIs work and are implemented.  

4.  One last advantage is that it would makeit easy to expand the demo in the future.  Modules could be added, deleted, or replaced as the future evolution of AGS may dictate.

Anyway food for thought.  Toss the idea around a bit and see if anyone likes it.  

Cheers

How can I get the room to change (in this case, turn on the light using flashlight plugin) by using an inventory (flashlight).

You can do something like this:  Make hotspot 1 cover the whole room.  Create an interaction for the hotspot "use inventory" and put the following doe into that interaction.

int room_is_dark;

function room_xx() {
  // Use inventory on hotspot #1, covers whole room
  if character[GetPlayerCharacter()].activeinv == FLASHLIGHT) {
     TintScreen(0, 0, 0);
     RestoreWalkableArea(1);
     room_is_dark=0;
  }
}

Create "player enters before fade-in interaction" interaction with the followin code.

function room_xx() {
  // Player enters screen before fade-in
     TintScreen(95, 95, 95);      //  Make room dark
     RemoveWalkableArea(1);   // Don't allow player to move
     room_is_dark=1;
}

Now for all other interactions in the room, code them something like this.

function room_xx() {
  // Any room interaction
  if (room_is_dark) {
     DisplaySpeech(GetPlayerCharacter(), "I would but I can't see a damm thing!");
  }
  else {
      // what ever you would do when the light is on
      // goes here
  }
}

OK, I thought using cursor mode 14 would work, since 11,12,13 dont crash on me.

These probably don't crash because there is something else you have defined that has initializes the memory space, corresponding to modes 11..13, to benign values.  

 

If it don't exist you can't use it.  If you need more than 0..9 then you will need to do some scripting to make a multiple use cursor mode.

[Timer]

Timer
Try doin this to fix the timer ...


If you declare timer  inside the bounds of a function it will be  dynamicalluy created everytime the function executes

int timer=0;    

function repeatedly_execute() {
  timer++;
  if (timer>=15)  timer=0;
  if (timer==0)    SetButtonPic(GUI1,0,1,6);
  if (timer==5)    SetButtonPic(GUI1,0,1,3);
  if (timer==10)  SetButtonPic(GUI1,0,1,5);
}

Cursor Mode Crash

When you push the button, it sets cursor mode to 10. When I play the game and push the button, it crashes and displays that message above.  I believe it does that becouse it is setting the cursor mode above 9.

I agree.  Don't use a cursor mode that is not defined.

I like the idea.  Sounds like a great project...

JD:  Some of what you ask is already possible.  Let me tell you what I know about each of your suggestions:  

1) DisplayButton(int Button, Int GUI), HideButton(Int Button, Int GUI)-- Hide and unhide these buttons from the GUI. I could have swore you had these already implemented, but I cant find them anywhere in the manual.

You can use SetButtonPic() to hide or show buttons.  You just need to have a transparent sprite for the hide function and perhaps some simple logic to disable whatever functions are attached to the button.

2) Special Marker for Labels: @MODE_HOTSPOT@-- Would display the mode and the hotspot the mouse is over eG: Look At Door.

Wouldn't it be better to just add an @MODE@  feature.  Then you would have @MODE@ @HOTSPOT@.

3) DescribeMode(Int Mode, Description)-- Describes the mode. EG: mode 1 would be "Look At:". This is for use the the special marker label above.

Couldn't @MODE@ just use the name text  specified when defining the cursors?

4) Can List Boxes have the highlighting feature off? If it can, I dont know how to do it. If not, can it be implemented?

You just need to do a ListBoxSetSelected (gui, object, -1).

5) A function for a list box to display Inventory Item names, by either odd numbers, or even numbers or all numbers.

This can be implemented using a simple while loop and the ListBoxAdd() function.

6) And Last, a function to be able to scroll up or down on list boxes.

The function ListBoxSetTopItem () can be used to scroll a listbox up and down.  

So I guess it boils down to the need for an @MODE@ feature, which seems to be a good idea to me.  The only other question is if there are a few more equally useful @STRINGS@  type things that should be suggested?

%

DIsplay() works like StrFormat() so there special characters, such as "%", "\" ..., that are used to specify the string's format.  The backslash cause the next character to be interpreted as a normal character and not a format instruction.  The percent character signifies the beginning of a format specification, as in %d to display an integer variable here.   If you want to display a "%" then put this in your string "\%".    

While yes it would be possible to copy all the data into the special script view struct before running all scripts, that would be quite time consuming.

How dynamic is this data?  Doesn't most of it remain unchanged throughout the game?  In this case it would only need to get updated only once  or at most infrequently.  Perhaps a script request, much like the UpdateMouse() function could be used to initiate such updates?  

If you went this way with it, then you would have the option of changing the way internal data is stored, at some point in the future.  In which case a call to the update command would do nothing since the data  would always be current.

remixor:  I;m old but no an old timer and Your question touv=ched on issues I have been unsure about for quite a while but have lacked the courage to ask about.  So please don't feel bad at all.

Cerulean:  I have been confused about this from the begining.  Since you seem to have an understaning of the actual facts as well as a historical perspective, perhaps you could elaborate more and give a longer explanation of the difference in resolutions, other than the obvious of course.  

jannar:  I have a few template contributions to make once this baby is released.  I'm sure others have contributions as well.  Proably we need a sticky or a "plugin" type page to list them all.  

Isn't most of this stuff just internal data that doesn't require any calculations or processing?   Is there a way to selectively expose these as global variables?  Maybe use an "import" statement of some sort in the header or global script?  

Hmm... how about having internal type defs.  Declare a variable with the type def and the internal data is exposed as if were a local variable.  I guess you could make it read only by just doing a behind the scenes copy to the local variable space before the script runs.  Err ... or something like that.

For example one would put somethin like this in a script file.

  #define NO_OF_VIEWS 10
  VIEW_DEF    myview[NO_OF_VIEWS];

Then it would be possible to acess internal data for the first 10 views as follows:

  myview[1].number_of_loops
  myview[1].loop[1].number_of_frames
  :

Well, I hope I haven't made things worse by getting all these ideas.  Maybe sleep on it for a couple days and see if something comes to mind.

You can use a button and SetButtonPic to do this.  You will need a different graphic for each displayable level.  Specify a graphic for the "normal" view only (not for "mouse over" and "pressed" views.  Also specify "no action" for the left click parameter.    

I think this kind of thing could be very useful.   The only problem I can see is the future proliferation of such functions.  Perhaps an alternative would be to have one function and an item parameter something like this:

  GetFrameInfo(int item, int view, int loop, int frame)

   where item is SPEED, NUM_FRAMES, NUM_LOOPS,
   or NEXT_LOOP_CHECKED

I don't know?  One way is as good as the other I guess.  

The global move and animate functions Scorp describes sound really useful because it would allow NPC's to easily wander about the game world without regard to the player's location.  This, IMHO, would make for really interesting game play.    

The "game template" and "gui name"  features rock!!