Macros cause parsing to fail (#define and #include statements)

[dijksterhuis]

Was parsing Mike Force vehicle configs as the tag inclusions/exclusions can be pain to work out the final results without starting the gamemode and manually testing.

The parser would fail on these first macro lines

#include "..\ui\icons.inc"

#define RESPAWN_SHORT respawnType = "RESPAWN"; time = 10
#define RESPAWN_MEDIUM respawnType = "RESPAWN"; time = 30
#define RESPAWN_LONG respawnType = "RESPAWN"; time = 60
#define WRECK_SHORT respawnType = "WRECK"; time = 10
#define WRECK_MEDIUM respawnType = "WRECK"; time = 30
#define WRECK_LONG respawnType = "WRECK"; time = 60

#include is a similar issue to #8 as it loads in additional config classes from somewhere else (inheritance is so fun isn't it :P )

But #define macros are used to inject common values later in the config file.... and they don't necessarily have a key that can be parsed by armaclass

NOTE -- I think the lack of a key caused errors without doing with the macro replacement on RESPAWN_SHORT. However, it was over 12 hours ago and i'm about to go to bed as it's 6am. so I could be wrong!

https://github.com/Savage-Game-Design/Mike-Force/blob/development/mission/config/subconfigs/vehicle_respawn_info.hpp#L503

class spawn_point_types {
	class light_transport {
		name = "Light transport";
		RESPAWN_SHORT;  // the problem line
		class categories {
			...
		}
	}
}

I've got a very messy, hacked together script which could possibly turn into a PR at some point.

• grabs the config file with readlines
• ignores the #include macros
• grabs the #define macros and parses them
• replaces everything in the readlines data that matches the macro key
• feeds the fixed readlines data to armaclass.parse

Of course, there's also another option which is just to flat out exclude macros and any lines that don't have an appropriate key!

[dijksterhuis]

I've just seen #2 and your comment #2 (comment)

🤦

i'll take a read through and see what's up

[overfl0]

Hi, I was thinking of tackling the includes when I'd be done with figuring out #8 in a meaningful way.

What needs to be kept in mind when making changes to the library is that we need to be able to use it to make small changes to the config and to write it back to disk with minimal changes.
As a result, I would be against doing the preprocessor's job by default, because you wouldn't be able to write the macros back to disk if you have expanded them. And from what I remember reading on the discord, implementing the preprocessor correctly is very hard to do.
Expanding the macros will sometimes even be impossible, if the macros are defined in a file that's included, as the parser has no way open that file and read it, while it's parsing your config.

What I would much rather see is that the library detects that something is most probably a macro (because it looks like a macro and doesn't match anything else), and mark it as such.
Maybe using a key:val of __macro_<number>: 'RESPAWN_SHORT', for example. That would then allow either modifying the file keeping the macro intact, or even modifying the (or adding a new) macro in Python and writing it to a file, using the generator.

I can't tell when I'd go back to this as I'm currently quite busy IRL. However, there are a few things that I was planning to add to this library, like some fuzzing in the CI step, etc... so I hope that it's going to happen rather sooner than later.

PRs are welcome neverthless. Even if I start working on a feature myself, having a PR will certainly speed up the time to have that feature shipped. I'm assuming the chances of you knowing Cython are fairly small, so I'm going to have to rewrite some bits of your (potential) PR anyway, to make use of Cython's enhancements.