Basic garage functionality in script #120
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -129,6 +130,53 @@ DebugState::DebugState(RWGame* game, const glm::vec3& vp, const glm::quat& vd) | |||
| m->addEntry(Menu::lambda("Cull Here", [=] { | |||
| game->getRenderer()->setCullOverride(true, _debugCam); | |||
| }, entryHeight)); | |||
| m->addEntry(Menu::lambda("Unsolid garage doors", [=] { | |||
|
|
|||
| std::vector<std::string> garageDoorModels { | |||
There was a problem hiding this comment.
you could probably use const static std::array of const char* here to avoid doing memory allocations/for a bit more performance (if it matters)
There was a problem hiding this comment.
It's only a debug feature (called only if you choose to do so) and std::array doesn't support initializing from an unknown number of elements afaik?
The compiler will most certainly optimize everything of that away anyway.
There was a problem hiding this comment.
Not sure if it can figure out N or not - if its debug then I guess its moot point either way :)
|
Looks good to me. +1. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've confirmed that the game handles garages using indices from 0 to $garageCount-1 (value returned from
create_garage).In my savegames, there is one additional garage in slot 0 which is probably created (or controlled) by the crusher crane from opcode 02FB (The gtamodding wiki article [2nd of june '16] doesn't say that a garage is created; I think this is the major difference to opcode 01EE ).
It's quite possible that 02FB only controls the crusher garage or that the garage is hardcoded to element 0 anyway. However, my implementation (02FB creating the crusher garage) should work fine with the standard mission script from GTA3 which only contains 1 crusher anyway.
As garages + global variables (which hold garage handles / indices) are both part of the savegame this shouldn't be able to break anything either.
If there are any problems in the future we can still change it.
Besides crusher crane garage creation this also adds 2 opcodes to check if a specific car is in a garage and another one to check if any car is inside a garage (presumably). These functions only check if the car hits the bounding box of the garage to be considered "inside garage" - consider it a stub.
Another opcode stub (to only open garages for a certain car) was added because we'll need it in LUIGI2 soon anyway and it was mission garage related.
(As a hack) the garages can be "opened" by a debug menu function as we don't have generic code for handling garages (and their doors) yet. Also the rules for opening garages and finding garage doors are not really known yet (to us).
@spaceeinstein seems to know more about this but I think some reverse engineering still has to be done to get them right.
I think the opcodes could be named better + they are pretty hacky.
However, this is enough to stub them for now.
I added '@todo's and we should probably verify the behaviour in the future.
We'll also need seperate code / class for the garages in the future as requested per #107 .
I'll try to get more details about that before implementing that (sometime in the future) though.
I consider this PR ready for merge