Hi all,

Well is was almost exactly two years ago that I took my sabbatical from Game Guru. However, during that time I checked in and used the system to do some testing of models I had created. I will admit that when I stepped away, I was a bit disappointed in the feature progress of GG, but with the most recent versions many of the features I was waiting for are now available. In particular the control of the camera. Further (Lee) the unbundling of the AI functions is a great step.

It's going to take some time to catch-up and get to using all these new commands. I am already deep into a user programmable script that steps the camera to fly, turn, ascend/descend, land and take-off vertically, and the ability to fly camera from one x/z spot to another on the map. It's working but needs tweaking. I hope to publish some prototype video of the system in a couple of weeks, and I plan to make the script public for anyone to use.

OK to my question.
I've measured the basic map to be 51,100 unit x 51,100 units. Based upon the default scale of GG, what length of measure is one unit? (meters, feet, inches, etc ???). Also, does the Vertical "Y" direction uses a different scale value? I measured the difference between the base terrain and the Y value of the player, to be a difference of 35 units. (height of base terrain 600, Y value of the player 635.). Assuming that the Y value is the center point of the player, that would make the player height 70 vertical units. Is this correct? What length of measure do we use of the vertical?

Thanks

As far as i'm aware the Y value starts at feet of the character. Player height I think is about 80 units, ideal ceiling height is about 125 units (in my opinion). When I make a building I make floor to ceiling at 125 units, with door height 90 units, and window lower frame height about 40 units high.

Normal door opening in real life is 6 foot 8 inches which equals 80 inches which converts to 80 units.
I make my door openings in GG models 7 foot 0 inches which converts to 84 units (in case I run into characters wearing head gear).

Normal floor to ceiling height in real life is 8 foot 0 inches which equals 96 inches which converts to 96 units.
I make my models with a floor to ceiling height of 9 feet which equals 108 inches which converts to 108 units.

In the screenshot each colored cube = 12 unit/inches thus 7 cubes =84 units or in real life 7'-0" (Check the door height by counting the cubes using the yard stick entity)

The yard stick (as I call it) was created with the same software I use for making models. My software allows me to work in real units. (1 foot equals 12 inches) thus I work in inches.

I tried doing it that way with my models, it always felt I was going to bang my head walking through doors and hit the ceiling if I jump, I think its the camera perspective, it kind of cramps things up, that's why I go larger.

I have I have encountered the same problem. Your 125 units for floor to ceiling height converts to a ceiling height of 10.42 feet.
Nothing wrong about that. If you were to jump as high as GG characters jump, in my house, you would also bump your head.
Don't do that... I think if higher ceilings make the model look proportional then we should use what we are comfortable with.

OK, thanks much

if we consider the one unit = 1 inch, than the entire map is equal to about 80% of a square mile, or 4,160 feet x 4,160 feet. That seems rather small to me, though working in inches is easier.

@ Belidos... If the position of the Player begins at the ground/feet level, than why is there a 35 unit difference between the height (Y) of the player, and the height of the Terrain? Based upon 1 inch = 1 unit, 80 units would make the player 6 feet 6 inches tall (which could be right, but I've always felt that the height of the player was a little on the high side. )

Side note / request (I'll add it to the board) Would be nice if in the editor we had a read-out of the x / z units at the center of the position the editor is showing. I know that the numbers are there (in the lower right corner of the editor screen), but couldn't we get that read-out in unit values rather than two numbers that have to be manually converted to get the unit values.

Thanks again

Welcome back, GoDevils! I have nothing to offer this thread except the greeting, sorry.

I believe that most of the characters are between 6' foot and 6'-3" based on a visual scale.

I also use the 1 unit = 1 inch conversion for general measurement. Visual scale can be thrown off a bit though if using default player collision cylinder because that means interior doors are essentially exterior width. Most things can and should be modeled to scale but for things like weapon pickups/world models, I will scale to 110 or 115% actual size (Default pickups are more like 140% scale). For architecture, camera FOV will have a lot to do with how the space is perceived.



The map is small. You can run from end to end in a few minutes.

I can agree with that. I use (using the 1 unit equals 1 inch) 42 inches (3'=6") for door clear width openings and 84 inches (7'-0") for door clear height.

Just a little interesting info... If you create an entity 100 feet long (1200 inches) and snap them in line end to end you will get 42 buildings from edge of terrain to edge of terrain for a overall terrain dimension of 4200 feet or 50,400 inches or close to that.

A lot of great info here guys. thanks for sharing. The whole unit subject should be added to an official pdf.

Here is a rough illustration of how the dimension of the terrain was calculated. Each red rectangle with a white line is 100 feet (or 1,200 inches)
Note that the last rectangle (on the right) is reported as entity 42 on the bar below the terrain.
42 x 1,200 = 50,400 inches or 4,200 feet. There is an area not covered by a red rectangle that equals an additional 400 inches.
50,400 inches plus additional 400 inches = 50,800 or a total width of terrain of 4,233 feet. (eight tenths of a mile)
The "x" counter shown on the information bar seems to have no direct relation to the measurement of the terrain in inches or feet or units. I could be wrong.
This method of calculating terrain size is rough but it seems to be mathematically close enough for military work.

Hi Jerry... I'm back! Devils really sucked this year, however just renewed my season ticket... hope springs eternal

Thanks so much for the input guys.

One unit = 1 inch (or 2.54 centimeters).

The thing that is a problem for scripters is that all of the movement commands require unit values. The only way I can get those values is by starting the test game and running a script I wrote that displays the XYZ unit values. It works, but it is a pain to go back and forth to get those values.

Edit 6/11

Just a clarification.
Using 12 units per foot (1 inch unit )or decimal 10 units per foot (1.2 inch unit) in the modeling software really only applies to real life dimensioning of models. There is really no direct relation to "x" / "Y" terrain coordinates in foot/inch units (there is sort of but cumbersome to translate for any use in a lua script). LUA script relies on the numbers from 0 to 499

The terrain coordinate system is based on a grid (0 to 499) vertical and horizontal that allows the user to read the x coordinate only at these locations on the task bar. Base on the fact that the terrain is about 4,254 feet in real life, the distance between 1 "x" coordinate to the adjacent visual "x" coordinate location is about 8.5 feet. If you have an entity located at horizontal "X" location zero then in a lua script you can move it to the right by continuing to incrementing the "x" coordinate by 1 after incrementing to x coordinate 499 (one at a time) the entity will have traveled all the way across the terrain.

Had a quick play with blender today looking at scale for doorways, I created three, the first was as suggested by M2 (80x42), the second was as I suggested (90x50), and a third in between (85x45), here is the result when measured against the masked soldier.



It looks to me that the scale in between M2's and mine would be the better choice visually, it may not be exact scale, but it just seems to look better to me, so I think I might start doing my doorways to this scale.

I have been reading the posts regarding the dimension issues:

m2design : "The yard stick (as I call it) was created with the same software I use for making models. "

GoDevils: "The thing that is a problem for scripters is that all of the movement commands require unit values. The only way I can get those values is by starting the test game and running a script I wrote that displays the XYZ unit values. It works, but it is a pain to go back and forth to get those values."

Is there any way this could be made easier in GG? I mean really, dimensions are super important as everyone seems to be unanimously pointing out and there is no easy way in GG to translate to real world values for models or distance in GG!? ...Except with all this scaling fiddling around. Sorry, not sounding good for an "easy" game making application.

There are two different things going on here. There are entity units and there are terrain coordinate units they are not the same animal. The entity units are base on real dimensions. Terrain location coordinates are based on a system lee has created (I think) as part of GG. (call it GG GPS) Using the terrain system and the "X" coordinate displayed in the task bar at the lower right corner of a map there are no coordinate locations larger than 499. In entity creation units the models need to be created using a standard scale so all entities are proportional (characters, houses, implements, etc. as an example)
In the terrain system all entities are located on terrain locations which are limited to map locations from 0 to 499. Thus confusion.

Not sure why, if one is creating an entity movement lua file, why any of this is a problem. There are lua commands that locate the subject entity x,y,z coordinates and commands to increment/decrement these coordinates to move the entity to any position in the GG world Limited to the given 0 to 499 positions. It is a little confusing when you are using the coordinates shown on the task bar when moving the mouse across the map terrain as they only display wide movement of the mouse . Example: say you have moved the mouse cursor to locate the x coordinate Zero on the task bar then move the cursor to the right until the next x coordinate is displayed, it will not be 1 as expected in will be in increments of 10, if you want x coordinate 5 you will have to guess with a mouse click somewhere between x coordinate 0 and coordinate ten. Wish the taskbar reflected the actual mouse movement in increments of 1... oh well

FWIW, this is how I size doors...



This is what I've settled with after considerable testing. The door is wide enough that the player can pass without snags (charactercapsulescale=100) and is narrow enough to be somewhat believable as an interior door. The height measurement is totally arbitrary. In my case, I sized it to match seam lines in my wall texture pattern. AI may hesitate before crossing the threshold but they are able to pass through without problem. You can create the illusion of a narrower door by having a thicker doorframe if collision is disabled when open.

@ m2design

Regarding XYZ location values

You are correct that LUA has many commands that return XYZ values. However, how do I get the XYZ value of a location that I am trying to move to?
I write scripts that move entities through a preset set of steps from one XYZ location to another. Thus far, the only way to find those :"move to" XYZ values is with a little script I wrote that displays the current XYZ location of the player during test play. I move the player to the place I want the entity to go in the next step, and use those values in my script. Just seems like it would be easier to display at least the X/Z position values in the editor, rather than transferring to test game play to get the numbers.

If anyone is interested, here is the script I referred to.

-- Script to display current X Y Z coordinates of the player/camera

local x1 = 0
local y1 = 0
local z1 = 0

function aabasicplayerxyzprompt_init(e)
end

function aabasicplayerxyzprompt_main(e)
x1=math.floor (g_PlayerPosX)
y1=math.floor (g_PlayerPosY)
z1=math.floor (g_PlayerPosZ)
Prompt("X= "..x1.." Y= "..y1.." Z= "..z1)
end