Common format for configuration files

[Tow_dragon]

That wouldn’t make any sense. How compiler would know, whether to destruct object bound to c-ref? How would we prevent from destructing it multiple times (we can make several c-refs bound indirectly to the temporary). That’d effectively require using some kind of GC.

The memory model of C++ doesn’t make much sense. It’s both overcomplicated and too limiting. But it’s getting off the topic.

[Ivan]

And I still see and issue with that:

- value = &creature"upgrade"]; 
 - if (!value->isNull()) 
 - c->upgrades.insert(value->Float()); 
 + c->upgrades.insert(creature"upgrade"].Float());

Before we don’t insert anything. After we insert junk.

My fault. Missed that vector insertion. It may be better to replace “upgrade” field in JSON with array - to allow such stuff like multiple upgrades in the future.

For example, we could add at the beginning of each config file a machine-readable format specification (something like DTD)

I thought about this too. Probably will work on this in September.

When g"additionalDefs"] is null, the Vector() function returns const ref to its default argument — a temporary empty vector constructed just before the call. That temporary is destructed shortly after and defs_vec becomes a dangling reference! Any attempt to use it (like foreach) is illegal.

That worked fine for me. I’ll make default values “static” for now and replace them with references to value from DTD later.

You forgot about conversion operators. Node class can have operator int() and operator string() and they’ll be pretty different functions.

Forgot about that. I’ll remove Float()\String()\etc then.

[ubuntux]

I’m trying to merge cregens.txt into creatures.json. The problem is that they are parsed by different objects (CObjectHandler vs CCreatureHandler). Is it possible to move the vector cregens from the first object into the second ? It seems easy to do, but I don’t understand the implications.

Also CObjectHandler is parsing files that are widely different. Is it used as a catch-all ?

[Tow]

These handler classes in lib are all just engine-wide visible containers for game mechanics info. It’s possible to move data (like cregens) vector from one to another without any mechanical implications.

I’d however argue, if cregen actually belongs to creature info. It is rather a property of an adventure map object, that it spawns a certain type of creature; not necessarily the other way around. Each creature generator has defined its spawned creature type but not all creature types have their spawning spots. It may be more clear, if we keep cregen data in a separate file.

---

By the way, please try to stick to out brace convention (that is giving each brace its own line). At least for the sake of style consistency.

[ubuntux]

cregen is used to convert dwelling into creature and vice versa. So it could belong to both.
I could add a dwelling property to each creatures, and add a dwelling vector to CCreatureHandler. Then populate cregen in CObjectHandler with the information from CCreatureHandler. Woudl that be ok ?

And sorry for the braces. It’s a style I’m not fond of. I’ll try to be more careful.

[Tow]

cregen is used to convert dwelling into creature and vice versa. So it could belong to both.

As I said, I somehow feel object handler to be a more natural place for cregen info (you can have creature without cregen, you can’t have cregen without creature), however I don’t particularly insist on keeping things as they are. Place the data where you want.

I could add a dwelling property to each creatures, and add a dwelling vector to CCreatureHandler. Then populate cregen in CObjectHandler with the information from CCreatureHandler. Woudl that be ok ?

I advocate against duplicating the information. May it be in cre or obj handler but let it be kept in one place. Duplication can bring only trouble.

[ubuntux]

OK. I will make a separate config file.

---

I introduced a bug in rev 2339 that shows on some maps. For instance in Arrogance3 most of the castles are gone. The change is rather simple but I can’t find the issue. I believe there’s some c++ wizardry involved

May be

ifs >> const_cast<CGDefInfo*>(n)->name;

is not equivalent to

const_cast<CGDefInfo*>(n)->name = t"village"].String();

Could you take a look ?

[Tow]

I already corrected that issue in r2356. I was also surprised and related that to your recent changes… but the fix is apparently unrelated. Frankly speaking I don’t know how that could’ve been working before.

[ubuntux]

Frankly speaking I don’t know how that could’ve been working before.

That’s scary

I went back and forth between r2338 and 2339. Former always worked and later was always broken. Acessing these CGDefInfo objects seem to have a side effect. operator overload ?

[ubuntux]

I’m done converting the various text files into json. I’ve left the following files:
fonts.txt --> nothing there is used anymore
settings.txt --> special file, should be use editable properly one day
threatlevel.txt --> belong to an i18n file; the format may not be json

[ori.bar]

I went back and forth between r2338 and 2339. Former always worked and later was always broken. Acessing these CGDefInfo objects seem to have a side effect. operator overload ?

See my change to CGameState.cpp in r2364. Some function tried to access a non existing file (a .txt file that was already json’d).

[ubuntux]

Indeed. So we have 2 functions that do the same thing but in different order: initVillagesCapitols and loadTownDInfos.