Add bhvDefaultStarMarker and related objects to replace hardcoded star spawn coordinates #830
Conversation
…r spawn coordinates spawn_default_star and cur_obj_spawn_star_at_y_offset no longer take coordinates. If no star marker object is found, the star spawn will fall back to the object's home coordinates.
|
Will forcefully merge if this is not reviewed before the end of the week. |
| OBJECT_WITH_ACTS(/*model*/ MODEL_NONE, /*pos*/ -1100, -2372, 1100, /*angle*/ 0, 135, 0, /*behParam*/ 0x01000000, /*beh*/ bhvMerryGoRoundBooManager, /*acts*/ ACT_2 | ACT_3 | ACT_4 | ACT_5 | ACT_6), | ||
| OBJECT_WITH_ACTS(/*model*/ MODEL_BOO, /*pos*/ 1030, 1922, 2546, /*angle*/ 0, -90, 0, /*behParam*/ 0x04000000, /*beh*/ bhvBalconyBigBoo, /*acts*/ ALL_ACTS), | ||
| OBJECT_WITH_ACTS(/*model*/ MODEL_BOO, /*pos*/ 581, 1850, -206, /*angle*/ 0, -90, 0, /*behParam*/ 0x00000000, /*beh*/ bhvBoo, /*acts*/ ALL_ACTS), | ||
| OBJECT_WITH_ACTS(/*model*/ MODEL_BOO, /*pos*/ 1000, 50, 1000, /*angle*/ 0, 0, 0, /*behParam*/ 0x00000000, /*beh*/ bhvGhostHuntBigBoo, /*acts*/ ACT_1), |
There was a problem hiding this comment.
Why are these formatting changes needed?
There was a problem hiding this comment.
Less ugly I guess, though this section also introduces star markers so it makes no real difference in terms of conflicts.
| void spawn_default_star(void) { | ||
| f32 dist; | ||
| struct Object *starObj; | ||
| struct Object *starMarker = cur_obj_find_nearest_object_with_behavior_and_bparams(bhvDefaultStarMarker, |
There was a problem hiding this comment.
This is regression compared to vanilla logic where I could specify arbitrary location for a star to spawn. Now if I have multiple spawners, closest will be chosen.
There was a problem hiding this comment.
This would only be a problem if you have multiple spawners for the same star ID. Otherwise you'd only be able to have one spawner per area (which would be a problem for obvious reasons).
You can always make a new function for this if you have a use case of overriding the spawn marker, but in general hardcoding star coords is worse in almost every other way.
There was a problem hiding this comment.
If developer has to change code, this PR does nothing good. If you want to go this way, introduce a enum for bparam2 to search for the object based on that bparam2 instead of nearest object.
There was a problem hiding this comment.
The exact idea here is that they don't. Having to hardcode coordinates for stars means people can't handle that through fast64 alone, and forgetting to change those coords will result in broken spawns almost every time.
All the developer needs to do is add a star marker object via fast64 to set the spawn location, with a matching bparam1. If no star marker is found, it falls back to the object's home as a safeguard (which is still an improvement over hardcoding).
Comparing against bparam2 as an additional identifier isn't a good option here because that bparam2 is inhereted from the parent object (which could be set to anything). In my opinion though the need for this is an edge case that vanilla doesn't do natively anywhere either. If it's really necessary to keep a hardcoded spawn function in HackerSM64, that too can be added to this PR.
spawn_default_starandcur_obj_spawn_star_at_y_offsetnow look for the nearestbhvDefaultStarMarkerobject with a matching bparam1, rather than using hardcoded coordinates. If no star marker object is found, the star spawn will fall back to the object's home coordinates.This PR is the sequel to #829.