Search Unity

2 steps backwards

Discussion in 'Scripting' started by warrenbrandt, Sep 6, 2020.

  1. warrenbrandt

    warrenbrandt

    Joined:
    Mar 3, 2018
    Posts:
    413
    its my own fault...i usually backup as much as possible especially after doing a few hours.
    I had added a panel with money and destinations etc spent about 3 hours.
    saved everything
    ran it on my mobile and bang...suddenly my NPCs animations arent playing and the distance isnt being detected between my NPC's and the player...All I remember doing is moving my player to another area to test something i was working on.

    I know its impossible to tell without looking at scripts etc...Is there anything you can think of from experience that i have done, that i can undo to not have to lose these hours. Im sure its not a scripting problem, nothing has changed, i wasnt even working on those scripts.

    Everything looks normal i dont know whats wrong. if anybody can please help i would appreciate it.
     
  2. PraetorBlue

    PraetorBlue

    Joined:
    Dec 13, 2012
    Posts:
    7,909
    The only thing to do is start debugging. If no code has changed then usually something has just become misconfigured. Like you forgot to assign something an inspector somewhere, or assigned the wrong thing.
     
  3. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    38,742
    Yeah, what Praetor said is it... Debug.Log is your friend, and also since this is animation related, you can open up the Animator window when you expect the animations to go, and actually visually see where the state machine is, see which state it thinks it is in. You can combine this with Debug.Log() output at the locations where you set the animations to be what you think they should be, and that should lead you to some intel.

    I highly recommend setting up git source control. It really plays nicely with Unity and there are tons of tutorials out there on setting it up. Once you do that it's like a "savegame system" for development. You choose precisely when to make saves, and you can annotate those saves meaningfully, such as "before starting money panel."

    Each commit becomes something where you can compare the differences (in files) from previous to next. For me I like to use source control EXTREMELY frequently, and will make stepwise commits, such as:

    - created blank pane for money panel
    - connected money panel into main scene script
    - created logic to display money in money panel, etc.

    Each commit becomes a point that you can trivially teleport back to in time, and make sure something that suddenly stopped working actually was working when you think it was.

    I am in the process of converting Jetpack Kurt to run on Android TV. So far it is well over 100 small babysteps towards it, and it is just about done actually.

    But with git, at each point in the work process, I can instantly teleport back to it (git is really fast!) and confirm something, revert something, study what went wrong, reason about it, etc. I almost can't work WITHOUT source control anymore.

    Here's an example of about 30 minutes of work from a few days ago. Each line represents the commit message that I typed free-form when I made the commit, basically comments to myself should I ever have a problem, and I frequently do. I am only human.

    Screen Shot 2020-09-05 at 6.41.57 PM.png

    These commits list from newest going back in time, so new ones happen at the top. All commits are always kept, every possible saved condition you ever snapshotted with a commit, going back to day 1 on the project.

    You can see I was having issues with the input axes getting confused. You can also see me making simple "notes" commit, sometimes to one of my internal "notes.txt" files, or else directly into the code.

    git can instantly show me the edits I made to a file... this is the edits for the "am I going insane?" commit for the axis reversal listed above:

    Screen Shot 2020-09-05 at 6.46.57 PM.png

    You can instantly see how I inverted the axis from + to - and committed the change permanently into history. Red is removed a line, green is added a line, or in this case it is clearly just changes to pairs of lines.

    Now if I ever have a question about it, or switch it back, git is tracking an entire history of ALL the changes to every line of every piece of code.

    It is unbelievably useful and comforting. And all of my changes are pushed regularly to other computers I own, as well as up to the cloud via bitbucket, github and gitlab private repositories.

    If you are super-nerdy, you can also ask git to tell you how many commits you have made. Here is the full count of commits to my Jetpack Kurt game, which I started back on March 18, 2013:

    kurtina:Scenes kurt$ git rev-list --count HEAD
    4923


    Update from June 28, 2021: Jetpack Kurt has been under a lot of development in the past year! It's now at:

    kurtina:jetpack kurt$ git rev-list --count HEAD
    5782
     
    Last edited: Jun 29, 2021
  4. warrenbrandt

    warrenbrandt

    Joined:
    Mar 3, 2018
    Posts:
    413
    That is brilliant info Kurt yes i have been talking about git etc for a while with myself. But never implemented anything. Anyway im back to where i am, just rolled back and surprisingly 3 hours of work got done in 30 minutes, as i knew what i was doing.

    I have worked out that simply moving my player further up my scene causes this problem with the NPC not seeing the player anymore and not playing death animations.

    How can simply changing the player position cause all this?
    How would i debug that?
     
  5. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    38,742
    I imagine you might start with: How does the "NPC see the player?" Distance? Colliders? Something else? Based on that mechanism, find out why it fails when you think it should continue to work. You can print out values that go into the decision of seeing or not seeing, and from that figure out how to proceed.
     
  6. Madgvox

    Madgvox

    Joined:
    Apr 13, 2014
    Posts:
    1,317
    When you say "further up the scene", do you mean that you are moving the player GameObject higher in the hierarchy?

    That sounds to me that you are using GameObject.FindWithTag or GameObject.Find to find your player object, which are inherently unreliable for exactly this reason. I'm guessing that moving your player in the hierarchy was causing the death animation logic and NPCs to lock onto the wrong object.

    You should store information about what object your player is and other data in a more reliable place, like a global singleton that the player registers with and all other objects can access, for example.
     
  7. Essivee

    Essivee

    Joined:
    Nov 9, 2022
    Posts:
    3
    Question about these frequent commits and the rule of closing Unity before using git:

    I bet you only save your work in Unity before making a commit, but not close the whole software between every commit, right?
     
  8. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    38,742
    I always press Save-Scene and Save-Project before even looking in git

    Then I very selectively stage ONLY the changes that I intended to happen.
     
    Essivee likes this.