Summary
ppmod.onportal can invoke the portal placement callback for a prop_portal located at [0, 0, 0] during early unsuccessful portal shots. This looks like a successful portal placement event, but no valid portal has actually spawned in the level.
Observed Behavior
When the player shoots before entering the test room / before a valid portal can be placed, ppmod.onportal may
emit a callback like:
{
"event_type": "portal_spawned",
"portal_color": "blue",
"portal_color_index": 1,
"portal_first": true,
"portal_entity": {
"classname": "prop_portal",
"entindex": 645,
"origin": [0, 0, 0]
}
}
The portal entity appears to be a prop_portal discovered by ppmod, but its origin is still [0, 0, 0], so this should not be treated as a real successful placement.
Later, a real successful portal placement emits a callback with a valid world position:
{
"event_type": "portal_spawned",
"portal_color": "blue",
"portal_color_index": 1,
"portal_first": false,
"portal_entity": {
"classname": "prop_portal",
"entindex": 645,
"origin": [477.822, 767.969, 56.0293]
}
}
## Expected Behavior
ppmod.onportal should only emit placement callbacks for actual successful portal placements, or expose enough
information to distinguish initialization/discovery callbacks from real placements.
## Notes
portal_first == true is not sufficient to filter these out, because the first real successful portal placement can
also have portal_first == true.
A simple downstream workaround is to ignore callbacks where the portal entity origin is exactly [0, 0, 0], but it
would be better if ppmod.onportal avoided emitting these false positives or marked them explicitly.
Summary
ppmod.onportalcan invoke the portal placement callback for aprop_portallocated at[0, 0, 0]during early unsuccessful portal shots. This looks like a successful portal placement event, but no valid portal has actually spawned in the level.Observed Behavior
When the player shoots before entering the test room / before a valid portal can be placed,
ppmod.onportalmayemit a callback like:
{ "event_type": "portal_spawned", "portal_color": "blue", "portal_color_index": 1, "portal_first": true, "portal_entity": { "classname": "prop_portal", "entindex": 645, "origin": [0, 0, 0] } } The portal entity appears to be a prop_portal discovered by ppmod, but its origin is still [0, 0, 0], so this should not be treated as a real successful placement. Later, a real successful portal placement emits a callback with a valid world position: { "event_type": "portal_spawned", "portal_color": "blue", "portal_color_index": 1, "portal_first": false, "portal_entity": { "classname": "prop_portal", "entindex": 645, "origin": [477.822, 767.969, 56.0293] } } ## Expected Behavior ppmod.onportal should only emit placement callbacks for actual successful portal placements, or expose enough information to distinguish initialization/discovery callbacks from real placements. ## Notes portal_first == true is not sufficient to filter these out, because the first real successful portal placement can also have portal_first == true. A simple downstream workaround is to ignore callbacks where the portal entity origin is exactly [0, 0, 0], but it would be better if ppmod.onportal avoided emitting these false positives or marked them explicitly.