Warzone 2100 Forums

some notification about ini.

Bollean fields has different styles.
Normal is than used 1 and 0 In body.ini used: true/false
in weaporn: YES/NO

all same type fields should be done same way.

Some params are quoted:
weapons.ini Is it nessercary???

Some ini files made in bad way.
weponmodifier.ini is it should be like?

What about format of research stats?
i think all research data should be in one file

I agree. All boolean values should be 0/1 rather than text, and the weaponmodifier list should be reorganized.

Per wrote:I agree. All boolean values should be 0/1 rather than text, and the weaponmodifier list should be reorganized.

Thanks for fix.

terraintable.ini is strange too.

weapons.ini:

I read docks at http://developer.wz2100.net/wiki/TxtEditing It is outdated but I want to ask some things

numexplosions unused # it has 0,1,2 vals in ini

fireonmove YES = fire on move without accuracy penalties; NO = impossible to fire on move; PARTIAL = fire on move with accuracy penalties. # i dont find partial traces. is it present?

another sugestion is to create profiles for ini files.

It can be used for generation documentation. (I can write python script for this.)
For validating ini files in game
For validating ini files in editor

This is example for weapons.ini
https://gist.github.com/4253237

name - field name name
type - some description of val for editor.
max, min, choices, default - is used for validation
help_text description of field

It still needs to fix descriptions and add some max/min default vals

Is any integer default value is 0?

Love the ini profile idea - very useful! Would it be worth adding an extra property to each profile that states whether the value is mandatory or not? My understanding is that if a property is not defined, it defaults to the value of a property of the same name in the ZNULL section at the start of the ini.

Also, rather than using an array for the property profiles, would it not be easier to use an object with named references, where the name would be the property key and the value would be the profile associated with that property? You can then process an ini section and quickly look up the profile for each property via the named reference on the object.

I like the profile idea.

I removed the partial fire on move penalty option, since it was unused both in mp and campaign, and IMHO a very poor idea.

I will look into the other files with quoted lists as well, later (bodypropulsionimd.ini and terraintable.ini). I also consider renaming weaponmodifier.ini to propulsionmodifier.ini, and splitting out bodymodifier.ini from it. (Currently no body modifiers are in use, but this is supported and I think a good idea.)

If numExplosions is higher than 1, the projectile will scatter several explosion effects around the target on hit.

aubergine wrote:Would it be worth adding an extra property to each profile that states whether the value is mandatory or not?

something like blank=true or required=false.

My understanding is that if a property is not defined, it defaults to the value of a property of the same name in the ZNULL section at the start of the ini.

@per is it true?
Is ZNULL must be on start?
What to do with files with out znull?

Also, rather than using an array for the property profiles, would it not be easier to use an object with named references, where the name would be the property key and the value would be the profile associated with that property? You can then process an ini section and quickly look up the profile for each property via the named reference on the object.

If it needed I can change. PS I parse it from python and don`t have object benefits.

Duha wrote:

My understanding is that if a property is not defined, it defaults to the value of a property of the same name in the ZNULL section at the start of the ini.

@per is it true?
Is ZNULL must be on start?
What to do with files with out znull?

Some files need a ZNULL-something entry. It does not need to be at the start of the file (anymore), as the loading code will move it to the start anyway.

If a property is not defined, often it will get a decent default value, usually zero. But that is not always the case. Only way to know is to check the C++ code to see if that is the case or not. It does not read the ZNULL-entry's value.

Another thing for the profile might be to add min/max values (where applicable) to int values to help ensure the value doesn't go out of range in a stats editor.

What is the purpose of the ZNULL thing? I was never quite sure, and just assumed it was default values or something?

https://github.com/Warzone2100/warzone2 ... /brain.ini
designable = true

@Per; a bit of an ignorant post, but;

Are we talking about the format of the file produced by the editor, or are we talking about the editor itself?

Before my other laptop's premature death one of my many projects was to prototype a simple text-editor in Perl/Tk and when I saw this topic I thought to myself that it would be just as easy to prototype said editor.

Nameless wrote:Are we talking about the format of the file produced by the editor, or are we talking about the editor itself?

Not sure if I understand the question. The format of the stats files is turning into the INI file format. Above people are talking about defining another format for validating the contents of the INI files. Did that make it any more clear?

@Duha - thanks for noticing. Fixed.

.. and I forgot to mention that I was talking about your initial post... Ah well.

In any case, I *do* understand the direction that this thread taking haha

One more thing about .ini's: in body.ini we have a name field, but in weapons.ini we still rely on names.txt for that. Is it by design?

NoQ wrote:One more thing about .ini's: in body.ini we have a name field, but in weapons.ini we still rely on names.txt for that. Is it by design?

I'm trying to design it away from relying on names.txt, but we're not quite there yet.