DISCOVERY: File Formats, The Scripting Formats (UI, and LUA)

[Karybdis 34]

This thread is for the completion of the specs relating to the LUA formats. Of course LUA is actually a programming language so this creates a bit of a problem. Therefore the specifications will be for the 4 non-system (IE not straight LUA programming with no patterns) LUA filetypes. These 4 are : Attractors and Repellers, Advisor Scripts, Tutorial Scripts, and Definitions Scripts.

(OLD UI SPEC EDITED OUT FOR SPACE SAVING - UI SPECS AND RESEARCH CAN BE FOUND IN THE KNOWN FORMATS THREAD)

[Karybdis 34]

LUA's as mentioned before are divided into 4 subcategories so far. Each category covers a different non-system type of the script language. System types (IE files utilizing much of the LUA language) are simply covered by the LUA reference book in the mod area. (File #'s 15261,4150,17212,29202,29752 that I know of) and Misc LUAs include only simple lua commands like Dofile.

Advisor LUA's describe all advisor messages that appear in the game. Maxis was helpful enough to describe the specification for these types of files in detail. Presumably for other Maxis workers making files of their own. The Spec follows.

----

-----------------------------------------------------------------------------------------------
Conventions and other information on advisor scrips.
------------------------------------------------------------------------------------------------

-----------------------------------
-- Files ---------------------------

adv_.lua
Files holding advice messages for particular advisor or advice category.

adv_const.lua
File holding various game constants.

adv_game_data.lua
Files holding simulation variables and functions exposed to LUA.

-----------------------------------------------------
-- Naming conventions ---------------------------

1. All names but constants have to be lower case : 'game_events'.
2. Names of constants are upper case : 'game_events.NEW_CITY'

---------------------------------------------
-- Text tokens ---------------------------

Format for all text tokens is #token name#. Tokens are replaced by the game with appropriate strings. All predefined tokens have to be in lower case. Here is a list of predefined tokens you can use:

#city# -- City name.
#mayor# -- Mayor's name.
#population# -- The population count.
#year# -- Current year.

Aside from predefined tokens you can use tokens made of LUA code
#game.g_population# -- will be replaced with population count.
#game . g_police_funding_p# -- will be replaced police funding percentage.

For LUA tokens you might need to use one of the token type tags
m@ -- for money amounts.
d@ -- for dates.
t@ -- for time.
n@ -- for numbers (optional). This is also the default type tag.
s@ -- for strings (optional).

For instance # m@ game . g_budget# will be replaced with the value of total city budget variable. Type tags are needed for lacalization purposes.

Here is the list of predefined advice specific tokens

#advisor# -- The name of the advisor the message belongs to.
#link_id# -- Every advice link has to beging with token as its prefix (read more on Links).

The list of predefined neighbor deal specific tokens

#nd_city# -- The name of neighbor city.
#nd_cost# -- Deal cost (monthly)
#nd_amount# -- Deal amount (monthly)

The list of predefined reward building specific tokens

#building_initial_cost# -- The plop cost that the reward building.
#building_monthly_cost# -- Monthly cost that that reward building important for buisness deal buildings.

This list will be updated as new tokens being added.

---------------------------------------------
-- HTML links ---------------------------

The links are used by the advisor system for performing game specific actions. Usually the link will be edited in the HTML editor. After that, however you will have to go and update it to accomodate for appliation needs. Your final version of a link has to look something like this

Zoom MIDDLE

Here #link_id# is a token used by the applicaiton to associate the link with the advice message/advisor object the link belongs to. Of course, game.camera_... can be replaced with any valid game action. The 'Zoom MIDDLE' part is what will have to get localized. After edit advice message with an HTML editor your link may look like this

Zoom MIDDLE

don`t get alarmed as HTML requires certain characters to be replaced with their codes. The applicaiton will convert these codes back to their readable form. FYI, some of the codes you might see are as follows

%20 - space character ' '
%28 - '('
%29 - ')'

----------------------------------------------------
-- Localizable strings ---------------------------

Every string intended for localization has to be of the following format

text@hex_id

where hex_id is a GUID of the usual form of 8 hexadecial digits. Here are the exemples of valid strings

1. "text@12341234 -- This is general greeting message from the Utility advisor."
2. 'text@abcdabcd'
3. [[text@abcdabcd Blah, blah, blah ...]]
4. [[text@ABCDDCBAThe text following the string id is FYI only.]]

Only part is important for application. That hex_id has to be a valid string id from our string database. In case the application failes to load the string from the string database the string is used as is.

---------------------------------------------
-- LUA languge ---------------------------

-- Strings
The following are valid LUA strings

'hello' -- can't use (", new line, etc.) inside the string body
"hello"-- can't use (', new line, etc.) inside the string body
[[hello world]] -- can use anything inside the string body including new line characters (Enter key on your keyboard).

-- Variables
pop_in_thousands = game.g_population / 1000
pop_threshold_big_city = 100000
pop_threshold_metropolis = 3000000

One can create variables on a as needed bases. Make sure they don`t collide with anything else (add some prefix or suffix to them).

-- Functions
function get_pop_in_thousands ()
return game.g_population / 1000
end

The difference between variable 'pop_in_thousands'and the function above is that the function will always give current game population value in 1000s while the variable will give that number computed at the time when the script was executed, at game start up in this case. Just as with variables one can define new function on as needed bases.Make sure they don`t collide with any other names in our scripts.

-- Tables

Tables are bags of variables or/and functions They are a good way to group logically related things together to make sure there are no collisions with anything else in scripts and for organizational purposes. It is a good idea to put your tuning variables into a table, as well as some helper functions one may use in the scripts.

Here are some examples of tables.

1. t = {} -- empty table. Single character names is a bad style. Please descriptive names for everything.

2. tt = {x=1, y=2.5} -- you can acces x using t.x syntax. Same goes for 'y'

3. ttt = {} -- These two lines are equivalent to ttt = {z = 7, my_variable = 10000}
ttt.z = 7
ttt.my_variable = 10000

4. ttt.pop_in_thousands =
function ()
return game.g_population / 1000
end
You can call this function like this
ttt.pop_in_thousands().
Calling a function will result in a value returned by the function. One could make a token out of this value for instance like this %ttt.pop_in_thousands()%. At run time this token would be substituted with the number giving the population in thousands.

--
--
--

This is the Maxis conventions script. Of course it really says nothing for now Advisors work. Here's a sample advisor script with definitions

------------ Advice record ----
--Fire Protection Spread Thin
a = create_advice_safety("6a2437c4")

a.trigger = "game.g_fire_station_count > 1 and game.g_fire_coverage_p tuning_constants.POPULATION_STEP_3"
a.title = "text@4a3aba6eFire Protection Spread Thin"
a.message = [[text@ca3aba72 Mayor #mayor#, your hoses are a little short! You got are]]
a.priority = tuning_constants.ADVICE_PRIORITY_MED_HIGH
a.mood = advice_moods.BAD_JOB
a.timeout = tuning_constants.ADVICE_TIMEOUT_SHORT
a.frequency = tuning_constants.ADVICE_FREQUENCY_MEDIUM


the a= at the top defines the safect advice instance I believe.
a.trigger = the game triggers that cause the advice to be given
a.title = the title in simcitylocale with a string incase it cant be accessed
a.message = the message displayed text@id string used again
a.priority = the priority of the message as defined in the constants file
a.mood = the advisors mood visibly when he says the message
a.timeout = the message timeout for this advice
a.frequency = the amount of times this is shown in the ticker visibly

----

Using the bottom bit with the top definitions and ways of defining file calls, its pretty easy to get advice working as you can see. I still need help completing a proper specification for this of course.

Advisor scripts like any other can be preceeded by LUA calls and functions such as dofile() or function

********

The Next type of LUA's covered here are Attractors and Generators and Repellers. These are the things which determine when people group around areas based on an event. Maxis also supplied a definition of how to write these.

----

--
-- examples
--
-- This example shows how to create an example automata_group, attractor, generator, and occupant_group.
--
-- General script notes:
-- 1) Generally, you use a table { } to denote that a field has more than one value.
-- e.g. radius = 10, range = { 10, 20 },
-- Many fields give you the option of including a single value or a table of multiple values, so usually
-- radius = { 10 } and radius = 10 are interchangeable
--
-- 2) Remember to separate fields with commas. There's usually no harm in putting an extra comma
-- where it's not needed, but leaving the comma out will generate a script error.
--
-- 3) When you need to specify a hexadecimal number (0xABCDEF000), put quotes "" around it to treat it
-- like a string. Decimal numbers can be entered without quotes.
--
-- 4) If a field name is a number (for example, the 24-hour clock times in the time_of_day field), use square
-- brackets around the field name:
-- e.g. time_of_day = { [3] = 1.0, [12] = 0.5 }
--
-- 5) The file _templates.lua contains the specifications for every table in the scripts, with some notes.
--

dofile("_templates.lua")

-- set up common animations for all pedestrians
automata_group.pedestrian =
{
group_id = "0x8a1e1740", -- this should be a GUID defined in ingred.ini's "occupant groups" value map

anims = {
walk = 0,
wait = "0x0C",
woohoo = "0x07",
whoop = "0x0A",
hop_clap = "0x0B",
clap = "0x09",
booyah = "0x08",
panic_run = "0x0D",
tantrum = "0x06",
reject = "0x04",
phooee = "0x05",
noway = "0x03",
kissmy = "0x02",
booer = "0x01",
},

-- this is a class ID defined in C++. Most pedestrian groups won't need to override this.
class_id = "0x896e75af",
}

-- a subset of pedestrian automata, containing child models
automata_group.child =
{
-- this special field "_parent" points to another group that already exists. Everything
-- that applies to "pedestrian" also applies to "child".
_parent = automata_group.pedestrian,

group_id = "0x6a1e174d", -- this should be a GUID defined in ingred.ini's "occupant groups" value map

-- specify additional models to use when creating "child" automata. Usually, each model will have an
-- examplar that specifies which groups it belongs to. This list just allows you to associate new models
-- with a group without first creating an exemplar
models = {
sprite_model("0x0001000"),
sprite_model("0x0002000"),
sprite_model("0x0003000")
},
}


-- create an attractor that attracts and repels school kids
attractor.schoolkids_attractor =
{
-- attraction strength from -100 to 100 (negative values repel)
strength = { 80, 0 }, -- this example falls off to 0 at max radius
-- strength = 80, -- this example would be at constant strength 80 throughout the radius
-- strength = { -80, -80, -80, 20 }, -- and this example repels for 3/4 of the radius, then attracts at the outer edge

radius = 50, -- influence radius, in meters
automata = { "child" }, -- automata_groups this attractor affects
calendar = { monday, tuesday, wednesday, thursday, friday },
time_of_day = {
[7] = 0.0, -- start to ramp up at 7 AM...
[8] = 1.0, -- to max attraction strength at 8 AM
[8.5] = 0.3, -- then taper off
[9.0] = 0.0,
[14.9] = 0.0, -- suddenly...
[15.0] = -1.0, -- ...go home at 3PM (negative values repel)
[15.5] = 0.0
},

behavior = { -- behavior is always expressed as a table of tables, since there can be more than 1
{
radius = 15, -- when automata are within 10 meters...
state = BehaviorState.DISAPPEAR, -- they should disappear as if going into the building
},
{
radius = 30, -- when automata are within 30 meters...
state = BehaviorState.BEE_LINE, -- they should break from paths and head straight towards the building
},
},
}

-- create a generator that creates school kids
generator.schoolkids_generator =
{
automata = { "child" }, -- create children

occupancy_pct = 0.2, -- generate 20% of school's occupancy...
rate = 2, -- ...two times...
rate_scale = RateScale.PER_MINUTE, -- ...per game minute

-- generate at random distances between 10 and 50 meters away.
-- if this generator is linked to a time_of_day clock, then negative values will cause the
-- automata to be generated towards the inside of the range, and positive values will create
-- them towards the outside of the range (so that they will mimic an attached attractor)
radius = { 10, 50 },

-- copy times from schoolkids_attractor
calendar = { monday, tuesday, wednesday, thursday, friday },
time_of_day = {
[7] = 0.0, -- start to ramp up at 7 AM...
[8] = 1.0, -- to max attraction strength at 8 AM
[8.5] = 0.3, -- then taper off
[9.0] = 0.0,
[14.9] = 0.0, -- suddenly...
[15.0] = -1.0, -- ...go home at 3PM (negative values repel)
[15.5] = 0.0
},
}


-- Finally, create a "school" occupant group. Each occupant that belongs to this group will have
-- a "schoolkids_attractor" and "schoolkids_generator" attached to it.

occupant_group.school =
{
group_id = "0x8a1ddfb4", -- this should be a GUID defined in ingred.ini's "occupant groups" value map

-- alternatively, you could create an occupant group without giving it its own GUID or changing a property in
-- the exemplars. Since all school buildings have the "school coverage radius" property, you could uncomment the
-- following line.
-- Any time an occupant is created and it has that property, then it will be made a part of the "school" occupant
-- group and have a "schoolkids_attractor" and "schoolkids_generator" attached to it
--
-- property_check = { "0x691b42b3" }, -- "School Coverage Radius"

controllers = {
"schoolkids_attractor",
"schoolkids_generator"
},
}


-- verification
-- this function checks all tables against _templates.lua, for typos, required fields, and correct value types
-- It slows down parsing of the scripts, however -- include it when making quick changes but comment
-- it out when the scripts are stable
--~ verify_all_templates()

----

I don t think these scripts really require any description from me as they're pretty obvious You can check existing LUAs for samples if you need them.

****************

Definitions scripts are mainly just for constants. They're pretty simple and have some easy to understand formats.

----

these files begin with the usual dofile commands to load a file it needs. IE
dofile("adv_advisors.lua")

advisor_anim_types =
{
NEUTRAL = 0,
HAPPY = 1,
ATTENTION = 2,
ALARMED = 3,

NEUTRAL_TO_HAPPY = 4,
NEUTRAL_TO_ALARMED = 5,
NEUTRAL_TO_ATTENTION = 6,

HAPPY_TO_NEUTRAL = 7,
ALARMED_TO_NEUTRAL = 8,
ATTENTION_TO_NEUTRAL = 9
}
make_table_const (advisor_anim_types )

That's a simple definitions table. The things between the brackets may be on the top line only.

Functions may also be present which end with an end statement. Here's an example.

function sprite_model(instance_id)
return { GUIDSpriteType, GUIDSpriteGroup, instance_id }
end

(This function returns the TGI as said.)

--

hr = advisor_heads : new_record(advisor_ids.TRANSPORTATION, advisor_genders.M)

hr[advisor_anim_types.NEUTRAL] = hex2dec("2a42b530")
hr[advisor_anim_types.HAPPY] = hex2dec("2a42b532")

This is another type of definition block. It defines a main variable and what it represents followed by internal variables for that block only. What exactly the parts do I'm not sure

THis is another type of Block I'm not too sure of the workings of

advisors : new
({
id = advisor_ids.ENVIRONMENT,
advice_type = advice_types.ENVIRONMENT,
caption = "text@aa358803Environment Advisor",
name = "text@ca75f7f3",
}
, department_advisor
,1)

Another block type. As you can see it can be subdivided into sections which are ended by an end statement called local trends

game.trend_slope = function (trend_type, period_in_months) return 0 end --returns a trand value between from (-100, +100) for the period of time (see game_trends for trend types)
game.trend_value = function (trend_type, num_months_ago) return 0 end --returns a value the trend variable had 'num_months_ago'
game.trend_count = function (trend_type, period_in_months) return 0 end --returns a sample count for the period of time
game.trend_delta = function (trend_type, period_in_months) --returns a growith percentage
local past_value = game.trend_value(trend_type, period_in_months) + 0.00001 -- for avoiding the division pbolems
local present_value = game.trend_value(trend_type, 0)
local result = (present_value / past_value - 1) * 100
return result
end

A Tag definition, which is another type of definition LUA

TAG_ADVICE = newtag()
settag(base_advice, TAG_ADVICE)
settagmethod(tag(base_advice), "index", event_hierarchy_index)

This block type is identical to the first block type. The defs being outside the main brackets doesnt seem to make much difference

advice_types = {}
-- on C++ side this will correspond to advisor ID
advice_types.NULL = 0
advice_types.MYSIM = 1
advice_types.UTILITIES = 21
advice_types.HEALTH_EDUCATION = 22
advice_types.CITY_PLANNING = 23
advice_types.TRANSPORTATION = 24
advice_types.ENVIRONMENT = 25
advice_types.FINANCES = 26
advice_types.SAFETY = 27
advice_types.FLUFF_NEWS = 28

-- This table has to be extended at the end
make_table_const (advice_types)

GUID's and other types of definitions can be outside of brackets like this

GUIDExemplars = "0xa079ce1b"
GUIDCivicBuildings = "0x07bddf1c"
GUIDResidentialBuildings = "0x67bddf0c"
GUIDCommercialBuildings = "0x47bddf12"
GUIDIndustrialBuildings = "0xa7bddf17"

However it seems the file must have an end statement when this is true

This concludes the information on definitions types in LUA files used in Simcity4. If other types are noticed please post them here. Help complete the spec too of course since I dont really have one. Just block examples.

**************************

The Last type of LUA files found in simcity other than Misc simple LUAs and System (or general programming) LUAs are Tutorial scripts. There are three of these in the game as far as I can tell. 17051, 8517 and 5407. Here's as much of a spec as I can make.

----

The tutorial scripts actually begin with a series of definitions and functions in order to set the properties for how various things in the tutorials are determined. These only need to be defined once. The other two scripts simply call on these definitions in order to determine things

All tutorials are made based on Steps. a step is an independant thing that you do inside a tutorial. when you complete what is requested you move onto the next step. Tutorials consist of lots of these steps followed by an ending block. Here's an example step and ending block with descriptions where possible

----------------STEP 0-----------------------------

a = tutorial_create_task("0a39f624")
-- for now just move in to any available house
a.task_action = tutorial_do_nothing()
-- setting butttons eabled at this task.
tutorial_button_set(a
, tutorial_buttons.kPuckButtonMayor
, tutorial_buttons.kButtonZoomIn
, tutorial_buttons.kButtonZoomOut
, tutorial_buttons.kButtonSimFast
)

a.zoomLevel = 0;
set_camera(a,32,32)

a.instruction_msg = [[text@0x8a5ae72d



Welcome to the SimCity4 tutorial on how to become a popular Mayor,
presented by your very own assistant, xxxxx. That's me to your left.

The objective of this tutorial is to introduce you to the ways to increase your
popularity within your city. If you don't complete my guidance as expected, I'll
ask you to keep trying so that we can go on to the next step.

If all goes well, in about 30 minutes you will be ready to become a better Mayor.

Click here to continue.

]]

a.try_again_msg = [[text@ea4ad695 try again?]]
a.congratulation_msg = [[text@6a4ad76a Congratulation]]


the beginning a= is the main creation step for this.
a.task_action the action the tutorial does at this step
tutorial buttons are as mentioned the buttons on the interface that work for this step.
a.zoomlevel is the zoom
set_camera is the camera position
the instruction message is the message that is given to the user for what they are supposed to perform
the try again message is used if you fail the step
the congradulation message is for when you pass the step.

Here's an ending block.

tutorial_number_index[3] = tutorialtasks.n+1
print ("third tutorial script")
print (tutorial_number_index[3])
--dofile("tutorial_tasks2.lua")

--print(tutorialtasks[1].task_action)
print(tutorialtasks[1].target_buttons[1])
--print(tutorialtasks[3].target_buttons[1])
--print(tutorialtasks[5].target_buttons[1])
--print(tutorialtasks[4].task_action.target_guids)
--print (tutorial_number_index[1])
--print (tutorial_number_index[2])
--print (tutorial_number_index[3])

I'm afraid I don't really know what these blocks do other than signifying that the tutorial has been completed and that the variables can show this.

********************

That's it for the LUA specs and what I've figured out so far. The rest is up to everyone else to help me build the specifications for. Hope this has covered enough of the LUA base for the game considering that LUAs are as complex as C++ lol. Remarkebly good specs can be made it seems.

[DarkMatter 21]

Just a quick note, UI files are XML files, which makes them very easy to parse and display on a variety of ways. I also found the images that are used for the query info windows when you query a building, so I can make an editor/viewer for UI files eventually.

[Karybdis 34]

I have completed the (Sprite and Automata) and (Advices) Specs. I'll save the trouble of posting them here since they're long. They'll be in the mod area when I get the chance.

Will be working on Tutorials, Defining Blocks, and UI's tomorrow hopefully

[Karybdis 34]

Tutorials Spec Done

UI and Definitions remain (Definitions is about 40% done)

New LUA type (Advisor definition) introduced with the following Spec

----------------------------------------------------------

The New Advisor Definitions Script. Defines the Advisor Details. Spec follows

---- Starting Block

dofile("filename.lua") -- usual dofile includes before parsing

advisor_base_template = create_template -- Creates a base template which can have values declared in the advisors block for each advisor
({
class_id = 0,
id = 0,
advice_type = 0,
caption = "",
name = "",
})

advisors = {n = 0} -- Set current advisor num to 0 to begin file.

function advisors : new (init_table, base_table, flat) -- function definition
local t = advisor_base_template : new (init_table, base_table, flat)
local i = getn(self) +1
self = t -- add the table to the main advisors' repository
self . n = self . n + 1 -- update the table count
return t
end

---- Advisors Block (repeating)

mysim_advisor = advisors : new -- creates a new advisor type for use in other sections.
({
class_id = hex2dec('4a1dbbbf'), -- Class ID for this advisor type
id = advisor_ids.NULL, -- this one will be ingnored by the game
}, nil, nil) -- Unused since this is creating a type.

advisors : new
({
class_id = hex2dec('6a5f8755'), -- Class ID used ingame for the advisor
id = advisor_ids.HEALTH_EDUCATION, -- Type from definitions LUA
advice_type = advice_types.HEALTH_EDUCATION, -- Type from LUA
caption = "text@aa49638aHealth & Education Advisor", -- Text of Advisor title
name = "text@0a75f82b", -- Text of advisor Name
}
, department_advisor -- Advisor type as defined in above type section
,1) -- Flat value


----------------------------------------------

The flat value is all that needs to be figured out for this LUA type.

Hopefully Definitions will be done tomorrow.

[Karybdis 34]

Definitions Spec is complete

Remaining is the flat value for the Advisor LUA, and the revamped UI script with all UI values.

[redlotus 16]

I have got a couple of questions that have been driving me nuts for the past few days.

 

First, how do are the values for the variables that are used in the advisor scripts being determined?  Specifically, the game.g_ variables that are used a lot in the triggers for each of the advisor scripts.  I know that they have there intial value set to 0 in the definitions file, but how are they revised after that?

 

My second questions is:  Can an LUA script be written in such a way that the variables are saved to a property?  For example, in the constants file, most of the game_trends values are set to a game variable (property) like this:

game_trends.G_R_POPULATION = hex2dec(

'2A4E2003')

Is it possible to reverse this so that the variable can be used in the game (e.g. using the numbers for a graph)?  And maybe even do some math with the variables before they are assigned to a property?

I assume that this has not yet been tried, but for those of you with more experience in this kind of thing, I just wanted to know if it would be worth my time trying to do it.  If anyone has any information, I would be very greatfull.

Thanks

[Tropod 144]

----------------

On 9/19/2003 12:40:23 PM redlotus wrote:

 

My second questions is:  Can an LUA script be written in such a way that the variables are saved to a property?  For example, in the constants file, most of the game_trends values are set to a game variable (property) like this:

game_trends.G_R_POPULATION = hex2dec(

'2A4E2003'

)

Is it possible to reverse this so that the variable can be used in the game (e.g. using the numbers for a graph)?  And maybe even do some math with the variables before they are assigned to a property?

I assume that this has not yet been tried, but for those of you with more experience in this kind of thing, I just wanted to know if it would be worth my time trying to do it.  If anyone has any information, I would be very greatfull.

Thanks

----------------

 

I suggest you download the GraphModd from the Mods section, and take a look at it. If I understand what you're saying here; yes, it is in fact possible to use these (hex) values for the game. What the extent of this (use) is however, I am not entirely sure.

[redlotus 16]

I actually have already downloaded the mod.  I used it, and the thread where you described how you created the mod, to create a RCI totals mod that someone had requested.  So I am familiar with how to use the already listed hex values for graph mods.

 

The problem is that there are a few variables, most notably the game.g_ family of variables, that do not have hex values linked to them.  If I understand the constants LUA file correctly, the hex values are the ones created by the engine, probably in the executable where we can't see a list of them.  The constants LUA file then transfers the value associated with the hex address to a named variable that can be used by the advisor scripts (like I mentioned, usually for triggers).

 

So my two questions can be boiled down to this:  How are the named variables that aren't listed in the constants LUA file getting their values? and Can we assign a hex address to hold the value of one of the game.g_ values?

[Karybdis 34]

Those values should be classid's which are variables held inside the savegame and only defined with the exe

To answer the first question,

game = {}
TAG_GAME_DATA = newtag()
settag(game, TAG_GAME_DATA )

-- Defines all game. values coming from the game.

game.l_tract_hq_l = 0 -- cISC4ResidentialSimulator:: GetHQMinAndMaxTractCoords

This means l_tract_hq_1 is defined in the exe as cisc4residentialsimulator. cisc4residentialsimulator is a code line which preforms gethqminandmaxtractcoords function when executed and brings it back into the game as l_tract_hq_1. The hqminandmaxtractcoords are defined inside the savegame internally by the EXE so we never actually see what the true call value is.

To answer the second question, you probably can, however using this in game may produce ... well wierd consequences. You can try calling this as a token without defining it as a hex from within an advice area. Hex values are more for if you want to define something to be able to be used as a resource by a bar graph or data view

[redlotus 16]

Thank you.  I think I understand now.

 

I was kinda hoping that I was missing something and that we would be able to get a list of any other hex values and what they related to.  It would have made the process of sorting the save game file a lot easier.  I have found a lot of 4-byte groups that are very similar (eg the first byte is typically 2A, 6A, EA, etc.) to the hex values in the constants LUA file.  I suppose that would be just a little too much to ask for.

 

The second question was really just a follow up for the RCI totals mod that I had made.  The person I made it for actually wanted an unemployment graph that would show workforce vs # of jobs.  I just might try to do something like this in the future, but I do have a couple of questions.  I assume that the LUA files would be able to perform simple math.  Where would the best place be to place this math and then the assigning of a hex value to the result?  Do we know of any hex values that are not currently used in the game?  And, lastly, is it even possible to put a LUA script in a DAT file and have it replace a current LUA script that is in the 1.dat file?  Or should I just mod the 1.dat file directly?

 

Thanks for your time.

[Karybdis 34]

all files with the same instance will replace their predecessors including LUA I'm 90% sure

I would add a function to system.lua that performs the math.

I'd then make a g.function in the file that defines those that I put there that calls that function and uses other variables. Maybe you could just skip a step and go there.

then I'd assign a value to it in constants.lua.

Not guaranteed to work but its what I'd do if I wanted to.

[Karybdis 34]

K, LUA Advisor Spec finished

(OLD UI SPEC EDITED OUT FOR SPACE)

[DarkMatter 21]

Here is an updated spec with more detailed information and info on enumeration values.

 

SimCity 4 UI Definition Files
=============================

SimCity 4 defines all of its user interface elements, or UI elements, through a text-based file 
similar to XML. SimCity 4 UI's are composed of legacy tags, which contain attributes defining 
the type of element, its look and behavior, etc. Legacies can have children, which contain more 
legacy tags defining child elements. SC4 UI files are not valid XML, but are very similar. The 
differentes between UI files and XML are as follows:

1) In a UI file, a comment is denoted by a # at the beginning of a line. 
In XML, a comment is denoted by a tag, contstruted as so: 
2) In a UI file, legacy tags are not properly terminated. They have no closing tag or 
terminating bracket. UI LEGACY tags are simply closed by a >.
In XML, a tag must be terminated in one of the two following ways:

or

3) In a UI file, there is no root tag. There may be more than one LEGACY tag at the root level:

In XML, you can only have one root element. The above code is invalid in XML, but this code 
would work:

4) Attributes in a UI file are never bounded by quotes:

In XML, attributes must be bounded by quotes:

The differences between XML and UI files poses a bit of a challenge, as a custom parser must be 
written to handle UI code, or a preparation parser must be written to convert UI code into 
valid XML. Once an UI file is valid XML, any normal XML parser should be able to generate a DOM 
in memory out of the UI code.

UI Classes
-------------

SC4 UI files define user interface elements. This is done through attributes contained in 
LEGACY tags. The possible number of attributes is quite large, but not all attributes will 
always be used. First and foremost are the clsid, iid, and id attributes. These all define what 
kind of element a LEGACY tag is defining. Below is a list of known class id values for UI 
elements (this is the class id enumeration):

Class ID Description
--------------- -----------------------------------------------
GZWinGen 	Defines a UI window. This is a container control.
GZWinText 	Defines a simple text label.
GZWinTextEdit 	Defines a text edit box.
GZWinBtn 	Defines a push button.
GZWinBmp 	Defines a bitmap image.
GZWinCustom 	Defines a custom control.
GZWinGrid 	Defines a grid control.
GZWinFlatRect 	Defines a rectangle.
GZWinSlider 	Defines a slider control. (Like school capacity)
GZWinCombo 	Defines a combo selection control.
GZWinListBox 	Defines a listbox selection control.
GZWinTreeView 	Defines a treeview control.
GZWinSpinner 	Defines a spinner control. (Like tax adjusters)
GZWinOutline 	Defines an outline.
GZWinScrollbar 	Defines a scrollbar.

UI Attributes
-------------

Attribute 	Type  		Description
--------------- --------------- ----------------------------------------------
clsid  		hex or enum 	Defines the class of the control. Can be a hex
    				number or a class id e
iid  		enum  		Defines the interface id for the control. Will
    				always be one of the class id enumeration values
    				with an I appended to the beginning.
id  		hex  		An id number in hex.
area  		rectangle 	Defines the bounds of a rectangle that defines
    				the controls area. Format: (x,y,width,height)
fillcolor 	color  		Defines the default fill color of the control.
   				Format: (r,g,b)
forecolor	color  		Defines the foreground color of the control.
    				Format: (r,g,b)
backcolor 	color  		Defines the background color of the control.
    				Format: (r,g,b)
caption  	string  	Defines the text used for the controls caption.
captionres 	hex  		Defines the instance id of a localizable string
    				to be loaded from SimCityLocale.dat (or other 
    				location).
showcaption 	bool  		Specifies weather the caption is shown for the
    				control. Format: yes|no
wrapcaption 	bool  		Specifies weather the control caption is wrapped.
    				Format: yes|no
winflag_? 	bool  		Defines specific flags that affect the control.
    				Format: yes|no. See winflag section below.
font  		string  	Specifies the font to use for the control text.
autosize 	bool  		Specifies weather the control should be auto-
    				sized. Format: yes|no
sizable  	bool  		Specifies weather the control is sizable.
    				Format: yes|no
movable  	bool  		Specifies weather the control is movable.
    				Format: yes|no
tips  		bool  		Specifies weather the control has tooltips.
    				Format: yes|no
tipsdelay 	number  	Defines the popup timeout for the controls 
    				tooltip. Format: milliseconds
tipstimeout 	number  	Defines the dissapear timeout for the controls
    				tooltip. Format: milliseconds
tipsflag 	unknown  	unknown
tipsoffset 	unknown  	unknown
tipsres  	unknown  	unknown
tipstext 	string  	Defines the controls tooltip text.
opaque  	bool  		Specifies weather the control is opaque.
    				Format: yes|no
btnclicksnd 	hex  		Defines the group and instance id of the sound
    				to play when the control is clicked. Format:
    				{hex gid,hex iid}
image  		hex  		Defines the group and instane id of the image
    				to use for this control. Format: {hex gid,hex iid}
colorfont? 	color  		The colorfont? lines define colors used for
    				alternate font styles. Format: (r,g,b)
toggle 		bool  		Defines weather the control is toggleable. 
    				Format: on|off
triggerondown 	bool  		Defines weather the control executes when pressed.
    				Format: on|off
defaultkeys 	unknown  	unknown
closevisible 	unknown  	unknown
gobackvisible	unknown  	unknown
minmaxvisible 	unknown  	unknown
blttype  	enum  		Blitting type. Not sure of all possible values.
    				Format: tiled|streached|?
userdata 	unknown  	unknown
closedisabled 	bool  		unknown
gobackdisabled 	bool  		unknown
minmaxdisabled 	bool  		unknown
titlebar 	unknown  	unknown
outline  	unknown  	unknown
paint  		unknown  	unknown
sidebar  	unknown  	unknown
imagerect 	unknown  	unknown
notify  	unknown  	unknown
transparentbkg 	unknown  	unknown
edgeimage	unknown  	unknown
opaque  	unknown  	unknown
forecolor 	unknown  	unknown
allowinsert 	unknown  	unknown
allowundo 	unknown  	unknown
singleline 	unknown  	unknown
initvalue 	unknown  	unknown
highlightcolor 	color  		Defines color of control highlight. Format: (r,g,b)
outlinecolor 	color  		Defines color of control outline. Format: (r,g,b)
maxtext  	unknown  	unknown
overwrite 	unknown  	unknown
insertindex 	unknown  	unknown
insertpos 	unknown  	unknown
caretperiod 	unknown  	unknown
maxundo  	unknown  	unknown
notify  	unknown  	unknown
wrapped  	unknown  	unknown
textoffsets 	unknown  	unknown
editable 	unknown  	unknown
hscrollbar 	unknown  	unknown
vscrollbar 	unknown  	unknown
selrule  	unknown  	unknown
maxselcount 	unknown  	unknown
olinecolor 	color  		Defines an outline color. Format: (r,g,b)
dcolwidth 	number  	Defines a column width.
dcolheight 	number  	Defines a column height.
colhdrsz 	unknown  	unknown
rowhdrsz 	unknown  	unknown
fnone  		unknown  	unknown
fedit  		unknown  	unknown
fhscroll 	unknown  	unknown
fvscroll 	unknown  	unknown
fcolheading 	unknown  	unknown
frowheading 	unknown  	unknown
fcolgrid 	unknown  	unknown
frowgrid 	unknown  	unknown
finsmode 	unknown  	unknown
fopqbkgnd 	unknown  	unknown
fdoutline 	unknown  	unknown
fcellwrap 	unknown  	unknown
shiftcaption 	unknown  	unknown
fallownosel 	unknown  	unknown
ffixcolcnt 	unknown  	unknown
ffixrowcnt 	unknown  	unknown
fdpastlastcol 	unknown  	unknown
fdpastlastrow 	unknown  	unknown
fcelloverlap 	unknown  	unknown
fdrpdnmenu 	unknown  	unknown
fhlcelldata 	unknown  	unknown
fdefault 	unknown  	unknown
fall  		unknown  	unknown
colgridclr 	color  		Grid column color. Format: (r,g,b)
rowgridclr 	color  		Grid row color. Format: (r,g,b)
wingridcol 	color  		Grid window color. Format: (r,g,b)
btnupsnd 	hex  		Defines group and instance id of a sound
    				played when a button is released. 
    				Format: {hex gid, hex iid}
autonumber 	unknown  	unknown
autonumbercomma unknown  	unknown
autonumbercurrency unknown 	unknown
coloroutlineb 	color  		Defines an outline color. Format: (r,g,b)
coloroutliner 	color  		Defines an outline color. Format: (r,g,b)
digits  	unknown  	unknown
coloroutlinet 	color  		Defines an outline color. Format: (r,g,b)
coloroutlinel 	color  		Defines an outline color. Format: (r,g,b)
stepsize 	unknown  	unknown
colorright 	unknown  	unknown
colorbottom 	unknown  	unknown
colortop 	unknown  	unknown
colorleft 	unknown  	unknown
displayroot 	unknown  	unknown
displaynodeicons unknown 	unknown
displaytreelines unknown 	unknown
multiselect 	bool 		Specifies if multiple selections are allowed.
icongutter 	unknown  	unknown
rowheight 	number  	Defines a rows height.
roortext 	unknown  	unknown
rootcolorforeground unknown 	unknown
rootcolorbackground unknown 	unknown
rootforegrounghilited unknown 	unknown
rootbackgroundhilited unknown 	unknown
rootexpanded 	unknown  	unknown
rootselected 	unknown  	unknown
rootfont 	unknown  	unknown
direction 	unknown  	unknown
initselection 	unknown  	unknown
combodownarrowrect unknown 	unknown
combodowncolor 	unknown  	unknown
buttongutter 	unknown  	unknown
sunken  	unknown  	unknown
scrollbargutters unknown 	unknown
sort  		unknown  	unknown
drop  		unknown  	unknown
colordark 	unknown  	unknown
colorlight 	unknown  	unknown
node  		unknown  	unknown
comments 	unknown  	unknown
commentslmd 	unknown  	unknown
commentsrmd 	unknown  	unknown
commentslmu 	unknown  	unknown
commentsrmu	unknown  	unknown
commentsmm 	unknown  	unknown
commentsku 	unknown  	unknown
commentskd 	unknown  	unknown
direction 	unknown  	unknown
pagesize 	unknown  	unknown
direction 	unknown  	unknown
linesize 	unknown  	unknown
linepagecount 	unknown  	unknown
style  		unknown  	unknown
gutters  	unknown  	unknown

Window Flags
------------

Following are all the window flag attributes. These allways are bool values, with possible 
values of yes or no. They are mostly self explanitory, and augment the behaviour of a control.

winflag_visible
winflag_enabled
winflag_movable
winflag_sizable
winflag_sortable
winflag_acceptfocus
winflag_ignoremouse
winflag_pbuff
winflag_pbufftrans
winflag_pbuggerase
winflag_pbuffvid
windlag_mousetrans

Alternate Font Attributes
-------------------------

Following are all the possible alternate font color attributes. These are always color values.

colorfontnormal
colorfontdisabled
colorfonthilited
colorfontnormalbkg
colorfontdisabledbkg
colorfonthilitedbkg

Known Enumerations
------------------

Some attributes have values that can be taken from an enumeration. An enumeration is a list of 
nonstandard values (i.e. standard values are string, number, hex)

Align Enumeration
-----------------
left
leftcenter
center
rightcenter
right

Blit Type Enumeration
---------------------
tiled
normal
edge
(other possible values?)

Style Enumeration
-----------------
standard
nofill
left
right
top
bottom

Possible Bool Values
--------------------
yes
no
on
off

Final Words
-----------

This spec is still incomplete in a few ways. Many attributes are unknown in status, and not all 
possible values for the known enumerations are known. Its possible there are other enumerations 
that we do not yet know about. Any help in completing this spec is greatly appreciated.

[ilive 36]

thanks for all these values, DM

 

about Blit Type Enumeration, other values I found are :

normal

edge

 

[Karybdis 34]

Man I wish this thread would suddenly cut to a new page

Anyways, I've added a bunch more definitions to DM's new specification (great by the way)

And I've put it into a handy new Wordpad file that you can add to and look at. In the wordpad file, everything we know how to use properly is in Bolded Blue. Everything we dont know yet or dont know how to use properly is in bolded red.

Easy tracking of stuff that needs to be done. Hope it helps

[Karybdis 34]

This is a complete copy of the new LUA mission spec that's built off of buggi's original spec. This one includes all the rest of the options for building missions, all of the functions and a full overview of the Trigger option which starts off missions being available.

[RalphaelNinja 244]

I am reposting my post from Daeley's Custom Query Stuff in the BSC tea room in hopes that some of us Modders can find an answer.

 

-------------------------- 

I've spent a few days working on obtaining unique LUA script ID's for Daeley's LUA script and have come up with a semi blank.

 

I'll enlist anyone else here that wishes to continue this as Daeley is using and replacing an existing LUA script ID (which can cause problems in the future when Daeley upgrades or add new scripts).

 

The LUA script command dofile(...) doesn't seem to allow us to create and execute new files (whether they are self contained or external).

 

However there is hope as apparently the new Landmarks from Maxis have new self-contained LUA's which seems to get registered throught the commands of : (from Plugin_002_TheLivingMall.dat)

 

 

--#-package:00005000# -- package signature

--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--~~  Advice and advisors package
--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dofile(plugin_002_adv_const.lua)
dofile(plugin_002_adv_fluffnews.lua)

 

which registers the following ID to be recognized as a valid LUA script:

CA63E2A3     4A5E8EF6     FF2511A6 

 

Within my test, the living mall dat file has been reduced to that one LUA file.

 

---------------------------------------------

 

After thinking about this a bit, I think those dofile() translates into IDs using an algorithm. I changed the dofile(plugin_002...) to dofile(plugin_003...) and the LUA at FF2511A6 no longer works. The original filename of Plugin_002_TheLivingMall.dat has been renamed to george.dat and the entry point for the above LUA dofile command is at CA63E2A3     4A5E8EF6     FF3D761E.

 

Ralphael

[RalphaelNinja 244]

Each DAT file can contain its' own LUA (any instance number) and will autoexecute based on the top of the LUA containing the following:

 

--#-package:BD008913# -- package signature

 

The package number must be unique also, of which you can use the generated Instance. However if you have two dat with LUA's with the same package number, one will not work (depending on the load ordere).

 

I haven't been able to translate the instance ID for the dofile().

 

Edit: if the LUA doesn't execute, try changing the first character of the Package ID to 0. It seems that my generated id of :A3506332 is not valid. However :03506332 is valid. go figure...

 

Ralphael

[Tropod 144]

Ok; so with this new LUA discovery then; anyone think there's any chance in hell that it's possible to create a new menu-ing structure via a LUA? Whether it be by invoking a function or whatever?

[builderman 3]

Doubt it but you could check into it Tropod.

[Daeley 46]

here's a little site for the LUA dabblers: www.lua.org

 

and more specifically: http://www.lua.org/pil/  -- a complete description of how LUA works

 

note that LUA can also read/write files, so we could use it to create our own custum savegames awww my poor brain can't handle the output of possibilities

[Karybdis 34]

Just a note to thread readers since this thread was revived. The UI Specs present in this thread are quite outdated, and the newer ones can be found in its thread. File Formats, Known Formats.

[builderman 3]

OK, with all of our forays into LUAs and UI files, is it possible to link a UI button to a LUA script? There are a few interesting applications for this.

The first one that comes to mind, quite trivial, Random Landmark!

[Daeley 46]

actually, I've already done a lot of work on trying to figure out how UI buttons work (long before there was so much knowledge on LUA's) and it's not very encouraging... there just seem to be too many missing links in our knowledge about how the IGZWinButton function really work.

[Tropod 144]

EDIT: Post didn't come out quite right.

Ralphael's method/post (above) seems to only be good for certain types of LUAs.
After playing around with an LUA for awhile, I've managed to come up with the following (this is a functional example - other (Exemplar etc) files are needed in conjuction with this though, to link up with, but the LUA itself is functional. This is just part of something I've done up for EI Rail UDI);
----------------------------------------------------

--#-package:01234567# -- package signature

if not rawget(globals(), _unique_name_here) then
_unique_name_here = 1

 

-- other coding & functions in here, for example,

automata_group.el_train_engine =TTT
{
_parent = automata_group.train,
group_id = 0x422c,
class_id = 0x4c22ae53, -- cSC4MassTransitTrain
source_building = 0x1303,
csi_image = 0x0c0305c6,
}
--end include check

end

----------------------------------------------------
The LUA file also needs to contain unique TGI ID as well.

 

Using this, I've found it is possible to modify things that are normally contained in files like vehicle.lua, without actually touching the vehicles.lua file itself. How this works in conjunction with other LUAs, & the whole scope of things in general; what other items, functions are possible; and whether conflicts are possible still, &/or how the game might load certain items; I'm not entirely sure yet. But it does look rather promising (I've not come across any problems, yet). So hopefully, there'll be no more need to use certain system LUAs.

[Daeley 46]

I don't know how the LUA's get executed, but it's my best guess they get executed following ascending package numbers. You could look at it as one big program where you paste all the LUA's with package numbers together and replace the dofile(file.lua) functions with the code from file.lua... So basically, from my experience this means once a file is loaded through dofile, you can access and edit all of it's variables. I have already done something like this for the light rail project and swamper77 to create custom automata attractors.

 

I don't think this should lead into any conflicts with the system variables as long as nothing is done to delete certain of them or empty certain variable tables... This also means conflicts can arise between custom LUA using the same (e.a generic) variable names. For example, when using a building counter variable just naming it counter is asking for trouble... building_xyz_counter works much better

[glundberg 0]

I have done a bit of research into how to get a LUA script to execute. There are exactly three requirements:

1) The first line of the script must be a package ID, which must be a valid hexadecimal value.

I did not test to see how large this value may be, but I did test to ensure that several values between 00000000 and FFFFFFFF (inclusive) would work (all did), and that non-hex values did not work (none did).

I also did not test to determine if there is a specific order of initialization for the scripts, or if duplicate package ID numbers had any effect. This seemed moot to me since it's rather simple to ensure scripts do not care about order of initialization or multiple-initializations of the same script.

2) For obvious reasons, the dataset TYPE MUST be LUA (CA63E2A3).

3) The dataset GROUP must be EITHER 4A5E8F3F (which appears to be LUA scripts mainly related to automata) or 4A5E8EF6 (which appears to be LUA scripts mainly related to advisors).

Note that the group for the LUA script in the Living Mall plugin is one of these values.

I tested +/- 1 from each of the above group values and neither caused my test script to load.

As to the dofile stuff .. it appears that's only needed by the Maxis-supplied LUA scripts. Note there is a script with a package ID which does a dofile() for everything else. Maxis does some fiddling with the dofile() function to cause it to know that the filename specified refers to a TGI dataset.

We, however, do not have that luxury, so we MUST have a package ID at the top of every script dataset.

Since the dataset group numbers must match those of Maxis' LUA scripts, care must be taken to ensure that the instance numbers do not collide unless the intention actually is to replace the Maxis-supplied script.

[Karybdis 34]

<P>Actually the latest version of datgen should have a hash tool implemented which will allow you to make the proper instances for your LUAs.....with the proper instance, you can do Dofile commands just like maxis does, as maxis hashes the dofile name and gets the IID of the proper file that way </P>

[GoaSkin 2]

I found out the following automata-related variables must exist with a little bit reverse-engineering. I have not found out the variable type yet:



track_buildings
automata
create_automaton
create_controller
attach_controller
attach_controller_group
detach_controller
detach_controller_group
get_source_building_count
playerdrive
csi_image
source_building
key_effects
group_if
percentage
controllers
models
anims
_parent
class_id
radius
strength
max_count
time_of_day
calendar
effect_trigger
deactivate_trigger
lifetime
delay
use_lot_facing
use_lot_center
ignore_lot
transient
ground_only
destroy_automata
follow_roads
follow_rail
persist_offscreen
behavior
state
sfx
priority
timeout
final
ignore_paths
ignore_roads
ignore_terrain
ignore_attractors
avoid_lots
avoid_roads
kph_multiply
acceleration
path_offset
random_walk
turn
idle_delay
idle_time
deceleration
ignore_states
exclusive_radius
population_pct
occupancy_pct
count
rate
rate_scale
event
random_change
lifetime_count
group_count
Minzoom
StartingZoom
MaxSpeed
MinSpeed
AccelPerSecond
DecelPerSecond
DecaySpeedPerSec
MaxTurnAngle
TurnPerSec
RestoreTurnPerSec
TurnAngleThreshhold
GripPercentage
GuardrailDotTolerance
GuardrailDistance
GuardrailPercentage
OffRoadSpeedModifier
RelativeDensity
TrainDerailmentThrottleDuration
TrainFullThrottlePitchMax
MaxTapDuration
TankTurnInPlace
HitPoints
AccelRate
BankRate
ClimbRate
DiveRate
RudderRate
ReturnToCenterFactor
MinThrottle
FlapRateClimb
FlapRateDive
LandingThrottle
LandingElevator
TrimRate
MaxTrim
OffRoadTurnAngleRange
Mass
WingArea
TakeOffSpeed
ElevatorMax
ElevatorChangeRate
AileronMax
AileronChangeRate
RudderMax
RudderChangeRate
ThrottleMax
ThrottleChangeRate
FlapsMax
FlapsChangeRate
StallAngle
LiftFactorLevelFlight
LiftFactorMaxClimb
LiftFactorFullStall
Power
SpeedMultiplier
DragFactor
RotationalDragFactor
BankMax
BankChangeRate
PitchMax
PitchChangeRate
YawRateMax
BankMultiplier
PitchMultiplier
TurnsPerSecond
RestoreTurnsPerSecond
DecaySpeedPerSecond
SpeedModifier
SwitchTurnDirectionsModifier
MinTurn
MaxTurn
MaxSpeedChangePerMillisecond
BaseForwardTurnRadius
BaseBackwardTurnRadius
AIMaxSpeedChangePerMillisecond
AIMaxTurnChangePerMillisecond
AIChrashSpeedAnimateCollisionThreshold
AICrashSpeedInanimateCollisionTreshold
ForwardMotionPitchModifier
ForwardMotionPitchMaxAngle
SideMotionPitchModifier
SideMotionPitchMaxAngle
CrashSequenceMillisecondMax
CrashPitchTotal
CrashRunAgroundSpeedReductionModifier
CrashRunAGroundRollTotal
CrashClimbableTerrainAngleThreshold
CrashMaxAltitudeIncrease
CrashSpeedAnimateCollisionThreshold
CrashSpeedInanimateCollisionThreshold
CrashAnimateCollisionSpeedScalingFactor
MinAcceleration
MaxAcceleration
ReverseInertialTime
ForwardInertialTime
TurnInPlacePerSec
MaxMillisecondDelta
FerryQueueDistance
FerryDockDistance
FerryMaxDockingOrientationChangePerMillisecond
FerryMaxDockingPositionChangePerMillisecond
one_shot
hard_transition
controller
hold
bone
override