1. Darklight Games Avatar Darklight Games
  2. Untitled project
  3. darkesthour
  4. Issues

Mortar operators can sometimes appear under the ground

Issue #46 resolved
Colin Basnett created an issue

No description provided.

Comments (14)

  1. Colin Basnett reporter

    This visual glitch also occurs when occupying the commander's position in an open-topped vehicle and using the debug LeaveBody command, which separates the Controller from the Pawn. This could give a hint as to why this bug occurs.

  3. Colin Basnett reporter

    @Matt_UK explained to me it could have something to do with the player pawn being replicated on the client before the vehicle; so when the player spawns on the client and attempts to attach to the correct bone, it fails.

    @AndrewTheel, it would be best if you could develop a test level specifically for replicating this issue. In this way, we can test fixes in isolation. I will give more details later.

    Upgrading this bug's severity, as I would really like to have this resolved for 6.0.

  7. Matt Hands

    Been doing quite a bit of investigation on mortars. Two separate issues affecting positioning:

    1. General replication timing issues, similar to other vehicleweapon/pawns. Similar solution and have worked that into mortar code (not committed yet).

    2. Replication relevancy problems that are specific to mortars. Probably because mortar vehicle, VW & VWPawn all uniquely spawn on demand when mortar weapon is deployed. Possibly to do with whether mortar is visible to owner - I'm checking that out, as visibility affects relevance. It is quite common for an owning client not to have the Gun or VehicleBase actors, as seen by the WVPawn's SpecialCalcFirstPersonView() spamming out endless log errors. This is not a timing issue - the client NEVER receives the replicated actor, so something is stopping the server considering the actor to be relevant to the client.

    If there isn't a good and quick solution, I'm thinking that a hack - but a sensible and justified hack - could be to make the mortar actors bAlwaysRelevant. Only applies when mortar actually deployed, as that's the only time the actors are spawned, even on the server. And only likely to be 1 or 2 deployed at any time, so that would mean 3 to 6 additional actors made relevant to all clients, when a good proportion of those would/should be relevant anyway. But will see if there's a better solution first.

  8. Matt Hands

    Things I'm trying:

    1. Make (or make sure) mortar vehicle & WV are visible to owning client, even in some token, not really visible way. Not visible can mean not relevant. Most likely solution (I hope !).

    2. Make mortar WVPawn the Owner of the mortar vehicle - reverses normal state of affairs, but we always have VWPawn and it's the PlayerController's Pawn, so I would hope by making it own the vehicle, the vehicle should be relevant. And if vehicle is relevant, I'd hope attached VW would also be relevant.

    3. bAlwaysRelevant - I think this may only be needed for the mortar vehicle, as VW may fail to be considered relevant solely because it's Base isn't considered relevant. Last resort.

    Should be able to try these steps tomorrow and will commit if works or appears may work.

  10. Matt Hands

    Cracked it - very happy !

    Problem was caused when undeploying. Mortar destroys itself and often does so before the exiting process (unpossess, possess, etc, ect) has properly completed for the client. Solution is to delay destruction of mortar actors until that happens.

    Tests using simple time delay prove it works. I'm trying out some different timing methods to see if we can have a better, triggered solution that doesn't involve an arbitrary time delay.

  11. Matt Hands

    Should be fixed in commit a040439. Two problems should be resolved here:

    1. General problem of attachment position not being applied correctly to mortar operator, same as for other vehicle weapon crew. Same solution driven from PostNetReceive() on net client, to detach & re-attach the 'Driver'.

    2. Mortar-specific problem of client not always having the necessary Gun/VehWep actor. Problem was caused by premature destruction of mortar vehicle actors by server upon undeploying, before client had time to complete the process of exiting and repossessing the player pawn. Client now calls ServerDestroyMortar() function on server, but only when it has completed what it needs to do.

    Other changes made to prevent client going into state 'LeavingVehicle', as we rely on it being in state 'Undeploying' to now that we need to trigger destruction. Those changes actually an improvement anyway, as no longer have to flag mortar weapon pawn as being multi-position when it clearly isn't.

    I have checked this with the LeaveBody debug and with behind view. Also by leaving lots of LeaveBody pawns deployed on mortars and reconnecting to force all-new replication. I haven't found a problem yet, certainly not the type reported here. There are still other issues with mortars, but if this works out, I'd say this particular issue can be closed. Fingers crossed !

    Ps - other issues:

    • make server play same gun/player anims so hit detection always matches client

    • US mortar specifies wrong attachment bone

    • mortar anim files a bit messy

    • probably don't need to extend ROTankCannon classes

  15. Log in to comment
Assignee
Type
bug
Priority
critical
Status
resolved
Component
Mortars
Version
6.0
Votes
0
Watchers
3
Jira: the preferred issue tracker for Bitbucket. Join the team!