rezecib
-
Posts
3902 -
Joined
-
Last visited
.png.fb917063f57cc4964ee8d50b4e96d993.thumb.png.ab9751fc00fa4a6e86df695303ef2250.png)
Recent Profile Visitors
42668 profile views
-
Actions do have a strfn that you can define. However to do this for an existing action you will have to monkeypatch the existing action's strfn. This doesn't really relate to the componentaction part of this (which is just about deciding whether an action can be shown to be performed). And yes there is action priority, also on the action definition side rather than the componentaction side. Look at scripts/actions.lua for usage. Only two actions can be displayed, but the logic is a bit complicated. You can look at the component PlayerActionPicker:DoGetMouseActions for details. -
In the middle of the component PlayerController:OnUpdate, there's a check: if self.handler ~= nil and self.inst:HasTag("usingmagiciantool") then self:CancelPlacement() self:CancelDeployPlacement() self:CancelAOETargeting() end However, below this, there's a check to see if the player has an item on their cursor, which then starts placement mode: local placer_item = controller_mode and self:GetCursorInventoryObject() or self.inst.replica.inventory:GetActiveItem() --show deploy placer if self.deploy_mode and self.placer == nil and placer_item ~= nil and placer_item.replica.inventoryitem ~= nil and placer_item.replica.inventoryitem:IsDeployable(self.inst) then local placer_name = placer_item.replica.inventoryitem:GetDeployPlacerName() local placer_skin = placer_item.AnimState:GetSkinBuild() --hack that relies on the build name to match the linked skinname if placer_skin == "" then placer_skin = nil end if self.deployplacer ~= nil and (self.deployplacer.prefab ~= placer_name or self.deployplacer.skinname ~= placer_skin) then self:CancelDeployPlacement() end if self.deployplacer == nil then self.deployplacer = SpawnPrefab(placer_name, placer_skin, nil, self.inst.userid ) if self.deployplacer ~= nil then self.deployplacer.components.placer:SetBuilder(self.inst, nil, placer_item) self.deployplacer.components.placer.testfn = function(pt) local mouseover = TheInput:GetWorldEntityUnderMouse() return placer_item:IsValid() and placer_item.replica.inventoryitem ~= nil and placer_item.replica.inventoryitem:CanDeploy(pt, mouseover, self.inst, self.deployplacer.Transform:GetRotation()), (mouseover ~= nil and not mouseover:HasTag("walkableplatform") and not mouseover:HasTag("walkableperipheral") and not mouseover:HasTag("ignoremouseover")) or TheInput:GetHUDEntityUnderMouse() ~= nil end self.deployplacer.components.placer:OnUpdate(0) --so that our position is accurate on the first frame end end else self:CancelDeployPlacement() end In the case of deploy-placement, this means that on every frame placement is cancelled and restarted immediately on the same frame. It seems that the intent here was to not allow placement, but placement is actually functional despite this, somehow. Rather than thrashing on creating and destroying the placer, maybe this should just allow placement? Or the placer creation block should check the same condition to avoid thrashing. This is particularly problematic with the Geometric Placement mod, because creating placers creates a grid, which is more expensive than just destroying and recreating the placer itself.
-
Try using 3.1.1 (it's the last version I published for single-player on steam, and haven't gotten other crash reports, so it's possible I broke something in the DST-focused updates since then) -
Expected behavior: When paused, mousing over the UI or invalid ground tiles hides the pitchfork tile indicator (matching behavior when unpaused) Observed behavior: When paused, mousing over the UI or invalid ground tiles keeps the pitchfork tile indicator and it won't disappear until unpaused I believe this is due to PlayerController:OnWallUpdate missing the section of PlayerController:OnUpdate that handles action selection and updating placers. (this came to my attention due to a crash with Geometric Placement, caused by inadventently sharing some global state that came into conflict when multiple grids are shown simultaneously)
-
Translation (just Google translate): For what it's worth, I get about 6 comments a day about this specific issue between the two mods of mine that I've updated since the mod uploader was switched to the v2 workshop API. I've been suggesting deleting the mod folder, verifying, and reinstalling as workarounds, but it seems that this mostly does not fix the issue. Has anyone found more successful workarounds? Is this something the devs could instrument and monitor to determine the failure cases that result in these stuck downloads? As a mod author I'm at a loss on what I can do to help players who encounter this.
-
I update them at the same time (if anything I forget this one sometimes x_x) -
Sorry, my bad, I forgot to test on a boat. Uploaded a fix for that (and several other bugs) just now.
-
Unfortunately I think only the PC version supports mods.
-
But Combined Status doesn't show the stats of items, maybe you're thinking of Display Food Values or the Crockpot Simulator?
-
@Zeldicon What do you think could be updated in response to Warly and the food changes?
-
Yup, grepping through databundles/scripts is pretty much the way to do it. Printing on dedicated servers (which is how servers with caves work) goes to the server_log, which you can find in Documents/Klei/DoNotStarveTogether, but it takes a little hunting, and there will be one for the surface and one for the caves (they're separate servers). Usually when debugging I keep the log files themselves open in a text editor so I can search them and scroll.
-
@L. Ringmaster Screens are nothing special, they're just like other classes. Global Positions modifies the PlayerStatusScreen in order to add a hide/show location button. In general, modifying a local function somewhere is hard, I do not recommend attempting this (although it's possible with the debug library's upvalues). In this case, however, it's not just a local function, it gets attached to something that you can then access (self.player_widgets.ban.onclick). I'm not 100% sure how to write the code for this without digging deeper, but it looks like you may need to hook into some other function to make sure you catch all playerListing objects when/if they get updated. The Global Positions example I linked shows something similar, hooking into the scroll_list updatefn. At a glance it doesn't look like you need to do that, though.
-
@legends0356 It needs to be extracted from the zip, so that it goes: mods/CombinedStatus/modinfo.lua; if the modinfo isn't visible at a path like mods/somemodname/modinfo, then the game won't see it.
-
I don't maintain the server version so it's up to them to update it
-
@MP98 Let me know if you figure it out, although it may not be something I can solve. It's also possible it's affected by predictive mode (I play with prediction off, and they may have changed the code for it in a way that interferes).
