jak-project/goal_src/jak1/levels/snow/target-ice.gc

215 lines
11 KiB
Common Lisp
Raw Normal View History

;;-*-Lisp-*-
2020-09-04 14:44:23 -04:00
(in-package goal)
Dependency graph work - Part 1 - Preliminary work (#3505) Relates to #1353 This adds no new functionality or overhead to the compiler, yet. This is the preliminary work that has: - added code to the compiler in several spots to flag when something is used without being properly required/imported/whatever (disabled by default) - that was used to generate project wide file dependencies (some circulars were manually fixed) - then that graph underwent a transitive reduction and the result was written to all `jak1` source files. The next step will be making this actually produce and use a dependency graph. Some of the reasons why I'm working on this: - eliminates more `game.gp` boilerplate. This includes the `.gd` files to some extent (`*-ag` files and `tpage` files will still need to be handled) this is the point of the new `bundles` form. This should make it even easier to add a new file into the source tree. - a build order that is actually informed from something real and compiler warnings that tell you when you are using something that won't be available at build time. - narrows the search space for doing LSP actions -- like searching for references. Since it would be way too much work to store in the compiler every location where every symbol/function/etc is used, I have to do ad-hoc searches. By having a dependency graph i can significantly reduce that search space. - opens the doors for common shared code with a legitimate pattern. Right now jak 2 shares code from the jak 1 folder. This is basically a hack -- but by having an explicit require syntax, it would be possible to reference arbitrary file paths, such as a `common` folder. Some stats: - Jak 1 has about 2500 edges between files, including transitives - With transitives reduced at the source code level, each file seems to have a modest amount of explicit requirements. Known issues: - Tracking the location for where `defmacro`s and virtual state definitions were defined (and therefore the file) is still problematic. Because those forms are in a macro environment, the reader does not track them. I'm wondering if a workaround could be to search the reader's text_db by not just the `goos::Object` but by the text position. But for the purposes of finishing this work, I just statically analyzed and searched the code with throwaway python code.
2024-05-12 12:37:59 -04:00
(bundles "SNO.DGO")
(require "engine/target/target-handler.gc")
2020-09-04 14:44:23 -04:00
2021-12-12 23:27:18 -05:00
;; DECOMP BEGINS
(defstate target-ice-stance (target)
:event target-standard-event-handler
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
:enter
(behavior ()
(set! (-> self control unknown-surface00) *walk-mods*))
:exit target-state-hook-exit
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
:trans
(behavior ()
((-> self state-hook))
(if (!= (-> self control ground-pat material) (pat-material ice)) (go target-stance))
(when (move-legs?)
(remove-exit)
(go target-ice-walk))
(when (and (cpad-hold? (-> self control unknown-cpad-info00 number) l1 r1) (can-duck?))
(remove-exit)
(go target-duck-stance))
(if (and (logtest? (logior (logior (-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 0)
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 1))
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 2))
(pad-buttons x))
(can-jump? #f))
(go target-jump (-> *TARGET-bank* jump-height-min) (-> *TARGET-bank* jump-height-max) (the-as surface #f)))
(if (and (logtest? (logior (logior (-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 0)
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 1))
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 2))
(pad-buttons circle))
(can-feet?))
(go target-attack))
(if (can-hands? #t) (go target-running-attack))
(slide-down-test)
(fall-test))
:code
(behavior ()
(let ((gp-0 60))
(let ((v1-2 (ja-group)))
2021-12-12 23:27:18 -05:00
(cond
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
((or (= v1-2 eichar-jump-ja) (= v1-2 eichar-jump-loop-ja)) (set! gp-0 21))
((ja-group? eichar-wheel-flip-ja)
(ja-no-eval :group! eichar-wheel-flip-land-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
2021-12-12 23:27:18 -05:00
(suspend)
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
(ja :num! (seek!))))
((ja-group? eichar-attack-from-stance-ja)
(cond
((rand-vu-percent? 0.3)
(ja-no-eval :group! eichar-attack-from-stance-alt-end-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(suspend)
(ja :num! (seek!))))
(else
(ja-no-eval :group! eichar-attack-from-stance-end-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(suspend)
(ja :num! (seek!))))))
((ja-group? eichar-smack-surface-ja)
(ja-no-eval :group! eichar-smack-surface-end-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(suspend)
(ja :num! (seek!))))
((ja-group? eichar-yellow-running-blast-ja)
(ja-no-eval :group! eichar-yellow-running-blast-end-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
2021-12-12 23:27:18 -05:00
(suspend)
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
(ja :num! (seek!)))
(set! gp-0 0))
((ja-group? eichar-attack-punch-ja)
2021-12-12 23:27:18 -05:00
(set! (-> self control unknown-float81) (-> self control unknown-float80))
(set! (-> self control unknown-surface00) *walk-no-turn-mods*)
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
(ja-no-eval :group!
(if (rand-vu-percent? 0.3) eichar-attack-punch-alt-end-ja eichar-attack-punch-end-ja)
:num! (seek!)
:frame-num 0.0)
2021-12-12 23:27:18 -05:00
(until (ja-done? 0)
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
(seek! (-> self control unknown-float81) 0.0 (seconds-per-frame))
2021-12-12 23:27:18 -05:00
(suspend)
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
(ja :num! (seek!)))
2021-12-12 23:27:18 -05:00
(set! (-> self control unknown-surface00) *walk-mods*)
(set! (-> self control unknown-float81) 0.0)
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
(rot->dir-targ! (-> self control)))
((let ((v1-188 (ja-group))) (or (= v1-188 eichar-duck-stance-ja) (= v1-188 eichar-duck-walk-ja)))
(ja-channel-push! 1 (seconds 0.04))
(ja-no-eval :group! eichar-stance-to-duck-ja :num! (seek! 0.0 1.2) :frame-num max)
(until (ja-done? 0)
2021-12-12 23:27:18 -05:00
(suspend)
g/j1: Cleanup all main issues in the formatter and format all of `goal_src/jak1` (#3535) This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same: ![Screenshot 2024-05-25 132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2) > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: ![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00
(ja :num! (seek! 0.0 1.2)))
(set! gp-0 60))))
(while (< 16384.0 (-> self control unknown-float01))
(cond
((ja-group? eichar-ice-slide-ja))
(else (ja-channel-push! 1 (the-as time-frame gp-0)) (set! gp-0 150) (ja :group! eichar-ice-slide-ja)))
(suspend)
(ja :num! (loop!)))
(when (not (ja-group? eichar-ice-stance-ja))
(ja-channel-push! 1 (the-as time-frame gp-0))
(ja :group! eichar-ice-stance-ja)))
(loop
(suspend)
(ja :num! (loop!))))
:post target-post)
(defstate target-ice-walk (target)
:event target-standard-event-handler
:enter
(behavior ()
(set-time! (-> self state-time))
(set! (-> self control unknown-surface00) *walk-mods*))
:exit
(behavior ()
(target-effect-exit)
(target-state-hook-exit))
:trans
(behavior ()
((-> self state-hook))
(when (!= (-> self control ground-pat material) (pat-material ice))
(remove-exit)
(go target-walk))
(if (and (logtest? (logior (logior (-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 0)
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 1))
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 2))
(pad-buttons l1 r1))
(and (time-elapsed? (-> *TARGET-bank* wheel-timeout) (-> self control unknown-dword30))
(and (!= (-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) stick0-speed) 0.0) (can-wheel?))))
(go target-wheel))
(when (and (cpad-hold? (-> self control unknown-cpad-info00 number) l1 r1) (can-duck?))
(target-effect-exit)
(remove-exit)
(go target-duck-stance))
(when (and (not (move-legs?))
(let ((gp-0 (ja-group))
(f0-1 (ja-aframe-num 0)))
(if (and (= gp-0 eichar-ice-skate-ja) (>= f0-1 30.0) (>= 35.0 f0-1)) #t)))
(target-effect-exit)
(remove-exit)
(go target-ice-stance))
(if (and (logtest? (logior (logior (-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 0)
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 1))
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 2))
(pad-buttons x))
(can-jump? #f))
(go target-jump (-> *TARGET-bank* jump-height-min) (-> *TARGET-bank* jump-height-max) (the-as surface #f)))
(if (and (logtest? (logior (logior (-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 0)
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 1))
(-> *cpad-list* cpads (-> self control unknown-cpad-info00 number) button0-rel 2))
(pad-buttons circle))
(can-feet?))
(go target-attack))
(if (can-hands? #t) (go target-running-attack))
(slide-down-test)
(fall-test))
:code
(behavior ()
(cond
((ja-group? eichar-walk-ja)
(let ((f30-0 (ja-aframe-num 0)))
(ja-channel-push! 1 (seconds 0.1))
(ja :group! eichar-ice-skate-ja :num! (identity f30-0))))
((ja-group? eichar-ice-skate-ja))
(else
(let ((v1-18 (ja-group)))
(cond
((or (= v1-18 eichar-attack-punch-end-ja) (= v1-18 eichar-attack-punch-alt-end-ja))
(set! (-> self control unknown-float81) (-> self control unknown-float80))
(set! (-> self control unknown-surface00) *walk-no-turn-mods*)
(while (< (ja-aframe-num 0) 42.0)
(suspend)
(ja :num! (seek!)))
(set! (-> self control unknown-surface00) *walk-mods*)
(set! (-> self control unknown-float81) 0.0)
(ja-channel-push! 1 (seconds 0.1))
(ja :group! eichar-ice-skate-ja :num! (identity (ja-aframe 34.0 0)))
(while (!= (-> self skel root-channel 0) (-> self skel channel))
(suspend)))
((ja-group? eichar-attack-punch-ja)
(set! (-> self control unknown-float81) (-> self control unknown-float80))
(set! (-> self control unknown-surface00) *walk-no-turn-mods*)
(ja-no-eval :group! eichar-attack-punch-end-ja :num! (seek! (ja-aframe 42.0 0)) :frame-num 0.0)
(until (ja-done? 0)
(suspend)
(ja :num! (seek! (ja-aframe 42.0 0))))
(set! (-> self control unknown-surface00) *walk-mods*)
(set! (-> self control unknown-float81) 0.0)
(ja-channel-push! 1 (seconds 0.1))
(ja :group! eichar-ice-skate-ja :num! (identity (ja-aframe 34.0 0)))
(while (!= (-> self skel root-channel 0) (-> self skel channel))
(suspend)))
(else (ja-channel-push! 1 (seconds 0.05)) (ja :group! eichar-ice-skate-ja))))))
(loop
(suspend)
(let* ((s5-0 (vector-normalize-copy! (new 'stack-no-clear 'vector) (-> self control unknown-vector01) 1.0))
;; og:preserve-this modified to avoid dividing by zero when jak's speed is 0.
;; this fixes the issue where jak gets stuck on frame 60 of the ice-walk animation
;; instead of switching to stance (due to making zero progress here),
;; _and_ it fixes the issue where we get a NaN frame number in daxter, causing the eye animation
;; to read bogus memory.
(vector01-len (vector-length (-> self control unknown-vector01)))
(gp-6 (vector-float*! (new 'stack-no-clear 'vector)
(-> self control unknown-vector00)
;; og:preserve-this
(/ 1.0 (if (= vector01-len 0) 0.001 vector01-len)) ;; added the .001 case here.
))
(f0-18 (fmax -1.0 (fmin 1.0 (vector-dot s5-0 gp-6)))))
(ja :num!
(loop! (cond
((< f0-18 0.0) (lerp-scale 2.0 1.0 f0-18 -1.0 0.5))
((< 0.5 f0-18) (lerp-scale 1.0 0.75 f0-18 0.5 1.0))
(else (lerp-scale 1.33 1.0 f0-18 0.0 0.5))))))))
:post target-post)