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

[npiganeau]

TS2 file format is JSON.

If you want to make a new implementation of ts2 in go, then

• either it comes into the roadmap of the next arch defined here, then it must implement the ts2 data model and thus it must read ts2 JSON files as they are now
• or it is a fork of ts2 (which you are free to do, of course) and in this case you choose whatever file format you want, but don't expect it to be compatible with ts2 nor to see ts2 follow your file format changes.

[mdziczkowski]

@npiganeau it will be compatible with it, but the order of the entries in TrainItems will be changed to make it more sorted and grouped by __type__

And second thing... I would propose you to make it modular to make the future development easier. I am participating in many train related projects and one of it (written in Deplhi and currently beeing converted to other language) has become so large (over 250,000 lines of code) that it was very difficult to progress with the works. That why the developers have listened to my advise and splited it into blocks (modules) and it helped much

[npiganeau]

I would propose you to make it modular to make the future development easier.

That's what's planned for v0.7. See wiki link in previous post.

[mdziczkowski]

@npiganeau in wiki is about 0.6 and not 0.7

what have you used to do the graph? and the editor should be pinned to launcher and not server (server should be a second plan element to with users shouldn't have direct access

[npiganeau]

@mcgiwer Since I wrote the wiki, and I also coded the software, I do hope that I know what I am talking about :-)

Next arch is what is planned starting from v0.7 to make ts2 modular.

v0.6 is a monolithic software of over 20,000 lines of code

[mdziczkowski]

I edited my earlier post and fixed the amount of zero's (it seem I have small keyboard issues and not always all chars pop in)