entities: add `pos_navcon` entity

[illwieckz]

Add pos_navcon entity. When linked with a target having the same name of another pos_navcon's targetname, the game will know it can generate a navcon there.

The bidir flag can be toggled to make the link bidirectional (from the game point of view, nothing is displayed differently in editor).

The playerclasses expects a space-separated strings of player classes able to use the navcon, for example: builder level0 level1.

It is expected the game implements the reading of those and generate the related navcons. This is to be done by someone else in the Unvanquished repository.

The current design allows to link multiple navcons in a chain, I suggest that all linked navcons inherit the playerclasses from both sides, and chained navcons inherit all the player classes from previous pos_navcon, but it is recommended to set the playerclass in the first one (the one having no targetname field).

[illwieckz]

To test this, one should copy build/netradiant/unvanquished.game/pkg/entities.ent from this repository to gamepacks/unvanquished.game/pkg/entities.ent in NetRadiant install folder.

[illwieckz]

The current design allows to link multiple navcons in a chain, I suggest that all linked navcons inherit the playerclasses from both side, and chained navcons inherit all the player classes from previous pos_navcon, but it is recommended to set the playerclass in the first one (the one having no targetname field).

If we do that we will probably have to avoid circular navcon chains, as the game would never be able to start iterating them, because I guess the best way to start following chains is to start with navcons not having a targetname.

[illwieckz]

If we do that we will probably have to avoid circular navcon chains, as the game would never be able to start iterating them, because I guess the best way to start following chains is to start with navcons not having a targetname.

Or I define a pos_navcon_start and a pos_navcon_next, and only pos_navcon_next will be used for chaining.

[illwieckz]

Or I define a pos_navcon_start and a pos_navcon_next, and only pos_navcon_next will be used for chaining.

Actually it's a better idea.

[sweet235]

I think there are two possible methods to make the game use this data:

1. Make the game handle these entities.
2. Make q3map2 ignore these entities (do not put them in the .bsp). Instead, generate .navcon files. This could be done by netradiant or by a seperate program.

Both have their advantages and drawbacks. My first instinct is to go for method 2. The navcon files are simple text files, and provide a unified, tweakable interface.

Edit: The game will ignore any entities it does not know. So putting them in the .bsp does not hurt.

[illwieckz]

Now with a chain of pos_navcon_start → pos_navcon_next → pos_navcon_next:

The idea is that the game would look for all pos_navcon_start, read the playerclasses for player class names (if there are none, enable the navcon for all the classes), and then create a navcon between pos_navcon_start and the linked pos_navcon_next. If the pos_navcon_next also has a target, then the game would create another navcon with them using the same players classes.

The bidir flag and the playerclasses field is now only meant to be set in pos_navcon_start, and a pos_navcon_start or a pos_navcon_next is not supposed to link to a pos_navcon_start (no cycle).

[sweet235]

The idea is that the game would look for all pos_navcon_start

The game, or netradiant, or q3map2, or some other program. We have the choice.

[illwieckz]

I think there are two possible methods to make the game use this data:

1. Make the game handle these entities.

2. Make q3map2 ignore these entities (do not put them in the .bsp). Instead, generate `.navcon` files. This could be done by netradiant or by a seperate program.

Both have their advantages and drawbacks. My first instinct is to go for method 2. The navcon files are simple text files, and provide a unified, tweakable interface.

Of course, but once you implemented 2 you can just copy this implementation in game. 😃️

Actually for both ladders and this we can let the game generate navcon files and then let the game read it again (like we do with navmeshes).

We just need to standardize some file names to have multiple navcon files per map, so generating some will not overwrite user-generated navcons.

[sweet235]

Of course, but once you implemented 2 you can just copy this implementation in game.

It is not that simple. We would have to take the union of the set of navcons in the .bsp and the set of navcons in the .navcon. That is one complication with this approach.

[illwieckz]

For example we may have:

• maps/chasm-level0.navcon (the one we edit by hand)
• maps/chasm-level0_ents.navcon (the one we translate from bsp entities)
• maps/chasm-level0_auto.navcon (the one we generate from things like ladders)

The entity syntax in the BSP is exactly the same as the .map file, it's just a .map file without brushes, but anyway we already have an entity parser in the game.

[illwieckz]

The sgame will translate/generate at navgen time:

• maps/chasm-level0_ents.navcon
• maps/chasm-level0_auto.navcon

The sgame will load at bot spawn time:

• maps/chasm-level0.navcon
• maps/chasm-level0_ents.navcon
• maps/chasm-level0_auto.navcon

[illwieckz]

I suggest we can also use team names in playerclasses.

For example with a navcon doing a long jump down that would kill an human but not an alien, on would just write playerclasses "aliens" and the game will generate a navcon for all alien classes.

[illwieckz]

Here is a test map:

https://github.com/UnvanquishedAssets/map-chasm_src.dpkdir/raw/illwieckz/navcon-test/maps/chasm.map

The chained navcons on the left are a bidir for the human class.

The navcon on the right is not bidir and goes from up to down. I wrote aliens team name instead of a classname, so we can generate a navcon for all the alien classes.

[sweet235]

Currently open questions to ponder:

• Do we want seperate entities for pos_navcon_start and pos_navcon_next, or do we want a single entity pos_navcon?
• How do we specify the navcon radius?

[illwieckz]

• Do we want seperate entities for pos_navcon_start and pos_navcon_next, or do we want a single entity pos_navcon?

It makes far easier to implement inheritance for things like bidir, classes and radius when there is a clearly identified start entity.

• How do we specify the navcon radius?

I can just add a radius int field to the start entity description.

[sweet235]

It makes far easier to implement inheritance for things like bidir, classes and radius when there is a clearly identified start entity.

I mean: what will be more intuitive to the casual netradiant user? I have no idea, we should try to ask them.

[illwieckz]

• How do we specify the navcon radius?

I can just add a radius int field to the start entity description.

Unfortunately we can't name it radius because there is already a radius key with a vec3 in other entities.

It makes far easier to implement inheritance for things like bidir, classes and radius when there is a clearly identified start entity.

I mean: what will be more intuitive to the casual netradiant user? I have no idea, we should try to ask them.

There is a portal/camera link, a camera/position link, etc. so it's not that different.

[sweet235]

Unfortunately we can't name it radius because there is already a radius key with a vec3 in other entities.

Maybe something short like size.

[illwieckz]

Also having a clearly identified different name makes easier for the netradiant user to know what entity has the bidir/radius/classes values, especially for someone opening a map he is not author of.

[illwieckz]

I added size (float) for radius.

[sweet235]

Currently open questions to ponder ...

I think there are no more open questions, and this is ready to be tested.

[sweet235]

It is expected the game implements the reading of those and generate the related navcons. This is to be done by someone else in Unvanquished repository.

"Someone else" made a prototype at https://github.com/sweet235/navcon-extractor

[cu-kai]

@sweet235's navcon extractor worked well for my test-navcons map (to be uploaded s00n™ to https://github.com/UnvanquishedAssets/UnvanquishedTestAssets/tree/master) and I would support being able to optionally generate navcon files from these entities either as part of the navgen process (controversial, I know), or by some other method (q3map2 could do this? or even more controversial: bring back daemonmap?)

[sweet235]

@sweet235's navcon extractor

It was written by me and illwieckz.

my test-navcons map

I made a PR at https://github.com/UnvanquishedAssets/UnvanquishedTestAssets/pull/14

support being able to optionally generate navcon files from these entities either as part of the navgen process, or by some other method

We did not decide that yet. But we do propose that the game shall load more than one navcon file for each class, as described above:

The sgame will translate/generate at navgen time:

• maps/chasm-level0_ents.navcon
• maps/chasm-level0_auto.navcon

The sgame will load at bot spawn time:

• maps/chasm-level0.navcon
• maps/chasm-level0_ents.navcon
• maps/chasm-level0_auto.navcon

The navcon extractor prototype simply generates what will be maps/chasm-level0_ents.navcon.

[illwieckz]

In the navcon extractor prototype, we implemented playerclasses being able to also hold team names, as it was good enough to test for both per-class navcon generation and team-expansion, but we may prefer having an explicit playerteams key instead, having both playerclasses and playerteams.

[illwieckz]

I split playerclasses with playerteams, so one can either do:

"playerclasses" "human_naked human_bsuit"

or do:

"playerteams" "humans"

I updated https://github.com/sweet235/navcon-extractor accordingly.

[illwieckz]

The actual design looks good and fulfills the need, so I guess we can merge it.