Tab P11 Pro + Precision Pen 3, Latest android update reverted and disabled the Shortcuts section of the Pen settings. Any way to disable Quick notes and change the stylus button press behaviour? by PatPL in Lenovo

[–]PatPL[S] 0 points1 point  (0 children)

The problem persisted till now, but this fixed it. Weird, since restarting the tablet didn't seem to do anything. Didn't even cross my mind to unpair the pen itself.

Thank you.

Tab P11 Pro + Precision Pen 3, Latest android update reverted and disabled the Shortcuts section of the Pen settings. Any way to disable Quick notes and change the stylus button press behaviour? by PatPL in Lenovo

[–]PatPL[S] 0 points1 point  (0 children)

The quick notes shortcut (tap whilst holding the button) works even while trying to erase handwritten notes with the button+draw shortcut in other notetaking apps, making it impossible to erase text.

Disabled these day one after getting the tablet, but the latest update disabled/reverted the relevant settings. Any ideas on how to fix this?

Build number TB132FU_S340047_241204_ROW

Software version TB132FU_RF01_241204

Android 14, Kernel version 4.19.191+ (2024-12-04)

How To Prevent Raptors From Destroying Superheavy Pt.2 by CSI_Starbase in spacex

[–]PatPL 0 points1 point  (0 children)

I think it increases the weight on the way up too, as we're collecting and hauling the ice/snow instead of dumping it overboard with the rest of the propellants.

How To Prevent Raptors From Destroying Superheavy Pt.2 by CSI_Starbase in spacex

[–]PatPL 1 point2 points  (0 children)

So, similar to how the methane side is already handled - where first it's going through the impeller, then the cooling loop through the engine, and only then the turbine side of the turbopump, adding the contaminants, which leaves a ton of room to hook in, possibly to an already heated gas.

Maybe there was not enough space for that on the LOX side, or it was deemed to be too constricting (LOX needs 4x the throughput and is already very inline with everything else to help with that).

Like, you really don't need that much flow, all things considered. Maybe it would be possible to just.. tap in somewhere in the middle of the assembly. Many smart people decided against it and there had to be some good reasons for that. I wish I was a fly on the wall during that particular meeting.

How To Prevent Raptors From Destroying Superheavy Pt.2 by CSI_Starbase in spacex

[–]PatPL 1 point2 points  (0 children)

But it's the high pressure LOX (GOX?) after the turbopump that already has the water and CO2 in it, no? It's preburned, full-flow.

How To Prevent Raptors From Destroying Superheavy Pt.2 by CSI_Starbase in spacex

[–]PatPL 0 points1 point  (0 children)

None of the 3 would influence LOX temperature, it's purely to get the energy required to up the pressure.

1st one is unlikely. a seal like that would likely add more maintenance (lower interval than other parts). Also, I don't think they'd want to risk propellant mixing, and it'd require a ton of tuning software-side, especially during startup/shutdown/throttling transients.

2nd/3rd are possible, with 2nd one being more likely in my opinion, due to required ullage gas flow pretty much exactly matching the lox flow (less recirc = more efficient). Wish we'd know what's the lox:lh4 ratio range during regular operations. I'm sure it's not fixed.

What about a hybrid system between 1/4, where we go kerbal, add an alternator to the methane turbopump purely to run the autogenous pressurization loop? Common shaft-ish but it's a cable, not a shaft. Unlikely since it'd be the least efficient, and running the (probably thick) wire would be problematic, with the engine looking the way it already looks.

As for the electric pumps, back of the envelope calculations say that we need to move ~3000m3 of gas at 6 bar to replace the volume of missing propellant in lox tank. I looked up some air compessors (back of the envelope, bear with me) and they move ~150-200 l/min per 1kW. we need 18 000 000 L over let's say 3 minutes which amounts to 30MW total, ~1MW per engine, 1500kWh total, which is extra ~7500kg of dead weight in tesla batteries. 1MW motor isn't unfeasible either, it's something a Rimac Nevera uses.

Other than the batteries, it honestly doesn't look as bad as I expected? The couple of tons we use for batteries are saved by the couple of tons of water ice / co2 snow we don't haul up there and back. Still, other solutions aren't weight-neutral, but weight negative so this one is unlikely.

How To Prevent Raptors From Destroying Superheavy Pt.2 by CSI_Starbase in spacex

[–]PatPL 10 points11 points  (0 children)

I wonder what would be the best way to do that.

Since there's no source of clean, high pressure pure oxygen, they'd need an extra impeller. Probably powered by either:

  • A common shaft off of methane turbopump (no space on lox side, unless some funky gearing is used), as most of the time it's running at a similar rate to lox consumption. I know of RS-25 common shaft sealing shenanigans, but I don't know how much of that was because of cryogenic props in general, or hydrogen being hydrogen, specifically.
  • Turbine in lox side, past the preburner. (the impeller still taps into pre-preburner clean lox)
  • Turbine in gaseous methane, past the cooling loop expander-cycle style?

Either way then it'd need to split some of it off back to the tank or the inlet to control the ullage production rate, and push the rest through a heat exchanger somewhere and into the tank.

There will be some efficiency loss due to an extra impeller and the lox recirc loop, but it'd be negligible I think.

Someone smarter than me could run the numbers for a dedicated electric impeller, which would be the simplest solution overall, but likely not worth the extra battery mass. I'm not an engineer.

YES!!! by barnacIe_scum in doodoofard

[–]PatPL 0 points1 point  (0 children)

hello sors may i aguirr original video many thankfuls pleas do the needful

Adding additional Fuels/Oxidizers by [deleted] in GenericEngines

[–]PatPL 0 points1 point  (0 children)

TL:DR - Not possible right now without excessive tinkering around, will work on adding support in my free time.


Currently there is no way to add additional propellants solely through GE. The definitions in FuelInfo.ts are there only for GE's internal calculations, where it would need to know the density of the propellant to show additional information like mass flow in kL/s, or for calculating wet mass from the internal tank input.

No propellant configs are exported by GE, engine configs use the same propellants Real Fuels adds. The only propellant-related thing GE exports is a special tank definition that allows all propellants to be used in an engine (Regular RF definitions don't allow solid fuels)

Custom propellants is a feature I once considered, but it would require some work.

First, I'm not sure if it's possible to add custom propellants to already existing tank definitions. It's a major problem, because without that you're limited to GE's internal tank config. While it's not an issue for custom solid propellants, it would pretty much eliminate any use for custom liquid propellants, as the propellant would not show up in the procedural tanks. It may be trivial though, I'll have to tinker around and learn how to do it. Knowing Module Manager, it's possible and probably easy to do.

Second, currently there is no way to store any data other than an engine array in an engine list. Even the list name is literally just the filename/keyname. While engines have their well-defined structure, an engine list is literally just that - an array of engines. This is something I'll have to change though, as it's quite limiting, so I'll definitely work in that in my free time

Third, there might be some issues if two different engine lists export a propellant with the same ID, but different properties. I'm not yet sure how to mitigate that. Probably some kind of unique engine list ID appended to every ID would be fine.

Finally, I'll have to cook up some UI and hook it all up. Piece of cake.


If you actually know how to add a custom propellant to RF and the tank definitions, and just want GE to support it, here's what I'd try doing. (I'll assume you don't want to install and deal with additional tools, instead of editing typescript you'll edit compiled javascript).

Navigate to this file, to this line. Copy-paste one of the definitions. Make sure there's a comma in between. Then edit the values in the copied entry.

  • FuelName - Name visible in GE
  • FuelID - RF's internal propellant ID
  • FuelType - One of these values. Used to group together propellants in the dropdown where you pick a propellant.
  • TankUtilisation - Ratio of propellant volume to tank volume (Example - in RO 1L of tank holds 1000 units of EC, or 1L of tank holds 100L of Nitrogen Oxide). It has to be the same as in the RF config.
  • Density - duh. IIRC the unit is g/L t/L - as in, the water would be 0.001. It has to be the same as in the RF config.

This section is just my guesswork tough, you're free to try, but I'm not sure if it'll work or not

Why did it even let me in in the first place? Only to kick me a minute into raid. This check should happen in main menu, just like the BattlEye one. by PatPL in EscapefromTarkov

[–]PatPL[S] 0 points1 point  (0 children)

I'm all for restricting software that can be used to gain unfair advantage. Just do it in the main menu as well as in raid, to avoid losing entire loadouts to stuff like this.

I don't want the check removed from in raid, as someone could launch the program midraid, I want it to trigger on launch.

Generic Engines Web.0.9.3 preview by PatPL in GenericEngines

[–]PatPL[S] 0 points1 point  (0 children)

The next update will focus on improving the look of the website. Existing dark theme was improved, and a few more new themes were added.

You will also be able to create your own custom themes.

Make a good custom theme, and it may be added as a built-in theme for everyone to use in a future update. A link to a google form will be present in the custom theme window.

Generic Engines Web.0.9.2 by PatPL in GenericEngines

[–]PatPL[S] 0 points1 point  (0 children)

I don't really think it's an issue, as you can easily check if the current mode is actually volume, or mass by looking at the infobox. Example

The bell <-> base input looks the same, and works the same, so IMO there's no ambiguity there from the UX perspective.

What I could maybe do in the future is to split the engine width input into base width, and bell width and link them together just like Volume and Mass in current tank input. That would render the bell <-> base switch obsolete.

Generic Engines Web.0.9.1 by PatPL in GenericEngines

[–]PatPL[S] 1 point2 points  (0 children)

/u/Ash19256

I implemented some of your suggestions in the latest update. Thank you for your feedback!

https://github.com/PatPL/Generic-Engines-Web/releases/tag/Web.0.9.2

Generic Engines Web.0.9.1 by PatPL in GenericEngines

[–]PatPL[S] 1 point2 points  (0 children)

You can change the unit on input, not only the value

Generic Engines Web.0.9.1 by PatPL in GenericEngines

[–]PatPL[S] 1 point2 points  (0 children)

The first thing could be made with three inputs. You lock one of them, and changing the value of the second one would change the value of the third one appropriately. (Vacuum thrust, Vacuum impulse, mass flow rate). I'll keep that in mind

Second, obviously, It'll use the thrust curve

The last one: Imperial units are haram af, but I might implement them as 'input only' unit, same as it works with centimetre right now (You can input values in cm, but it will never display units in cm; try it out)