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

1089 lines
46 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 "levels/sunken/double-lurker.gc")
(require "engine/anim/joint-exploder.gc")
2020-09-04 14:44:23 -04:00
;; DECOMP BEGINS
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
(defskelgroup *ice-cube-break-sg*
ice-cube-break
ice-cube-break-lod0-jg
-1
((ice-cube-break-lod0-mg (meters 999999)))
:bounds (static-spherem 0 -15 0 50))
(deftype ice-cube (nav-enemy)
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
((part2 sparticle-launch-control)
(part3 sparticle-launch-control)
(part4 sparticle-launch-control)
(track-target? symbol)
(slow-down? symbol)
(tracking-player? symbol)
(force-spawn-pt int32)
(speed float)
(anim-blend float)
(prev-charge-angle-diff float)
(charge-angle float)
(ground-y float)
(cprims-type uint64)
(next-skid-sound-time time-frame)
(starting-pos vector :inline)
(target-pt vector :inline))
(:methods
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
(ice-cube-method-51 (_type_ vector vector) symbol :overlay-at nav-enemy-method-51)
(ice-cube-method-53 (_type_ vector vector) symbol :overlay-at nav-enemy-method-53))
(:states
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
ice-cube-appear
ice-cube-appear-land
ice-cube-become-mean
ice-cube-face-player
ice-cube-mean-charge
ice-cube-mean-charge-done
ice-cube-mean-turn-to-charge
ice-cube-retract-spikes
ice-cube-shatter
ice-cube-tired
ice-cube-trying-to-appear))
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
(defskelgroup *ice-cube-sg*
ice-cube
ice-cube-lod0-jg
-1
((ice-cube-lod0-mg (meters 20)) (ice-cube-lod1-mg (meters 40)) (ice-cube-lod2-mg (meters 999999)))
:bounds (static-spherem 0 3 0 3.6)
:shadow ice-cube-shadow-mg)
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
(define *ice-cube-nav-enemy-info*
(new 'static
'nav-enemy-info
:idle-anim 5
:walk-anim 6
:turn-anim -1
:notice-anim 7
:run-anim 6
:jump-anim 6
:jump-land-anim 6
:victory-anim 7
:taunt-anim 7
:die-anim 7
:neck-joint 5
:player-look-at-joint 5
:run-travel-speed (meters 20)
:run-rotate-speed (degrees 2880)
:run-acceleration (meters 1)
:run-turn-time (seconds 0.1)
:walk-travel-speed (meters 3)
:walk-rotate-speed (degrees 720)
:walk-acceleration (meters 1)
:walk-turn-time (seconds 0.5)
:attack-shove-back (meters 3)
:attack-shove-up (meters 2)
:shadow-size (meters 1)
:notice-nav-radius (meters 1.5)
:nav-nearest-y-threshold (meters 10)
:notice-distance (meters 35)
:stop-chase-distance (meters 45)
:frustration-distance (meters 8)
:frustration-time (seconds 4)
:die-anim-hold-frame 10000000000.0
:jump-anim-start-frame 10.0
:jump-land-anim-end-frame 10000000000.0
:jump-height-min (meters 3)
:jump-height-factor 0.5
:jump-start-anim-speed 1.0
:shadow-max-y (meters 1)
:shadow-min-y (meters -3.5)
:shadow-locus-dist (meters 150)
:use-align #f
:draw-shadow #f
:move-to-ground #t
:hover-if-no-ground #f
:use-momentum #f
:use-flee #f
:use-proximity-notice #f
:use-jump-blocked #f
:use-jump-patrol #f
:gnd-collide-with (collide-kind background)
:debug-draw-neck #f
:debug-draw-jump #f))
(defpartgroup group-ice-cube-appear1
:id 507
:flags (use-local-clock)
:bounds (static-bspherem 0 0 0 16)
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
:parts
((sp-item 1887 :fade-after (meters 70) :falloff-to (meters 70))
(sp-item 1888 :fade-after (meters 70) :falloff-to (meters 70))))
(defpart 1888
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
:init-specs
((:texture (new 'static 'texture-id :index #x19 :page #x2))
(:num 16.0)
(:x (meters -2) (meters 4))
(:y (meters 0.5) (meters 1))
(:z (meters -2) (meters 4))
(:scale-x (meters 0.24) (meters 0.24))
(:rot-z (degrees 0) (degrees 360))
(:scale-y :copy scale-x)
(:r 128.0)
(:g 128.0)
(:b 128.0)
(:a 128.0 64.0)
(:vel-y (meters 0.033333335) (meters 0.05))
(:rotvel-z (degrees -2.4) (degrees 3.4666667))
(:accel-y (meters -0.0013333333))
(:friction 0.99)
(:timer (seconds 1.5))
(:flags (bit2 bit12))
(:conerot-x (degrees 0) (degrees 40))
(:conerot-y (degrees 0) (degrees 360))))
(defpart 1887
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
:init-specs
((:texture (new 'static 'texture-id :page #x2))
(:num 32.0)
(:x (meters -2) (meters 4))
(:y (meters 0.5) (meters 1))
(:z (meters -2) (meters 4))
(:scale-x (meters 2.5) (meters 2.5))
(:rot-z (degrees 0) (degrees 360))
(:scale-y :copy scale-x)
(:r 128.0)
(:g 128.0)
(:b 128.0)
(:a 32.0 32.0)
(:vel-y (meters 0.05) (meters 0.016666668))
(:scalevel-x (meters 0.006666667))
(:rotvel-z (degrees -1.2) (degrees 1.2))
(:scalevel-y :copy scalevel-x)
(:fade-a -0.07111111)
(:accel-y (meters -0.0013333333))
(:friction 0.99)
(:timer (seconds 1.5))
(:flags (bit2 bit12))
(:conerot-x (degrees 0) (degrees 40))
(:conerot-y (degrees 0) (degrees 360))))
(defpartgroup group-ice-cube-appear2
:id 508
:flags (use-local-clock)
:bounds (static-bspherem 0 0 0 16)
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
:parts ((sp-item 1889 :fade-after (meters 70) :falloff-to (meters 70))))
(defpart 1889
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
:init-specs
((:texture (new 'static 'texture-id :index #x19 :page #x2))
(:num 1.0 2.0)
(:x (meters -0.25) (meters 0.5))
(:z (meters -0.25) (meters 0.5))
(:scale-x (meters 0.2) (meters 0.1))
(:rot-z (degrees 0) (degrees 360))
(:scale-y :copy scale-x)
(:r 128.0)
(:g 128.0)
(:b 128.0)
(:a 64.0 64.0)
(:vel-y (meters 0) (meters 0.006666667))
(:rotvel-z (degrees -2.4) (degrees 3.4666667))
(:accel-y (meters -0.0013333333))
(:timer (seconds 0.5))
(:flags (bit2 bit12))
(:conerot-x (degrees 0) (degrees 30))
(:conerot-y (degrees 0) (degrees 360))))
(defpartgroup group-ice-cube-foot-puff
:id 567
:duration (seconds 0.017)
:linger-duration (seconds 1.5)
:bounds (static-bspherem 0 0 0 2)
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
:parts ((sp-item 2325) (sp-item 2326) (sp-item 2327)))
(defpart 2325
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
:init-specs
((:texture (new 'static 'texture-id :page #x2))
(:num 16.0)
(:scale-x (meters 1) (meters 1))
(:rot-z (degrees 0) (degrees 360))
(:scale-y :copy scale-x)
(:r 196.0 64.0)
(:g 196.0 64.0)
(:b 196.0 64.0)
(:a 16.0 32.0)
(:vel-y (meters 0.02) (meters 0.01))
(:scalevel-x (meters 0.0033333334))
(:rotvel-z (degrees -0.2) (degrees 0.4))
(:scalevel-y :copy scalevel-x)
(:fade-a -0.16)
(:accel-y (meters -0.00033333333))
(:friction 0.95)
(:timer (seconds 1))
(:flags (bit2 bit12))
(:conerot-x (degrees 60) (degrees 30))
(:conerot-y (degrees 0) (degrees 360))))
(defpart 2326
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
:init-specs
((:texture (new 'static 'texture-id :page #x2))
(:num 12.0)
(:scale-x (meters 0.5) (meters 0.25))
(:rot-z (degrees 0) (degrees 360))
(:scale-y :copy scale-x)
(:r 196.0 64.0)
(:g 196.0 64.0)
(:b 196.0 64.0)
(:a 16.0 16.0)
(:vel-y (meters 0.053333335) (meters 0.02))
(:scalevel-x (meters 0.0016666667))
(:rotvel-z (degrees -0.2) (degrees 0.4))
(:scalevel-y :copy scalevel-x)
(:fade-a -0.21333334)
(:accel-y (meters -0.00033333333))
(:friction 0.95)
(:timer (seconds 0.5))
(:flags (bit2 bit12))
(:conerot-x (degrees 60) (degrees 30))
(:conerot-y (degrees 0) (degrees 360))))
(defpart 2327
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
:init-specs
((:texture (new 'static 'texture-id :index #x4 :page #x2))
(:num 32.0)
(:x (meters -0.4) (meters 0.8))
(:y (meters -0.1) (meters 0.4))
(:z (meters -0.4) (meters 0.8))
(:scale-x (meters 0.07) (meters 0.02))
(:scale-y :copy scale-x)
(:r 196.0 2.0 64.0)
(:g 196.0 1 64.0)
(:b 196.0 1 64.0)
(:a 64.0 64.0)
(:vel-y (meters 0.015) (meters 0.006666667))
(:fade-a -0.42666668)
(:accel-y (meters -0.0013333333) (meters 0.00066666666))
(:timer (seconds 1))
(:flags (bit2 bit12))
(:conerot-x (degrees 30) (degrees 50.000004))
(:conerot-y (degrees 0) (degrees 360))
(:conerot-radius (meters 0.5))))
(defpartgroup group-ice-cube-shatter
:id 509
:flags (use-local-clock)
:bounds (static-bspherem 0 0 0 16)
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
:parts ((sp-item 1890) (sp-item 1891) (sp-item 1892)))
(defpart 1892
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
:init-specs
((:texture (new 'static 'texture-id :index #xf :page #x2))
(:num 64.0)
(:y (meters 1))
(:scale-x (meters 0.24) (meters 0.24))
(:scale-y :copy scale-x)
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 96.0 32.0)
(:vel-y (meters 0.033333335) (meters 0.13333334))
(:accel-y (meters -0.000033333334))
(:friction 0.99)
(:timer (seconds 0.2) (seconds 0.297))
(:flags (bit2 bit12))
(:conerot-x (degrees 0) (degrees 140))
(:conerot-y (degrees 0) (degrees 360))
(:conerot-radius (meters 0) (meters 1.5))))
(defpart 1891
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
:init-specs
((:texture (new 'static 'texture-id :page #x2))
(:num 8.0)
(:x (meters -2) (meters 4))
(:y (meters 1))
(:z (meters -2) (meters 4))
(:scale-x (meters 3) (meters 2))
(:rot-z (degrees 0) (degrees 360))
(:scale-y :copy scale-x)
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 64.0 64.0)
(:vel-y (meters 0) (meters 0.016666668))
(:scalevel-x (meters 0.006666667))
(:rotvel-z (degrees -0.3) (degrees 0.6))
(:scalevel-y :copy scalevel-x)
(:fade-a -0.28444445)
(:friction 0.99)
(:timer (seconds 1.5))
(:flags (bit2 bit12))
(:conerot-x (degrees 0) (degrees 120))
(:conerot-y (degrees 0) (degrees 360))
(:conerot-radius (meters 0) (meters 1.5))))
(defpart 1890
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
:init-specs
((:texture (new 'static 'texture-id :page #x2))
(:num 16.0)
(:x (meters -2) (meters 4))
(:y (meters 1))
(:z (meters -2) (meters 4))
(:scale-x (meters 1) (meters 1))
(:rot-z (degrees 0) (degrees 360))
(:scale-y :copy scale-x)
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 32.0 32.0)
(:vel-y (meters 0.13333334) (meters 0.033333335))
(:scalevel-x (meters 0.006666667))
(:rotvel-z (degrees -1.2) (degrees 1.2))
(:scalevel-y :copy scalevel-x)
(:fade-a -0.35555556)
(:friction 0.99)
(:timer (seconds 0.6))
(:flags (bit2 bit12))
(:conerot-x (degrees 0) (degrees 120))
(:conerot-y (degrees 0) (degrees 360))
(:conerot-radius (meters 0) (meters 1.5))))
(defbehavior ice-cube-default-event-handler ice-cube ((arg0 process) (arg1 int) (arg2 symbol) (arg3 event-message-block))
[opengoal] make `none` a child of `object` (#3001) Previously, `object` and `none` were both top-level types. This made decompilation rather messy as they have no LCA and resulted in a lot of variables coming out as type `none` which is very very wrong and additionally there were plenty of casts to `object`. This changes it so `none` becomes a child of `object` (it is still represented by `NullType` which remains unusable in compilation). This change makes `object` the sole top-level type, and the type that can represent *any* GOAL object. I believe this matches the original GOAL built-in type structure. A function that has a return type of `object` can now return an integer or a `none` at the same time. However, keep in mind that the return value of `(none)` is still undefined, just as before. This also makes a cast to `object` meaningless in 90% of the situations it showed up in (as every single thing is already an `object`) and the decompiler will no longer emit them. Casts to `none` are also reduced. Yay! Additionally, state handlers also don't get the final `(none)` printed out anymore. The return type of a state handler is completely meaningless outside the event handler (which is return type `object` anyway) so there are no limitations on what the last form needs to be. I did this instead of making them return `object` to trick the decompiler into not trying to output a variable to be used as a return value (internally, in the decompiler they still have return type `none`, but they have `object` elsewhere). Fixes #1703 Fixes #830 Fixes #928
2023-09-22 05:54:49 -04:00
(case arg2
(('attack)
(cond
((and (= (-> arg0 type) target)
(= (-> self cprims-type) 2)
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
(not (send-event *target* 'query 'powerup (pickup-type eco-red))))
[opengoal] make `none` a child of `object` (#3001) Previously, `object` and `none` were both top-level types. This made decompilation rather messy as they have no LCA and resulted in a lot of variables coming out as type `none` which is very very wrong and additionally there were plenty of casts to `object`. This changes it so `none` becomes a child of `object` (it is still represented by `NullType` which remains unusable in compilation). This change makes `object` the sole top-level type, and the type that can represent *any* GOAL object. I believe this matches the original GOAL built-in type structure. A function that has a return type of `object` can now return an integer or a `none` at the same time. However, keep in mind that the return value of `(none)` is still undefined, just as before. This also makes a cast to `object` meaningless in 90% of the situations it showed up in (as every single thing is already an `object`) and the decompiler will no longer emit them. Casts to `none` are also reduced. Yay! Additionally, state handlers also don't get the final `(none)` printed out anymore. The return type of a state handler is completely meaningless outside the event handler (which is return type `object` anyway) so there are no limitations on what the last form needs to be. I did this instead of making them return `object` to trick the decompiler into not trying to output a variable to be used as a return value (internally, in the decompiler they still have return type `none`, but they have `object` elsewhere). Fixes #1703 Fixes #830 Fixes #928
2023-09-22 05:54:49 -04:00
(when (and (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
((= (-> arg0 type) target) (send-event arg0 'attack (-> arg3 param 0) (new 'static 'attack-info)))
[opengoal] make `none` a child of `object` (#3001) Previously, `object` and `none` were both top-level types. This made decompilation rather messy as they have no LCA and resulted in a lot of variables coming out as type `none` which is very very wrong and additionally there were plenty of casts to `object`. This changes it so `none` becomes a child of `object` (it is still represented by `NullType` which remains unusable in compilation). This change makes `object` the sole top-level type, and the type that can represent *any* GOAL object. I believe this matches the original GOAL built-in type structure. A function that has a return type of `object` can now return an integer or a `none` at the same time. However, keep in mind that the return value of `(none)` is still undefined, just as before. This also makes a cast to `object` meaningless in 90% of the situations it showed up in (as every single thing is already an `object`) and the decompiler will no longer emit them. Casts to `none` are also reduced. Yay! Additionally, state handlers also don't get the final `(none)` printed out anymore. The return type of a state handler is completely meaningless outside the event handler (which is return type `object` anyway) so there are no limitations on what the last form needs to be. I did this instead of making them return `object` to trick the decompiler into not trying to output a variable to be used as a return value (internally, in the decompiler they still have return type `none`, but they have `object` elsewhere). Fixes #1703 Fixes #830 Fixes #928
2023-09-22 05:54:49 -04:00
(else
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
(let ((a1-3 (new 'stack-no-clear 'event-message-block)))
(set! (-> a1-3 from) self)
(set! (-> a1-3 num-params) 4)
(set! (-> a1-3 message) 'attack)
(set! (-> a1-3 param 0) (-> arg3 param 0))
(set! (-> a1-3 param 1) (the-as uint #f))
(let ((v1-20 (+ *global-attack-id* 1))) (set! *global-attack-id* v1-20) (set! (-> a1-3 param 2) (the-as uint v1-20)))
(set! (-> a1-3 param 3) (the-as uint 0))
(send-event-function arg0 a1-3))))
(= (-> arg0 type) target))
[opengoal] make `none` a child of `object` (#3001) Previously, `object` and `none` were both top-level types. This made decompilation rather messy as they have no LCA and resulted in a lot of variables coming out as type `none` which is very very wrong and additionally there were plenty of casts to `object`. This changes it so `none` becomes a child of `object` (it is still represented by `NullType` which remains unusable in compilation). This change makes `object` the sole top-level type, and the type that can represent *any* GOAL object. I believe this matches the original GOAL built-in type structure. A function that has a return type of `object` can now return an integer or a `none` at the same time. However, keep in mind that the return value of `(none)` is still undefined, just as before. This also makes a cast to `object` meaningless in 90% of the situations it showed up in (as every single thing is already an `object`) and the decompiler will no longer emit them. Casts to `none` are also reduced. Yay! Additionally, state handlers also don't get the final `(none)` printed out anymore. The return type of a state handler is completely meaningless outside the event handler (which is return type `object` anyway) so there are no limitations on what the last form needs to be. I did this instead of making them return `object` to trick the decompiler into not trying to output a variable to be used as a return value (internally, in the decompiler they still have return type `none`, but they have `object` elsewhere). Fixes #1703 Fixes #830 Fixes #928
2023-09-22 05:54:49 -04:00
(set-collide-offense (-> self collide-info) 2 (collide-offense no-offense))
(logior! (-> self nav-enemy-flags) (nav-enemy-flags navenmf8))
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
(level-hint-spawn (text-id snow-ice-cube-hint) "sksp0350" (the-as entity #f) *entity-pool* (game-task none))))
(else (nav-enemy-set-hit-from-direction arg0) (go ice-cube-shatter))))
[opengoal] make `none` a child of `object` (#3001) Previously, `object` and `none` were both top-level types. This made decompilation rather messy as they have no LCA and resulted in a lot of variables coming out as type `none` which is very very wrong and additionally there were plenty of casts to `object`. This changes it so `none` becomes a child of `object` (it is still represented by `NullType` which remains unusable in compilation). This change makes `object` the sole top-level type, and the type that can represent *any* GOAL object. I believe this matches the original GOAL built-in type structure. A function that has a return type of `object` can now return an integer or a `none` at the same time. However, keep in mind that the return value of `(none)` is still undefined, just as before. This also makes a cast to `object` meaningless in 90% of the situations it showed up in (as every single thing is already an `object`) and the decompiler will no longer emit them. Casts to `none` are also reduced. Yay! Additionally, state handlers also don't get the final `(none)` printed out anymore. The return type of a state handler is completely meaningless outside the event handler (which is return type `object` anyway) so there are no limitations on what the last form needs to be. I did this instead of making them return `object` to trick the decompiler into not trying to output a variable to be used as a return value (internally, in the decompiler they still have return type `none`, but they have `object` elsewhere). Fixes #1703 Fixes #830 Fixes #928
2023-09-22 05:54:49 -04:00
(('touch)
(when (and (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
((= (-> arg0 type) target) (send-event arg0 'attack (-> arg3 param 0) (new 'static 'attack-info)))
[opengoal] make `none` a child of `object` (#3001) Previously, `object` and `none` were both top-level types. This made decompilation rather messy as they have no LCA and resulted in a lot of variables coming out as type `none` which is very very wrong and additionally there were plenty of casts to `object`. This changes it so `none` becomes a child of `object` (it is still represented by `NullType` which remains unusable in compilation). This change makes `object` the sole top-level type, and the type that can represent *any* GOAL object. I believe this matches the original GOAL built-in type structure. A function that has a return type of `object` can now return an integer or a `none` at the same time. However, keep in mind that the return value of `(none)` is still undefined, just as before. This also makes a cast to `object` meaningless in 90% of the situations it showed up in (as every single thing is already an `object`) and the decompiler will no longer emit them. Casts to `none` are also reduced. Yay! Additionally, state handlers also don't get the final `(none)` printed out anymore. The return type of a state handler is completely meaningless outside the event handler (which is return type `object` anyway) so there are no limitations on what the last form needs to be. I did this instead of making them return `object` to trick the decompiler into not trying to output a variable to be used as a return value (internally, in the decompiler they still have return type `none`, but they have `object` elsewhere). Fixes #1703 Fixes #830 Fixes #928
2023-09-22 05:54:49 -04:00
(else
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
(let ((a1-7 (new 'stack-no-clear 'event-message-block)))
(set! (-> a1-7 from) self)
(set! (-> a1-7 num-params) 4)
(set! (-> a1-7 message) 'attack)
(set! (-> a1-7 param 0) (-> arg3 param 0))
(set! (-> a1-7 param 1) (the-as uint #f))
(let ((v1-38 (+ *global-attack-id* 1))) (set! *global-attack-id* v1-38) (set! (-> a1-7 param 2) (the-as uint v1-38)))
(set! (-> a1-7 param 3) (the-as uint 0))
(send-event-function arg0 a1-7))))
(= (-> arg0 type) target))
[opengoal] make `none` a child of `object` (#3001) Previously, `object` and `none` were both top-level types. This made decompilation rather messy as they have no LCA and resulted in a lot of variables coming out as type `none` which is very very wrong and additionally there were plenty of casts to `object`. This changes it so `none` becomes a child of `object` (it is still represented by `NullType` which remains unusable in compilation). This change makes `object` the sole top-level type, and the type that can represent *any* GOAL object. I believe this matches the original GOAL built-in type structure. A function that has a return type of `object` can now return an integer or a `none` at the same time. However, keep in mind that the return value of `(none)` is still undefined, just as before. This also makes a cast to `object` meaningless in 90% of the situations it showed up in (as every single thing is already an `object`) and the decompiler will no longer emit them. Casts to `none` are also reduced. Yay! Additionally, state handlers also don't get the final `(none)` printed out anymore. The return type of a state handler is completely meaningless outside the event handler (which is return type `object` anyway) so there are no limitations on what the last form needs to be. I did this instead of making them return `object` to trick the decompiler into not trying to output a variable to be used as a return value (internally, in the decompiler they still have return type `none`, but they have `object` elsewhere). Fixes #1703 Fixes #830 Fixes #928
2023-09-22 05:54:49 -04:00
(set-collide-offense (-> self collide-info) 2 (collide-offense no-offense))
(let ((v0-3 (the-as object (logior (-> self nav-enemy-flags) (nav-enemy-flags navenmf8)))))
(set! (-> self nav-enemy-flags) (the-as nav-enemy-flags v0-3))
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
v0-3)))
[opengoal] make `none` a child of `object` (#3001) Previously, `object` and `none` were both top-level types. This made decompilation rather messy as they have no LCA and resulted in a lot of variables coming out as type `none` which is very very wrong and additionally there were plenty of casts to `object`. This changes it so `none` becomes a child of `object` (it is still represented by `NullType` which remains unusable in compilation). This change makes `object` the sole top-level type, and the type that can represent *any* GOAL object. I believe this matches the original GOAL built-in type structure. A function that has a return type of `object` can now return an integer or a `none` at the same time. However, keep in mind that the return value of `(none)` is still undefined, just as before. This also makes a cast to `object` meaningless in 90% of the situations it showed up in (as every single thing is already an `object`) and the decompiler will no longer emit them. Casts to `none` are also reduced. Yay! Additionally, state handlers also don't get the final `(none)` printed out anymore. The return type of a state handler is completely meaningless outside the event handler (which is return type `object` anyway) so there are no limitations on what the last form needs to be. I did this instead of making them return `object` to trick the decompiler into not trying to output a variable to be used as a return value (internally, in the decompiler they still have return type `none`, but they have `object` elsewhere). Fixes #1703 Fixes #830 Fixes #928
2023-09-22 05:54:49 -04:00
(('touched)
(when (!= (-> arg0 type) target)
(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
((= (-> arg0 type) target) (send-event arg0 'attack (-> arg3 param 0) (static-attack-info ((mode #f)))))
[opengoal] make `none` a child of `object` (#3001) Previously, `object` and `none` were both top-level types. This made decompilation rather messy as they have no LCA and resulted in a lot of variables coming out as type `none` which is very very wrong and additionally there were plenty of casts to `object`. This changes it so `none` becomes a child of `object` (it is still represented by `NullType` which remains unusable in compilation). This change makes `object` the sole top-level type, and the type that can represent *any* GOAL object. I believe this matches the original GOAL built-in type structure. A function that has a return type of `object` can now return an integer or a `none` at the same time. However, keep in mind that the return value of `(none)` is still undefined, just as before. This also makes a cast to `object` meaningless in 90% of the situations it showed up in (as every single thing is already an `object`) and the decompiler will no longer emit them. Casts to `none` are also reduced. Yay! Additionally, state handlers also don't get the final `(none)` printed out anymore. The return type of a state handler is completely meaningless outside the event handler (which is return type `object` anyway) so there are no limitations on what the last form needs to be. I did this instead of making them return `object` to trick the decompiler into not trying to output a variable to be used as a return value (internally, in the decompiler they still have return type `none`, but they have `object` elsewhere). Fixes #1703 Fixes #830 Fixes #928
2023-09-22 05:54:49 -04:00
(else
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
(let ((a1-10 (new 'stack-no-clear 'event-message-block)))
(set! (-> a1-10 from) self)
(set! (-> a1-10 num-params) 4)
(set! (-> a1-10 message) 'attack)
(set! (-> a1-10 param 0) (-> arg3 param 0))
(set! (-> a1-10 param 1) (the-as uint #f))
(let ((v1-54 (+ *global-attack-id* 1))) (set! *global-attack-id* v1-54) (set! (-> a1-10 param 2) (the-as uint v1-54)))
(set! (-> a1-10 param 3) (the-as uint 0))
(send-event-function arg0 a1-10))))))))
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod initialize-collision ((this ice-cube))
(let ((s5-0 (new 'process 'collide-shape-moving this (collide-list-enum usually-hit-by-player))))
(set! (-> s5-0 dynam) (copy *standard-dynamics* 'process))
(set! (-> s5-0 reaction) default-collision-reaction)
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
(set! (-> s5-0 no-reaction) (the-as (function collide-shape-moving collide-shape-intersect vector vector none) nothing))
(let ((s4-0 (new 'process 'collide-shape-prim-group s5-0 (the-as uint 5) 0)))
(set! (-> s4-0 prim-core collide-as) (collide-kind enemy))
(set! (-> s4-0 collide-with) (collide-kind target))
(set! (-> s4-0 prim-core action) (collide-action solid))
(set-vector! (-> s4-0 local-sphere) 0.0 12288.0 0.0 14745.6)
(set-root-prim! s5-0 s4-0)
(let ((s3-0 (new 'process 'collide-shape-prim-sphere s5-0 (the-as uint 3))))
(set! (-> s3-0 prim-core collide-as) (collide-kind enemy))
(set! (-> s3-0 collide-with) (collide-kind target))
(set! (-> s3-0 prim-core action) (collide-action solid))
(set! (-> s3-0 prim-core offense) (collide-offense touch))
(set-vector! (-> s3-0 local-sphere) 0.0 3276.8 0.0 3276.8)
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
(append-prim s4-0 s3-0))
(let ((s3-1 (new 'process 'collide-shape-prim-sphere s5-0 (the-as uint 3))))
(set! (-> s3-1 prim-core collide-as) (collide-kind enemy))
(set! (-> s3-1 collide-with) (collide-kind target))
(set! (-> s3-1 prim-core action) (collide-action solid))
(set! (-> s3-1 prim-core offense) (collide-offense touch))
(set-vector! (-> s3-1 local-sphere) 0.0 5734.4 0.0 3276.8)
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
(append-prim s4-0 s3-1))
(let ((s3-2 (new 'process 'collide-shape-prim-sphere s5-0 (the-as uint 3))))
(set! (-> s3-2 prim-core collide-as) (collide-kind enemy))
(set! (-> s3-2 collide-with) (collide-kind target))
(set! (-> s3-2 prim-core action) (collide-action solid))
(set! (-> s3-2 prim-core offense) (collide-offense touch))
(set-vector! (-> s3-2 local-sphere) 0.0 8192.0 0.0 3276.8)
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
(append-prim s4-0 s3-2))
(let ((s3-3 (new 'process 'collide-shape-prim-sphere s5-0 (the-as uint 1))))
(set! (-> s3-3 prim-core collide-as) (collide-kind enemy))
(set! (-> s3-3 collide-with) (collide-kind target))
(set! (-> s3-3 prim-core offense) (collide-offense normal-attack))
(set! (-> s3-3 transform-index) 6)
(set-vector! (-> s3-3 local-sphere) 819.2 0.0 0.0 2048.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
(append-prim s4-0 s3-3))
(let ((s3-4 (new 'process 'collide-shape-prim-sphere s5-0 (the-as uint 1))))
(set! (-> s3-4 prim-core collide-as) (collide-kind enemy))
(set! (-> s3-4 collide-with) (collide-kind target))
(set! (-> s3-4 prim-core offense) (collide-offense normal-attack))
(set! (-> s3-4 transform-index) 4)
(set-vector! (-> s3-4 local-sphere) 0.0 2048.0 0.0 4505.6)
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
(append-prim s4-0 s3-4)))
(set! (-> s5-0 nav-radius) 6144.0)
(backup-collide-with-as s5-0)
(set! (-> s5-0 max-iteration-count) (the-as uint 1))
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
(set! (-> this collide-info) s5-0))
(set! (-> this cprims-type) (the-as uint 0))
(set-root-prim-collide-with! (-> this collide-info) (collide-kind target))
(set! (-> this collide-info event-self) 'touched)
(nav-enemy-method-57 this)
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
(none))
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod nav-enemy-method-57 ((this ice-cube))
(when (!= (-> this cprims-type) 1)
(set! (-> this cprims-type) (the-as uint 1))
(let ((v1-3 (-> this collide-info root-prim)))
(set-vector! (-> v1-3 local-sphere) 0.0 12288.0 0.0 14745.6)
(set-vector! (-> (the-as collide-shape-prim-group v1-3) prims 3 local-sphere) 819.2 0.0 0.0 2048.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
(set-vector! (-> (the-as collide-shape-prim-group v1-3) prims 4 local-sphere) 0.0 2048.0 0.0 4505.6)))
(none))
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod nav-enemy-method-58 ((this ice-cube))
(when (!= (-> this cprims-type) 2)
(set! (-> this cprims-type) (the-as uint 2))
(let ((v1-3 (-> this collide-info root-prim)))
(set-vector! (-> v1-3 local-sphere) 0.0 12288.0 0.0 16384.0)
(set-vector! (-> (the-as collide-shape-prim-group v1-3) prims 3 local-sphere) 819.2 0.0 0.0 4915.2)
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
(set-vector! (-> (the-as collide-shape-prim-group v1-3) prims 4 local-sphere) 0.0 2048.0 0.0 9420.8)))
(none))
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod nav-enemy-method-48 ((this ice-cube))
(process-drawable-from-entity! this (-> this entity))
(initialize-skeleton this *ice-cube-sg* '())
(init-defaults! this *ice-cube-nav-enemy-info*)
(set! (-> this neck up) (the-as uint 0))
(set! (-> this neck nose) (the-as uint 1))
(set! (-> this neck ear) (the-as uint 2))
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
(none))
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod deactivate ((this ice-cube))
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
(if (nonzero? (-> this part2)) (kill-and-free-particles (-> this part2)))
(if (nonzero? (-> this part3)) (kill-and-free-particles (-> this part3)))
(if (nonzero? (-> this part4)) (kill-and-free-particles (-> this part4)))
((method-of-type process-drawable deactivate) this)
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
(none))
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod relocate ((this ice-cube) (arg0 int))
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
(if (nonzero? (-> this part2)) (&+! (-> this part2) arg0))
(if (nonzero? (-> this part3)) (&+! (-> this part3) arg0))
(if (nonzero? (-> this part4)) (&+! (-> this part4) arg0))
(call-parent-method this arg0))
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod init-from-entity! ((this ice-cube) (arg0 entity-actor))
(set! (-> this part) (create-launch-control (-> *part-group-id-table* 507) this))
(set! (-> this part2) (create-launch-control (-> *part-group-id-table* 508) this))
(set! (-> this part3) (create-launch-control (-> *part-group-id-table* 509) this))
(set! (-> this part4) (create-launch-control (-> *part-group-id-table* 567) this))
(initialize-collision this)
(nav-enemy-method-48 this)
(let ((s4-0 (-> this path curve num-cverts)))
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
(if (<= s4-0 0) (go process-drawable-art-error "no path"))
(let ((v1-21 (res-lump-value arg0 'mode uint128 :default (the-as uint128 -1))))
(if (and (>= (the-as int v1-21) 0) (< (the-as int v1-21) s4-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
(set! (-> this force-spawn-pt) (the-as int v1-21))
(set! (-> this force-spawn-pt) -1))))
(go ice-cube-trying-to-appear)
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
(none))
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod nav-enemy-method-60 ((this ice-cube) (arg0 symbol))
(let ((gp-0 (new 'stack-no-clear 'vector)))
(when (-> this tracking-player?)
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
(if (and *target* arg0) (set! (-> this target-pt quad) (-> (target-pos 0) quad))))
(vector-! gp-0 (-> this target-pt) (-> this collide-info trans))
(seek-toward-heading-vec! (-> this collide-info) gp-0 524288.0 (seconds 0.1))
(let ((v0-5 (< (fabs (deg- (quaternion-y-angle (-> this collide-info quat)) (vector-y-angle gp-0))) 364.0889)))
(b! #t cfg-10 :delay (nop!))
(the-as none 0)
(set! v0-5 (the-as symbol #f))
(label cfg-10)
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
v0-5)))
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod ice-cube-method-51 ((this ice-cube) (arg0 vector) (arg1 vector))
(let ((s5-0 (new 'stack-no-clear 'vector)))
(let* ((s4-0 (new 'stack-no-clear 'collide-tri-result))
(f0-0 40960.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
(f30-0 (+ f0-0 40960.0)))
(set! (-> s5-0 quad) (-> arg0 quad))
(+! (-> s5-0 y) f0-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
(let ((f0-2 (fill-and-probe-using-y-probe *collide-cache*
s5-0
f30-0
(collide-kind background)
(-> this collide-info process)
s4-0
(new 'static 'pat-surface :noentity #x1))))
;; og:preserve-this yes this is bugged
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
(if (or (< f0-2 0.0) (= (logand #b111000 (the-as int (-> s4-0 pat))) 8)) (return #f))
(set! (-> s5-0 y) (- (-> s5-0 y) (* f0-2 f30-0)))))
(set! (-> arg1 quad) (-> s5-0 quad)))
#t)
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod nav-enemy-method-52 ((this ice-cube) (arg0 vector))
(when *target*
(let ((f0-0 (vector-vector-xz-distance arg0 (target-pos 0))))
(when (and (>= f0-0 40960.0) (>= 81920.0 f0-0) (not (nav-enemy-method-50 this arg0)))
(let ((a0-4 (new 'stack-no-clear 'vector)))
(set! (-> a0-4 quad) (-> arg0 quad))
(set! (-> a0-4 w) (-> this collide-info root-prim local-sphere w))
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
(if (sphere-in-view-frustum? (the-as sphere a0-4)) (return #t))))))
#f)
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod ice-cube-method-53 ((this ice-cube) (arg0 vector) (arg1 vector))
(local-vars (s1-0 int) (s2-0 int))
(let ((s3-0 (-> this path curve num-cverts)))
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
(if (<= s3-0 0) (return #f))
(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
((>= (-> this force-spawn-pt) 0) (set! s1-0 (-> this force-spawn-pt)) (set! s2-0 1))
(else (set! s1-0 (rand-vu-int-count s3-0)) (set! s2-0 s3-0)))
(while (> s2-0 0)
(eval-path-curve-div! (-> this path) arg0 (the float s1-0) 'interp)
(when (nav-enemy-method-52 this arg0)
(let ((a1-3 (new 'stack-no-clear 'vector))
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
(s3-1 (new 'stack-no-clear 'collide-tri-result)))
(set! (-> a1-3 quad) (-> arg0 quad))
(+! (-> a1-3 y) 16384.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
(if (>= (fill-and-probe-using-line-sphere *collide-cache*
a1-3
(new 'static 'vector :y -32768.0 :w 1.0)
409.6
(collide-kind background)
this
s3-1
(new 'static 'pat-surface :noentity #x1))
0.0)
(set! (-> arg0 quad) (-> s3-1 intersect quad))))
(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
(*target* (vector-! arg1 (target-pos 0) arg0) (set! (-> arg1 y) 0.0))
(else
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
(set-vector! arg1 (rand-vu-float-range -4096.0 4096.0) 0.0 (rand-vu-float-range -4096.0 4096.0) 1.0)
(+! (-> arg1 x) 409.6)))
(vector-normalize! arg1 1.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
(return #t))
(set! s1-0 (mod (+ s1-0 1) s3-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
(+! s2-0 -1)))
#f)
(defstate ice-cube-trying-to-appear (ice-cube)
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 ()
(ja-channel-set! 0)
(ja-post)
(logior! (-> self draw status) (draw-status hidden))
(clear-collide-with-as (-> self collide-info)))
:exit
(behavior ()
(logclear! (-> self draw status) (draw-status hidden))
(restore-collide-with-as (-> self collide-info)))
:trans
(behavior ()
(when (and *target* (>= 163840.0 (vector-vector-distance (-> self collide-info trans) (-> *target* control trans))))
(let ((s5-0 (new 'stack-no-clear 'vector))
(gp-0 (new 'stack-no-clear 'vector)))
(when (ice-cube-method-53 self s5-0 gp-0)
(set! (-> self collide-info trans quad) (-> s5-0 quad))
(forward-up->quaternion (-> self collide-info quat) gp-0 *up-vector*)
(nav-enemy-method-57 self)
(go ice-cube-appear)))))
:code
(behavior ()
(logior! (-> self mask) (process-mask sleep-code))
(suspend)
0))
(defstate ice-cube-appear (ice-cube)
:event ice-cube-default-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 ()
(nav-enemy-method-57 self)
(set! (-> self ground-y) (-> self collide-info trans y))
(spawn (-> self part) (-> self collide-info trans))
(set-current-poly! (-> self nav) (nav-control-method-16 (-> self nav) (-> self collide-info trans)))
(+! (-> self collide-info trans y) -12288.0)
(set! (-> self collide-info transv quad) (-> *null-vector* quad))
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
(set! (-> self collide-info transv y) (rand-vu-float-range 102400.0 114688.0)))
:trans
(behavior ()
(when (and (< (-> self collide-info trans y) (-> self ground-y)) (< (-> self collide-info transv y) 0.0))
(set! (-> self collide-info trans y) (-> self ground-y))
(set! (-> self collide-info transv quad) (-> *null-vector* quad))
(go ice-cube-appear-land))
(let* ((s5-0 (-> self node-list))
(a0-2 (-> s5-0 length))
(gp-0 (new 'stack-no-clear 'vector)))
(vector<-cspace! gp-0 (-> s5-0 data (nav-enemy-rnd-int-count a0-2)))
(spawn (-> self part2) gp-0)))
:code
(behavior ()
(ja-channel-push! 1 (seconds 0.2))
(ja-no-eval :group! ice-cube-appear-jump-up-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(suspend)
(ja :num! (seek!)))
(loop
(suspend)))
:post nav-enemy-falling-post)
(defstate ice-cube-appear-land (ice-cube)
:event ice-cube-default-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
:code
(behavior ()
(let ((gp-0 (new 'stack-no-clear 'vector)))
(vector<-cspace! gp-0 (joint-node ice-cube-lod0-jg Rball))
(spawn (-> self part4) gp-0)
(vector<-cspace! gp-0 (joint-node ice-cube-lod0-jg Lball))
(spawn (-> self part4) gp-0))
(ja-channel-push! 1 (seconds 0.1))
(ja-no-eval :group! ice-cube-appear-land-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(suspend)
(ja :num! (seek!)))
(if (target-in-range? self (-> self nav-info notice-distance)) (go ice-cube-become-mean) (go-virtual nav-enemy-idle)))
:post ja-post)
(defstate nav-enemy-idle (ice-cube)
:virtual #t
:event ice-cube-default-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 ()
(let ((t9-0 (-> (method-of-type nav-enemy nav-enemy-idle) enter))) (if t9-0 (t9-0)))
(set! (-> self draw force-lod) -1)
(logior! (-> self mask) (process-mask actor-pause))))
(defstate nav-enemy-patrol (ice-cube)
:virtual #t
:event ice-cube-default-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 ()
(let ((t9-0 (-> (method-of-type nav-enemy nav-enemy-patrol) enter))) (if t9-0 (t9-0)))
(set! (-> self draw force-lod) -1)
(logior! (-> self mask) (process-mask actor-pause)))
:code
(behavior ()
(ja-channel-push! 1 (seconds 0.2))
(let ((t9-1 (-> (method-of-type nav-enemy nav-enemy-patrol) code))) (if t9-1 ((the-as (function none) t9-1))))))
(defstate nav-enemy-notice (ice-cube)
:virtual #t
:enter #f
:exit #f
:trans #f
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
:code
(behavior ()
(nav-enemy-method-57 self)
(logclear! (-> self nav-enemy-flags) (nav-enemy-flags navenmf1))
(logclear! (-> self mask) (process-mask actor-pause))
(go ice-cube-face-player))
:post #f)
(defstate ice-cube-face-player (ice-cube)
:event ice-cube-default-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-time! (-> self state-time))
(logior! (-> self nav-enemy-flags) (nav-enemy-flags navenmf2))
(nav-enemy-method-57 self)
(logclear! (-> self mask) (process-mask actor-pause))
(if (or (not *target*)
(logtest? (-> *target* state-flags)
(state-flags being-attacked invulnerable timed-invulnerable invuln-powerup do-not-notice dying))
(not (nav-enemy-test-point-near-nav-mesh? (-> *target* control shadow-pos))))
(go-virtual nav-enemy-patrol))
(set! (-> self tracking-player?) #t)
(set! (-> self target-pt quad) (-> (target-pos 0) quad))
(nav-enemy-neck-control-look-at)
(set-vector! (-> self collide-info transv) 0.0 114688.0 0.0 1.0))
:code
(behavior ()
(local-vars (gp-0 symbol))
(ja-channel-push! 1 (seconds 0.2))
(ja-no-eval :group! ice-cube-appear-jump-up-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(let ((f30-0 (-> self collide-info transv y)))
(integrate-for-enemy-with-move-to-ground! (-> self collide-info)
(-> self collide-info transv)
(collide-kind background)
32768.0
#f
#f
#f)
(if (< 0.0 f30-0) (set! (-> self collide-info transv y) f30-0)))
(+! (-> self collide-info transv y) (* -544768.0 (seconds-per-frame)))
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
(let* ((v1-26 (>= 0.0 (-> self collide-info transv y)))
(v1-27 (and v1-26 (logtest? (-> self collide-info status) (cshape-moving-flags onsurf)))))
(set! gp-0 (nav-enemy-method-60 self (not v1-27))))
(suspend)
(ja :num! (seek!)))
(loop
(let ((s5-0 (and (>= 0.0 (-> self collide-info transv y)) (logtest? (-> self collide-info status) (cshape-moving-flags onsurf)))))
(set! gp-0 (and s5-0 gp-0))
(if gp-0 (goto cfg-26))
(integrate-for-enemy-with-move-to-ground! (-> self collide-info)
(-> self collide-info transv)
(collide-kind background)
32768.0
#f
#f
#f)
(+! (-> self collide-info transv y) (* -544768.0 (seconds-per-frame)))
(set! gp-0 (nav-enemy-method-60 self (not s5-0))))
(suspend))
(label cfg-26)
(let ((gp-1 (new 'stack-no-clear 'vector)))
(vector<-cspace! gp-1 (joint-node ice-cube-lod0-jg Rball))
(spawn (-> self part4) gp-1)
(vector<-cspace! gp-1 (joint-node ice-cube-lod0-jg Lball))
(spawn (-> self part4) gp-1))
(ja-no-eval :group! ice-cube-appear-land-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(suspend)
(ja :num! (seek!)))
(go ice-cube-become-mean))
:post nav-enemy-simple-post)
(defstate ice-cube-become-mean (ice-cube)
:event ice-cube-default-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 draw force-lod) 0)
(logclear! (-> self mask) (process-mask actor-pause))
(nav-enemy-method-57 self))
:code
(behavior ()
(ja-channel-push! 1 (seconds 0.075))
(let ((gp-0 #f))
(ja-no-eval :group! ice-cube-extend-spikes-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(when (and (not gp-0) (>= (ja-aframe-num 0) 8.0))
(set! gp-0 #t)
(nav-enemy-method-58 self))
(suspend)
(ja :num! (seek!))))
(go ice-cube-mean-turn-to-charge))
:post nav-enemy-simple-post)
`deftype` and `defmethod` syntax major changes (#3094) Major change to how `deftype` shows up in our code: - the decompiler will no longer emit the `offset-assert`, `method-count-assert`, `size-assert` and `flag-assert` parameters. There are extremely few cases where having this in the decompiled code is helpful, as the types there come from `all-types` which already has those parameters. This also doesn't break type consistency because: - the asserts aren't compared. - the first step of the test uses `all-types`, which has the asserts, which will throw an error if they're bad. - the decompiler won't emit the `heap-base` parameter unless necessary now. - the decompiler will try its hardest to turn a fixed-offset field into an `overlay-at` field. It falls back to the old offset if all else fails. - `overlay-at` now supports field "dereferencing" to specify the offset that's within a field that's a structure, e.g.: ```lisp (deftype foobar (structure) ((vec vector :inline) (flags int32 :overlay-at (-> vec w)) ) ) ``` in this structure, the offset of `flags` will be 12 because that is the final offset of `vec`'s `w` field within this structure. - **removed ID from all method declarations.** IDs are only ever automatically assigned now. Fixes #3068. - added an `:overlay` parameter to method declarations, in order to declare a new method that goes on top of a previously-defined method. Syntax is `:overlay <method-name>`. Please do not ever use this. - added `state-methods` list parameter. This lets you quickly specify a list of states to be put in the method table. Same syntax as the `states` list parameter. The decompiler will try to put as many states in this as it can without messing with the method ID order. Also changes `defmethod` to make the first type definition (before the arguments) optional. The type can now be inferred from the first argument. Fixes #3093. --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-29 23:20:02 -04:00
(defmethod nav-enemy-method-54 ((this ice-cube) (arg0 vector))
(let* ((s4-0 (-> this path curve num-cverts))
(s2-0 (nav-enemy-rnd-int-count s4-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
(s5-0 (new 'stack-no-clear 'vector)))
(dotimes (s3-0 s4-0)
(eval-path-curve-div! (-> this path) s5-0 (the float s2-0) 'interp)
(when (>= (vector-vector-xz-distance s5-0 (-> this collide-info trans)) 32768.0)
(when (ice-cube-method-51 this s5-0 s5-0)
(set! (-> this target-pt quad) (-> s5-0 quad))
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
(return #t)))
(set! s2-0 (mod (+ s2-0 1) s4-0))))
#f)
(defstate ice-cube-mean-turn-to-charge (ice-cube)
:event ice-cube-default-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-time! (-> self state-time))
(logior! (-> self nav-enemy-flags) (nav-enemy-flags navenmf2))
(nav-enemy-method-58 self)
(if (or (not *target*)
(logtest? (-> *target* state-flags)
(state-flags being-attacked invulnerable timed-invulnerable invuln-powerup do-not-notice dying))
(not (nav-enemy-test-point-near-nav-mesh? (-> *target* control shadow-pos))))
(go ice-cube-retract-spikes))
(set! (-> self tracking-player?) #t)
(set! (-> self target-pt quad) (-> (target-pos 0) quad))
(nav-enemy-neck-control-look-at)
(set-vector! (-> self collide-info transv) 0.0 114688.0 0.0 1.0))
:code
(behavior ()
(local-vars (gp-0 symbol))
(ja-channel-push! 1 (seconds 0.075))
(ja-no-eval :group! ice-cube-turn-on-player-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(let ((f30-0 (-> self collide-info transv y)))
(integrate-for-enemy-with-move-to-ground! (-> self collide-info)
(-> self collide-info transv)
(collide-kind background)
32768.0
#f
#f
#f)
(if (< 0.0 f30-0) (set! (-> self collide-info transv y) f30-0)))
(+! (-> self collide-info transv y) (* -544768.0 (seconds-per-frame)))
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
(let* ((v1-26 (>= 0.0 (-> self collide-info transv y)))
(v1-27 (and v1-26 (logtest? (-> self collide-info status) (cshape-moving-flags onsurf)))))
(set! gp-0 (nav-enemy-method-60 self (not v1-27))))
(suspend)
(ja :num! (seek!)))
(loop
(let ((s5-0 (and (>= 0.0 (-> self collide-info transv y)) (logtest? (-> self collide-info status) (cshape-moving-flags onsurf)))))
(set! gp-0 (and s5-0 gp-0))
(if gp-0 (goto cfg-26))
(integrate-for-enemy-with-move-to-ground! (-> self collide-info)
(-> self collide-info transv)
(collide-kind background)
32768.0
#f
#f
#f)
(+! (-> self collide-info transv y) (* -544768.0 (seconds-per-frame)))
(set! gp-0 (nav-enemy-method-60 self (not s5-0))))
(suspend))
(label cfg-26)
(let ((gp-1 (new 'stack-no-clear 'vector)))
(vector<-cspace! gp-1 (joint-node ice-cube-lod0-jg Rball))
(spawn (-> self part4) gp-1)
(vector<-cspace! gp-1 (joint-node ice-cube-lod0-jg Lball))
(spawn (-> self part4) gp-1))
(ja-no-eval :group! ice-cube-turn-on-player-land-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(suspend)
(ja :num! (seek!)))
(go ice-cube-mean-charge))
:post nav-enemy-simple-post)
(defstate ice-cube-mean-charge (ice-cube)
:event ice-cube-default-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-time! (-> self state-time))
(nav-enemy-method-58 self)
(logior! (-> self nav-enemy-flags) (nav-enemy-flags navenmf2))
(set-time! (-> self next-skid-sound-time))
(if (or (not *target*)
(logtest? (-> *target* state-flags)
(state-flags being-attacked invulnerable timed-invulnerable invuln-powerup do-not-notice dying))
(not (nav-enemy-test-point-near-nav-mesh? (-> *target* control shadow-pos))))
(go ice-cube-retract-spikes))
(set! (-> self target-speed) (-> self nav-info run-travel-speed))
(set! (-> self acceleration) (-> self nav-info run-acceleration))
(set! (-> self rotate-speed) (-> self nav-info run-rotate-speed))
(set! (-> self turn-time) (-> self nav-info run-turn-time))
(logclear! (-> self nav flags) (nav-control-flags navcf8))
(set-root-prim-collide-with! (-> self collide-info) (collide-kind cak-2 cak-3 target crate enemy))
(set! (-> self track-target?) #t)
(set! (-> self slow-down?) #f)
(set! (-> self speed) 81920.0)
(set! (-> self prev-charge-angle-diff) 0.0)
(let ((a0-6 (-> self collide-info trans))) (set! (-> self starting-pos quad) (-> a0-6 quad)))
(set! (-> self charge-angle) (quaternion-y-angle (-> self collide-info quat))))
:exit
(behavior ()
(logior! (-> self nav flags) (nav-control-flags navcf8))
(set-root-prim-collide-with! (-> self collide-info) (collide-kind target)))
:trans
(behavior ()
(when (or (not *target*) (logtest? (-> *target* state-flags) (state-flags do-not-notice)))
(cond
((= (-> self speed) 0.0) (go ice-cube-mean-charge-done))
(else (set! (-> self slow-down?) #t) (set! (-> self track-target?) #f) (set! (-> self tracking-player?) #f))))
(if (-> self tracking-player?) (set! (-> self target-pt quad) (-> (target-pos 0) quad)))
(let ((gp-1 (new 'stack-no-clear 'vector))
(s5-0 (new 'stack-no-clear 'vector)))
(vector-! gp-1 (-> self target-pt) (-> self starting-pos))
(vector-! s5-0 (-> self collide-info trans) (-> self starting-pos))
(let ((f30-0 (vector-xz-length gp-1))
(f28-0 (vector-xz-length s5-0)))
(if (< (+ 14336.0 f30-0) f28-0) (set! (-> self slow-down?) #t))
(let ((f0-5 (atan (-> gp-1 x) (-> gp-1 z)))
(gp-2 (-> self nav target-pos)))
(if (< f30-0 (+ 8192.0 f28-0)) (set! (-> self track-target?) #f))
(cond
((-> self track-target?)
(let ((f26-0 (deg-seek-smooth (-> self charge-angle) f0-5 (* 2730.6667 (seconds-per-frame)) 0.25)))
(set! (-> self prev-charge-angle-diff) (deg- f26-0 (-> self charge-angle)))
(set! (-> self charge-angle) f26-0)))
(else
(let ((f0-11 (* 0.99 (-> self prev-charge-angle-diff))))
(set! (-> self prev-charge-angle-diff) f0-11)
(+! (-> self charge-angle) f0-11))))
(set-vector! gp-2 0.0 0.0 (+ 15360.0 (fmax f30-0 f28-0)) 1.0)
(vector-rotate-around-y! gp-2 gp-2 (-> self charge-angle))
(vector+! gp-2 gp-2 (-> self starting-pos))
(nav-control-method-28 (-> self nav) (collide-kind wall-object ground-object))
(nav-control-method-11 (-> self nav) gp-2))))
(set! (-> self nav travel y) 0.0)
(when (-> self slow-down?)
(set! (-> self speed) (seek-with-smooth (-> self speed) 0.0 (* 81920.0 (seconds-per-frame)) 0.8 1638.4))
(if (>= 0.0 (-> self speed)) (go ice-cube-mean-charge-done))
(when (zero? (nav-enemy-rnd-int-count 45))
(let ((gp-3 (new 'stack-no-clear 'vector)))
(vector<-cspace! gp-3 (joint-node ice-cube-lod0-jg Rball))
(spawn (-> self part4) gp-3)
(vector<-cspace! gp-3 (joint-node ice-cube-lod0-jg Lball))
(spawn (-> self part4) gp-3)))
(when (>= (current-time) (-> self next-skid-sound-time))
(set! (-> self next-skid-sound-time) (+ (current-time) (nav-enemy-rnd-int-range 60 120)))
(sound-play "ice-stop" :vol (the float (the int (* 0.0012207031 (-> self speed)))))))
(let ((f30-1 (* (vector-xz-length (-> self nav travel)) (-> *display* frames-per-second))))
(if (< f30-1 13107.2) (go ice-cube-mean-charge-done))
(set! (-> self collide-info transv quad) (-> self nav travel quad))
(if (< (-> self speed) f30-1) (set! f30-1 (-> self speed)))
(set! (-> self anim-blend) (fmin 1.0 (* 0.000016276043 f30-1)))
(vector-normalize! (-> self collide-info transv) f30-1))
(+! (-> self collide-info transv y) -36864.0)
(quaternion-rotate-y-to-vector! (-> self collide-info quat)
(-> self collide-info quat)
(the-as quaternion (-> self collide-info transv))
(* 16384.0 (seconds-per-frame)))
(integrate-for-enemy-with-move-to-ground! (-> self collide-info)
(-> self collide-info transv)
(collide-kind background)
8192.0
#f
#f
#f))
:code
(behavior ()
(ja-channel-push! 1 (seconds 0.2))
(ja :group! ice-cube-invuln-run-ja :num! min)
(until (-> self slow-down?)
(suspend)
(ja :num! (loop!)))
(ja-channel-push! 2 (seconds 0.07))
(ja :group! ice-cube-invuln-stopping-upright-ja :num! min)
(ja :chan 1 :group! ice-cube-invuln-stopping-ja :num! (chan 0) :frame-interp (-> self anim-blend))
(loop
(suspend)
(ja :num! (loop!))
(ja :chan 1 :num! (chan 0) :frame-interp (-> self anim-blend))))
:post nav-enemy-simple-post)
(defstate ice-cube-mean-charge-done (ice-cube)
:event ice-cube-default-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
:code
(behavior ()
(nav-enemy-method-58 self)
(nav-enemy-neck-control-inactive)
(go ice-cube-retract-spikes)))
(defstate ice-cube-retract-spikes (ice-cube)
:event ice-cube-default-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
:code
(behavior ()
(nav-enemy-method-58 self)
(nav-enemy-neck-control-inactive)
(ja-channel-push! 1 (seconds 0.07))
(let ((gp-0 #f))
(ja-no-eval :group! ice-cube-retract-spikes-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(when (and (not gp-0) (>= (ja-aframe-num 0) 3.0))
(set! gp-0 #t)
(nav-enemy-method-57 self))
(suspend)
(ja :num! (seek!))))
(go ice-cube-tired))
:post nav-enemy-simple-post)
(defstate ice-cube-tired (ice-cube)
:event ice-cube-default-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-time! (-> self state-time)))
:trans
(behavior ()
(when (time-elapsed? (-> self state-time) (seconds 2))
(cond
((or (not *target*)
(< (-> self enemy-info idle-distance) (vector-vector-distance (-> self collide-info trans) (-> *target* control trans))))
(go-virtual nav-enemy-idle))
((target-in-range? self (-> self nav-info notice-distance)) (go ice-cube-face-player))
(else (go-virtual nav-enemy-patrol)))))
:code
(behavior ()
(ja-channel-push! 1 (seconds 0.2))
(ja-no-eval :group! ice-cube-head-wipe-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(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-channel-push! 1 (seconds 0.2))
(loop
(ja-no-eval :group! ice-cube-breathing-ja :num! (seek!) :frame-num 0.0)
(until (ja-done? 0)
(suspend)
(ja :num! (seek!)))))
:post nav-enemy-simple-post)
(defstate ice-cube-shatter (ice-cube)
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
:code
(behavior ()
(logclear! (-> self mask) (process-mask actor-pause))
(let ((gp-0 (new 'stack-no-clear 'vector)))
(vector<-cspace! gp-0 (joint-node ice-cube-lod0-jg main))
(spawn (-> self part3) gp-0))
(drop-pickup (-> self enemy-info) #t *entity-pool* (-> self enemy-info) 0)
(clear-collide-with-as (-> self collide-info))
(cleanup-for-death self)
(let ((gp-1 (new 'stack 'joint-exploder-tuning 1)))
(set! (-> gp-1 duration) (seconds 3))
(set! (-> gp-1 gravity) -327680.0)
(set! (-> gp-1 fountain-rand-transv-lo quad) (-> (target-pos 0) quad))
(process-spawn joint-exploder
*ice-cube-break-sg*
2
gp-1
(new 'static
'joint-exploder-static-params
:joints
(new 'static
'boxed-array
:type
joint-exploder-static-joint-params
(new 'static 'joint-exploder-static-joint-params :joint-index 28)
(new 'static 'joint-exploder-static-joint-params :joint-index 23)
(new 'static 'joint-exploder-static-joint-params :joint-index 8)
(new 'static 'joint-exploder-static-joint-params :joint-index 7)
(new 'static 'joint-exploder-static-joint-params :joint-index 26)
(new 'static 'joint-exploder-static-joint-params :joint-index 21)
(new 'static 'joint-exploder-static-joint-params :joint-index 24)
(new 'static 'joint-exploder-static-joint-params :joint-index 29)
(new 'static 'joint-exploder-static-joint-params :joint-index 11)
(new 'static 'joint-exploder-static-joint-params :joint-index 4)
(new 'static 'joint-exploder-static-joint-params :joint-index 6)
(new 'static 'joint-exploder-static-joint-params :joint-index 5)
(new 'static 'joint-exploder-static-joint-params :joint-index 12)
(new 'static 'joint-exploder-static-joint-params :joint-index 13)
(new 'static 'joint-exploder-static-joint-params :joint-index 14)
(new 'static 'joint-exploder-static-joint-params :joint-index 15)
(new 'static 'joint-exploder-static-joint-params :joint-index 16)
(new 'static 'joint-exploder-static-joint-params :joint-index 17)
(new 'static 'joint-exploder-static-joint-params :joint-index 18)
(new 'static 'joint-exploder-static-joint-params :joint-index 19)
(new 'static 'joint-exploder-static-joint-params :joint-index 3)
(new 'static 'joint-exploder-static-joint-params :joint-index 20)))
:to
self))
(sound-play "ice-explode")
(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-channel-set! 0)
(ja-post)
(until (not (-> self child))
(suspend))))