Messages

[here]

Thanks Gilbot, SSH

I tried commenting out the offending lines, restarting the editor,and then uncommenting them, but the compile error still remains.   I too have seen something like this before only with character.X,Y properties.  That time I used the character.SetPosition() function instead and assumed that I had done something wrong.

Anyway here is a link to the game where this seems to be reproducible.   The offending code can be found commented out on line 49 in the Room Script of Room 102. 

I'm having a bit of trouble accessin an object's X & Y properties.  Below is a snippet of room script that procudes a compile error when compiling the line in red.   The error is as follows:

"Error (line 49): '(null)' is not a public member of 'Object'."

I also get the error if I try using the script-o-name and also if I try assigning the property to an int variable.   I assume I'm overlooking something very obvious but I don;t know what that might be.  Perhaps someone here can see what's wrong with what I am trying to do.

function object0_a() {
   // script for object0: INTERACT WITH OBJECT
   if (player.y<120) {
      Display("You can't reach it from up here. You'll have to find a way down the curb.");
   }
   else {
      player.Walk(object[0].X, object[0].Y, eBlock);
      GiveScore (2);
      oSomething.Visible = false; 
      player.AddInventory(iKey);
      SetDialogOption (0, 3, eOptionOff);
      SetDialogOption (0, 4, eOptionOn);
   }
}

Btw, this line was formerly a MoveCharacterToObject() function and this was the simplest thing I could think of.  If there is a better way I'd be glad to have comments about that as well.

Hehe, So that's why I couldn't find it in my own archive  .  I thought I was going crazy for awhile.   

Thanks for the links anyway.  I've added two of them to my AGS archive as I didn't have those particular versions.   

Does anyone have a copy of the original Demo Quest (i.e. the version prior to the gaes factory)?  If so would you be kind enough to put it up somewhere where I can download it.    Thanks.

It reminded me of "Zorba The Greek" somewhat.  I don't know the correct musical terminolgy but I think it was the "accent notes" that made me think of ZTG not necessarily the melody.  I wish you would finish it because I foound it enjoyable.   

The thing is that you used HL content. Textures. models, etc... those things are copyrighted to the owner, which is Valve and its publisher. Selling that kind of game means copyright violation -> that firm (but mainly YOU, cause you are the developer) will be sued for at least 25.000 $.   Also they can put you into the jail. I think those guys understand that the main responsobility will be on you, so think for yourself ...

1.  The Turkish distributor may or may not have a license to distribute the materials in question.  It's not clear that they don't and they calim that they do; so I think this would open the door for futrher negotiations.  Just ask them to produce documentation.

2.  In the US the person or entity that has money would get sued for copyright infringement.   You would possibly be named in the suit but would not be the primary target because you are not the monied interest.   The distributor would also be the primary target because it is they who are distributing the materials not you.  You have made a derrivative work under "fair use"  provisions of copyright law.  You have represented to them this fact and they have told you they have a license to distribute your derrivative work.  If you can get all of this documented then I think a deal is possible.  Just be sure to use your own attorney, from your own country.

3.  In the US you can't be sent to prison as the result of a civil lawsuit, so there is no point in suing someone who has no money.   The jail thing depends upon the country.

4.  CoolBlue's profile says he is 16 years old.  In the US persons under the age of 18 cannot enter into enforceable contracts. 

I would contiue to negotiate with them, get everything in writting, see what kind of money they are talking about, and get some legal advice before signing aynthing.  If there isn't enough money in the deal to cover attorney fees then this distributor isn't serious about the deal, IMHO.

You could also get a free Terran-x.tk domaim if it's available.

[Dynamic Variables]

If you declare it outside of the function, it's a global variable and not a local one.

Perhaps some clarification about variables would be useful here.  If I get some terminology wrong someone please correct me. 

Dynamic Variables
These  variables are declared inside the bounds of a function.  They exist only while the function is being executed.  When the function completes dynamic variables are "destroyed" (i.e. the memory allocated to such variable(s) is freed and may be reallocated for other purposes).  These variables are used to hold intermediate results of calculations or other values that are calcualted every time the function is executed.   These variables do not retain their values from one executition of the function to another.   It is generally accepted practice to declare such variables at the beginning of the function prior to executable statements.

Static Variables
These variables are declared outside the bounds of any functions.  They are created when the game is loaded and remain in existence and retain their values for the duration of the session.  These variables are accessable by any function defined in the same script file but not by functions in other script files.  The values of such variables are also saved and restored byt the "Save/Restore Game" mechanism.  It is generally accepted practice to declare such variables at the beginning of the script file prior to executable statements.  In a large script file, such as the global script, that is organized into functional groups it is also acceptable to declare such variables at the beginning of the function group where it is intended to be used. 

Global Variables
These are static variables that have been made available to all script files via export and import statements.  Normally these variables are declared in the Global Script file and immediately followed by the corresponding export statement.  An import statement in the Script Header then ives access to the variable from all room scripts.

I do need declare those ints outside of the function though, I have other functions that use them.

In the case of "textid", "length", and "i",  in the example, I would declare these inside each function where they are being used.  You will of course have to eliminate the curent declarations that are outside any function bounds. 

I think overall the potential confusion caused by adding this feature probably outweighs its usefulness.

Hehe, this answers the original question,  and I can live with that.   

Traveler thanks for your thoughtful reply, however I think every one here is missing the point.   Accessing non-existent entities is not an issue, I think everyone agrees that you can't do that and that generating an error at run-time is the appropiate action.   It's not relevant to the discussion.

It's my contention that a pointer value of null is legal and that one should be able to test for it without generating a runime error and that "control.OwningGUI.Controls[0].AsButton" is a pointer.

I'm well aware of the Intel Archeticture as I did quite a lot of ASM programing during my time at General Electric.  I believe you are mistaken about the processor throwing null pointer access exceptions though.  Programs are given specific sections of memory they are allowed to access.  If a program attempts to access other memory an interrupt is generated that represents a runtime error.   A null pointer access may or may not casue this to happen, it depends upon the language implementation.  This is irrelevant anyway because this is not what casuses "control.OwningGUI.Controls[0].AsButton" to generate a runtime error, the error is generated by the AGS interpreter.   

You and Snarky mention performance hits and engine bloat associated with evaluating pointer expressions as I suggest.  I don't believe this is much of an issue either.  It seems to me AGS is already checking for null when evaluating pointer expressions, otherwise it couldn't generate the runtime error.   Although I can't be certain I don't think returning  NULL is any more performane intensive or complicated than generating a runtime error.   

Again, it'd be extremely hard to track down errors because of such a default behavior. Right now, if you access null, the code crashes ...

Access null?  Again I think this misses the point and that you are not understanding the issue.   Please explain to me where I have said that accessing  something with a null pointer should be allowed.  I haven't.  What I have said is that "control.OwningGUI.Controls[0].AsButton" is an exprression that represents a pointer and that if it doesn't point to anything for any reason it should evaluate to a value of null. 

With the default behavior you'll get default null-s all over the place, so it may not turn out that there is something very wrong with your code - until some user reports it. Doing a fix right now pretty much translates to downloading the entire game again so it's a high risk to let out code with possible hidden errors. I know this feature is very tempting and looks convenient but it would cause a lot of probles down the road.

Actually, the situation is just the opposite as you describe and this is the reason I submitted this humble suggestion.  I believe that people will find that something like "if (control.OwningGUI.Controls[0].AsButton==null)"  casuses an error and then they will make changes until the error goes away by doing something like "if (control==null)", leaving an incomplete test and future possibilites of game crash. 

It's standard coding behaviour that you'd expect -- if you do something like that in Java, C#, C or C++ you'll get an error (a NullPointerException in Java/C#, or the program will crash in C/C++). Even Visual Basic will generate an error if you do this.

Really, I'm quite surprised by this.  I guess I have always been careful and disciplined in pointer usage and so have never came across something like this before now (or at least don't remember if I have).  Hehe, I'll have to try it for myself one of these days just to convince myself that I'm not living in the "Twilight Zone" or something.   Anyway I think the bottom line on this is that you should do whatever you think is best for AGS and it's users.  Ans as always I'll leave to that your your own good judgement. 

I just tried this out but it worked fine -- does it fail repeatedly for you, or was it just the once?

It failed a couple of times but it was during the same session.   I'm upgrading a game to the new version and so created a temp directory and moved all the room files there and reintroduce them back into the game one at a time.  The first and second rooms seemed to have a problem being updated in that session.

I just tried adding a third room and  UpdateList works now.  The editor is now in a new session and I have activated the compiler via "Test" several times.   I can't reproduce it now nor can I say fo certain what happened the first time.  So I suppose we just write it off as a Windowism. 

[Queue Formation]

I believe that C-Language behaves as I describe.  I can't remember if I ever had occasion to try somnething like this myself or not so I did some research on the net.   I wasn't able to find an explicit statement of how C is supposed to behave in this situation but I found an example from Juciy Studio that illustrates my point.

In the example below the queue is initialized so that  "queue->front->next" is set to NULL.  Now what happens if the leave() function is called immediately after initialization?  The leave function checks to see if anything is left in the queue via "if (queue->front->next->next == NULL)".   Since the queue is empty queue->front->next is clearly NULL.  As I understand Traveler's and Snarky's remark they would expect the "if" statement to generate an exception at runtime, which would mean that this example is incorrect.

I don't have a C-compiler on this machine, perhaps someone would like to make a test and let us know what happens.  At this point I am very curious.

Queue Formation
A queue is a special kind of data structure that restricts access to its elements. It does this by only allowing insertions to take place at the rear of the list, and deletions to take place at the front of the list. A queue is characterised by the expression First In, First Out (FIFO). An analogy of a queue isn't required as we spend most of our time stuck in the things. You join at the back, and leave at the front (unless you're bigger than the person in front of you). To implement a queue, we shall use an extra structure to keep track of the front and rear of the queue.

typedef struct node
{
    char data;          /* Store the keystroke by the user */
    struct node *next;  /* Pointer to the next node */
} NODE;

typedef struct queue
{
    NODE *front;        /* Front of the queue */
    NODE *rear;         /* Back of the queue */
} QUEUE;

Initialising an Empty Queue
By making the front pointer equal the rear pointer, we create a dummy node as the queue members front and rear are both of type NODE.

int initialise(QUEUE *queue)
{
    if ((queue->front = (NODE *)malloc(sizeof(NODE))) == NULL)
        return 0;
    queue->rear = queue->front;
    queue->front->next = NULL;
    return 1;
}

Removing Items from the Queue
We will write a leave function to remove a character from the queue. Start by creating an old node template, oldnode, of type NODE. Make the oldnode point to the first item in the queue, bypassing the dummy node. By moving the next member of the front node to the next node, we can free the oldnode. If the node is the last node in the queue, we need to ensure the rear of the queue point to the front of the queue (an empty queue).

char leave(QUEUE *queue)
{
    NODE *oldnode;
    char key;
    oldnode = queue->front->next;
    key = oldnode->data;
    /* Check if removing the last node from the queue */
    if (queue->front->next->next == NULL)
        queue->rear = queue->front;
    else
        queue->front->next = queue->front->next->next;
    free(oldnode);
    return key;
}

P.S. Sorry for the long post 

Possible Bug: After copying Room2.crm to game directory, RoomEditor->RefreshList doesn't add the new room file to the list of editable rooms.  If I am misunderstanding the purpose of the RefreshList function then I appologize for being a nusiance. 

You could possibly use the RawDraw() functions to draw such tiles if you wanted to do that. 

In this case ...

int width = control.OwningGUI.Controls[0].AsButton.Width;

the path would evaluate to null and the resulting exptression would be the equivalent to ...

int width = null.Width;

which would then generate a runtime error. 

So what I am suggesting is that evaluation of pointer paths would not generate runtime errors but would instead evaluate to null if the given path was not valid.  Subsequent usage (in the same or subsequent script staements) of such a path to access member data or functions would be subject to runtime error checking as it is now.

I'd like to turn-off the in-game cursor when the user mouses out of the game window.   I tried what you suggest Esseb but it's not reliable.  If the mouse is moving fast enough the in-game cursor get's left behind and so you never see it in the end zone (I've tried with an adjustable border).   

Too bad there is not an event or built-in variable or something.   I was just wondering if anyone knew a trick or something.   

When running a game in window mode, how can I detect if the mouse cursor has been positioned outside the AGS game window?   

Well, you only need to check the parts of the path that could be null.

That was pretty much the meat of my question. Thanks for clarifying what was going on.   Perhaps the manual should make this point.

In my opinion, a path should evaluate to null if any portion of it is null instead of generating runtime errors.  This would allow a simple test of the entire path as in my first example.   

However, now that I have a clearer understaning of the situation I can do what is necessary to avoid the possibility of runtime errors.  Thanks.   

If "control" is null then the following test generates a runtime error. 

   if (control.OwningGUI.Controls[0].AsButton!=null) {
      // Do Something
   }

So then is it necessary to use a nested if statement to check each portion of the path for null or is there a better way?

   if (control!=null) {
      if (control.OwningGUI!=null) {
         if (control.OwningGUI.Controls[0]=null) {
            if (control.OwningGUI.Controls[0].AsButton!=null) {
               // Do Something
            }
         }
      }
   }

Is it the case that AsButton or Controls{x} generates the runtime error and if so perhaps just returning null would be a better choice, since the result of those operations is a pointer.  Runtime errors would ultimately be generated if such a null pointer is subsequently used in a context that warrants it?

This seems to me to be very reminiscent to the recent discussion about lazy evaluation. 

Rick, the text is correctly being centered within the button. However, it looks wrong because you have a fixed 25x20 image for the button ...

Ah man... I knew it was me but I just couldn't see the obvious.  Sorry for the false alarm...