Some files might not respond to `ml`

[Zedb0T]

I still need to test/verify that this occurs on vanilla but for some reason on the Mod base, when I ML the vehicle-racer.gc, then resest actors or even select new game, I do not observe the changes but the ml seems to report that it had worked/doesnt error.

I then tested the ml on a different file with the same changes and was able to observe the changes instantly. I even loaded a different mission that uses the method to ensure I had a "clean" process and nothing stale and still did not see the change.

At the moment the cause of this is unknown so if anyone experiences it with other files, please specify what files/changes below

https://github.com/open-goal/jak-project/assets/89345505/d5266850-d1a7-4365-9deb-74d3a13a77a8

[ManDude]

When you change the method of a type, it is not propagated to child types. This is normal behavior for methods.

[xTVaser]

Ah right, that does make sense. This would be resolved by having a proper dependency tree so an ml knows what additional files should be rebuilt. A reminder for me to pick that work back up.

[water111]

Wait I think method-set! should actually update the child method types for children that inherit the method. It goes and scans every single type in the symbol table and should update the method of children that inherit it.

I'm not sure why this works and I can take a look tomorrow.

I don't think a dependency tree would actually help since the definition of a child type shouldn't depend on the implementation of a method in the parent. (which is why the original game's method-set! has this crazy check of all types)

[xTVaser]

My thought is if you had a situation like:

TypeA with MethodA defined in FileA
TypeB that doesn't override MethodA in FileB

It sounds like (and my experience also lines up) that if you are debugging TypeB and modify something in methods/states defined in the parent FileA -- when you (ml "FileA") nothing updates.

However, if you knew to automatically (ml "FileB") when you (ml "FileA") that would "solve" the issue. Source-code wise there is a dependence since the child type depends on the parent type.

Though, if it's possible to avoid that, that would be even better.

[water111]

I agree with the dependency you said, but I think there's an issue if TypeA and MethodA are defined in different files. If you modify TypeA's file (rigid-body-h.gc), then FileB should rebuild and be reloaded. But if you modify MethodA's file (rigid-body.gc), then then FileB shouldn't be reloaded.

(this is just my best guess for how goal should work, just based on how their code is organized and how the linker works. if you had TypeB depend on MethodA then you'd have circular references of files)