Stardew Valley has two random number seeds. One is the normal character seed. The other, your multiplayer ID, can be determined by analyzing the save file.
Except! On the Switch, you can't easily access the save file AND the random number generator is different than on PC. There is a seed cracker that looks at your traveling cart listing and calculates the character seed. Maybe because it's less important and harder to observe, I haven't found any tool to crack the other seed and don't have time to attempt writing it myself.
By inspecting cracked geode contents, you should be able to isolate your multiplayer ID and then predict random events on Nintendo just as PC players have done for the last decade with access to the save file.
The C# code for the game is online and the Switch RNG is known, so you never have to work in the dark. It's three steps: ensure your Switch RNG implementation works by testing against the normal seed, ensure your geode RNG implementation works by testing against the PC RNG, and then apply the Switch RNG to the geode function enough times that only one seed could create your observed sequence.
-----
Two semi-related open questions: Are you able to solve as quickly while starting at ANY geode as you'd be solving from the first geode? Does the RNG eventually repeat, so it actually doesn't matter what your multiplayer ID is as long as you observe a unique sequence, since there will only be one continuation of that sequence?
My favorite is the Doom random number generator, which is just a list of “random” numbers that it cycles through and if you know how to use it, you can do things like concentrate BFG attacks.
> (It's then filtered through the list, so the list needs to have good pseudorandomness properties anyway, but still.)
Not sure? Suppose your list only had two number 0 and 1, and you build your random numbers one bit at a time.
Or more realistically, you have 256 numbers on the list 0, 1, 2, ..., 255 in order. If the 'large numbers of players drawing from the same list' assumption holds, it doesn't matter much that the list is in order.
What's just a bit weird is why anyone would want to turn an embarrassingly parallel problem into something with a sequential bottleneck?
> Or more realistically, you have 256 numbers on the list 0, 1, 2, ..., 255 in order. If the 'large numbers of players drawing from the same list' assumption holds, it doesn't matter much that the list is in order.
Why not? That should convert your random number generation into draws from a Poisson process. If you were looking to simulate a Poisson distribution, you're set. If not, you probably just ruined your RNG.
(If the idea is that the interval between any two samples is so large that the list will inevitably be cycled several times before any one person can sample a second byte, there's something to that. It's going to make asking for random numbers more than 8 bits long challenging though.)
Reminds me of a "Dice" electronics kit I assembled when I was a kid. It just used some standard sequential counter ICs run at very high rate. Pressing the "roll" button would just stop the counter!
Current-gen X1 Carbons are sold with 400 or 500 nit IPS displays. I have complaints with nearly every other aspect of the ThinkPad---even the universally praised keyboard---but the display has been stellar.
Lenovo and Linux support should carry an asterisk. Hopefully their acquisition of Phoenix fixes much of the "too quick to market" problems they seem to keep having.
My ThinkPad Z13 (aka AMD Carbon) was a piece of garbage: arrived without Fedora fully installed, crashed at least once per week, had GPU and dock and USB and sleep problems, sent back for repairs multiple times. I tried to return it after the multiple failed repairs and they refused. My greatest joy was that insurance covered it being stolen from my apartment in Dublin.
My X1 Carbon Gen 11? Not great. Crashed 7 times in the 9 days I had it. Didn't sleep properly. Ibus and wireplumber would randomly crash. I'd get a glib error if I type an invalid Bash command. I tried Fedora 38 and Kinoite, Ubuntu 22, Debian 12, RHEL 9.2, TUXEDO, Pop, and Tumbleweed. Nobody had the right mix. Red Hat didn't even make it through the installer. Debian overheated rather than suspended when you close the lid. I learned about and trialed all sorts of kernel flags: intel_idle.max_cstate, iommu=pt, Intel_iommu=on, Intel_iommu=pt, usbcore.autosuspend=-1, i915.enable_dc=0, i915.enable_psr=0, acpi.ec_no_wakeup=1, thinkpad_acpi.fan_control=1, acpi_osi, and a few others. Sometimes the 10-second power button shutdown was ignored; you have to use the little reset hole.
I can't even fully blame Lenovo. Their Linux lead puts in a ton of effort to do everything right. BIOS seems to be a major weak point. I'll read BIOS release notes for the laptops I hated, and they'll have a list with e.g. "fixed fingerprint reader problem, fixed hanging after hibernation, fixed hanging after resuming with lid closed, wake now works with any keyboard key instead of just F-keys, fixed issue where computer restarts unexpectedly, fixed overheating while charging, fixed problems related to docking and external monitors, fix sound, fix backlight, fix power profiles, fix slow boot, fixed USB port refusing to charge or enumerate (rarely (yes they actually said rarely in the release notes, this problem affected at least me)), improve lid behavior, fix touchpad ACPI, fix sleep from power button, trackpoint doesn't work if lid closed with suspend disabled (fixed), touchpad stops functioning after restart (fixed), system hangs during Modern Standby (fixed, we hope?), bunch of CVEs, camera shouldn't suck anymore, updated copyright year" This is less than half of the changes and was paraphrased from the actual Z13 release notes.
I mean... G. F-ing D. With so many EC/BIOS problems on nearly every peripheral, I'm baffled that this got released in the first place.
Also, if you're going to sell Linux laptops, at least have Linux support at the service center. On multiple occasions, I got a call, "we ran a Windows USB image, we didn't find any suspend problem."
My X1 Carbon Gen 12? Acceptable. Gets hot easily. Every now and then (twice a month) just stalls, sometimes I can unplug and close the lid and come back later and the OOM killer will finally do its job. I'd put 90 percent of the blame on KDE Plasma and Fedora. I almost blame myself for having too much stuff open at once, but then I recall that "having a lot of work open" generally can be done on older laptops, well-built desktops, and Windows machines.
My X1 Carbon Gen 13? Did not NOT have problems until Ubuntu 26.04. Screen would glitch green, some hardware was unsupported---in particular, wireless---had suspend problems, overly long boot, one CPU would always run at max (gnome-shell at 100% of CPU 0, whole machine at 13%). The biggest problem was learning that full-disk encryption and secure boot don't play nicely with installing the HWE kernel (which I would've needed for the unsupported hardware), requiring a full backup and reinstall while I was trying to start a new project during my probationary period at work. I need Ubuntu for work, and my colleagues were already annoyed that they couldn't find a Legion 5 with ANSI keyboard from a German vendor so that we would all have a common platform. Unfortunately, Rust coreutils and GNOME are still buggy in 26.04 and it affects my workflow, but at least the hardware (finally) works.
Partner's P-series? No problems so far. Coworkers' Legions? no complaints from them. Old-ass X301? Works fine. T480? Nice machine.
Lenovo itself has horrible dark patterns on their website (defaulting to 3-year premium warranty in the EU despite this being an optional upgrade and restoring this default every time you modify the device config from the checkout cart, market-specific pricing and customizations despite all units originating from the same factory such that Linux from another country was a better deal than "No OS" from my own country, basing price decisions on how long you view specific pages). The fact that the website has many glaring bugs (including in the feedback forms to report bugs) is not a great look for a computing company.
My dream machine was the XPS 9370 Developer. Dell went the wrong way for me with the bathroom shower tile keyboard and mostly OLED screens and no more explicit Linux support. If anyone can capture that lightning in a bottle again, I'll buy four.
> same USB C charger that came with your phone
Yeah, you'll need that phone charger for your Lenovo, because the latest few generations of Lenovo chargers break in a way that they'll only charge in one orientation for a while, and then they eventually break completely. Luckily, they do this quickly, so you can replace them under warranty for as long as you're willing to tolerate the issue.
-----
I choose Lenovo because every other PC laptop (plus quite a few Macs) is/are worse, but I can't call ThinkPads "good"
It's been a while since I've used Twitter, but I thought the tweet ordering was never chronological. Has this changed? You just have to trust that the algorithm will always surface relevant information to the top of the feed?
I recently layed out and ordered a single-sided two-layer board with only a minimum config STM32 + crystal, two USB ports with ESD protection, and two LEDs (one is always-on). I went for commodity SMD parts and it still costs 20 USD per unit to produce and ship from China. Even that PCB doesn't work right now.
[Sorry, dear reader. This post turned into a rubber duck session at your expense.]
The main peripheral and reason for the PCB is a USB MIDI device with a bit of custom sysex. Modifying an Adafruit was out of the question; the MIDI peripheral powers itself and the microcontroller/host, and the other USB peripheral. (Basically always, the host shall provide power. This USB connector, however, was designed for a proprietary, discontinued, expensive accessory.) I chose STM32 over 8051 or AVR or RP2040 because it's the cheapest dual-USB chip stocked by LCSC with good vendor tool support. I'm writing my own code because there's no ST middleware for MIDI.
The second LED should blink until both devices are plugged in and then remain steady, on. In testing, the LED visibly changes its timing after the second USB attach but doesn't stay on (rather, it blinks at a shorter and shorter period until simply shutting off, at which point the MIDI communication stops; the timing of the shutoff is not consistent) and the USB input events only register 40% of the time until the MIDI shutdown.
The LED is misconfigured intentionally; it's open drain and GPIO while I try to fix the MIDI nonsense. Later, I'll change it to push-pull on TIM2 to support PWM brightness (e.g. to monitor audio levels when not in text entry mode). Changing GPIO to PWM is its own minor pain because the USER CODE lines in the ST USB code are separate from the USB_Init/USB_RegisterClass/USB_Start sequence, so I have to reinsert my MIDI class every time I change something in CubeMX even if I don't change the USB configuration. (The USER CODE sections persist so that you can change the chip configuration and keep your code.)
Open-drain could explain weird LED behavior but not the communication shutoff. The MCU and LDO don't get noticeably warm, so I doubt it's an overcurrent situation.
I suspect D+/D- could be at the wrong level. As most STM32s, the microcontroller runs at 3.3 rather than 5 volts. (I would've loved an atmega32u4 for its 8-bit simplicity and native 5V operation but then the PCB will be double the cost and size as I'd need a pair of MCUs talking to each other with each one having a single USB port or else an off-chip USB host IC etc.) Sure, I can use a cheap multimeter to test the USB data lines, but this tells me the average level and not if the waveform is being clipped on the positive side (which is usually only a problem under 3 volts). Even if it's an electrical issue, an oscilloscope will reveal the cause but still won't provide a solution. It'll be up to me to cobble together more circuitry.
More probable is at least one code mistake, like a stack overflow or buffer overrun or peripheral misconfiguration/failure. I'm registering any expected USB class on both ports: HID and CDC and MIDI. The whole idea of the board is converting arbitrary USB input (PC keyboard, MIDI controller, joystick, etc.) into specific MIDI messages at standard USB data rates e.g. 12 Mbit/s at both ports with a fairly large buffer. The main MIDI device (supplying the power) will drop the connection after a few seconds of inactivity. I'm using an ST-Link V3 MINIE to step through, which is the cheapest I'd go on a debugger. Luckily I added SWO to my debug port and can still get useful debug info without stopping the processor. I also have to snip the power line of an OTG USB cable if I want the second USB peripheral to be a PC, which is a nifty hack you usually don't learn in the one month PCB design crash course.
I have zero visibility into what the commercial USB MIDI device expects (bus speed, signal characteristics) from the discontinued accessory and only knew its connection handshake from a random, otherwise-inactive Github user's single commit.
In any case, the USB algorithms I wrote work when the host is a PC and the code is ported to Python.
I could reroute pins to ADC and roll my own built-in oscilloscope (it's QFP and not BGA chosen specifically that I can solder in a hotfix, because I've done board design before and know it NEVER, EVER, NOT ONCE EVER goes right on the first attempt) but I'd rather spend time with my kids than a choose-your-own-adventure debug hackathon in my disorganized home office, although I did fall into the IDE trap. Every few years, IDEs and toolchains and build systems change, and this project was no different. Rather than STM32CubeIDE, I took a few hours to teach myself to use the STM32Cube Core and marus25 Cortex-Debug extensions in VS Code, as that seems to be the current trend at ST, and I do favor a vendor-agnostic, Eclipse-free workflow.
If this were my first project and I had to buy all of the tools for debugging, it would probably cost 200 euros or more even if I only buy cheap knockoffs. The other commenter suggesting a $10 logic analyzer?? I mean... I do own one of those, but it's barely tee-ball compared to the major leagues of Lauterbach or Rohde & Schwarz or even Saleae.
In any case, I fear I'll need a new revision with its two-week turnaround or at least a manual rewire of this design. It's frustrating... such a simple design, and I've already sunk over 100 euros and at least 10 hours into it and have a bug with odd symptoms. And, as a PCB design tradition, I'll be humbled and humiliated when I discover it's something like a missing switch case or a wrong clock setting or otherwise relatively basic mistake.
I'm not the first to state: There's a reason it's not called easyware.
PCB debugging is honestly one of the most intense experiences I've had in my life (and I don't even have a boss looking over my shoulder). It requires intense physical and mental concentration. You're dealing with a hypothesis space that includes both software and hardware faults, and you're also having to make delicate manipulations of a physical object.
At the very least, you can (and probably should) put a plaintext netlist and BOM into an LLM to triple-check your work.
It will use the part datasheets and decent EE logic to cross reference pins and parts and polarities and generally check that SMD caps and resistors have realistic specifications for their footprint, switching regulators and communication ICs are configured correctly (e.g. when you have resistor settings for an ethernet PHY indicating 100Base-T and RMII, you also won't need TX/RX 2 and 3 and two clocks and a COL net, which it would check), all nets are named and linked correctly, buses have the correct and consistent termination, and so on.
I still believe Amazon is uniquely qualified to dominate and capitalize in this "mass data gathering" space. They have trucks, packing material, and streamlined logistics. They have a ton of robots that are mobile and/or warehouse-task-optimized. They store and work with data on a massive scale. They sell a ton of products leveraging the statistical analysis of customers and suppliers. What other company has this mix?
Amazon should move families.
In the beginning, do it for free or at a reduced cost.
The catch is that they are then allowed to take a full, detailed record of every single item in the home plus a complete data capture of the moving procedure and then use all this data without restriction. (Thus, this scheme would not work in Europe without a great deal of additional thought and lawyering.)
I admit: I know neither how they model amazon.com customers nor the accuracy of their existing customer model. Regardless of how it already works, a handful of complete data points inserted into their model should help sell more products overall.
Suppose Amazon learns that 100 percent of cat owners have a Petmate carrier yet none of those were bought via Amazon. Or that 60 percent of Eames chair owners and 2 percent of non-owners have bidets. Most people would buy one but not the other at the exact same time and place, right? You'd target the chair purchaser with well-placed bidet ads and likely sell a few more of those.
Maybe Amazon can find these fine-grained customer details out via other channels, but nothing will beat self-gathered ground truth data, especially if it's a byproduct of some other service being offered. And sure, the examples are extreme, but---as with stock market arbitrage---any differences found from the existing model (and there SHOULD be many) should be exploitable.
Each moving job can be accepted/rejected/scheduled based on availability (plus whatever they assess as risks), so Amazon makes sure robotics/logistics capital isn't sitting around unused while also not hurting itself by needing to order a new fleet on a business gamble.
A ton of training data for robots is harvested, which can be used and sold.
There's probably a side-hustle with offering moving insurance, and having a video capture of the entire moving process for motion training would also ensure there's very little speculation of events after a damage claim is filed. This puts real monetary numbers into the training cost function, which should speed up improvements in on-the-fly vision-based value appraisal, price-aware object packing, choice of handling algorithm, etc. which are weird little subdomains but all worthy of advancement.
In the end, if Amazon finds it can relocate people more efficiently than existing firms after a few years in operation (mindful that human labor is expensive and eventually replaceable; plus small companies will never have Amazon's economies of scale) raise prices to somewhere less expensive than the competition while also profitable, and capture the entire rational home moving market.
(I also have no idea if this is actually a good idea and what the costs/profits of each factor of this business should be---more amazon.com sales via better ad targeting, the inventory data itself, the robot data, the relocation, the insurance---but my gut says they have the capital to lightly pivot and outmaneuver competitors until they become profitable.)
Mere mention of "reverse engineering" gets me kicked back to Opus.
Where I reside, reverse engineering for interoperability is generally legal, and interoperability (e.g. getting a USB HID and USB MIDI devices or DOS programs to work in Linux/Android) is essentially what I'm interested in.
My "find" is almost always
head, of course, being optionalThe tradeoff is needing to learn regex, which is not any easier to learn than find arguments.
reply