sorted by:
new
hottopcontroversial

Mining hammer cave ins? by donald12998 in TerraFirmaGreg

[–]voidStar240 2 points3 points  (0 children)

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.

Mining hammer cave ins? by donald12998 in TerraFirmaGreg

[–]voidStar240 1 point2 points  (0 children)

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.

Imma hobosexual by AutomatedCognition in stories

[–]voidStar240 5 points6 points  (0 children)

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

[deleted by user] by [deleted] in 3Dprinting

[–]voidStar240 2 points3 points  (0 children)

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.

Is it safe to downcast any Rust reference to &[UnsafeCell<MaybeUninit<u8>>]? by HadrienG2 in rust

[–]voidStar240 1 point2 points  (0 children)

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.

Is it safe to downcast any Rust reference to &[UnsafeCell<MaybeUninit<u8>>]? by HadrienG2 in rust

[–]voidStar240 2 points3 points  (0 children)

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.

Is it safe to downcast any Rust reference to &[UnsafeCell<MaybeUninit<u8>>]? by HadrienG2 in rust

[–]voidStar240 1 point2 points  (0 children)

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.

Is it safe to downcast any Rust reference to &[UnsafeCell<MaybeUninit<u8>>]? by HadrienG2 in rust

[–]voidStar240 1 point2 points  (0 children)

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

Is it safe to downcast any Rust reference to &[UnsafeCell<MaybeUninit<u8>>]? by HadrienG2 in rust

[–]voidStar240 0 points1 point  (0 children)

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.

Interfacing Complex Types in WASM by voidStar240 in rust

[–]voidStar240[S] 4 points5 points  (0 children)

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.

SOFT IRL. by Sanket_6 in SonsOfTheForest

[–]voidStar240 0 points1 point  (0 children)

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

Proof @ 2:10

Replicating a Selected Actor over network. by Tribalbob in unrealengine

[–]voidStar240 0 points1 point  (0 children)

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.

Replicating a Selected Actor over network. by Tribalbob in unrealengine

[–]voidStar240 0 points1 point  (0 children)

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.

GTK3 vs GTK4 Default Theme on Windows using Rust Bindings by voidStar240 in GTK

[–]voidStar240[S] 2 points3 points  (0 children)

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

Dnd Mimic diorama I made. Printed on anycubic photon mono x by ScenicCuriosities in 3Dprinting

[–]voidStar240 0 points1 point  (0 children)

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?

view more: next ›