I was joking with some friends about doing exactly this. Schuck it down to just the battery and minimal drivetrain, and make a very heavy go-kart.

Seagate’s error rate values (IDs 1, 7, and 195) are busted. Not in that they’re wrong or anything, but that they’re misleading to people who don’t know exactly how to read them.

ALL of those are actually reporting zero errors. This calculator can confirm it for you: https://s.i.wtf/

Edit: As for the first image, I don’t see any attributes in #2 which match with it. It’s possible there is an issue with the drive, but it could also be something to do with the cable. I can’t tell with any confidence.

Edit Edit: I compared the values to my own Seagates and skimmed a manual. While I can’t say for sure what the error reported is in relation to, it is absolutely not to be ignored. If your return period ends very soon, stop here and just return it. If you have plenty of time, you may optionally investigate further to build a stronger case that the drive is a dud. My method is to run a test for bad blocks using this alternative method (https://wiki.archlinux.org/title/Badblocks#Alternatives), but the smart self-test listed would probably also spit errors if there are issues. If either fail, you have absolute proof the drive is a dud to send alongside the refund.

No testing/proof should be required to receive your refund, but if you can prove it’s a dud, you may just stop it from getting repacked and resold.

Reference: https://developer.valvesoftware.com/wiki/Lightmap

Skipping over some details and simplifying this to (hopefully) make it something anyone can reasonably understand: For Source in particular (as other engines may do things differently), maps start out as being fully bright without shadows. Here is an image I stole off a google search showing what that looks like:

When the map is being compiled (or exported or whatever term resonates with you the best), the lights placed within the map as well (and probably sky information too) are used to determine what parts should be covered in shadow and what should be brightly lit. The result is called the lightmap. (The lightmap itself doesn’t have any texture of, say concrete. It only stores data along the lines of “this light brightness here is 50%”). By taking the texture of the surface (concrete, asphalt, stucco) and darkening / lightening it according to the lightmap, you then end up with a lit version of the map which does have shadows.

Now on to the bicubic part: To keep the size of map files down, and reduce the resources required to load it, lightmaps by default render at a resolution of one pixel per (approximately) 40 cm or roughly one pixel per 1.5 ft. This low resolution is perfectly fine since the shadow of a building or highway overpass doesn’t need to be especially detailed beyond just “it’s dark over there”. Where required, the map author can increase the resolution in the spots that require additional detail. However, there is still one problem: When rendering a frame for you to view, the low texture lightmap is “scaled up” to cover the entire surface and you don’t want pixelated shadows. The fast way of handling this is linear scaling, where to find the value of a “scaled up” pixel, you just take the values of the nearest “original pixels” and simply average them (with more weight given toward nearer “original pixels” than farther). While extremely fast, this leads to stair-stepping as shown in the top-left panel:

Bicubic is just a fancier method of finding the value of that “scaled up” value. It’s a slower method than linear, but it resolves the stair-stepping problem.

I love you because one day you walked into my house, wouldn’t leave despite repeatedly being told to, and then I eventually gave up and let you sleep in my bed.