GML Do you know what could make this error to occur?

A

AKKSTER

Guest
FATAL ERROR in
action number 1
of Create Event
for object o_ventlightoff:

Variable o_usage.<unknown variable>(100010, -2147483648) not set before reading it.
at gml_Object_o_ventlightoff_CreateEvent_1 (line 1) - o_usage.usage -=5;

I have an object that is called o_usage and in it's create event there is this:
GML:
var usage;
usage = 0;
 
A

AKKSTER

Guest
Get rid of the var usage; line. That makes it a temporary variable that goes away at the end of the event or script.

You should learn about the 3 variable scopes:
but I still get en error if I don't have that I put it to prevent the error but I couldn't. This is the error:
FATAL ERROR in
action number 1
of Create Event
for object o_ventlightoff:

Variable o_usage.<unknown variable>(100011, -2147483648) not set before reading it.
at gml_Object_o_ventlightoff_CreateEvent_1 (line 1) - o_usage.usage -=5;
 
Last edited by a moderator:

Nidoking

Member
Don't use an object name in dot syntax. It looks like you have more than one o_usage. How is Game Maker supposed to know which o_usage you're talking about?
 

FrostyCat

Redemption Seeker
You are racing two Create events against each other, o_ventlightoff's and o_usage's. You get that error because o_ventlightoff's Create event is running first, before o_usage even exists yet. It's possible to make o_usage's come first using Instance Creation Order in the room editor, but in the long run, setting up races like this is a bad habit.
 

kburkhart84

Firehammer Games
You are racing two Create events against each other, o_ventlightoff's and o_usage's. You get that error because o_ventlightoff's Create event is running first, before o_usage even exists yet. It's possible to make o_usage's come first using Instance Creation Order in the room editor, but in the long run, setting up races like this is a bad habit.
What you generally can do to get around this is to have one object create the other, which ensures things happen in the proper order. Depending on what you are doing, and if you are working with objects that tend to stay around the whole time, you can put some objects into a room at the beginning, and make them persistant. Then, when you go into the next room, the first object is already done with its own creation event and the second one can then access the first one.

As Frosty mentioned, using instance creation order isn't usually a good idea...its too easy to forget what you changed, and where. If you force the issue like I suggested above, there isn't really any way for it to fail, and it will work the same every time, with less risk of you forgetting stuff.
 
A

AKKSTER

Guest
What you generally can do to get around this is to have one object create the other, which ensures things happen in the proper order. Depending on what you are doing, and if you are working with objects that tend to stay around the whole time, you can put some objects into a room at the beginning, and make them persistant. Then, when you go into the next room, the first object is already done with its own creation event and the second one can then access the first one.

As Frosty mentioned, using instance creation order isn't usually a good idea...its too easy to forget what you changed, and where. If you force the issue like I suggested above, there isn't really any way for it to fail, and it will work the same every time, with less risk of you forgetting stuff.
I declared usage as a global variable and that solved the problem but idk if it would cause an error of some sort to have a global variable
 
i can believe that is for 1 of the variables is not set or you are trying to use a VAR that is considered as a one usage and then when its not required anymore its removed from memory, if you need a variable to use everytime DONT USE "VAR"
 
A

AKKSTER

Guest
i can believe that is for 1 of the variables is not set or you are trying to use a VAR that is considered as a one usage and then when its not required anymore its removed from memory, if you need a variable to use everytime DONT USE "VAR"
I know. I put var to see if it could solve the case but it couldn't so I deleted it and made it a global variable
 

TheouAegis

Member
Using global.usage means you now have 1 usage variable that is shared among all instances. So if there can be more than one o_usage in the room and each o_usage is supposed to have its own independent usage variable, do not use global.usage for this.
 
A

AKKSTER

Guest
Using global.usage means you now have 1 usage variable that is shared among all instances. So if there can be more than one o_usage in the room and each o_usage is supposed to have its own independent usage variable, do not use global.usage for this.
There is only one o_usage in the room though.
 

TheouAegis

Member
Then just declaring usage=0 in the Create event of o_usage and using o_usage.usage-=5
is fine. But o_usage must exist in the room before you can refer to any of its variables.

Also if usage is 0 by default, then o_usage.usage-=5 would mean usage would become -5. So somewhere you clearly must have a line like
if o_usage.usage>=5
getting tested before reducing o_usage.usage, right? From a logical standpoint, there shouldn't be an instance race like FC alluded to at all in that case. If global.usage is the only way to have a usage variable without any errors and if you put in the conditional that usage is high enough to be reduced (you did do that, didn't you?), then the next logical conclusion is o_usage doesn't exist in the room either.

Things get messier the more interdependent your objects become.
 
Last edited:
A

AKKSTER

Guest
Then just declaring usage=0 in the Create event of o_usage and using o_usage.usage-=5
is fine. But o_usage must exist in the room before you can refer to any of its variables.

Also if usage is 0 by default, then o_usage.usage-=5 would mean usage would become -5. So somewhere you clearly must have a line like
if o_usage.usage>=5
getting tested before reducing o_usage.usage, right? From a logical standpoint, there shouldn't be an instance race like FC alluded to at all in that case. If global.usage is the only way to have a usage variable without any errors and if you put in the conditional that usage is high enough to be reduced (you did do that, didn't you?), then the next logical conclusion is o_usage doesn't exist in the room either.

Things get messier the more interdependent your objects become.
I already have the line
GML:
if usage<0 {usage=0;}
 

TheouAegis

Member
I already have the line
GML:
if usage<0 {usage=0;}
So even if usage is 0, o_ventlightoff will always subtract 5 from usage? You don't have a requirement that usage be at least greater than 0 before being able to use it? I mean, the variable is called "usage"... one would think if it was 0, it wouldn't be of any use. 🤔 If you are getting an instance race like FC alluded to, then that means you are allowing o_ventlightoff to use up power (or whatever) even when there is none. That doesn't sound very logical to you, does it? Whatever is creating o_ventlightoff should first check if usage is at least 5 before creating o_ventlightoff.
 
A

AKKSTER

Guest
So even if usage is 0, o_ventlightoff will always subtract 5 from usage? You don't have a requirement that usage be at least greater than 0 before being able to use it? I mean, the variable is called "usage"... one would think if it was 0, it wouldn't be of any use. 🤔 If you are getting an instance race like FC alluded to, then that means you are allowing o_ventlightoff to use up power (or whatever) even when there is none. That doesn't sound very logical to you, does it? Whatever is creating o_ventlightoff should first check if usage is at least 5 before creating o_ventlightoff.
Hey dude, this is an object which has a counterpart that adds 5 and they turn into each other when left pressed (on-off). It isn't logical but it doesn't make a problem since it can't use because usage can't be below 0. Why are you insisting on having that code anyways?
 
Top