Variant Project

[AnonymousHero]

Regarding the edit files:

I tend to think of the edit files as CSV+, and I think the actual parsing bits of that could be factored out relatively easily.

The only thing the parsing code really needs to know is

• what field type signifies a new record? ('N', usually)
• what (if any) separator character is used within a record field ('|', usually) for multi-valued fields (flags)

(or am I missing something? I'm only really familiar with the parsing code from ToME where I ripped out the *.raw generation.)

AFAICT this would also be sufficient for things like vault definitions.

Everything else could be treated as opaque strings and we'd at least get some sharing of code.

EDIT: Either that or just use a standardized human-readable format like, say, JSON or YAML. I'm sure there are libraries for C for both of those.

[Nick]

There's actually quite a lot of difference from variant to variant with what's in the edit files. While you could just take the line start and the rest as a string, most of the content in the init files is the parsing, so it wouldn't really help much.

I'm quite keen too to stick to things that are not in any way going to affect gameplay - so I'm even dubious about the view stuff and targeting. I think that it's best to start with a small core of common code and then expand it later if that seems like a good idea, rather than be pulling stuff out of variants and then having to put it back in.

[AnonymousHero]

Sure, I agree that it's best to start small and then expand as necessary/possible. I was just sayin'...