[PATCH] Some special entities can't be placed in Atlas

[historic_bruno]

Rubble entities have an active Decay component and because of how that's implemented, they can only be local entities. This condition is violated if a rubble entity is placed in Atlas or spawned with the units demo map, resulting in an error or crash.

One way to fix this would be to set the Decay component as inactive in the rubble template, and then add a method to Decay that allows changing the active status (to be used when the rubble entity is properly spawned). That way they could be placed or spawned as non-decaying, non-local entities without any errors.

It might also be nice to prevent some special entities from being placed in Atlas since they have no useful purpose.

[historic_bruno]

Also applies to the common siege templates introduced in r12937, which aren't intended to be spawned as entities.

[trompetin17]

Hi, this is my patch to exclude folders. If you are going to build in your system, check if you have boost::regex

• Include (Folder /boost/regex)
• Include if you need the lib ( in windows you need libboost_regex-vc*-mt-gd-1_53.lib)

(I have this file in my windows environment if you need it)

I added a file inside simulation/data called atlasFilters.json, right now only support "excludeFolders", this must be a valid regular expression.

For example to exclude the folders rubble,formations and special, you use this regular expression "excludeFolders": "(rubble|formations|special)"

If you need to add another folder add "|" and your folder "excludeFolders": "(rubble|formations|special|otherFolder)"

If you need help with the regular expression feel free to contact me in #0ad-dev

If you have any suggestion, bug. please tell me

:)

[sanderd17]

I think full regex is a bit too much. You can use the included GetPathnames function from VFS, which also has a fiter.

It takes a directory name, and a file filter. So having a number of "include" lines would be fine. The file filter is not complete regex, but good enough for most cases, and if we need something more complex, we're doing it wrong. It just represents a random char with a '?', and multiple chars with a '*'.

This could look like a working filter:

{
  "includes": [
    {"directory": "campaigns/", "file": "*.xml"},
    {"directory": "gaia/", "file": "*.xml"},
    {"directory": "other/", "file": "*.xml"},
    {"directory": "skirmish/structures/", "file": "*.xml"},
    {"directory": "skirmish/units/", "file": "*.xml"},
    {"directory": "campaigns/", "file": "*.xml"},
    {"directory": "special/", "file": "trigger_point*.xml"},
    {"directory": "special/", "file": "territory*.xml"},
    {"directory": "structures/", "file": "*.xml"},
    {"directory": "units/", "file": "*.xml"},
  ]
}

And for those elements still included that need to be excluded (wallsets, ballista_common, ...), we can just move them to a different directory. There aren't a lot of references to those anyway (none in the maps, as they're not placeable).

Or if you really want, have a nested include/exclude, and use the match_wildcard function directly.

EDIT: just thought I'd mention this: we want the VFS to remain as stand-alone as possible. So adding extra dependencies (and certainly boost) isn't a good idea.

[trompetin17]

Done. I did like you suggest here.

Replying to sanderd17:

I think full regex is a bit too much. You can use the included GetPathnames function from VFS, which also has a fiter.

It takes a directory name, and a file filter. So having a number of "include" lines would be fine. The file filter is not complete regex, but good enough for most cases, and if we need something more complex, we're doing it wrong. It just represents a random char with a '?', and multiple chars with a '*'.

This could look like a working filter:

{
  "includes": [
    {"directory": "campaigns/", "file": "*.xml"},
    {"directory": "gaia/", "file": "*.xml"},
    {"directory": "other/", "file": "*.xml"},
    {"directory": "skirmish/structures/", "file": "*.xml"},
    {"directory": "skirmish/units/", "file": "*.xml"},
    {"directory": "campaigns/", "file": "*.xml"},
    {"directory": "special/", "file": "trigger_point*.xml"},
    {"directory": "special/", "file": "territory*.xml"},
    {"directory": "structures/", "file": "*.xml"},
    {"directory": "units/", "file": "*.xml"},
  ]
}

And for those elements still included that need to be excluded (wallsets, ballista_common, ...), we can just move them to a different directory. There aren't a lot of references to those anyway (none in the maps, as they're not placeable).

Or if you really want, have a nested include/exclude, and use the match_wildcard function directly.

EDIT: just thought I'd mention this: we want the VFS to remain as stand-alone as possible. So adding extra dependencies (and certainly boost) isn't a good idea.

[sanderd17]

Looks good, but it should be PlaceableTemplates (without the 's', you don't make the adjective plural in English).

Can you also look into moving the ballistas and related stuff into a different directory? Something like templates/special_units/ could work I think, but you'll have to update the references to it (not a lot of references I think).

Also, do the early continue if, as leper told you.

[trompetin17]

Done.

Please review my patch, this have move entities to "special_units" folder, and rename PlaceablesTemplates to PlaceableTemplates.

Replying to sanderd17:

Looks good, but it should be PlaceableTemplates (without the 's', you don't make the adjective plural in English).

Can you also look into moving the ballistas and related stuff into a different directory? Something like templates/special_units/ could work I think, but you'll have to update the references to it (not a lot of references I think).

Also, do the early continue if, as leper told you.

[sanderd17]

The packed ones and the unpacked ones are placeable (they have a visual), while the common isn't. So you shouldn't move the *_packed and *_unpacked to the special ones, just the *_common. . Also, you shouldn't edit the po files manually. Those are software generated, so will be updated automatically.

[trompetin17]

FIXED See my new patch please, thx Replying to sanderd17:

The packed ones and the unpacked ones are placeable (they have a visual), while the common isn't. So you shouldn't move the *_packed and *_unpacked to the special ones, just the *_common. . Also, you shouldn't edit the po files manually. Those are software generated, so will be updated automatically.

[sanderd17]

In 15467:

Disallow placing some special entities in Atlas. Fixes #1696. Patch by trompetin17

[sanderd17]

In 15521:

Re-allow placing skirmish entities in Atlas. Refs #1696