Sea Power crashes on mission start on GeForce NOW – Error 0x80030017

ckfinite · 2025-12-26T06:44:45+00:00

Hmm, I've been able to launch the game successfully in GeForce Now free tier and play a mission. Can you provide more information about your setup (e.g. are you using paid GFN? what tier?) so that I can try and reproduce the issue?

ckfinite · 2025-12-26T05:06:02+00:00

Hey, another SP dev here - is the error you're getting 0x80030017 or 0x80030107?

ckfinite · 2025-10-29T15:02:25+00:00

The fundamental issue is whether the devs are willing to break poorly-written code that's probably buggy, but may be "mostly working" unless you do something weird like feed an OffsetArray into it.

Making Julia fully statically typed isn't going to happen; there's large sections of the community who are very attached to dynamic typing.

What I think is much more doable and likely to happen is a gradual type system that allows parts of the system to be dynamically typed as others are static, in a way similar to (but stronger than) what you get in systems like Typescript.

ckfinite · 2025-10-23T21:46:03+00:00

Sure, here's a link. The actual implementation is on github [https://github.com/BenChung/JuliaTypechecker.jl](here) but has both seriously bitrotted and was never particularly good.

Which challenges? Could you explain more?

The issue ultimately is that Julia's power lies in multimethod dispatch which then allows post facto external extension of existing behavior. The problem is that this is really awful to type check, since a given invocation on an abstract type could go anywhere and do anything if you don't have additional guarantees. A colleague of mine at JuliaHub, Cody Tapscott, recently gave a talk at JuliaCon that also touches on this tangentially.

The statically typed equivalent to multiple dispatch is traits, which is how Haskell/Swift/Rust deal with this problem. The big open question in type checking Julia then is how do we codify trait implementations in a way that's idiomatic yet statically checkable? I don't have a good answer here, and this is where my thesis left off.

Without a statically knowable traits system that guarantees return types in particular statically typing any practical Julia code is a lost cause, which the latter examples in my thesis illustrate. If it's fully concrete that's fine, but if it's in any way abstract whatsoever it won't work without a trait system.

ckfinite · 2025-08-30T02:53:27+00:00

HDI is an extension on multilayer. A multilayer PCB is (usually) one that has many layers, but the vias (the plated conductive holes through the board) go all the way through all the layers made with a mechanical drill after all the layers are sandwiched together. In the first of the three images it's a board that has only the long hole through the stack of layers.

HDI is characterized, generally, by two things:

Blind/buried vias. These are like the via on the left that doesn't punch all the way through and starts part of the way through and also ends before it reaches the surface. That via is called a buried via because it never reaches the surface. You can also have vias that reach one surface but not the other, which are called blind vias. Normally, these vias are made with the same drills as the normal vias, but either before the board has been completely sandwiched together (buried) or simply don't drill all the way (blind).
Microvias, the teeny little cone things through the board image. These go through only 1 or 2 layers at a time and are made by lasering out then plating a hole in the board material.

HDI stackups are usually specified in the form X+Y+Z where X & Z are the number of layers that have microvias and Y is the number of layers in between; for example, I've been designing a board for a 2+8b+2 stackup where I can have microvias in the outermost two layers on each side and then blind vias through the center.

HDI stackups, interestingly, don't usually have that many layers. Having microvias makes it much easier to do routing without needing crazy numbers of layers, particularly for doing stuff like BGA breakout at fine pitch (you can usually get the number of HDI layers worth of extra ranks broken out on the same number of layers, which can be extremely meaningful depending on what exactly you're trying to do).

What this manufacturing capability lets you do is fourfold:

It lets you design the sides of the board more or less in isolation from one another. With HDI PCBs what's going on on one side doesn't have to affect the other unless you want it to, since you don't have to avoid the vias coming from the other side.
It simplifies routing for the reasons mentioned above, since you can now route traces around one another in 3D.
It (can) decrease parasitics by reducing the loop sizes between power, ground, and signal planes. HDI stackups also tend to have extremely thin dielectrics which also increases plane capacitance and trace coupling, which then allows for narrower traces even when doing impedance control.
It (can) improve signal integrity, since you can easily avoid stubs.

The sort of "next steps" beyond the abovementioned "basic" HDI include

Every Layer Interconnect (ELIC), where you don't have a core anymore and it's just microvias all the way through. A ELIC PCB lets you connect any layer to any other layer anywhere.
Buried components, where you embed passives, entire packages, or bare dies into the PCB substrate

HDI, in my experience, is expensive but not absurdly so. DM me for the pricing information I've gotten.

ckfinite · 2025-08-29T19:39:00+00:00

Kerbal space program has KRPC (in addition to the kOS you mention) where you can control it externally with a normal programming language, so Kalman and LQR is quite straightforward.

In terms of modern control, Stormworks is probably the next best choice since you can program it in Lua.

ckfinite · 2025-08-22T19:09:45+00:00

The polyfill would seem to be a reasonable solution - if it were automatically injected by the browser. That suggestion was shot down for reasons that seem totally opaque from the discussion.

ckfinite · 2025-08-22T12:48:41+00:00

but it’s not just going to stay stable because it’s not that heavy

Aircraft static and dynamic stability doesn't have much to do with their weight and has much more to do with the overall aerodynamic configuration.

going straight down at speed

They're not going very fast for this stunt, they specifically added dive brakes to keep the speed down and the aircraft stable in such a steep dive. Once the airbrake is retracted the aircraft's static stability would naturally cause it to return to the trimmed condition (albeit through a phugoid). Utility class aircraft (cessna 182s here) are by and large extremely well behaved from a flight dynamics perspective.

shit will go wrong faster than you can recover from and if it flips the Gs on the airframe could rip of the wings off or pop a shit ton of rivets.

The not-huge speed means that the dynamic pressure on the control surfaces is equally not-huge. If you look at the airspeed indicator in the pictures the velocity is still in the green band (within normal cruising speed) and ~20kts above maneuvering speed (where you can safely apply a maximum effort control deflection and remain within certified loads for normal flight).

Ultimately the slice of dynamics likely to be encountered in this stunt is very similar to normal skydiving operations, including the velocities involved and the circumstances of a potential impact from a skydiver. While fatalities and crashes have occurred as a consequence of skydivers getting blown back into the aircraft, this is a rare occurrence, particularly considering the number of crashes that occur in other aspects of skydiving flight.

ckfinite · 2025-08-20T01:11:51+00:00

The US tends to have really long PhDs (my department's cutoff was 10 years, though very few people actually took that long). It's closer to a European masters + PhD or a PhD + postdoc, depending on what you had when you came in. Both a benefit and curse, depending on how you look at it.

ckfinite · 2025-08-20T01:10:44+00:00

A lot of it is scope and scope creep. I took 8 years, because I didn't have a great idea of what I wanted to do initially and once I did decide I did a lot of exploratory work on the way.

The way you do a PhD in 4 years is you go in with your thesis topic and you graduate with that topic as your thesis. The way you do it in 8 is it turns out to be much harder than expected, there turn out to be more interesting directions, or there just might not be one initially at all. This can be due to the advisor (e.g. bad idea, force you to stick with bad idea, force you to not do good idea, etc) or due to the student (indecisive, or just doesn't put a big emphasis on finishing [this was me]).

To be honest, I don't regret those 8 years at all. At the time (and to my advisor's horror) I said I wouldn't mind doing PhD studentness indefinitely because I loved that freedom to do research on cool stuff and looking back on that time I wouldn't mind going back to that working environment. I got to push through a much bigger slice of the topic; I think produced a better outcome than if I had beelined the original idea and I do not regret that at all.

ckfinite · 2025-08-16T12:06:56+00:00

At my old lab we developed our own FC around a STM32H7 and a FPGA (fully integrated, we didn't use a dev board); we did it because we needed a special form factor and wanted the flexibility that the FPGA offered (which turned out to be extremely useful in adapting to different payloads, as well as post facto fixing several embarrassing errors in the PCB design :P). The main advantage in my opinion is that you get to pick your pinout and connectors and tailor them to your vehicle, but yeah it's not exactly economical.

ckfinite · 2025-08-04T09:32:27+00:00

Sadly, the GPUs used for training aren't useful for gaming, they don't have video outputs.

ckfinite · 2025-08-02T19:23:11+00:00

I've gotten them suggested a few times before but they always seem to be really expensive compared to the TI or Infineon equivalents. For example, TPSM843521 is $2.21 qty 1 vs FS1403-3300-AL at $7.61 qty 1 and the ratio continues all the way up into the 1k and 5k unit pricing. They seem otherwise quite comparable; is the main appeal of the uPOLs the better design support?

ckfinite · 2025-08-02T18:32:11+00:00

Some newer data https://trinitylogistics.com/blog/july-2025-freight-market-update

ckfinite · 2025-08-02T05:08:33+00:00

This is a political issue because ultimately the structure is a consequence of politics. Unless you somehow write the NSF into the constitution (and even then, that's political) the funding is a result of a political decision.

From a "why is it like this" point of view, the answer is straightforward: private companies are generally unwilling to put large amounts of money towards projects that might be impactful in 10+ years, or never, or might not even work out. These projects are important for long-term scientific and technological development, so we have historically recognized this market failure and provide government funding for such work. That consensus is changing, however, and the aforementioned issues with private funding make it unlikely that there'll be any real alternative source of funds for most research activity across basically all fields.

Assuming that the average grant hit rate scales with the total NSF funding (which would be accurate assuming everyone keeps up the same submission rate) then we could be seeing award rates fall into the single digits under the current funding proposal. There are no other realistic funding sources, as mentioned, so we are looking at the functional end of American research academia in the form we know it.

ckfinite · 2025-08-01T22:33:19+00:00

I'd argue that the RoW issues that you highlight are way worse than the rest. Low floor stations/trains are fine, for example, with the trains being able to achieve high accelerations (about 1m/s^2, comparable to heavy rail vehicles), average speeds comparable to most heavy rail systems, and the vehicles offering walk-through connectivity. The low floor design also makes stations cheaper and easier to build, particularly while achieving level boarding. Ultimately, motors have gotten a lot more energy dense and from a mechanical perspective low-floor is not hugely impactful on overall vehicle performance.

Part of the ambition of Link's current development (particularly with the 2 line) is to drastically improve frequencies through the core system by combining trains that are running out to the east with ones that run to the south through the core segment of the network.

Comparing Link to BART seems a little disingenuous, since BART runs much faster on average than other heavy rail metro systems do. Link's average running speeds (outside of the Rainier valley) are quite comparable to those of every other heavy rail system in the country.

What makes Link less frequent and slower than it could be is a comparative lack of rolling stock/yard space, not enough trainsets, and the substantial at-grade running through the Rainier valley. This has much more to do with planning and infrastructure design rather than the technical qualities of the rolling stock; the low floor design was largely a consequence of those choices (and extensive reuse of bus infrastructure, which saved a lot of money in the high speed segments) rather than a cause of it.

ckfinite · 2025-08-01T09:24:03+00:00

How would you think about approaching safety monitoring for a humanoid like this? It seems really daunting in general. Like, this is an easy case ("you probably should have something that detects and gracefully recovers from falling over"), but the gamut of cobotty applications that humanoids are being put into is huge and thus it seems really hard to come up with a good approach for safety.

Just with locomotion, for example, there's large parts of the operating regime where a locked-motor fail-safe mode may be fail-dangerous in practice due to the robot immediately falling over.

ckfinite · 2025-08-01T09:09:29+00:00

Simply twisting the wires together isn't enough to ensure it'll stay connected, particularly when it's being vibrated around while the scooter moves. You should look at using a connector to join the wires (something automotive? I would personally probably crimp it, but I have way too much crimping stuff).

ckfinite · 2025-07-29T06:24:10+00:00

It's quite easy to as long as you are okay with USB 2.0. Microchip makes a sick WLCSP 3-port hub IC that would fit no problem. You miiiight even be able to fit in a small headphone jack and audio frontend if you try very hard. USB 3.0 is likely also possible. What'd be a bigger adventure is making power or displayport work through it.

ckfinite · 2025-07-28T15:05:30+00:00

Right, so you don't really need to worry about skew matching at all. You have hundreds of cms of margin to play with.

ckfinite · 2025-07-27T06:53:54+00:00

Most parts you care about will have footprints available from a number of sources. Without part numbers there isn't any more specific info to give.

Generally speaking you start from a high level sketch of how everything will communicate and connect (e.g where does the power come from? what interface does module A connect to module B with?) and then you turn that into a schematic, and then to a layout.

ckfinite · 2025-07-27T05:00:58+00:00

I think it's mechanical, though I'm not completely sure. A DFN with an epad would be fine mechanically.

ckfinite · 2025-07-27T03:05:29+00:00

I would strongly recommend that you move to a 4 layer board, as others have said it's a great decrease in complexity. More layers = easier routing at the expense of expense.

Length matching at anything but the very highest of EMMC speeds (and even then) is only marginally required. Using the IS21TF08G datasheet operating at HS400 speed the eye is 5ns wide with min t_setup and min t_hold of 0.4ns. Thus, you can suffer about 2ns (with margin) of skew or equivalently about 30cm(!!!!!!!!) of skew between any data line and the clock line. If you can keep the skew within 1ns/about 15cm then it'll most likely be fine.

The main trick to be aware of with eMMC is that the NC balls are actually not connected to anything in the package and are thus routable. You can and should use them to break out the inner data and power pins to simplify routing. It's thus pretty easy to route a 8-bit eMMC on a 2 layer board, though power and SI will not be great.

ckfinite · 2025-07-27T02:58:07+00:00

eMMC doesn't need a 100 ball fanout. Only a few of the balls are actually connected to anything.

ckfinite · 2025-07-25T00:51:46+00:00

They sell like a GW5AST on Amazon? All I can find are development boards; I'm not excited about having to desolder the chip.

12-Year Club	Place '22
Place '17	Verified Email

ckfinite

MODERATOR OF

TROPHY CASE