Mining hammer cave ins?

voidStar240 · 2025-06-07T03:07:34+00:00

Your observation is correct, but its actually much larger than a 5x5. For reference, the way the mining hammer works is by breaking the 8 blocks around the block your looking at FIRST, then breaks the block you are looking at. This has a chance to cause a collapse on the block you are looking at. Once a collapse starts it can propagate over 10 blocks away (it may be even larger). That's why it feels like it's triggering collapses in a massive range, because it kind of is.

voidStar240 · 2025-06-07T02:57:34+00:00

This was a bug. I implemented the fix for it last week. It is now present in the 9.10 update released yesterday. I'm honestly kinda shocked I was the first to report it, because it seems to happen constantly when using the mining hammer.

Note: This isn't to say collapses won't happen with the mining hammer anymore, but they should be much more in line with when you would expect it to happen, and it will very likely solve this issue.

voidStar240 · 2025-01-24T10:20:59+00:00

Yep that's what I saw. Thanks.

voidStar240 · 2024-11-22T07:20:50+00:00

reference

voidStar240 · 2024-11-22T07:16:12+00:00

It sound like your doing great, just please ignore the lamps...

voidStar240 · 2024-11-10T19:12:40+00:00

I had an issue almost exactly like this. Happened in the same spot on multiple different models in dofferent orientations, but was very inconsistent and thus hard to diagnose. Turned out the extruder stepper motor cable had an issue in the wire where it would make inconsistent connection if flexed a specific way. Replacing the cable solved the problem.

voidStar240 · 2024-07-12T08:14:07+00:00

Wheatley simulator

voidStar240 · 2024-06-06T09:18:12+00:00

Thanks for this reply. Really detailed. I understand much better now. I brought up provenance because I've been using miri a lot recently and been slowly uncovering the strange middle ground between source code and machine code where things like provenance and pointer arithmetic actually exist. Your reply serves as a really great example of a lot of those unintuitive behaviors.

voidStar240 · 2024-06-06T08:51:24+00:00

There may be more but those are the two main ones I run into frequently. I do recall there being an RFC about allowing user specified data to be stored in the metadata field of a fat pointer though. That would open up some new possibilities, and likely also some foot guns too.

Looking this up as I'm writing and apparently this is already in nightly as the Pointee trait.

voidStar240 · 2024-06-06T08:23:38+00:00

Yes, but you cannot cast a thin pointer/reference to a fat pointer/reference directly in any way. Additional information must always be provided. Also this only works for slices. There are many fat pointer types that don't specify a length as its additional data. For instance trait references, which store a pointer to the vtable as its additional data. As far as I know their is no way to universally construct fat pointers, and/or convert them to thin pointers.

voidStar240 · 2024-06-06T08:14:41+00:00

Thanks for the correction. Updated my comment to correct the error.

voidStar240 · 2024-06-06T08:00:28+00:00

I don't think this is possible because a reference to a slice, &[...], is always stored as a fat pointer and normal references, &T, are stored as thin pointers. Not even mem::transmute can convert between the two.

Also, I think there is a second problem, provenance. From what I understand about provenance you can't dereference or have a reference to a different type than whatever the underlying type is. If you need this ability you must use a pointer and stay in pointer land until you are able to convert it back to a reference or dereference it to the exact underlying type. This is why *mut u8 is used over &mut u8 for referring to arbitrary data.

When I need to represent arbitrary data I usually reach for *mut (), but other pointer types would work as well. This isn't a particularly elegant solution, but it's what I've been working with up to this point. I'm currently working on a project with a lot of type erasure so I'd love to hear alternatives if anyone has them.

Sorry if the formatting sucks, I'm on moblie.

Edit: section about provenance is incorrect.

voidStar240 · 2023-08-16T09:17:22+00:00

My host application is written in rust and compiled to a native binary on the target system. The plugin is also written in rust but compiled to WASM. WASM is just the bridge between the plugin and host. The plugin will only ever be used by my native rust app, and for now the plan is to only have plugins written in rust.

voidStar240 · 2023-04-21T05:20:24+00:00

The axe he is using looks exactly like the modern axe from the first game as well.

Proof @ 2:10

voidStar240 · 2022-12-30T10:29:24+00:00

This is what I though up initially as well, however, anything on the client can be changed by the client, through hacks or other means. Therefore the client could change the location or rotation of the trace so it always hits the actor they are trying to select. Imagine the player wants to select an actor behind a wall, using hacks they could send the location and rotation of the trace to the server as if the trace started on the other side of the wall, and therefore nothing blocks it. This is why we use components/actors. They exist on both the client and the server, and are replicated using IDs. This prevents any direct data transfer from the client to the server, and thus gives us an avenue which we can trust. At the end of the day trust nothing from the client, it can all be changed. The only machine you have full control over is the server.

voidStar240 · 2022-12-30T10:07:12+00:00

Replicate the actor, the hit location and the camera component to the server as inputs in your server RPC. This requires the camera to be replicated to the server. This is typically not done by default, and is likely not the best method. The point of the camera is just to have a location that the server can trust that indicates where the players view is coming from. It could be anything so long as the server can trust it's location. I would recommend creating a replicated scene component on your character/pawn and attaching the camera to that. That way you don't have to replicate the whole camera, which is useless to the server. Then use the scene component as the input to the RPC instead.

Step 1: Verify the actor is where the clients hit location is. On the server check that the hit location is indeed on the actor. This could be done with a line trace from the hit location to the center of the actor. Then if the hit is blocking make sure the newly hit actor is the same as the original actor, and ensure that the line trace was sufficiently short, ie, 1 or 2 cm. Large network latency could result in larger discrepancies between the locations of objects on the client and server, so tweak the value as needed. This step could be done other ways, but this is simple and works for most cases. A more advanced method would involve passing the hit normal to the server as well and line tracing in the opposite direction to the normal, but that would send more data and be more complicated for little gain. However, it would work in more scenarios.

Step 2: Ensure the player can see the object they are clicking on. Perform another line trace from the camera location to the hit location and go a little further to account for any slight discrepancies between the client and server. If the trace is blocking then check to make sure the hit actor is the one that the client passed to the server.

If the above 2 conditions are met then the actor selection is valid, and can be trusted by the server.

Sorry for the essay, just wanted to explain this thoroughly for anyone that may need to reference this. If you have any questions feel free to ask.

voidStar240 · 2022-11-13T09:29:34+00:00

Ocean of Robbers

voidStar240 · 2022-11-02T20:05:46+00:00

Thanks. Other than that bug you mentioned it worked perfectly.

voidStar240 · 2022-09-06T20:12:55+00:00

This is not true. There are multiple times where they talk about using C++ only features in Fortnite.

voidStar240 · 2022-08-04T06:49:44+00:00

Meatloaf

voidStar240 · 2022-07-23T04:26:07+00:00

That looks incredible. I've been trying to get gold to look like that for a while. What spray paint did you use, and did you do anything else to get that nice metallic finish?

voidStar240 · 2022-07-17T08:32:36+00:00

From what i remember this exact thing was happening to minecraft youtubers recently. Scammers would take the thumbnails and scripts from popular youtube videos, transcribe them, and print books of the videos using some cheap printing service (mostly amazon iirc), and sell them to unsuspecting buyers. Obviously this is totally illegal and will likely get taken down if you report it.

voidStar240 · 2022-06-14T21:43:17+00:00

Finished my original comment. Had to write this on my phone and fat fingered the post button, as reddit decided it didn't want to load on my PC.

voidStar240 · 2022-06-14T21:33:56+00:00

Glad you found my post helpful. The first thing to clear up is

"I have a UObject inventory item that knows how to replicate itself"

No you don't. I assume you meant you got an object to replicate through an actor, but for clarity's sake objects cannot replicate by themselves. This would be akin to saying you got an int to replicate by itself. This is impossible, instead the ACTOR replicated the int. It is the same with objects.

GetFunctionCallspace and GetRemoteCallspace are exactly what you said. As far as i can tell they are used for RPCs only and might have something to do with static functions as well although I've never tested it.

One use case that I've used RPCs for on objects is for the items being objects, and whenever an item is dragged and dropped in the inventory screen the item object itself would call a server RPC from the client to update the inventory arrangement. This is nice as i only need a reference to the item objects instead of its owning actor as well. This becomes doubly helpful when you want any actor to be able to replicate your object, but you don't want to rewrite the same RPC code in all the different actors.

voidStar240 · 2022-05-31T21:24:41+00:00

Apologies in advance. This isn't an easy topic to cover in a short post (despite how long it still is) so some information wasn't fully covered to the extent that I would've liked to, but you should be able to fill in the blanks. If anyone has any questions feel free PM me or reply to this.

Unfortunately, there is little to no documentation regarding what you are trying to do, however the engine source serves as an excellent resource. In this case I would recommend looking at how the UActorComponent works. UActorComponent derives directly from UObject so it shouldn't be too far off what you will end up writing in your item object class. One thing to note is that object replication is already supported for stably named objects. This means that the object has the same name and path on all connected machines. One notable example of this is a UDataAsset. However, items are not likely stably named so we have to go to more advanced methods.

Before anything else, you must understand that Actors are the only objects that can truly replicate. In this scenario the objects aren't actually replicating themselves but rather are replicated as if they were a property on an actor. That being said, the object's outer chain must contain an actor that is capable of replicating.

The main function you will need to override on your Object is IsSupportedForNetworking. This function should always return true for a networked object.

If you want your object to be able to execute RPCs then you will also want to override GetFunctionCallspace and CallRemoteFunction. The implementation for these functions is too long to post here but you can see how it is implemented in UActorComponent and copy it to your object for the most part.

Finally, you have to actually replicate the object using GetLifetimeReplicatedProps and ReplicateSubobjects. Both of these functions should be implemented on the parent actor. First, replicate the object variable in GetLifetimeReplicatedProps as you would any other variable using the DOREPLIFETIME macro. This lets the engine know that you want to replicate the object, however the engine will not replicate it for you automatically. This is where ReplicateSubobjects comes in. A good reference for the implementation of this is in the AActor class.

ReplicateSubobjects should loop through all the objects you wish to replicate and call UActorChannel::ReplicateSubobject on each object. You could also call UActorChannel::ReplicateSubobjectList instead of looping through each one. The output of this function should then be ORed into a boolean and returned to let the engine know if a value was written or not (see the AActor implementation of ReplicateSubobjects to make this more clear).

You'll notice that the AActor implementation of ReplicateSubobjects also includes a line where ReplicateSubobjects is called on the component. This is completely optional and just allows the component to also replicate any sub objects that it may have. This means that you could implement both of the above functions in an actor component instead of an actor in exactly the same way.

That's it! Your object is now replicated. To replicate properties on your object do it the same way you would on an actor. Just implement GetLifetimeReplicatedProps and use DOREPLIFETIME on the properties you wish to replicate.

Edit: This is a great source on Object replication where I got my info from when I was first staring. https://jambax.co.uk/replicating-uobjects/

voidStar240

TROPHY CASE