Fastlane is missing the point, it's obviously not an OBVIOUS engine bug or more people would have this problem. So a simple stub won't reproduce the problem.

Even though my rating is Juniour Member(I'm 48). I've been on and off Beta programs sincs A3.9 and reported many real bugs, we've pushed the envelope of this engine in many ways.

If its a code bug, Why did this specific bug show up when converting to A7. The function in question didn't even change!First time I seen this bug is when I converted a project from A6.314 to A7, It was as if The player pointer didn't exist anymore in this area of script. Now when I add new functions below this function they are broken also. However other files included after this are not.

JCL Can it be a script size problem?

Just to test, I'm going to break the suspect script into 2 scripts. I'll see how this goes.

Jethro.

OK Here's some more info.

I chopped the faulty functions off the end of the faulty script and pasted them into a new script, I included the new script straight after the one it was in, so structurally the code would get loaded the same.
The fault still existed.

Here's the clue JCL, now I have this faulty piece of code (there's actually nothing wrong with the code) in a separate script, I can change its position (within reason, to save changing other code).

I moved it down further in the includes so It's actually closer to the code that sets the player pointer.

It now works perfectly.

There were absolutely no mods to the code except change my workaround pointer "my_Player" back to the faulty "player" pointer to test.

Now another test, when I move the script further away from the
end of the script, (ie. closer to the top of the includes.) the pointer becomes invalid again!!

So in a nutshell the faulty pointer becomes valid again simply by moving the functions closer to the end of the loaded script.

I hope this provides some more clues.

Jethro.

Yes, it indeed does. The position of functions in the code determines their order in the scheduler list. From your description I would also expect a dependence of this kind. Something sets the player pointer back, but this has only an effect if it either happens after the pointer is set, or before it is evaluated.

So the critical function that resets the player pointer is either somewhere within the code part that you moved. Or it is immediately before or behind the position where the inserted code just worked again.

I Found the bug.
I moved the problem include, 1 position down in the list of includes 1 at a time, until it started to work.
Then I went over the last include I leapfrogged, mymove3_c.wdl, with a fine tooth comb.

I'm now Eating a heafty chunk of humble pie.
In my code the Player pointer had been re-defined with:-
Entity* player;

I take most of the blame, however the old templates are what caused it in the first place.
Now because my code is converted from version to version, this has snuck in from the old A5 templates where the conitec template code actually reads:-
//SYNONYM player { TYPE ENTITY; }
//SYNONYM temp_ent { TYPE ENTITY; }
//SYNONYM carry { TYPE ACTION; }
entity* player; // pointer to player entity
entity* temp_ent;
action* carry;
inside movement.wdl!

Obviously re-defining the player pointer will cause mass confusion to the same pointer references before this, in A7, however it must have been a requirement in A5?
I was certain it was something to do with the engine because it only happenned after the A7 upgrade.

Thankyou very much JCL, for your help with this, sorry for wasting your time.

I had searched player== player= etc. across all files, however my editors search doesn't allow * char to find pointers.

You can safely remove this from the Bug list now.

Thanks again Jethro.

Can I bring the Ice Cream and we'll make it Humble Pie a-la-mode? Much sweeter that way.