Messages

Would it be possible to specify a scale factor in the Room Object Editor  if the "Use Walkable Area Scaling" box is unticked?  If it was ticked then the scale factor would come frm the walkable area.   

Also could there be an option to ignore walkbehind areas?   Currently an object such as a door that's not in pixel perfect alignment with a walkbehind is partially hidden.

Does anyone else thinnk these would be useful?

Ideally I would like to completely OO-ise it, but practically speaking I don't think I will. Global functions like SetScreenTransition, while you could argue should be a static member function like  Game.SetScreenTransition, doesn't really bring any benefit in doing it that way; whereas things like characters, objects, GUIs, etc really lend themselves intuitively to OO.

As people get acustomed to the OO way of doing things there are sure to be future requets for more.   A Game object would make more sense if one could do something like Game.ScreenTransition = eDisolve or myvar = Game.ScreenTransition.  It would be a clean way of  handling  the GetGameParameter() type of items that seem like are always requested and would eliminat need for many Set/Get functions.  What do you think?

Yeah, I am still pondering pointers... I definitely would like to add them once I've worked out how to take care of the technical issues.

From some of your previos comments I am guessing that you probably will need to use pointers to entries in some sort of symbol table rather than memory pointers to the actual variable or object.   When I worked at GE I helped develop a Relay Ladder Language, a script language of sorts as it was byte code interpreted.  Pointers were handled in a manner that was simpler and somewhat more restrictive than in C/C++

• There was only one type of pointer, pointer to variable implemented as an offset into the symbol table.
  
  
• There wasn't a reference operator.  A simple assignment statement  such as pointer_var=myvar would assign the reference to the pointer variable.
  
  
• There wasn't a dereference operator.  The language consisted of asm function library and a handful of boolean operators.  Dereferencing and other pointer operations, were done within the library asm functions. 
  
  
• The command line monitor program, when asked to display or modify a pointer variable, would automatically convert variable table offsets to symbol names so that the end user would work with symbol names.  This seemed to make the concept of pointers easier to grasp and their use less error prone for factory electricians and other non-programmeres.   
  
  I don't meam to suggest that the above is an optimal, complete, or even an apporpiate solution for AGS.  I thought that perhaps a different perspective would be of some help to you in your efforts with pointers. 
  
  I'm looking forward to updating BlueGui using the  new methodology.  Can't wait ...

Wowee!  Am I a couple of versions behind.  CJ thanks for kindly reading my previous lengthly post, I'll try to be a bitmore to the point this time round.     

The grey background was deliberate, mainly because of the #sectionstart / #sectionend lines, to make them obviously different to the rest of the code.

What would your preference for preprocessor directive colouring be?

I would be happy with any color as long as there wasn't  a backgound color.   

Well, the reason it's split up as it is at the moment is so that sprites, views, etc can be shared between different characters and different objects, which adds a degree of flexibility and stops you having to load duplicate copies of graphics.

I do understand the difficulty of team working on a project, and I'm hoping to add some sort of rudimentary diff/merge support at some stage.

I understand the need to avoid unnessary copies of graphics, sounds, music, and other entities that consume relatively large amounts of disk space.   I have some ideas how a degree of modularity can be achieved while maintaining the use of shared resources and would make a diff/merge or import/export functionality easier to implement.   This is obviously not the time or place to have a discussion about this  so I'll leave it for another day. 

Anyway, as far as the object-based functions go, I'm not sure whether to change over anything else. The characters and objects were the main reason for doing this -- can anyone see a benefit in object-ising any other parts of the script functions?

One possibility I'd like to do would be the GUI objects, but realistically that would require pointer support, because asking people to do stuff like  gui[3].listbox[4].Add()  would be rather messy.

There are a bunch of Get/Set functions, and never-ending request to add more, for game and room that would perhaps be better/easier handled as object properties?   

Do you mean for just for this release or forever?   Eventually, I think you would want to objectise everything that lends itself to an OO paradigm.

As for the GUI stuff I agree that it would logically be the next biggest one to change over.  It seems like you are still pondering the possibilty of adding support for pointers at some point.   If so then add the GUI stuff next time around, otherwise just do it now, IMHO.
   

Also added is Enum support along with autocomplete for it ..

Yeah....

Great work CJ ...

[Set vs Change]

I must have ESP or something.  I remember CJ mentioning something about this a long time ago and was thinking about asking about it the other day.  Good thing I read this thread first.   Anyway here are some of  my comments about  the above discussion.

Set vs Change
Regarding the question about  using "Change"  instead of "Set" in function names, probably "Set" should be used when there is a corresponding "Get" function.   If there isn't a corrsponding "Get" then using "Change" instead of "Set" is probably satisfactory.   I prefer "Set" because it's easier to spell.  (hehe)

Function Overloading
This is one of my favorite things.  It makes things easier to code and easier to read.  It would also resolve most of the AgsFunction vs AgsFunctionEx issues and reduce the function clutter .  Should character[].ChangeRoom() include coordinates or not?  Function overloading gives both;  Include coordinates and a NewRoomEx() is performed, leave them out and NewRoom() is performed.   

So I hope function overloading makes the final cut. 

#define Constants
I understand the need for readability but I also understand the desire for brevity.  So perhaps comprimise could be reached by using abreviated  terms as follows:

ANYAREA / WLKAREA  instead of  ANYWHERE / WALKABLE_AREAS
FWD/BCK instead of FORWARDS / BACKWARDS
BLK/NOBLK instead of BLOCKING / IN_BACKGROUND

A proliferation of english words as #define system terms is problematic.  For example suppose BLOCKING and RUNNING are defined to have a value of 1.  Since both terms have the same value it would not be possible to use them in the user's script to enumerate the state of a character, object or other entity.  If these terms were given unique values then they could be used for other things but then it wouldn't be possible to substitute 0 or 1 in AGS function calls. 

Again using abbreviations/mnemonics instead of actual words, as much as possible, seems, to me,  to be an acceptable way to resolve this situation.   Another possibility is to use enumerated data types instead of #define constants. 

I appolgize about being a bit off topic but one last thing about #define,  I use it quite often and the current editor highlighting, with the grey backgound, drives me crazy.  Is there something that can be done in the way of an option or something.  Please ...   
Character Names
Wouldn't it be a lot easier to read if we could write:

Roger.Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND); 

instead of

character[Roger].Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND);

So I guess  AGS could define "Roger"  as "character[1] instead of defining "Roger" as "1".   This can be a "can of worms"  because there are plenty of things that want to see the character ID of "Roger" (i.e. "1").  If we were to go down this road likely the charcter array would give way to  character objects with  "Roger"  being the object name in this case.    I guess this ends up being almost the same as the EGO=> question above.  What do you thingk CJ? 

Broader OO Issues
The scope of the discussion so far is limited to the script language (appropiate since that's the subject of the beta) and using characters as objects.   As mentioned earlier in the discussion, it is intended that the other game entities have a similar fate.   

It seems to me that a character object (or any other game entity), in addition to it's properties and inherited methods as discussed above, would also be comprised of it's interaction methods, sprites, animation views, loops, etc.  Is there a plan to reorganize AGS's internal structure, at some point, to more closely correspond to this kind of paridigm?     

The reason I ask is that something like this would make it possible/easy to import/export complete game entities; or maybe even game entities would just be stored in seperate files.  IMHO, the weakest part of AGS is the dificulty multiple developers have in simultaneously working on the same project.  This is primarily due to so many things being inseparably stored in the main game file.   OO's inherient  modularity offer hope in this regard. 

I wanted to bring this up now to avoid locking-in on somthing that would preclude these kinds of future capabilities.  I am curious as to your thinking on this CJ.   


P.S.  CJ, I appologize for spamming your beta thread; feel free to take me to the woodshed.    Nice work with the OO script.

I suppose you could use something like that for "game-in-a-game" type things but I think the results would still look funny, IMHO. 

I noticed the same thing on a Win2000 machine when I did a Ctrl+Alt+End.   

I  had to do this because for some reason the game that was running minimized, returning the desktop to the screen.  It's not my machine so I can't say what was going on  with the game minimizing.  I just assumed  there was something else running on that machine that made this happen?   

Wouldn't it look funny mixing scaled up and normal sized SCI fonts?

You could try using CreateTextOverlay(), MoveOverlay(), and RemoveOverlay()  functions instead of the DisplaySpeech...() functions. 

Cheers

Here is a version of the game that you can get stuck every anytime you want.  Just load the "Barn" save game and walk into the barn.  When I do it on my WinMe machine and ty to make him walk to the machine he gets stuck at the beginning of the second stall.

Stuck Garfield Game

I have observed this as well.   It happens to me whenever I go in the barn.  There is nothing I can do to avoid getting stuck.  I can zip up the whole mess and post it somewhere if that would be helpul.

I think this is an interesting idea.   If I were doing it I would twist it a little differently.  For example, the whole hall monitor thing is part of the school burearacy, which I think of as inflexible and uncreative in their thinking.  Prime exhibit is the apparent inability of many school authuorities to make a distinction between a dangerous  weapon and the drawing of same.  Sorry, don't not trying to go political on you, just making a point about how the system normally works.    It seems to me that this is the antithesis of a crime solving super sleuth.  In addition, I imagine that in the name of justice, crime solving, and all that stuff a few rules would need to be broken from time to time; not something a hall monitor would get away with for very long.

My suggestion would be to have the main character be a skinny, brainy guy and his side kick be the tough ex-bully.   The storyline could go something like this:   Bully used to pick on Skinny and make fun of him.  Nothing really violent though.  Skinny finally tells Bully off  something  like "Some day your going to be in trouble and your size/strength won't be enough to get you out of it...".  So a few days later a serious crime is committed at School and Bully is the prime suspect.  Skinny  comes the the rescue and discovers his sleuthing talent.  He a Bully become friends and sleuthing partners for continuing episodes.   ...  Or something like that.    

In any case I think that there needs to be conflict not only with the bad guys but also with the authorities who are supposed to figure this stuff out.  

Anyway this is just my 2 cents worth.     It will be intersting to see where you go with it.  

Cheers
Rick

Geoffkhan:  Thanks for the verification.  I agree with your recommendation as well.  As far as radians vs degrees it pretty much depends upon what you are doing.   Many engineering and physics problems are much simplified when expressed in radians.  Other kinds of problems an uses are better expressed using degrees.  I believe that the intel floating point processor uses radians and that Steve just exposed this functionality to AGS.  

Steve:  I have one question about your pluing.  How have you handled overflow and undeflow conditions?   Thanks..

[Download]

Steve,

I have taken the liberty of making the following document for your plugin.  Please take a look and see if I got everything right.  

Thanks,
Rick


Download
http://www.mccrea.demon.co.uk/step/ags/AGS_Maya.dll

Working with Floating Point
The floating point plugin performs floating point operation on floating point numbers.  Since AGS does not have a floating point data type the plugin uses integer variables to store floating point numbers.   Conversion functions are provided to convert from one format to another.   Since the compiler no longer differentiates between these two data types it is probably best to contrive a naming convention that makes this distinction.   For example all variables that are to contain floating point numbers can begin with  underscore characters or some other prefix.  

Ags Extensions
These functions supplement the AGS built-in functions and are not involved with floating point numbers.

• import int GetTextExtentX(int font, string text);
  
• import int GetTextExtentY(int font, string text);
  
  Conversion Functions
  The following functions provide the ability to convert integer numbers to/from floating point numbers.  Floating point results and parameters are stored in integer variables.  
  
  
• import int int_to_float(int a);
  
• import int ints_to_float(int units, int thousandths);
  
• import int float_to_int(int a);
  
  Floating Point Functions
  The following functions operate exclusively on floating point numbers stored in integer variables.
  
  
• import int fadd(int a, int b);
  
• import int fsub(int a, int b);
  
• import int fmul(int a, int b);
  
• import int fdiv(int a, int b);
  
• import int fneg(int a);
  
• import int fabs(int a);
  
• import int fcomp(int a, int b);
  
• import int fgreater(int a, int b);
  
• import int fless(int a, int b);
  
• import int sin(int a);
  
• import int cos(int a);
  
• import int tan(int a);
  
• import int asin(int a);
  
• import int acos(int a);
  
• import int atan(int a);
  
• import int atan2(int y, int x);
  
• import int exp(int a);
  
• import int log(int a);
  
• import int pow(int a, int b);
  
• import int sqrt(int a);
  
• import int pi();
  
  
  [edit]
  One question Steve.  Above you mention that cos takes radians, presumably this is also true of the other trig functions.  Can you verify if this is true.  

Avo: Thanks for the correction, don't know what I could have been thinking.

RawDraw's won't work because the images from them cannot be individually removed with an image ID like the Overlay images.  

Just to clear up a small point here.  You could of course remove all of the images and then redraw the ones you wanted using RawDraw.  Since nothing actually happens to the screen until after your script finishes the result will be the same as using overlays.  As you correctly observe, using overlays  provides more ability to operate on a single overlay but the disadvantage is that the number of overlays is limited to something like 10 or 15 (I believe, no sure what the current limit is).  I don't mean to tell you to do it one way or the other, just wanted you to not misunderstand abolut RawDraw.

1 - can't find where to put a script to execute upon the opening of the inventory GUI

I would just create global functions that manage both and then call those functions whenever you wanted to open, close, or other operation on the inventory GUI.  Normally they would be called from the global script interface_click() event handler.

2 - can't figure out how to access all the existing scripts for the AGS inventory system for modification; the edit script button brings up a bunch of inventory functions, but they are not ALL there...

I don't understand the question.  

3 - can't find where to put a script to have it execute whenever the mouse icon changes.  alternately, it could be running continuously and keep checking the mouse state.  (this isn't exactly for the inventory, this is for a cooler mouse system I am working on).

I did something similar in the BlueGui and had to continously monitor the mouse.  If you want to look at my source code have a look at the source code follow my sig at the bottom of this post.

Martijn,

If the plugin is returning integer values the results may be multiplied by 100 to keep 2 decimal place fraction.   If this is the case you just need to divide by 100 at some point.   

The floating point plugin is probably a better bet since I think you can have more control of the result.   

[edit]
Here is the thread that has some details of use.   
http://www.adventuregamestudio.co.uk/yabb/index.php?board=2;action=display;threadid=12673;start=msg151648#msg151648

Candle,

Most folks use a drawing prgram that supports layers and keep their original sopurce drawings in the native format of that drawing.   I disagree with the use of BMPs for AGS import because theyare excessively large.   The abilty to import PNG files has recently been added to AGS and I find these files to be much more compact and of relatively high quality.   PNG files have the added advantage in that they are also web viewable.  JPG files are notorious for a degrading image quality and most people don't use them.

There are a lot of opinions about what size to make character sprites.  I normally  establish a pixel scaling and use that for every character in a game.  In one of my current projects I am using a pixel scaling of 20 pixels/foot.  So a character that is supposed to be 6 ft tall would have a sprite that is  120 pixels tall.   This way any characters I make for the game may appear with eachother in any scene.   I am using this for a game resolution of 320x200.   The character size ends up being just about right for a scene depicting an inside room such as an office or bedroom.  For other scenes (i.e. outdoors) the character is scaled down using AGS's walkable area scaling.   I know other people do things a bit differently and I guess there is no right or wrong way.  This is just what works for me.  

Rick, wow!  Thanks for taking it upon yourself to write some of the function code for me. ...  

Thanks for the complement and welcome to the AGS community

1 - out of curiosity, what does "dia" stand for?  I cannot think of a logical reason why you picked this! haha

You mentioned "Diablo" and "db2"...

2 - "export function dbAddInventory(int item, int where);
export function dbLooseInventory(int item, int where);"

I can't figure out what these 2 lines do.  Usually in the header we have include files.  The notation in AGS seems to differ from C++ somewhat here in the header....what with the

and such, but export is the logical inverse of import.  Where is it being exported to?  Also, the "dbAddInventory" etc functions are not defined by you, and they do not seem to be in the list of AGS functions...so where do they come from?

The export directive allows the functions to be used in room script files.  I made an error because I originally used "db" as the postfix  and then later changed it to Dia.   So those lines should be:

export function DiaAddInventory(int item, int where);
export function DiaLooseInventory(int item, int where);

I violated my own style rules in doing so;  I ususally like to use a 2 char lower case prefix to differentiate from the builtin AGS functions from global functions I create.   I normally group such related functions into modules and then use the prefix to identify the module.   This further helps eliminate the possibility of future name conflicts.

... So, can you direct me to information on how to use these "overlays" or "raw draw" ?  I have no idea what you are talking about  

Lookup in the manual RawDrawGraphic(), CreateGraphicOverlay() , and related functions in the manual to get started.   Do some experiments with each and then ask more qustions.

4 - From your code, I can see that AGS defines every inventory item with a -1 (char doesnt own it) or 1 (char owns it).  Interesting.  I did not realize that.  I guess this is not a question

Lookup "variables" in the manual.  You will find a charater struct array.  one of the elements is the inv array.  This is an int array where each element corresponds to an inventory item defined with the AGS editor.   I am not certain if  it is 0 or -1 that means the character is carrying the item.  I believe that any positive number is interpreted to mean that the character has the item (i.e. it's graphic will show in the inventory window).  This is sometimes useful as in the case of money, bullets, or other instances where the character can have multiple quanities of items.  

Happy game making ...

[Script Header]

I would still use the character's inventory mechanism some thin like this...

• Use the AGS inventory mechanism to define inventory items.
  
  
• Instead of using the inventory window widget script your own inventory display.  Display this information on  a GUI as LostTraveler suggests or use some other methodoloy such as overlays or raw draw.  
  
  
• Use the GetInv...()  functions to look up the sprite id, invenotry name, description, etc.
  
  
• Create global variables to hold the inventory id's for each of the locations (i.e hands, pockets, etc).
  
  
• Make a couple of global script functions to manage the inventory.  Something similar to this.    
  
  Script Header
  

  #define NONE              -1
  #define INV_OUTFIT      0
  #define INV_LEFT          1
  #define INV_RIGHT        2 
  #define INV_POCKET1   3
  #define INV_POCKET2   4
  #define INV_POCKET3   5
  
  export function dbAddInventory(int item, int where);
  export function dbLooseInventory(int item, int where);
  

  
  
  Global Script
  

  
  DiaInventory[7];
  
  function DiaInitInventory()
  {
     int i;
  
     // Clear custom inventory slots
     i=0;
     while (i<7) {
        DiaInventory=NONE;
        i++;   
     }
     
     // Clear AGS inventory slots
     i=0;
     while (i<300) {
        character[EGO].inv=NONE;
        i++;   
     }
  }
  
  function DiaAddInventory(int item, int location)
  {
     int id;
  
     // Is location is not empty drop current item
     if (DiaInventory[location]!=NONE) {
        id = DiaInventory[location];
        DiaInventory[location] = NONE;
        character[EGO].inv[id] = NONE;    
     }
  
     // Add one unit of item to AGS inventory
     character[EGO].inv[item]=1;
  
     // Add one unit of item to custom inventory
     DiaInventory[location] = item;
  }
  
  DiaLooseInventory(int item)
  {
     int i;
  
     // Remove item from custom inventory
     i=0;
     while (i<7) {
        if (DiaInventory==item) {
           // Delete item from custom inventory
           DiaInventory=NONE;
        }
        i++;   
     }
  
     // Remove item from AGS inventory
     character[EGO].inv[item]=NONE;
  }
  
  
  

Just use the current inventory system and enfrce rules about how things got added or deleted to the inventory.  So you would end up with something like the following:

• Inventory Item #1 - Outfit Slot
  
• Inventory Item #2 - Right Hand Slot
  
• Inventory Item #3 - Left Hand Slot
  
• Inventory Item #4 - Pocket Slot #1
  
• Inventory Item #5 - Pocket Slot #2
  
• Inventory Item #6 - Pocket Slot #3
  
  You will likely need to define a dummy inventory item with a blank image for the case when there is no item in the slot.  This will keep the slots in a constant position.  
  

Yes ...