mishmash in the json data

[mdziczkowski]

I would suggest to clean-up the json because the "track items" are mixed up too much and it makes unable to create propper structures for it

[pedromorgan]

@mcgiwer Can u explain what the mish mash is ?

[npiganeau]

@mcgiwer Can you give examples? The files are read all right by the ts2 software, so I don't really understand what you mean either.

[pedromorgan]

To update @npiganeau , @mcgiwer is making some of the data structures in go, and the serialise technique from to_json() is py is not really readable in some cases in golang...

[pedromorgan]

eg tuples and arrays in "pure json" would be structures, instead of baing "embedded together" in a single string etc

[npiganeau]

You mean for routesSetParams for example ?

Well that's for historical reasons, they were treated as strings because they were stored in one column of the sqlite database. I'll see what I can do to make them pure json, should not be too complicated.

[pedromorgan]

its probably in the to_json() function,, should be called get_data() or something like that

Please NOTE that I am in favour of mixedNaming,

• so a setFoo() is expected to be a pyqt thingy
• but set_foo() would be a py thingy...

[npiganeau]

I've made the modification + updated ts2-data. It was just that I called the Str property instead of the property itself in for_json()

[pedromorgan]

Re ts2-data..

Can we make the countires small case eg uk instead of Uk, germany ??

[npiganeau]

Folder names are read 'as is' inside the "open" dialog of ts2, so having them lower case would not be very pretty, unless you find a way to show another name inside the software such as a __folder__ file with the full pretty name of the country (maybe with different translations defined inside the file could be cool too)

[mdziczkowski]

example:

many "types" are mixed with each other in the TrackItems. Even if they have seperate ID's it isn't sorted and grouped by the item type

[npiganeau]

That's because they are all of the same type of objects, that's why they have a unique ID. They have many interaction as being "trackItems" in the code (independently of their precise type), so you just can't separate them as if they were completely different.

You must think of the different trackItems types as being different set of properties of the same type.

In the python implementation, this is done by having a base class "TrackItem" and inherited classes for each, but that's an implementation dependant choice. If I had to do it in golang, I would probably have a common struct for all of them, a common "TrackItem" interface and a specific interface derived from "TrackItem" for each trackItem type.

[mdziczkowski]

@npiganeau they aren't exactly the same type. Coresponding from the __type__, there are differences in other fields and then from definied variables

[npiganeau]

@mcgiwer don't take it the wrong way round:

These json files are the dump of the theoretical "ts2 data model" that I have invented for ts2. This model is optimised for running the game, not for loading or saving the file : the goal is to have optimised game running, not to have an easy file loading. This model is implementation independent.

As I said, it has been implemented in python as inherited classes, but you should implement it as a single large struct on languages that do not support inheritance to be able to code items interactions (pointers between items for instance: nextItem and previousItem). All variables will not be used by all instances, but that's not an issue, is it?

[npiganeau]

BTW, when the files were saved to sqlite, all track items were stored in the same table.

[mdziczkowski]

@npiganeau what do you think about to split the ts2-data files into half? the SQLite ones would be for Python version and JSON would be for GO? this way it won't be coliding in case of need changing the file structure in ts2-python