Horrific. Man what a shame. Tiring, very this is.
I have a perfectly working script, then I add a single new local variable to this
same script like I have for many months, and it gives me that it's nill and
"trying to compare a nill to a number." I go to the effort to double check my text,
that it's activated before main, that it's assigned to zero in init, everything.
Finally I restart GG. Still calls it nill. Then I restart the computer, start a test level
from scratch, still calling it nill. All just for one single new variable. What in the world?!

Finally just before the suspected line, I have to insert;
if hgok[e] == nil then hgok[e] = 1 end ---- this is NOT the desired fix but it works--
but only for one entity on the map for the script. When I add more than one entity,
now it says "trying to compare nil to number" line 175
I go to line 175
Line 175 is;

175 end

Hard to say when I have not idea what script are you talking about, anyway there are a couple of things you has to mind:

1- Both the trigger and the referenced mesh should be dynamic. If you want destroy some mesh via another mesh script, both should be dynamic, otherwise most likely you'll get nil error. Static meshes return nothing.

2- Don't know why you declare this variable as nil value. BTW if you are forced to, so declare the variable as: myvar = nil or 1.

GG Lua debbugger is so basic, is like when you say my house is located between 100 and 250 meters from the church.
The truth is not very accurate, but it helps.
You have to learn to decipher the GG error messages.

well comparing a number to nil is bad.. any engine will have the same issue... how can you compare to something that doesn't exist?
if you define an array (i.e. hgok = {} ) it's values are nil by default, if you want to compare you need to set a default value for any index you want to compare (i.e. hgok[1] = 0, hgok[2] = 1, hgok[e] = e ... etc ).
post your script and we can help explain what you're doing wrong

Thanks smallg and 3com. I will be asking for your assistance you can be sure!

Yes, I certainly set the variable to 0 in the init section.
If you look closely at my thread, my complaint is that GG called an error of nil
variable on line 175, and that line was nothing more than; 175 end

At other times, the error skipped an identical section of the script that contained
the same variable but further down called an error to it.

I did all those checks as I listed them above, even going so far as to the initialize the
variable inside the main body trick;

doonce[e] = 0
function _main(e)
if doonce[e] == 0 then
if hgok[e] == nil then hgok[e] = 0 end
doonce[e] = 1
end

I'm half wondering if it's my computer when it gets hot (there's a very high heat
wave going on here), or just a windows memory allocation glitch.
I script nearly every day for GG lua. Some days no problem, some days there's
this weirdness that is just frustrating.
First post said;

"that it's activated before main, that it's assigned to zero in init"

What I'm getting at I guess is that GG seems pretty buggy to me. I get frustrated
by these "cursed scripts", and still keep trying to plug along. So what's the fix?
This line immediately before the "cursed" variable shook GG into obedience finally!

if hgok[e] == nil then hgok[e] = 1 end

But many times I don't need to go to that extreme recourse. It's just a mystery.

"I script nearly every day for GG lua"

I have 2443 hours of GG use according to Steam, ALL of that is testing scripts I have written. I have never encountered the problems you are complaining about!

If Lua says you have a problem at line n then you do indeed have a problem there, if the line doesn't seem to make sense given the error reported then either you are not looking at the correct script or you haven't saved the script that you think you are running. -- Edited to add: Just thought of a third reason, there may be extra characters on the line that don't show up in your editor, can happen if you cut and paste code from a browser window --

I might try a 3rd party lua editor for verifying, but how do they work
when there are custom GG dependent functions? I still have to run
in GG to actually test the scripts!

Update:

Tonight I got some very funny errors from a very simple script.
So I guess I'll let the computer rest overnight and try again -- maybe computer
is snot. I usually don't get started till later and my mind is rested from supper
and the kids are in bed and all's finally quiet. So GG might have been running for
a while, and the computer all day.... errrgh still.

Lua ignored my end statement after the littlescript_init(e) and said
44 <eof> expected near 'end'

line 44 ==
44 end
LOL

Next up is; 96 syntax error near 'score'
line 96 ==
96 score[e] = score[e] + scoreval[e]

How is there a syntax there? Both those variables are locally defined already...

I'm just documenting this because I'm gone crazy by the weirdness-- no worries
for anyone else! But... do I need to dump windows memory or something?
What does that do, and is it safe?

BTW I hope not to bother you any more on these complaints because it's simply
not a lua issue, it's something else I would have to work around.

@ GubbyBlips

Excuse if you already know this, if so, maybe help others.



in your script there is an orphan end. The statement if is build as follow:

--ok
if a==b then
do something
end

--bad
if a==b then
do something
end
end -- unneeded end here, It will thrown error.

end -main

Notice the if statement has 2 ends when it just need one; so there should be an end without if , somewhere.

A good practice, atleast for me, can be a well commented script lines, this help to know what it does and how it work each line,
It helps you understand what each thing does, especially if you like to use things like pim = pum and zo = zc, believe me it now make many sense, after a long time you don't know what this pim, pum meants. Atleast happens to me,

Good practice:



When this happens debugger goto final code line. (end -- main function usually)

Juat add than the " ==" is use to compare something, meantwhile "=" is used to pass a value to a variable.

You cant use ie: a == 96, to pass a value you do, a = 96, and for compare you do, if a == 96 then, notice here you are comparing "a" with 96 , if so, then do something, it's just a condition.

Just post the scripts so we can show you where you are going wrong!

This is the script, and this is the error!
What in the world?

firstly why does your error say the script is called getnear.lua when the script you gave is nearest_object.lua?

debugging the script you gave does have a few issues though;
'ee' doesn't exist at line 61
if g_Entity[e] ~= nil and g_Entity[e] ~= 0 and g_Entity[ee] ~= nil and g_Entity[ee] ~= 0 then
as it's only within the for loop, you should use lclosestee instead.

putting a function inside a function is not good unless it is a local function (in your init(e) function).

lclosestee and lclosestdist haven't been defined or given any default values (unless it's in another script for some reason?)
if ddd < lclosestdist then
TextCenterOnX(50,50,7, "lclosestee = "..lclosestee)
TextCenterOnX(50,60,7, "closestdis = "..lclosestdist)
so all of those lines will crash / error

ee does no take any value, the only function that can pass some value to ee you don't call it (function nearest_object_enemydist(ee,e))
You are using ee as iterator and as index, wich is an empty var, at least you are passing it some value, from another script.
The same with lclosestee and other one.

What are you expecting this script does?
Do you want to know if 2 meshes are nearest? if so, you alredy has some script than does, out there.

Oh yeah, of course. I clicked on the wrong script to send!

Fixed it...
well, at least now the script in question is sent...!
not fixed- but up there ^^ now!

line 56 Hide[e] should be Hide(e)

Hide[e] is perfectly good Lua as it goes but the next thing it would expect to see would be an '=' (if you were assigning a value) or a '(' if calling a function in a list.
As you instead follow it with 'end' Lua can't make sense of it so you get a syntax error.

Oh my word. Nice catch. Alrighty! Thanks.

That's why we need to see the whole script, or at least enough of it to see the context, as the actual error may not be on the line where Lua detects the syntax error. For example if you don't neatly indent the script (use spaces or tabs not a combination of the two!) it is easy to have too many end', too few ends and mismatching else/elseif statements.

When a script starts getting large it also helps to break it up into separate functions, if you name the functions nicely you can also aid readability, for example:

Right on AmenMoses!
So now since we got that little bit out of the way, I have a new question:
This script was used to detect bumping into and remove an object. We have
a stack of (4-5) barrels or whatever. You destroy the bottom barrel. The rest of
the barrels are supposed to fall-- yet most of the time they don't move.
Once or twice in testing the stack of barrels will fall, but that is almost never.
And only once will that stack move even if the bottom barrel is again destroyed.

These are the settings... dynamic of course, physics= yes, isimmobile= no
always active= yes, weight= 100, friction= 1.

Any ideas? Sometimes as the player in testing, I can bump into the barrels and
make them fall-- even that is not always, so we get barrels floating in the air for
some strange reason.

ResetPosition line has been added, but same results...

CollisionOff(e)
SetPosition(e, x,y,z) ---- move bottom barrel far away
ResetPosition(e, x,y,z) ---- move bottom barrel far away
CollisionOn(e)

It's due to the way the Physics Engine works (GG uses the Bullet engine btw), if an object doesn't move for a while it is put to sleep so the engine doesn't need to process it. To wake it up you need to give it a push, i.e. PushObject( objectId, 0, 0, 0 ) .

The objectId for an entity is g_Entity[ e ].obj btw.

Edited to add: To simplify things you could push the barrel you are moving out of the way, i.e. give it a tiny push upwards the frame before you remove it, this should wake up all the ones stacked on top. Don't give it too big of a push otherwise they will all fly off the map!

Try PushObject( g_Entity[ e ].obj, 0, 0.0001, 0 )

Btw, you may find this useful:
https://forum.game-guru.com/thread/219758#msg2601608

Nice. I definitely look forward to using much of those functions.
Also, I could use a clear explanation of the best way to use global variables--
how to define them, how to utilize them best and so forth, without getting
zapped by errors!

Any variable not declared as 'local' is by default global.

So:

A = 1 -- global

local A = 1 -- local

Anything declared as 'local' can only be accessed within the scope of where it is declared, so if declared within a function it can only be accessed within that function ( a 'good' thing).

Anything not declared as 'local' is accessible from everywhere and as you don't know what variables other scripts are using you are extremely like to screw up other scripts without intending to (or have them screw up yours!) by using global variables.

The convention in GG scripting is to start all global variables with g_ and I would add a further convention to append the name of the script as well just to make darn sure it is unique, i.e. for my pickuppables script I call all global variables g_PU_<name of variable>.

( btw any variables starting g_ will be saved by the default GG game saving mechanism, or at least they are supposed to be. )

In a similar vain, any global functions you define should take the name of the script, or a shortened version of it to make them unique, so again using the pickuppables as an example PU_EntityCarried would be an acceptable global function name.

Ok. Do you have to pre-define global variables to a value like zero,
or g_kgscore = 0 in init (seems like you would- just checking.)

Most of the errors I get is lua getting finicky about variables being nil.
And it seems what you described is that you don't have to create
a table first either? g_kgscore = {} if they are global? Or you do?
These are just traditional things I do in my script, without that much
knowledge on the "why"...

when you say that A is greater than B, you are making a comparison, the problem is that A is equal to 5 while B is equal to nil, B has no value, therefore there is nothing to compare, and therefore an error occurs.
To avoid this problem, ensure that the variables always receive a value, either by direct assignment [i]A = B[/i], or by receiving the value from another variable:


A is passing a value to B, therefore B is no longer an empty variable, now you can establish the comparison, without receiving any error.

When I work on a new script, I usually copy and paste the code version in the notepad before making drastic modifications, if I achieve the following objective, I copy and paste the new version of the code and as it works well, I add: --ok +, and I continue, when I get another success in the operation of the code I repeat the operation but this time I add: --ok ++ and so on.

If after a long time, If find this code, I know which version does one thing or another. And if the next attempt to improve the code is disastrous, I can go back to an earlier version of the code that worked well, and continue from there. Things like this help isolate an error to find it more easily.

In real life things have characteristics, unique features that differentiate them from others.
A car has color, brand, size, weight, etc.
In GG entities also have characteristics or properties, and you can work with them.
A table / array is like a bag, here you can put all the features together, and work with them.


car = {color = "blue",size="small",brand="bmw", weight=1000}

Now you can do:



Question is not why, but when. When use a table/array or does not.
That depends on how many characteristics the object with which you are going to work has, for example in the case of particles, they are many as you can see.

You have 200 apples and you have to transport them from point A to point B, you can take them one by one and make 200 trips, or put them all in a bag, and carry them at once.

In real life we execute code every day, in each of our actions.

I wake up in the morning and go to the kitchen, if I have oranges I will drink a juice, and if I don't have a cup of coffee. This in itself is already a decision making that implies a condition:



Easy. LOL

But you wanted oranges!

Usualy happens. LOL