Annoying error, maybe a Blitz3D bug !

Blitz3D Forums/Blitz3D Beginners Area/Annoying error, maybe a Blitz3D bug !

etxtra(Posted 2011) [#1]
Hi everyone! Today, I'm having the following error: "Entity does not exist". this error has popped out just today and the same program was working fine for weeks and I did no changes !
fortunately, the debugger gave me leads, a line of the program that may be causing the error:
Dim T_Tirs_Lasers_F#( 1, 8 )

	v_Correction_OBJ_E% = LoadMesh ( "Bin\Terrain\Tir Laser Finale.x" )
	T_Tirs_Lasers_F( 0, 0 ) = CopyMesh ( v_Correction_OBJ_E )
	PositionEntity T_Tirs_Lasers_F( 0, 0 ), 0.0, 20.0, 0.0

it worked fine yesterday and now it is a problem ! what's wrong ?
the highlighted line (by the debugger) is :
	PositionEntity T_Tirs_Lasers_F( 0, 0 ), 0.0, 20.0, 0.0


Last edited 2011


Warner(Posted 2011) [#2]
There is no bug there: replace LoadMesh by CreateCube and it works fine. So, your model can not be loaded.



Yasha(Posted 2011) [#3]
T_Tirs_Lasers_F is an array of floats. It can't reliably hold the address of an entity and is probably rounding it to an incorrect handle.

Last edited 2011


D4NM4N(Posted 2011) [#4]
Yasha is spot on. Never use floats (#) for pointers to data, always use an int (%) because floats can be fractionally inaccurate.
Also you should never use the equals operator (=) with floats either

Eg. this is unstable:
a#=1.0
if a=1.0 then unstable result

always use:
a#=1.0
if a>-1.000001 and a<1.000001 then stable result

as 'a' might not be a "smooth" 1.0

Last edited 2011


Rob the Great(Posted 2011) [#5]
I'm not sure if you're on a mission to find a bug in Blitz, but keep in mind that bugs are a rare thing to come across. The developers of Blitz are highly experienced programmers, and they've released a lot version updates to fix any bugs discovered in the past, which has always been a small list. Unless your code is incredibly simple and there is no possible explanation other than a bug, always assume it's your error, not Blitz's. In other words, if you can't re-create the same MAV using limited custom variables and less than 50 lines of code, it's probably not a bug.


jfk EO-11110(Posted 2011) [#6]
Using Floats for an Entity Handle may work one day, and not the other day, or it may work on one machine, but not on an other one. The reason why is: Entity handles will be a number that is automaticly created and has something to do with the memory location of the entity. When you're lucky then this number is lower than 128 Millions and therefor iut still can be handled by a float. If it's higher, an error will occur since the float is starting to use expressional encoding, that cannot be used as integer handle.


Kryzon(Posted 2011) [#7]
Is expressional enconding those crazy "5.53151e-139" numbers?


Yasha(Posted 2011) [#8]
All floats are encoded in the same way: http://en.wikipedia.org/wiki/IEEE_754-1985

All floating point numbers are stored as a fractional part and an exponent, which is why they have a much bigger absolute range than integers but much less precision.

"those crazy "5.53151e-139"" aren't anything special. They're simply a convenience since it would be unwieldy for the decimal representation to actually have 139 digits (i.e. that's normal scientific notation: 5.53151 * 10 ^ -139 ) when most of them would be zeros (due to the limited accuracy). The use of scientific notation is strictly a feature of the to-string/from-string conversion and nothing to do with the float's internal structure (they use binary like all other numbers).


D4NM4N(Posted 2011) [#9]
the only stable fractional format in programming is "Decimal" as far as i know (perhaps double too? not sure about that one) and this is true of all languages i believe.
-but blitz has neither of these so we have to live with floats.

Last edited 2011


Floyd(Posted 2011) [#10]
Blitz3D has only three data types: string, integer and float.

So a variable named x could be:

x$  ; a string
x#  ; a floating point number
x%  ; an integer
x   ; defaults to integer, same as x%

Once a variable has been defined you no longer have to use the type tags $ # %.

The same rules apply to values returned from functions. When defining your own functions you must specify the type. Again the default is integer.

Built-in function have the type pre-defined. You can see the type by pressing F1 and looking at the status bar at the bottom of the IDE.

You would see, for example, Sin#( which tells you that Sin is a float.
LoadMesh( has no type tag so it is an integer, the default.

Thus you should never store such a value in a floating point variable. Sometimes it will work "by accident", but you cannot rely on it.