jak-project/goal_src/jak1/levels/sunken/sunken-part2.gc

2459 lines
115 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 "SUN.DGO")
(require "engine/gfx/sprite/sparticle/sparticle-h.gc")
(require "engine/gfx/texture/texture-h.gc")
(require "engine/gfx/sprite/sparticle/sparticle-launcher-h.gc")
2020-09-04 14:44:23 -04:00
;; DECOMP BEGINS
(defpartgroup group-sunken-window-bubbles-34
:id 353
:bounds (static-bspherem 0 4 0 32)
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 1495
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1495
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1496 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1496
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 7.0000005) (degrees 50.000004))))
(defpart 1495
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 7.0000005) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-36
:id 354
:bounds (static-bspherem 0 4 0 32)
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 1497
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1497
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1498 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1498
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 160) (degrees 50.000004))))
(defpart 1497
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 160) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-30
:id 355
:bounds (static-bspherem 0 4 0 30)
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 1499
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1499
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1500 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1500
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees -20) (degrees 50.000004))))
(defpart 1499
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees -20) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-31
:id 356
:bounds (static-bspherem 0 4 0 32)
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 1501
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1501
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1502 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1502
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees -120) (degrees 50.000004))))
(defpart 1501
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees -120) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-29
:id 357
:bounds (static-bspherem 0 4 0 32)
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 1503
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1503
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1504 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1504
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 160) (degrees 50.000004))))
(defpart 1503
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 160) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-159
:id 358
:bounds (static-bspherem 0 4 0 32)
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 1505
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1505
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1506 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1506
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 60) (degrees 50.000004))))
(defpart 1505
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 60) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-161
:id 359
:bounds (static-bspherem 0 4 0 32)
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 1507
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1507
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1508 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1508
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 70) (degrees 50.000004))))
(defpart 1507
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 70) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-204
:id 360
:bounds (static-bspherem 0 4 0 32)
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 1509
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1509
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1510 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1510
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters 8) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 30) (degrees 50.000004))))
(defpart 1509
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters 8) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 30) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-205
:id 361
:bounds (static-bspherem 0 4 0 32)
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 1511
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1511
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1512 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1512
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters 0) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 130) (degrees 50.000004))))
(defpart 1511
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters 0) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 130) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-203
:id 362
:bounds (static-bspherem 0 4 0 32)
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 1513
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1513
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1514 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1514
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -10) (meters 20))
(:y (meters -2))
(:z (meters 0) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 80) (degrees 50.000004))))
(defpart 1513
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -10) (meters 20))
(:y (meters -2))
(:z (meters 0) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 80) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-42
:id 363
:bounds (static-bspherem 0 4 0 32)
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 1515
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1515
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1516 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1516
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -25) (meters 50))
(:y (meters -2))
(:z (meters 4) (meters 4))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 195))))
(defpart 1515
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -25) (meters 50))
(:y (meters -2))
(:z (meters 4) (meters 4))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 195))))
(defpartgroup group-sunken-window-bubbles-41
:id 364
:bounds (static-bspherem 0 4 0 32)
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 1517
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1517
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1518 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1518
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters 0) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees -70) (degrees 50.000004))))
(defpart 1517
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters 0) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees -70) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-206
:id 365
:bounds (static-bspherem 0 4 0 32)
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 1519
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1519
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1520 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1520
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters 0) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 170) (degrees 30))))
(defpart 1519
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters 0) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 170) (degrees 30))))
(defpartgroup group-sunken-window-bubbles-201
:id 366
:bounds (static-bspherem 0 4 0 32)
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 1521
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1521
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1522 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1522
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters 2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees -40) (degrees 50.000004))))
(defpart 1521
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters 2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees -40) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-3
:id 367
:bounds (static-bspherem 0 4 0 32)
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 1523
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1523
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1524 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1524
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters 2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 160) (degrees 50.000004))))
(defpart 1523
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -15) (meters 30))
(:y (meters -2))
(:z (meters 2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 160) (degrees 50.000004))))
(defpartgroup group-sunken-window-bubbles-2
:id 368
:bounds (static-bspherem 0 4 0 32)
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 1525
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1525
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1526 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1526
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 #x9 :page #x2))
(:num 0.1)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters 4) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 249.99998) (degrees 50.000004))))
(defpart 1525
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters 4) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.015))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 249.99998) (degrees 50.000004))))
(defpartgroup group-sunken-heatpipe-382
:id 369
:bounds (static-bspherem 0 1 0 3.5)
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 1528 :fade-after (meters 80) :falloff-to (meters 80) :binding 1527)
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1527 :flags (bit1 start-dead launch-asap))
(sp-item 1529 :fade-after (meters 64) :falloff-to (meters 64))))
(defpart 1528
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 #x3 :page #x2))
(:num 1.0)
(:x (meters -1.4))
(:y (meters 0))
(:scale-x (meters 0.5))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 32.0)
(:timer (seconds 0.5))
(:flags (bit2 bit3))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) 4 (meters 0.7))
(:rotate-y (degrees 50.000004))))
(defpart 1527
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 5.0)
(:x (meters 6.2222223))
(:y (meters 4))
(:z (meters 0.6))
(:scale-x (meters 1))
(:scale-y :copy scale-x)
(:r 128.0)
(:g 128.0)
(:a 0.0)
(:omega 0.0 65536.0)
(:vel-x (meters -0.0044444446) 1 (meters 0.008888889))
(:vel-y (meters 0))
(:vel-z (meters 0))
(:fade-a 1.28)
(:timer (seconds 0.5))
(:flags (bit2 bit3 bit7))
(:next-time (seconds 0.085) (seconds 0.08))
(:next-launcher 1422)))
(defpart 1529
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
((:num 0.2)
(:x (meters -1.4))
(:y (meters 0))
(:rot-x 6)
(:r 3276.8)
(:g 2457.6)
(:b 2867.2)
(:fade-g 1.3653333)
(:accel-y (meters 0.0002))
(:friction 0.99)
(:timer (seconds 1))
(:flags (bit2 bit3 aux-list))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) (meters 2.8))
(:rotate-y (degrees 50.000004))))
(defpartgroup group-sunken-heatpipe-381
:id 370
:bounds (static-bspherem 0 1 0 3.5)
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 1531 :fade-after (meters 80) :falloff-to (meters 80) :binding 1530)
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1530 :flags (bit1 start-dead launch-asap))
(sp-item 1532 :fade-after (meters 64) :falloff-to (meters 64))))
(defpart 1531
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 #x3 :page #x2))
(:num 1.0)
(:x (meters -1.4))
(:y (meters 0))
(:scale-x (meters 0.5))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 32.0)
(:timer (seconds 0.5))
(:flags (bit2 bit3))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) 4 (meters 0.7))
(:rotate-y (degrees 80))))
(defpart 1530
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 5.0)
(:x (meters 7.5555553))
(:y (meters 4))
(:z (meters 0.6))
(:scale-x (meters 1))
(:scale-y :copy scale-x)
(:r 128.0)
(:g 128.0)
(:a 0.0)
(:omega 0.0 65536.0)
(:vel-x (meters -0.0044444446) 1 (meters 0.008888889))
(:vel-y (meters 0))
(:vel-z (meters 0))
(:fade-a 1.28)
(:timer (seconds 0.5))
(:flags (bit2 bit3 bit7))
(:next-time (seconds 0.085) (seconds 0.08))
(:next-launcher 1422)))
(defpart 1532
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
((:num 0.2)
(:x (meters -1.4))
(:y (meters 0))
(:rot-x 6)
(:r 3276.8)
(:g 2457.6)
(:b 2867.2)
(:fade-g 1.3653333)
(:accel-y (meters 0.0002))
(:friction 0.99)
(:timer (seconds 1))
(:flags (bit2 bit3 aux-list))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) (meters 2.8))
(:rotate-y (degrees 80))))
(defpartgroup group-sunken-heatpipe-380
:id 371
:bounds (static-bspherem 0 1 0 3.5)
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 1534 :fade-after (meters 80) :falloff-to (meters 80) :binding 1533)
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1533 :flags (bit1 start-dead launch-asap))
(sp-item 1535 :fade-after (meters 64) :falloff-to (meters 64))))
(defpart 1534
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 #x3 :page #x2))
(:num 1.0)
(:x (meters -1.4))
(:y (meters 0))
(:scale-x (meters 0.5))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 32.0)
(:timer (seconds 0.5))
(:flags (bit2 bit3))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) 4 (meters 0.7))
(:rotate-y (degrees 47.5))))
(defpart 1533
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 5.0)
(:x (meters 6.2222223))
(:y (meters 4))
(:z (meters 0.6))
(:scale-x (meters 1))
(:scale-y :copy scale-x)
(:r 128.0)
(:g 128.0)
(:a 0.0)
(:omega 0.0 65536.0)
(:vel-x (meters -0.0044444446) 1 (meters 0.008888889))
(:vel-y (meters 0))
(:vel-z (meters 0))
(:fade-a 1.28)
(:timer (seconds 0.5))
(:flags (bit2 bit3 bit7))
(:next-time (seconds 0.085) (seconds 0.08))
(:next-launcher 1422)))
(defpart 1535
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
((:num 0.2)
(:x (meters -1.4))
(:y (meters 0))
(:rot-x 6)
(:r 3276.8)
(:g 2457.6)
(:b 2867.2)
(:fade-g 1.3653333)
(:accel-y (meters 0.0002))
(:friction 0.99)
(:timer (seconds 1))
(:flags (bit2 bit3 aux-list))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) (meters 2.8))
(:rotate-y (degrees 47.5))))
(defpartgroup group-sunken-heatpipe-379
:id 372
:bounds (static-bspherem 0 1 0 3.5)
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 1537 :fade-after (meters 80) :falloff-to (meters 80) :binding 1536)
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1536 :flags (bit1 start-dead launch-asap))
(sp-item 1538 :fade-after (meters 64) :falloff-to (meters 64))))
(defpart 1537
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 #x3 :page #x2))
(:num 1.0)
(:x (meters -1.4))
(:y (meters 0))
(:scale-x (meters 0.5))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 32.0)
(:timer (seconds 0.5))
(:flags (bit2 bit3))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) 4 (meters 0.7))
(:rotate-y (degrees 70))))
(defpart 1536
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 5.0)
(:x (meters 7.111111))
(:y (meters 4))
(:z (meters 0.6))
(:scale-x (meters 1))
(:scale-y :copy scale-x)
(:r 128.0)
(:g 128.0)
(:a 0.0)
(:omega 0.0 65536.0)
(:vel-x (meters -0.0044444446) 1 (meters 0.008888889))
(:vel-y (meters 0))
(:vel-z (meters 0))
(:fade-a 1.28)
(:timer (seconds 0.5))
(:flags (bit2 bit3 bit7))
(:next-time (seconds 0.085) (seconds 0.08))
(:next-launcher 1422)))
(defpart 1538
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
((:num 0.2)
(:x (meters -1.4))
(:y (meters 0))
(:rot-x 6)
(:r 3276.8)
(:g 2457.6)
(:b 2867.2)
(:fade-g 1.3653333)
(:accel-y (meters 0.0002))
(:friction 0.99)
(:timer (seconds 1))
(:flags (bit2 bit3 aux-list))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) (meters 2.8))
(:rotate-y (degrees 70))))
(defpartgroup group-sunken-heatpipe-378
:id 373
:bounds (static-bspherem 0 1 0 3.5)
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 1540 :fade-after (meters 80) :falloff-to (meters 80) :binding 1539)
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1539 :flags (bit1 start-dead launch-asap))
(sp-item 1541 :fade-after (meters 64) :falloff-to (meters 64))))
(defpart 1540
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 #x3 :page #x2))
(:num 1.0)
(:x (meters -1.4))
(:y (meters 0))
(:scale-x (meters 0.5))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 32.0)
(:timer (seconds 0.5))
(:flags (bit2 bit3))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) 4 (meters 0.7))
(:rotate-y (degrees 23.000002))))
(defpart 1539
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 5.0)
(:x (meters 5.111111))
(:y (meters 4))
(:z (meters 0.6))
(:scale-x (meters 1))
(:scale-y :copy scale-x)
(:r 128.0)
(:g 128.0)
(:a 0.0)
(:omega 0.0 65536.0)
(:vel-x (meters -0.0044444446) 1 (meters 0.008888889))
(:vel-y (meters 0))
(:vel-z (meters 0))
(:fade-a 1.28)
(:timer (seconds 0.5))
(:flags (bit2 bit3 bit7))
(:next-time (seconds 0.085) (seconds 0.08))
(:next-launcher 1422)))
(defpart 1541
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
((:num 0.2)
(:x (meters -1.4))
(:y (meters 0))
(:rot-x 6)
(:r 3276.8)
(:g 2457.6)
(:b 2867.2)
(:fade-g 1.3653333)
(:accel-y (meters 0.0002))
(:friction 0.99)
(:timer (seconds 1))
(:flags (bit2 bit3 aux-list))
(:conerot-x (degrees 90))
(:conerot-y (degrees 90))
(:conerot-radius (meters 0) (meters 2.8))
(:rotate-y (degrees 23.000002))))
(defpartgroup group-sunken-window-bubbles-402
:id 374
:bounds (static-bspherem 0 4 0 32)
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 1542
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1542
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1543 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1543
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 #x9 :page #x2))
(:num 0.06)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 190) (degrees 40))))
(defpart 1542
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.0016666667))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 190) (degrees 40))))
(defpartgroup group-sunken-window-bubbles-401
:id 375
:bounds (static-bspherem 0 4 0 32)
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 1544
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1544
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1545 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1545
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 #x9 :page #x2))
(:num 0.06)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 105) (degrees 40))))
(defpart 1544
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.0016666667))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 105) (degrees 40))))
(defpartgroup group-sunken-window-bubbles-400
:id 376
:bounds (static-bspherem 0 4 0 32)
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 1546
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1546
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1547 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1547
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 #x9 :page #x2))
(:num 0.06)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 20) (degrees 40))))
(defpart 1546
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.0016666667))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 20) (degrees 40))))
(defpartgroup group-sunken-window-bubbles-399
:id 377
:bounds (static-bspherem 0 4 0 32)
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 1548
:fade-after (meters 100)
:falloff-to (meters 100)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1548
:fade-after (meters 160)
:falloff-to (meters 160)
:period (seconds 2)
:length (seconds 0.017)
:binding 1423)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1423 :flags (bit1 start-dead launch-asap) :binding 1424)
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1424 :fade-after (meters 100) :falloff-to (meters 100) :flags (bit1 start-dead))
(sp-item 1549 :fade-after (meters 100) :falloff-to (meters 100))))
(defpart 1549
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 #x9 :page #x2))
(:num 0.06)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3) (meters 0.15))
(:scale-y (meters 0.2) (meters 0.1))
(:r 255.0)
(:g 255.0)
(:b 255.0)
(:a 0.0)
(:vel-y (meters 0.005) (meters 0.0033333334))
(:fade-a 0.16)
(:timer (seconds 16))
(:flags (bit2 bit3))
(:next-time (seconds 0.33) (seconds 0.657))
(:next-launcher 1429)
(:rotate-y (degrees 225) (degrees 40))))
(defpart 1548
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 #x9 :page #x2))
(:num 1.0)
(:x (meters -20) (meters 40))
(:y (meters -2))
(:z (meters -2) (meters 10))
(:scale-x (meters 0.3))
(:scale-y :copy scale-x)
(:r 0.0)
(:a 128.0)
(:vel-y (meters 0.005) (meters 0.0016666667))
(:timer (seconds 16))
(:flags (bit2 bit3))
(:rotate-y (degrees 225) (degrees 40))))