This is not a gremlin, and has occurred since upgrading to A7 The same code that worked with A6.314 doesn't work with A7.
I have reported this before but it was dismissed as a gremlin.

I have more info now so hopefully someone will look into it.

I am a PRO user and have been since A3.9 15 published games with gamestudio 10's of thousands of games sold. (My credentials over with.)

OK. This fault exists with A7.07 and current Beta A7.08 as well.

I have over 35 Include files in our main WDL file.
Near the end of one of these files after about line 7500 of code the player pointer is no longer seen!.

Every new function we add with
While (Player==NULL) {Wait(1);}
Never gets past this line of code whilst other function in other includes and before line 7500 (approx) in this include do!
So the player pointer is definately getting set this is the first thing we do in any of our player code!
To Work around this problem we ALSO set a new pointer called my_player. When we evaluate this with
While (MY_Player==NULL) {Wait(1);} our code now works.
The main reason I think it is a bug is everything worked OK with A6.
Its not just the above line of code either its anything to do with the player pointer.
eg. If Vec_Dist(my.x,Player.x)>100 will give an invalid pointer error even after the Player pointer is defined.

I've also noticed that WED repeats Actions in the action list when selecting an action for an Entity.
It seems to pickup the pre-defined function names as well.

Jethro.

The first thing to do in such cases is debugging. Anything could be an engine bug, but you'll never know unless you look where the problem lies at all. I can help when I know where the problem happens, and under which circumstances.

"Invalid pointer" means that a pointer is NULL. The first thing to do is finding when and where in the code that pointer is set to NULL. Display the pointer on the screen, like this:

draw_text(str_for_num(NULL,player),10,10,vector(0,0,0))

and check if and when "player" changes.

OK. I implemented what you said in two areas of my code,and this verifies what I already know.

The following code is in the faulty entities action.
While (Player==Null){
draw_text(str_for_num(NULL,player),10,50,vector(0,0,0));
Wait(1);
}
The above always returns "0".

The following code is in the players main loop
while(1) {
draw_text(str_for_num(NULL,player),10,10,vector(0,0,0));
move_view();
....rest of code
wait(1);
}

The above always returns "39965.617".
So the constant screen display is

"39965.617" --> player function using "player" pointer
"0" --> Entity function using "player" pointer

This prooves that in one area of my code the Engine defined Player pointer is set and in another area of my code it isn't.

OK. To my workaround.

Where I set the player pointer, I also set an extra player pointer, "my_player" as follows.

Player=me;
MY_Player=me; //Set this because of invalid Player pointer bug!

Now when I monitor the MY_Player pointer, in the same entity function it is recognised as valid and falls throuigh to the following loop which constantly displays the same pointer number as "Player" Pointer.
Entity code snippet.
While (vec_dist(my.x,MY_player.x) > 50) {
draw_text(str_for_num(NULL,MY_player),10,50,vector(0,0,0));
Wait(1);
}

So the constant screen display is

"39965.617" --> player function using "player" pointer
"39965.617" --> Entity function using "my_player" pointer


Go Figure "my_player" is reliable but "player" is NOT recognised from within this entities ACTION!
In all but one other "Faulty" entity function. The Player Pointer is recognised!

I know this doesn't make any sence at all that is why I'm reporting it!

Hope this helps jethro.

Heres the entire faulty action unedited.

Action SCTur_PU {
//first reset the counters.
MY.Passable=on;
MY.Invisible=on;
Sub_Stage=1; //This is the eggs and turtle picked up
Sub_level=1; //This is the secpan
If (Main_Diff==1)&&(My.Flag1==0){ent_Remove(me);}
If (Main_Diff==2)&&(My.Flag2==0){ent_Remove(me);}
If (Main_Diff==3)&&(My.Flag3==0){ent_Remove(me);}
//I'm for this difficulty so wait until Im needed
While (MY_Player==Null){draw_text(str_for_num(NULL,MY_player),10,50,vector(0,0,0));Wait(1);}
While (MY.Skill1!=Sub_level){Wait(1);}
//I'm now active, so wait to get picked up.
Turtle_Ent=ME; //So GPS Can find me
//MY.Passable=off; //not sure if turn this off. definately need on to carry turtle
MY.Invisible=off;
//Do it with proximity
While (vec_dist(my.x,MY_player.x) > 50) {draw_text(str_for_num(NULL,MY_player),10,50,vector(0,0,0));wait(1);} //For now just wait for player
//We're picked up from here, lock me to player.
Got_turtle=My.skill1;
While (Got_Turtle!=0){// Lock me to player
vec_for_vertex(temp,MY_Player,56);//Read Top left corner vertex
vec_set(my.x,temp.X);
vec_set(My.pan,MY_Player.pan);
Wait(1);
}
//Now get dropped off at secpan, and trigger the secpan.
Ent_Remove(me); //Im Removed while they do the sec pan.
}

The action you posted contains an obvious bug in this line:

If (Main_Diff==3)&&(My.Flag3==0){ent_Remove(me);}

You have to terminate the action here. You must not use the 'me' or 'my' pointer anymore after removing the entity.

I don't know if that can be the reason of the player pointer problem. If you can't find the reason, I suggest that you strip down the level so that is just shows the problem, and then send it to me - I'll look into it.

Yeah sorry for that, we just implemented this and hadn't tested with the diff2 and 3 entities, its not the reason, we corrected that already.

It should read:-
If (Main_Diff==3)&&(My.Flag3==0){ent_Remove(me);Return;}

I can't find the bug, I'll try to strip down, however it's not going to be easy! I suspect stripping down, may clear the bug, if it's to do with the size of the scripts.

Jethro

Don't strip your code, merely create a stand-alone application (a stub) that specifically and exclusively tests out the "player" pointer. It would take very few lines and would resolve this question neatly.

After all, if the problem is with the engine, a few lines using the Player pointer will amplify that bug and make it MUCH more efficiently to squash than searching through actual code. And if the problem is not with the engine, then the stub will run as normal and the problem lies elsewhere.

You make it sound so simple, Even if I make a 1 level application with our code base it needs about 80mb of predefined stuff, which is a bit difficult to email to support.

There is no simple fix, other than spend some time to commonise all references to sounds bitmaps etc, so the script doesn't break when you run it.

Jethro.

But it is that simple.

You're missing the point. A stub would have minimal graphics and everything... it's only purpose is to test your hypothesis: is player pointer broken? It shouldn't take more than an hour to write and test several whiles and ifs and other commmands using player... and then you know if the problem is with the engine or your code.

It's that simple. One hour. Tops.

The problem is that when creating a special application for testing the player pointer, you probably can't reproduce such a problem that is specific to a certain project.

Stripping down the project on the other hand has the advantage that in the process of stripping down, you have a good chance to find the reason of the problem at some point. Remove functions step by step and always test if the last step fixed the bug.

Absolutely, JCL. My point is merely towards the "engine bug vs. code bug" debate.

If it's agreed that a code bug (as we all suspect), then yeah, obviously stripping is the way to go. But if you still harbor any question that it could be the engine, then a stand alone app is the only way to go.