search

carnivores-cpe / Carn2-Menu

Carnivores 2/IA Menu implementation using left over code from Interface.cpp and referencing the Carnivores 1 menu code.
Creative Commons Zero v1.0 Universal
4 stars 3 forks source link

_RES Parser/interpreter is both too rigid and too loose #6

Open Rexhunter99 opened 4 years ago

Rexhunter99 commented 4 years ago

_RES.txt files need to be written in very specific ways or they will fail to load. Error reporting as to what caused the script loading to fail is nearly non-existant in the vanilla game. Implementing a more robust interpreter of the script with better error reporting would be a big step in the right direction to making _RES less painful to work with. It would also make it easier to implement new features to the _RES script.

As a long-term future goal, a stripped down binary version would be useful and interesting.

tminard commented 4 years ago

What about something like JSON or even YAML?

Rexhunter99 commented 4 years ago

What about something like JSON or even YAML?

It would be easier to stick with the current script format for now and just simply write a better interpreter for it, offering those later would be useful. I would not be opposed to JSON for handing things.

Ithamar commented 3 years ago

The problem with JSON is that comments are not allowed, which, as the format becomes more complex, makes it less and less easy for normal users to understand/edit. I think writing a better parser for the current format (or even YAML) would be much more helpful here.

tminard commented 3 years ago

What about HOCON? Interestingly, it’s not that different from the _RES custom format.

Ithamar commented 3 years ago

Never heard of it before, thanks for point it out ;) It seems to be JSON basically but with some stricter rules, and support for comments, so it would be more user-friendly then plain JSON.

I guess the big question is if it is worth introducing another format now, having to maintain both the current format and the new format, or fixing up the current config parser. I guess it'll be up to whoever ends up acting on this ticket ;)

tminard commented 3 years ago

Totally. Though to me the trade off is more about rewriting the existing parser (and extending to support new features, and documenting the format) vs rewriting the configs to use an open source parser and externally documented format.

Dinoguy1000 commented 3 years ago

Speaking from personal experience, maintaining two formats for the same thing sucks. If the decision is to switch to an open-source option, my recommendation is to consider the current format legacy and refuse to do any maintenance on it other than absolutely apocalyptically important stuff (e.g. security fixes).