Repository navigation
Conversation
…h MSVC 14.51 VS 18 (MSVC 14.51) rejects `constinit const uint8_t* pBasePtr = reinterpret_cast<const uint8_t*>(&__ImageBase)` with C2127: a reinterpret_cast is not a constant expression, even of an address constant. VS 2022, which CI uses, accepted it. Removing `constinit` keeps the same object code: the initializer is still an ADDR64 relocation to __ImageBase and no dynamic initializer is emitted (verified with dumpbin on the .obj by Codex's review). kpImageEnd keeps its CRT initializer as before. Co-authored-by: Codex <codex@openai.com> Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Object (door/container) replication bindings on the client are now owned by ObjectSystem: one binding per local reference, re-registration updates the existing entity and drops duplicates or stale collisions, and disconnecting clears object bindings while keeping actor entities. The server sends the new NotifyRemoveObjects (kNotifyRemoveObjects, appended before kServerOpcodeMax) to every player before destroying object entities, so clients can drop the bindings instead of keeping dead server ids. Removal uses the full 32-bit EnTT id including generation bits. Adds Catch2 tests for the message encoding and for the binding lifecycle on a real EnTT registry. Imported unchanged from Codex's staged index in C:\Git\TiltedEvolution-codex-objects (build/full-verification/ codex-object-lifecycle.patch, 12 files). Authored by Codex. Co-authored-by: Codex <codex@openai.com> Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Raise logging level and fix logs of quest progression. Previously, multi-execution of quest stage entry was suppressed. But multi quest starts weren't. This is a problem when a quest start has side effects that advance quest stage; as the party members started their quests, the stage-rewind would reflect back to the leader, allowing quest stage side effects to happen again. Also added fix to debugger to force setStage. This is needed so leader can set the stage to the stage they are at, and not have it suppressed so it is sent to party. Regularized quest logging so you can import into a spreadsheet, break fields on colon and comma (:,)
TESQuest::IsStageDone walked `stages` as a GameList<Stage>, but the field is really the pair of (executed stages, waiting stages) list heads. That walk only ever saw the first executed stage, so every other completed stage was reported as "not done" and ScriptSetStage let a reflected or late remote update re-run the fragments of a stage this client had already played (restarting scenes, duplicating quest side effects). Ask Papyrus instead. PR tiltedphoques#848 fixed the same bug with the native TESQuest::IsStageDone; this uses the Papyrus binding so no address-library id is involved. Co-authored-by: Richard Fortier <rfortier@ourchateau.net> Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
A quest normally ends on every client through the synced stage that completes it, so a member's stop event is redundant in the common case. When it isn't, it is because the member's local scripts decided the quest failed (e.g. misjudging the brawl outcome in "Trouble in Whiterun"), and forwarding it stopped the leader's quest and corrupted the party's progress. Keep updating the member's own quest log, but only broadcast stops from the leader unless `Gameplay:bPartyMembersCanStopQuests` is enabled. Doing this on the server (rather than in the client as PR tiltedphoques#846 proposed) keeps member quest progression intact and makes the behaviour a server setting. Co-authored-by: liangchen <141402668+otsffs@users.noreply.github.com> Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Scenes run on every client that has the owning quest at the right stage, so each client already plays the scene's lines locally, including those of actors it doesn't own. Broadcasting the owner's copy made receivers call StopCurrentDialogue() on their own actor mid-scene, ending the dialogue action early, letting their scene phase race ahead of the owner's and sometimes hanging the scene for everyone. Skip DialogueRequest/SubtitleRequest for actors with the scene bool bit set, except when the actor is in dialogue with the local player: those lines are not played anywhere else and still have to be synced. Reduced from PR tiltedphoques#854, which also handles member-to-NPC dialogue and remote line stomping; this keeps only the sender-side scene filter. Co-authored-by: Richard Fortier <rfortier@ourchateau.net> Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Extract cell retirement into ObjectLifecycle so production cleanup can be exercised with an EnTT registry and a synchronous notification callback. Preserve the existing current-cell retention policy and broadcast removals before entity identifiers can be reused. Add the optional TPServerTests target and regression coverage for occupied cells, complete cell identifiers, notification ordering, repeated cleanup, and entity generation bits. Co-authored-by: Codex <codex@openai.com>
Collaborator
|
Look, I see that you're trying to help improve the mod, but you really should've told your agent to not look at any open PRs so that it can work toward its own independent (and unbiased) solution to fix certain issues with questing. Your PR largely bases on #848 and it wouldn't be fair if we merged yours instead How well is this tested? Did you test this yourself in-game? What quests have been tested? I don't mind AI assisted PRs at all (especially when strong models are used), but please start with simpler tasks; you can browse issues or ask the dev team in the discord Join our discord because all collaboration happens there @sfedev |
Contributor
Author
|
Thanks for the feedback. You’re right that I should have coordinated with
the team before submitting overlapping work.
I used AI assistance to put this together, and that process included
reviewing and incorporating work from existing PRs. I should have made the
provenance and overlap clearer before opening mine. I don’t want this PR to
replace the original contributors’ work or take credit away from them.
Regarding testing: the client, server and launcher build successfully, and
the automated tests pass. I personally tested two local clients connecting,
interacting with containers and moving between cells/interiors. *I haven’t
tested the affected quests, quest scenes or full quest progression in-game*,
so I can’t claim that the quest changes are sufficiently validated.
I’m happy to remove the overlapping quest changes and separate the object
lifecycle fixes and their tests into a smaller PR, if that would be useful
to review.
I’ll follow your advice and focus on smaller issues with short,
reproducible tests, and coordinate through Discord before taking on further
quest work. Thanks for clarifying the expectations.
El jue, 10 sept 2026 a las 14:40, Daniil ***@***.***>)
escribió:
… *miredirex* left a comment (tiltedphoques/TiltedEvolution#890)
<#890 (comment)>
Look, I see that you're trying to help improve the mod, but you really
should've told your agent to not look at any open PRs so that it can work
toward its own independent (and unbiased) solution to fix certain issues
with questing. Your PR largely bases on #848
<#848> and it
wouldn't be fair if we merged yours instead
How well is this tested? Did you test this yourself in-game? What quests
have been tested?
I don't mind AI assisted PRs at all (especially when strong models are
used), but please start with simpler tasks; you can browse issues or ask
the dev team in the discord
Join our discord because all collaboration happens there @sfedev
<https://github.com/sfedev>
—
Reply to this email directly, view it on GitHub
<#890?email_source=notifications&email_token=AU2ZUOWHRPE67QEADKVBY235OKOM7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRRHA4DENBRGEY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5618824111>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU2ZUOVO2RJUMI7QSBFTV7D5OKOM7AVCNFSNUABFKJSXA33TNF2G64TZHM2DCMBSG4YDKNJXHNEXG43VMU5TKNBRGE2DANBYHA4KC5QC>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Collaborator
|
@sfedev Yes, object lifecycle fixes should be a separate PR (I'm assuming they are not related to questing whatsoever), so you can start with that in the meanwhile. Make sure to provide a brief description what it solves and what didn't work before. |
Contributor
Author
Contributor
|
For what it's worth, with games, a lot of stuff just isn't practical to unit test, and you must test in game. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Prevent repeated remote quest execution, redundant scene dialogue broadcasts,
and stale door/container bindings during cooperative play.
Changes:
function to avoid re-running completed quest stages.
configurable through Gameplay:bPartyMembersCanStopQuests.
addressed to the local player.
notify all clients before retiring server object entities.
server cell retirement.
Validation:
transitions on the integrated gameplay build.
Compatible client/server builds are required for the new server opcode.
Full story and long-scene testing remain pending. The follower transition
issue is deferred.