Apex seems to be using the wrong delta time

  • February 7, 2018 at 23:14 #22766
    EmanTs
    Participant

    When first starting the scene with both a game window and a scene window open, I have half a second lag spike, during which my units massively overshoot their patrol targets (some actually commit suicide).
    I noticed in the SteerableUnitComponent’s Fixed update, that deltaTime was being used instead of fixedDeltaTime. After fixing this, I noticed a small improvement, however, the problem still persists – is it possible that there is a similar issue somewhere else?

    February 8, 2018 at 10:38 #22769
    Rami
    Keymaster

    Hi Emants,

    Thanks for posting.

    Using deltaTime or fixedDeltaTime should not make any difference. According to the Unity docs:

    “When called from inside MonoBehaviour’s FixedUpdate, returns the fixed framerate delta time.”

    Thus it seems unlikely that you would see any difference in using deltaTime or fixedDeltaTime – unless, of course, Unity’s documentation is misleading.

    As far as I know we haven’t encountered such an issue before. The easiest fix I can see off the top of my head is to simply delay their movement until you can ensure that the game will run smoothly. Simply Stop() or Wait() them as soon as possible (e.g. in Awake) and start them again when appropriate. Wait() has the option to pass how many seconds it should wait for, so that would be the easiest to use probably.

    February 12, 2018 at 16:27 #22788
    EmanTs
    Participant

    Thank you – well, maybe it could be a coincidence, but a certain enemy would fall off a ledge after overshooting ~80% of the time, and after changing the delta time, I hadn’t seen him do it anymore.
    Regardless though, if fixeddeltatime is being used one way or another, we should not have any overshooting, but I do. I would like to address this problem because – although I would like the game to run without lag – I would also like to prepare for the case where it does – so enemies don’t go killing themselves because of a framerate dip

    February 13, 2018 at 10:27 #22799
    Rami
    Keymaster

    That is of course a serious issue that should be fixed. I don’t know why it happens or why we haven’t ever seen it in the various products and projects where we have used similar functionality. So unfortunately I wouldn’t know where to begin. When our lead developer returns from sickness I will address this with him, so hopefully we can bring you a fix as soon as possible.

    February 14, 2018 at 11:26 #22809
    Geminior
    Keymaster

    That Time.deltaTime works as Rami describes, is easily verified by a Debug.Log(Time.deltaTime) in fixed update.
    So given that, it would appear your issue has a different cause.

    Are you sure you start your units only after the game world has properly initialized?
    Have your stepped frame by frame with an attached debugger to check the state of things?

    April 24, 2018 at 21:07 #23127
    EmanTs
    Participant

    So it turns out that the issue is that enemies start moving at their max speed even if the preferred speed is set before the first seek. This is something all of my units are doing

    April 25, 2018 at 11:02 #23140
    Rami
    Keymaster

    That should not be the case – please ensure that preferred speed is actually set as you expect and that it is indeed set correctly before they start their movement.

    April 25, 2018 at 21:24 #23155
    EmanTs
    Participant

    well, does IUnitFacade unitFacade = gameObject.GetUnitFacade ();
    unitFacade.SetPreferredSpeed(m_NewPreferredSpeed);
    not change the speed immediately?
    Basicaly, we want to use any speed we want without limitations, so the speeds in HumanoidSpeedComponent are extremely high and we set preferred speed before any movement orders are issued.

    April 27, 2018 at 19:25 #23164
    Geminior
    Keymaster

    Yes setting the preferred speed, changes the preferred speed immediately and the unit will adjust according to its acceleration/deceleration capabilities if already moving.

    So for the unit to move at max speed when it hasn’t been asked really shouldn’t be possible. Calling Run will set max speed.
    I have double checked the code and I can’t find anything that would cause the speed to ignore preferred settings and go for max.

    Have you set strafeMaxSpeed and backPedalMaxSpeed to appropriate values, as those are dynamically applied depending on the unit’s facing direction relative to its direction of movement.

    I suggest you set a break point in the HumanoidSpeedComponent’s Run method and in the SpeedComponent’s SetPreferred speed method to ensure that no rogue calls are made.

You must be logged in to reply to this topic.