Issue 547. The minigame put the player a guessed distance from wherever
the pet had wandered to, in the direction of the player, which often
left bricks off screen or the whole minigame over a drop.
In the 2014 live captures the positions are the same for every try at
the same pet: the pet's destination is where it spawned, and the player
is teleported exactly 12 units along the direction the pet spawned
facing, turned to face the pet. This matches the spawner in the level
file for the Pet Ranch cat (spawned facing -43.4 degrees, player placed
at spawn + (-8.24, 8.73) facing 136.6 degrees) and holds for the
doberman, buffalo, triceratops, rabbit and the script spawned panda.
The pet is now put back on that spot and the player placed that way; the
heights come from the navmesh when there is one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Issue 536. A pet that reached a pet switch jumped on it by itself for
free. Now it works like digs, following what live did (2014 captures):
on the way the pet has state 0x500 and the owner gets
PR_BOUNCER_TUTORIAL_01; on the switch the pet has state 0x120 and the
Jump On Object ability, plays "excited" while the switch plays
"engaged", and the owner gets the pet action button
(ShowPetActionButton 2) and PR_BOUNCER_TUTORIAL_03. Using it costs
PetAbilities.ImaginationCost (2), the pet plays "jump", the owner gets
PR_TOOLTIP_1ST_PET_JUMPED_ON_SWITCH and the switch turns its bouncer on.
The switch plays "launch" then, as on live, instead of "engaged".
The pet switch is no longer written into the pet's serialized
interaction (it was never cleared).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Issue 537. A pet that reached a dig dug it up by itself for free. Now,
as on live (2014 captures), the pet goes to the dig with state 0x500 and
the Go To Object ability while the owner gets the PR_DIG_TUTORIAL_01
tooltip; at the dig it waits with state 0x120 and the Dig At Position
ability, and the owner gets the pet action button (ShowPetActionButton
3). Pressing SHIFT or the button makes the client send RequestUse on the
pet (LWOPetControlComponent::msgPetCommand 0x00c5d220, "contextAction");
that costs PetAbilities.ImaginationCost (1 for digging), hides the
button, shows PR_DIG_TUTORIAL_03 and starts the dig. The button goes
away when the pet leaves the dig.
The dig is no longer written into the pet's serialized interaction:
live did not serialize one for digs or pet switches.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Issue 546. The client plays a pet's spawnAnim ("spawn" unless set in
its config) only when the pet is constructed with state 8 (bit 0x80)
set (LWOPetComponent::Deserialize 0x00cd1270). Live summons were
constructed with status 0x84, played the pet's "despawn" effect (the
circles and stars, effect 365) and then dropped the bit; summoned pets
are now constructed that way, with the effect and the state change at
the end of the spawn animation.
Sending a pet back to the backpack killed it right after sending the
despawn effect, so the client removed it before the effect could play.
Live removed the pet some time after the effect; it is now removed once
the pet's despawn animation time has passed, and does nothing in the
meantime.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The NexusDashboard-parity dashboard (dDashboardServer) and everything built on it on the experimental branch:
accounts, characters, properties and moderation tools, permissions shared with in-game slash commands, economy
reports, World 3D and property 3D views with client scenery, scheduled events (features, vanity changes, live
events, announcements, restarts), vanity files and events, the CDClient browser, the message inspector with saved
captures, chat filter tools, community challenges, live ops, the AI moderator helper, and the server-side changes
they need.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Resolves an issue where item is null but is accessed but not doing that code and instead consulting the EntityManager for a valid Entity, alongside nullifying the m_Owner objectID should the pet be destroyed and timer still exist.
Update PetComponent.cpp
Add nullptr check
Add back timer
Update PetComponent.cpp
speculative fix for a different crash
Why are we accessing something before checking if its null
* move the pet minigame table loading logic out of petcomponent
* misc fixes
* actually, using paths is dumb here when they're already char strings. why bother? silly me.
* removed unga bunga reference-casting
* add back in puzzle not found error message
* pre-allocate unordered map and make getter const-correct
* Update dDatabase/CDClientDatabase/CDClientTables/CDTamingBuildPuzzleTable.cpp
Co-authored-by: David Markowitz <39972741+EmosewaMC@users.noreply.github.com>
---------
Co-authored-by: David Markowitz <39972741+EmosewaMC@users.noreply.github.com>
* Assorted pet improvements
* remove unecessary include
* updates to address some feedback
* fixed database code for testing
* messinng around with tables
* updated to address feedback
* fix world hang
* Remove at() in CDLootTableTable.cpp
* Uncapitalize LOT variable
* Uncapitalize LOT variable
* Assorted pet improvements
* remove unecessary include
* updates to address some feedback
* fixed database code for testing
* Removed reference member (for now)
* Removed cmake flag
* Components: Make ComponentType inline
Prevents the next commits ODR violation
* Components: Add new components
* Entity: Add headers
inline script component ComponentType
* Components: Flip constructor argument order
Entity comes first always
* Entity: Add generic AddComponent
Allows for much easier adding of components and is error proof by not allowing the user to add more than 1 of a specific component type to an Entity.
* Entity: Migrate all component constructors
Move all to the new variadic templates AddComponent function to reduce clutter and ways the component map is modified.
The new function makes no assumptions. Component is assumed to not exist and is checked for with operator[]. This will construct a null component which will then be newed if the component didnt exist, or it will just get the current component if it does already exist. No new component will be allocated or constructed if the component already exists and the already existing pointer is returned instead.
* Entity: Add placement new
For the case where the component may already exist, use a placement new to construct the component again, it would be constructed again, but would not need to go through the allocator.
* Entity: Add comments on likely new code
* Tests: Fix tests
* Update Entity.cpp
* Update SGCannon.cpp
* Entity: call destructor when re-constructing
* Update Entity.cpp
Update Entity.cpp
---------
Co-authored-by: Aaron Kimbrell <aronwk.aaron@gmail.com>
* Breakout rest of the enums from dcommonvars
so we don't have to deal with merge conflicts
ePlayerFlags is not a scoped enum, yet, due to it's complexity
* address feedback
* make player flag types consistent
* fix typo
* breakout the component types into a scoped enum
tested that things are the same as they were before
* fix missed rename
* fix brick-by-brick name to be crafting
because that's what it is
