Support for an improved GetEntityColBox( e ) to account for RT scaling

[marcuswilm]

I discovered that instruction 'GetEntityColBox( e )' in 'global.lua. As mentioned in the 'global.lua' comment, it is useful to find the size of an entity. However I discovered that there is a typo in the naming of that instruction. It has to be : 'GetEntityCollBox ( e )' (2 times the letter 'l' after the letter 'o').

I take the opportunity of this comment to mention that this instruction returns incorrect parameters when the entity has a different scale than 100 percent. As far as I discovered there are no available instructions in the 'global.lua' to identify the current scale of an entity.

[AmenMoses]

Take a look at the GetObjectDimensions( obj ) in physlib.lua!

[marcuswilm]

@AmenMoses , in order to better understand your reply, I would like to know the difference between an 'object' and an 'entity' in GameGuru (MAX and/or Classic). I indeed found the instruction 'getScales( obj )' but I don't find a similar instruction relative to an entity.

[AmenMoses]

Everything you place down in the editor has an object Id but only dynamic entities have an entity Id.

The global list g_Entity which is keyed on entity Id has a property (or field or whatever you want to call it) called obj which maps the object Id to the entity Id.

i.e. to find an entities object Id you can use local objId = g_Entity[e].obj

[marcuswilm]

@AmenMoses , thank you for your clear and useful explanation that helps me to improve my knowledge of scripting in GameGuru.

[AmenMoses]

https://forum.game-guru.com/thread/219758#msg2601608

That may be of interest.

[marcuswilm]

@AmenMoses thank you for the link relative to one of your numerous tutorials and threads superbly documented by your projects and videos relative to physics simulations in GameGuru. (I already saved a lot of them in my GG archives).

Your knowledge and your creativity in that matter is a great source of inspiration. Thank you also for that.

Thanks to your previous comment I made some new tests that brought me to the conclusion that the instruction 'GetEntityCollBox (e)' gives a wrong value for its 'zmin' parameter It always gives the same value as the 'xmin' one. It is not the case for the instruction 'GetObjectColBox' that is correct.

By the way : 'GetEntityCollBox' (with 2 times the letter 'l') is the syntax detected in 'GameGuruMAX.exe'. It makes me think that the instructions compiled in that .exe have priority on those found in the 'global.lua'.

[AmenMoses]

Yes, the ones in global.lua are simply comments intended as a sort of reference guide.

I always use the physlib GetObjectDimensions( obj ) function personally. That has always seemed to give the right results.

[marcuswilm]

@AmenMoses , I come back to your second comment in this report. You wrote this : "Everything you place down in the editor has an object Id but only dynamic entities have an entity Id".

According to my tests of today I am tempted to believe this : "Everything placed down in the editor has an Entity ID but only 'not static' entities have an Object ID".

Please could you verify this when you have some free time ? Thank you in advance

[AmenMoses]

No, everything has an object Id, only things you can add a script to generally have an entity Id.

Non active objects may also get and entity Id but they won't have an entry in the g_Entity list unless they are active so you have no way of getting at the Id's from Lua.

For example you could get the object Id of a static entity returned by one of the ray casting commands but you can't really do much with it.

[AmenMoses]

Btw the problem is in the function GetEntityData in DarkLUA.cpp:

                    case 14 : 
                    {
                        // Return collision box coordinates (6 values )
                        lua_pushnumber( L, pObject->collision.vecMin.x );
                        lua_pushnumber( L, pObject->collision.vecMin.y );
                        lua_pushnumber( L, pObject->collision.vecMin.x );   <--- should be z
                        lua_pushnumber( L, pObject->collision.vecMax.x );
                        lua_pushnumber( L, pObject->collision.vecMax.y );
                        lua_pushnumber( L, pObject->collision.vecMax.z );
                        return 6;
                    }

[marcuswilm]

@AmenMoses, thanks again for the time you spent on this report. I am glad that you confirm the error relative to the 'zmin' value for the 'GetEntityCollBox(e) .

About my previous comment posted today I understand your explanation. Nevertheless to show how I came to that contradictory assumption I'll prepare a video.

[marcuswilm]

@AmenMoses , as announced in my comment posted yesterday, I uploaded a video on my Vimeo gallery where I show the context of my tests relative to the instruction 'GetObjectColBox'. Video in HD mode : 226 MBytes = 11 minutes 29 seconds with my spoken comments ( I want to apologize for my bad and too slow spoken English. It explains that too lengthy video. ) This is the link to that video : https://vimeo.com/manage/videos/752024274

[AmenMoses]

You video demonstrates exactly what I said. There is no entry in the g_Entity table for the car so the line attempting to get the object Id will not work. (hence why you get the error)

It appears that the engine (not sure if it is just MAX doing this or whether Classic does it too) is allocating entity Ids for the static entities, which is rather strange, but as I said you cannot actually get at them from within Lua.

What you are doing is explicitly using the numbers in the scripts, e.g. '23' for the car, but that is not very sensible as if you edit the level at any time the numbers are likely to change as when the level is loaded the numbers are allocated from '1' again.

i.e. if you delete a couple of those cylinders you will probably find the car is no longer '23' the next time you load the level.

So in summary the g_Entity table is only populated for active entities and you will hence have no way of getting at the object Id from within Lua for static entities and moreover as static entities cannot execute a Lua script you have no way of working with them without doing as you have done and manually type in the numbers from the editor.

I am actually surprised that GG even allows you to move static entities via Lua commands, I didn't even consider that as being possible!

[AmenMoses]

Btw, not sure what you are trying to achieve but this is how I would do it: show_corners.zip

Attach script to car, change the MarkerName to match the name of your cylinders and the script will place one cylinder in each corner of the car, only does the 4 bottom corners though.

Advantages are that it will work for scaled entity and at any rotation as well. (oh and you don't need to mess around with entity ids!)

The car needs to be active and the cylinders static with no physics.

[marcuswilm]

@AmenMoses,

Reply to your first comment of today ( 5 hours ago) : I fully understand your explanation and therefore I admit that any attempt to bypass the normal logic of the engine by using the 'unstable' ID number of an asset (whatever it is : static or dynamic) is quite risky.

Reply to your second comment of today ( 2 hours ago) : Thank you for sharing your script that runs successfully in the test shown in the video and this according to your explanation about its use for that purpose.

What I am trying to achieve could surprise you. It cannot be explained with a few words.

Your scripts demonstrate how high your level is in matter of programming. You ( and surely many collaborators of GG Engine's project ) are a master and if I would compare your scripts to the moves played on a chessboard by a chess master then I would say that it is quite difficult to digest and understand at one shot for the curious tinker I am. Nevertheless from time to time I'll study its sections in order to improve my practice of lua scripting.

[LeeBamberTGC]

@marcuswilm @AmenMoses Thanks for spotting this, and for finding the typo, fixed for the next EXP build: I have also added GetEntityColBox (correct spelling) and left the old one in too for backward compatibility :)

[marcuswilm]

@LeeBamberTGC Thank you for informing us that you fixed that LUA command. I'll wait for the next official Steam release to verify and confirm.

(I don't take the risk to work with the Steam experimental versions of GG Max because it could compromise the development of my current w.i.p. project. Please read this topic https://forum.game-guru.com/thread/224184 explaining what usually happens each time a new update of GG Max is used. In the past when the Terrain editor was completely revised in an updated GG Max alpha version, all my previous previous projects - simple tests - were definitively 'broken' once they were opened with that updated version. )

:)

[marcuswilm]

@LeeBamberTGC @AmenMoses

As mentioned in my previous reply I verified that instruction with this GG Max version 'Steam 2023-09-28'. In my test I took one of my model created with my preferred modeler 'Metasequoia 4EX'.

I came to the conclusion that the six values (min and max) returned by the instruction 'GetEntityColBox(e)' are correct IF the asset (identified by its entity id number) is NOT rescaled in the editor.

To compare the sizes in GG Max (inches) with the ones calculated in my modeler (meters), I used the truncated conversion factor ( inch to metre = 0.025 ) used by GG Max.

(by the way, I don't understand that choice of the developers for GG Max : metres for the terrrain editor and inches for the positions and dimensions of the assets. It can lead to confusion.

Demonstration of my tests with these screen captures :

:)

[LeeBamberTGC]

@marcuswilm Changing any underlying fundamental now would break everyone elses projects, so we kinda stuck with the basics of what we have. I have retagged this issue however so we can add another command that meets your needs.

[marcuswilm]

@LeeBamberTGC Thank you for your fast reply. I am not surprised by your decision. :)

[LeeBamberTGC]

@marcuswilm yes I am all in on bug fixing the out and out nasties. For this one, I suggest a new command:

GetEntityColBoxWithScale(e)

Agreed?

[marcuswilm]

@LeeBamberTGC Hello Lee :) Frankly said I would suggest to forget this "problem" because in my humble opinion its solution won't be found in any enhancement of GG Max coding. And I am trying to explain why with these commented screen captures + a few additional lines of comments herewith :

A long time ago ( since the first alpha versions of GG Max ) I discovered that GG Max (FBX) Importer couldn't correctly scale my assets created with Metasequoia 4Ex. After a few trials and errors I was able to find the solution to obtain the correct scale of those assets in GG Max.

That solution was situated in the exporter of my modeler : There I modified the 'size' of the asset in the settings of the FBX export (as shown in this next screen capture ) :

I think that (in my case) this workflow is the easyest solution to obtain both accurate scales of the imported assets and of their collision boxes. Therefore I won't rescale those assets in GG Max editor because they are already correct with that workflow.

A last point to conclude this long explanation :
Why am I so interested by that instruction 'GetEntityColBox(e)' ? Because I am working on a project with high speed cars ( more than 300 km/h ) and therefore I don't use the bullet physics engine included in GameGuru Max because it cannot handle high speed collision. Lua can do it.

I hope that you understand my explanation and I take the opportunity of this comment to warmly congratulate you for all your efforts to make GameGuru Max a great game engine. I like it very much.

If you absolutely want to study any enhancement of that instruction 'GetEntyColBox(e)' with your suggested naming, I agree with that. However I'm afraid that you'll face that problem inherent to the asset importer of GameGuru Max coupled with a multitude of FBX format with intricated settings relative to the scaling.

:)

[LeeBamberTGC]

@marcuswilm Thanks for the break-down of the issue, and great to hear you have a workflow solution to get the scaling you need. MAX does rather fly in the face of the 1 unit = 1 meter system that most engines are written around, but changing it now would break many things. We will keep this feature request here as it may contribute to allowing the importer greater scaling controls down the road.