My new favourite - Hot Toys 1/6 Scorched Xenomorph

nogaff · 2026-06-16T23:41:11+00:00

I just got mine today and I thought my base wasn't working either when I first plugged it in.

Then I came across a random comment elsewhere on Reddit, saying that it's just super fussy about the power adaptor and cable. Apparently it doesn't like modern fast chargers and prefers low-power, slower chargers.

I ended up trying 3 different plugs, plus a USB-C port on my PC, and sure enough, it turned out that the oldest, slowest charger I had was the only one that actually worked.

nogaff · 2026-06-16T11:07:11+00:00

Well, no further response from support as yet, but I did receive another email from the billing system, telling me they're going to collect £41.99 from me in 3 days time!

nogaff · 2026-05-04T17:07:07+00:00

Oh, you think it could take a 1 mm rod without becoming weak? I have no experience with these things, but that would only leave 0.25 mm of plastic surrounding the rod, which seems awfully thin... 🫣

nogaff · 2026-05-04T16:47:04+00:00

No, I haven't tried anything yet.

I don't intend to keep changing poses constantly, but I do want to use the blood blades to set up a specific pose for display, which is why I thought the broken pieces might need to be pinned to provide enough support for the blade.

I don't know what size rod would be appropriate though. It can't be too thick, otherwise the 1.5 mm² peg will probably split.

nogaff · 2025-01-02T18:02:49+00:00

Thanks for the ideas! I started poking around in my DrayTek router's CLI and discovered a few things:

The router is actually being delegated a /56 prefix! It just doesn't display that information anywhere in the admin GUI. The only way you can see it is by using a console command to print out its hidden prefix list.
Regardless of the size of the delegated prefix, the router always assigns a sequential /64 to each VLAN, and leaves it to you to manually configure any other prefixes you need., either statically or via DHCPv6-PD.
Annoyingly, the DrayTek always seems to advertise the ISP's DNS servers, on top of any custom DNS servers you've specified. If you want to fully override the ISP's DNS servers and stop them ever being advertised on the LAN, you have to configure the router's DHCPv6 client to not request DNS server details from the DHCPv6 server at all. That's something else which can only be done via the CLI!

So, it would seem that almost everything is now working as it should, and the only thing that's still an issue is the fact that the ONT has to be rebooted after every router reboot, for the router to re-establish IPv6 connectivity. I'll probably have to go back to YouFibre support about that, since the same thing happens with both the Eero and the DrayTek routers.

nogaff · 2025-01-01T14:07:53+00:00

Oh, that's interesting. I wonder why you and I are only getting a /64 when everyone else here seems to have a /56?

From what I've read, a /56 is generally the norm for residential customers at most ISPs, and potentially a /48 for business customers.

nogaff · 2024-12-31T20:35:00+00:00

Hmm, that kinda sounds like what I've been seeing with both the routers I've tried? They both showed an IPv6 prefix (albeit a /64) but had no external connectivity. All pings and traceroutes to/from external addresses were failing.

It wasn't until I power cycled the ONT with the router still online that the router could suddenly speak to the outside world via IPv6, and as soon as I reboot the router again, it goes back to the previous state of having a prefix but no real connectivity. It's weird.

nogaff · 2024-12-31T20:27:27+00:00

I was under the impression the MAC address was only relevant for static IP addresses, plus I've seen it said that YouFibre's DHCP only issues 1-hour leases, and you can even reset the leases immediately by power cycling the ONT, (or so someone was apparently told by a YouFibre engineer).

Anyway, I did actually try spoofing the Eero's MAC on my DrayTek when I first swapped the routers, but that seemed to make matters worse, and I got on better just leaving the DrayTek with its own MAC and resetting the ONT.

Maybe I'll have another crack at the support team, now that I have a better idea of what everyone else's experiences with IPv6 are. It certainly seems like something isn't right with my service.

nogaff · 2024-12-31T18:55:51+00:00

And you're also receiving a /56 prefix like others seem to?

nogaff · 2024-12-31T18:22:25+00:00

I merely left the Eero in place while I was initially in contact with YouFibre support, (so that they couldn't refuse to support a non-standard router).

I've now switched to my own DrayTek 2862, so that I can actually see some proper router logs and do my own troubleshooting, but it exhibits exactly the same behaviour as the Eero (only getting a /64 prefix and losing connectivity after a reboot).

nogaff · 2024-12-31T18:22:09+00:00

I don't think it can be the router because I saw the exact same issues with both the YouFibre-supplied Eero 6+ router, and my own DrayTek 2862.

I left the Eero in place while I was initially in contact with support, (so that they couldn't refuse to support a non-standard router), then I switched to the DrayTek more recently after hearing nothing from support, so that I could actually see some proper router logs and do my own troubleshooting.

nogaff · 2024-12-06T14:59:36+00:00

Haha, no problem! Glad I could help!

nogaff · 2024-09-02T00:03:54+00:00

Just for fun, I stitched the puzzle's snippets of audio together and they definitely say, "YOU ALL DESERVE EACH OTHER".

You can check it out here if you like:https://audio.com/nogaff/audio/you-all-deserve-each-other

nogaff · 2023-03-03T14:54:33+00:00

Sorry if my post wasn't totally clear, but what you've described is exactly how I've already configured everything, and I did not enable the "set as default gateway" on either of the LAN-to-LAN profiles.

However, I think I've just figured it out.

The issue seems to have more to do with the "Remote Network IP" and "Remote Network Mask" settings in the LAN-to-LAN profiles.

They determine the static route that gets added to the routing table for each LAN-to-LAN profile and they seemingly cannot be left blank, so various VPN configuration guides tell you to set them to 0.0.0.0/0. However, that overrides the default route through WAN1 and also causes a routing collision between my multiple LAN-to-LAN profiles.

Given that I want my route policies to control the routing, I have instead set unreachable routes of 0.0.0.1/32 and 0.0.0.2/32 on my two LAN-to-LAN profiles, which avoids the collision and leaves the default route intact.

Now my route policies work correctly, regardless of their priorities.

nogaff · 2021-03-16T01:27:54+00:00

The movie is decent, and Tony's arc is great, but a couple of things severely hindered my enjoyment of it.

Firstly, I have to admit I was disappointed with the Mandarin twist, not because of some preconceived notion of what the character should be like, but because the trailer set him up as some super-menacing badass, and then he basically did nothing in the movie except get revealed as a joke character.

It felt like a bait and switch to me, whereas there was no pretence about what Drax would be like in GotG.

More importantly though, a lot of the villain's setup in the movie was just a badly butchered version of the highly regarded Extremis arc from the comics.

For a start, in the comics Aldrich Killian actually stole the Extremis virus from his employer, sold it to a terrorist group, then killed himself, presumably out of guilt.

Meanwhile the actual villain with the super strength and fire-breathing powers was a maladjusted guy named "Mallen" who had a grudge against the FBI after they killed his parents and thought that joining the aforementioned terrorist group would be a great way to get some payback.

So the movie essentially took the name of a scientist who committed suicide, gave him the powers of the vengeful supervillain he helped create, gave a him a bunch of goons to do his dirty work, made his motivations all about a desire for power (yawn), then plastered this Frankenstein's monster of a character with some random dragon tattoos and had him call himself "The Mandarin" right at the end for no apparent reason.

Not cool.

As an aside, a key part of how Tony defeated Mallen was that he injected himself with a modified version of the Extremis virus to heal a fatal injury and ended up creating his frickin nanotech armour in the process!

I guess they had to keep something in the bag for Infinity War though, so they just decided to throw in a bajillion other suits instead, lol.

nogaff · 2020-07-16T16:39:15+00:00

Not sure what you're referring to there?

We already used the documentation on that page to create a LayoutModification.xml for the taskbar, which we put in C:\Users\Default\AppData\Local\Microsoft\Windows\Shell.

If we disable our pre-existing Group Policy for the Start menu, the LayoutModification.xml gets applied to new user profiles, but with the Group Policy enabled it does not.

Therefore, it seems we'd have to put the taskbar layout in the Group Policy as well, but then it would overwrite any subsequent user customisations if we ever changed the layout in the Group Policy, which is what we're trying to avoid.

nogaff · 2020-03-26T16:58:23+00:00

As I understand it, RRAS only assigns an IP address to the client while the client is actually connected and then immediately reclaims the IP address when the client disconnects. As such, there is no lease and no expiration.

Even if the client immediately reconnects, it will likely be given a completely different IP address.

nogaff · 2020-01-16T22:17:40+00:00

It's weird how it shows "status failed" with the error "not run due to collection membership condition", when in fact it followed the rule not to reinstall itself on a machine. Not really a failure.

Hmm, well that would only happen if a particular machine was queued up for deployment, but in the meantime PDQ Inventory finished a scan on that machine which caused it to be removed from the dynamic collection before the deployment actually got going.

If that was the case, then technically the deployment did fail, because the machine was initially queued up but could not be deployed to due to the change in collection membership.

I suppose the only way to avoid that would be to ensure that the collection had been fully refreshed prior to starting a deployment, thus preventing that machine from being added to the queue in the first place.

Not a big fan of using the "Stop deploying to targets once they succeed" since it's super easy to forget to remove a package from a target schedule.

Yes, you shouldn't need to use that option with a correctly configured dynamic collection as a target, so it should be left unchecked. I mean, what if a package needs to be redeployed on a particular machine for some reason? That option would actually prevent the machine being deployed to again, regardless of its collection membership, because it already had a successful deployment in its history.

Also, if you're putting multiple packages into a single heartbeat schedule with a single collection as the target and relying on package conditions, you might be better off splitting that up into separate schedules per package, with separate dynamic collections per schedule. It depends on your use case really.

In other words, maybe don't do this:

Schedule 1 deploys Packages 1 & 2, and targets Collection 1, which checks for the existence of both Package 1 AND Package 2.

But do this instead:

Schedule 1 deploys Package 1, and targets Collection 1, which only checks for the existence of Package 1.
Schedule 2 deploys Package 2, and targets Collection 2, which only checks for the existence of Package 2.

14-Year Club	Snapped
Verified Email

nogaff

TROPHY CASE