Jump to content
chernaruski

Game defined base classes

Recommended Posts

How important is it to config using external base classes (base classes that were defined by the base game) ?

i.e
is it wrong/not recommended to use "house" on simple non-interactable custom objects, instead of using lets say "static" or "nonstrategic"?
I'm not sure what is the whole purpose of pre-defined by the game base class names.

Share this post


Link to post
Share on other sites

There was a misinterpretation of the No-crossposting rule. As one of the senior community moderators, I take responsibility for that, it should have been communicated better. 

However, Discord is not
 

Quote

just a chat where you can hope for a quick answer by someone and if you don't you go look for alternative sources of information (such as forums) instead of looking through tons and tons of irrelevant messages. Its an open room where messages "spammed" about anything, while at forums specific person can talk about a specific problem/question. 


It is operated by many of the same moderators here on the forum and we share the same rule set. 

With that in mind, if you would like to ask as a detailed question which may be of use to future users, then the forum is always the place to post it. 

Carry on. 

  • Like 1

Share this post


Link to post
Share on other sites

Off-topic: Never said you violated any rules. I just didn't like that you posted in two places, and then abandoned one of them without relaying the answers you've gotten.

 

So to not let the information from Arma discord be abanonded here it is:

 

Quote

~Dedmen

In scripts people can use script commands to find all objects of a certain type

if they search for "House" they'll get everything that inherits from "House" and they probably expect to only get houses, not props or cars.

 

On 4/12/2019 at 5:57 AM, chernaruski said:

I'm not sure what is the whole purpose of pre-defined by the game base class names. 

 

Quote

~Dedmen

All inheritance does is inherit config entries from the classes you inherit

you can also create vehicles with zero inheritance by just copying every single entry that you would otherwise inherit

The main difference of the base classes are usually simulation types. ThingX has physx, Thing doesn't. Houses are static and aren't supposed to move, while cars can drive

 

Quote

~Mondkalb

"you can also create vehicles with zero inheritance"

In theory, but not in reality: However some hardcoded stuff still exists that requires your vehicle to absolutely positively having to inherit from one of the baseclasses, as they are linked in the engine (Car, Tank, Man, House, etc)

I.e a house not inheriting from class house at some point does not work fully.

Very very similar how the engine knows about magic HeliH and it acting as a helicopter magnet without any other extra configuration parameters.

 

On 4/12/2019 at 5:57 AM, chernaruski said:

is it wrong/not recommended to use "house" on simple non-interactable custom objects, instead of using lets say "static" or "nonstrategic"?

No. There is barely any difference. You can use a config browser to look at the differences between classes
For example: http://tikka.ws/class/index.php?b=cfgVehicles&c=House&conf=1

and http://tikka.ws/class/index.php?b=cfgVehicles&c=Static&conf=1

You can see that both House and Static are basically the same thing. Same simulation type, and the only config differences are either empty placeholders, or things that you don't care about anyway if you just want a static object.

 

Main difference is just what I wrote in my first answer to you. Categorization. A garbage pile object is not a House, so it shouldn't inherit from House.

  • Like 1

Share this post


Link to post
Share on other sites

Offtopic: Let us move to on-topic then , I see no point on dwelling on this misunderstanding.

Let me be more specific on my questions , just to make sure we understand each other:

 Does using base class House/Structure on tree/clutter model , which is suppose to be Static , makes a difference or its pure categorization and it have no impact whatsoever on lets say... performance ?
At the moment I'm only interested in props related things, no physx involved.

On one hand you say:

Quote

The main difference of the base classes are usually simulation types. 

From the other 
 

Quote

Main difference is just what I wrote in my first answer to you. Categorization. 


I guess I should ask what are the "simulation types" or what you mean by "simulation types" ? 
Try to understand , there is a list of over 200 items base classes and it may confuse at the beginning , like it was with Flag_F and the moving canvas model I tried to do not awhile ago. So I assumed there is more in depth meaning for each base class.

Share this post


Link to post
Share on other sites
1 hour ago, chernaruski said:

 Does using base class House/Structure on tree/clutter model , which is suppose to be Static , makes a difference or its pure categorization and it have no impact whatsoever on lets say... performance ?

Yes.

 

1 hour ago, chernaruski said:

On one hand you say:

House and Static both have simulation type of "House". Thus they are the same. Thus simulation type is not a difference between them.

 

1 hour ago, chernaruski said:

I guess I should ask what are the "simulation types" or what you mean by "simulation types" ? 

"simulation" config entry. I linked a config viewer above. You can see their simulation entry.

They are not well documented, or not documented at all.

https://community.bistudio.com/wiki/CfgVehicles_Config_Reference#simulation

They define what internal engine code runs to "simulate" the object.

For example a "flag" regularly updates it's animation to show the flag swaying in the wind, which a house or car obviously don't do.

Also a "car" simulation takes into account the current speed of the car, and moves the car's position forward on regular intervals, which a house obviously doesn't do.

 

Performance wise some simulation types are more expensive than others. A house just stands there and does basically nothing. Whereas a thingX for example is a physx simulated object that must react to impacts and then react physics'y.

Here is a graph of some simulation types and their performance cost https://community.bistudio.com/wiki/Arma_3_Simple_Objects#Performance

 

In the wiki page there is also "fire" simulation type. That regularly checks if a unit is currently standing in the fire, and applies fire damage to it, and also makes fire sounds and effects.

 

Simulation types can also hold some other properties. For example you can "Get In" a Car/Tank/Helicopter. But not into a Fire/House.

 

I think "house" is the simplest simulation type. Along with "housesimulated" and "inventaryitem" (heh. typo) which are all the same thing.

There is also "church" which is the same as house, with the only difference being that the bell rings regularly.

Then you have "Fountain" which plays a water sound.

Or "door" which simulates opening gradually.

or "animal" which has very basic AI and walks around

or "vasi" for VASI lights (google it)

Or Triggers (the one you place in editor) they also are vehicles with a specific simulation type, that just executes the trigger condition code every 0.5 seconds.

 

"House" doesn't do nothing, it for example simulates lights that move along with it. Or it regularly checks if it's "out of view" to do even less simulation.
I don't think there is a simulation type which really doesn't do anything at all. If you want no simulation you have to create a simple object

 

There is "headlessclient" simulation type.. Maybe that's cheaper than house. But I think it doesn't have a renderable model.

 

 

There are dozens of simulation types and barely any documentation about it. If you do some serious modding you just learn what they do by asking the people who know. But if you are just making some static objects or props, you don't need to care about all this.

 

 

1 hour ago, chernaruski said:

Try to understand , there is a list of over 200 items base classes and it may confuse at the beginning

Most of them are just there to make writing configs easier.
If you are making houses with 4 doors, you can make a 4DoorHouse baseclass and inherit that, instead of copy-pasting the "doors=4" into every single one of your houses, that's the main purpose of them.

Removing the need to constantly copy-paste the ever same values into all of your classes. And if you inherit correctly you also cannot forget required entries.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×