PORT: Sistema de Energia (Excess Power) do Funky Station#780
PORT: Sistema de Energia (Excess Power) do Funky Station#780cristalyssd wants to merge 2 commits into
Conversation
Origem: funky-station/funky-station#2330 - Adiciona um PTL melhor e que pode ser ajustável (vende excesso de energia) - Adiciona Fabricador de Anti-Matéria (produz combustível para AME) Autor original: @rottenheadphones (PR #2330 do Funky Station)
github-actions
Bot
added
S: Untriaged
Changes: Sprites
Changes: UI
Changes: Audio
and removed
S: Untriaged
labels
|
RSI Diff Bot; head commit 3c4c663 merging into 113fb93 Resources/Textures/_NF/Objects/Power/big_ame_jar.rsi
Resources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi
Resources/Textures/_NF/Structures/Machines/AMEFab/64x32.rsi
Resources/Textures/_NF/Structures/Machines/AMEFab/base.rsi
Resources/Textures/_NF/Structures/Machines/GasConverter/32x32.rsi
Resources/Textures/_NF/Structures/Machines/GasConverter/base.rsi
Resources/Textures/_NF/Structures/Power/TransmissionPoint/32x32.rsi
Resources/Textures/_NF/Structures/Power/TransmissionPoint/96x32.rsi
Resources/Textures/_NF/Structures/Power/TransmissionPoint/base.rsi
Resources/Textures/_NF/Structures/Power/bles.rsi
|
|
Poderia fazer com que cada máquina dessas precisasse pesquisar na sci, facilitaria não precisar ser mapeado em todo mapa |
|
Mas daí a pesquisa seria tier 3, obviamente |
WalkthroughEsta PR introduz três novos sistemas de consumo de energia no servidor NF: ChangesUI Compartilhada de Ajuste de Consumo de Energia
Sistema EntitySpawnPowerConsumer (Anti-Matter Fabricator)
Sistema GasSpawnPowerConsumer (Gas Converter)
Sistema PowerTransmission (Ponto de Transmissão de Energia)
Sequence Diagram(s)sequenceDiagram
participant Player
participant AdjustablePowerDrawMenu
participant AdjustablePowerDrawBoundUserInterface
participant EntitySpawnPowerConsumerSystem
rect rgba(0, 100, 200, 0.5)
note over Player,AdjustablePowerDrawMenu: Ajuste de Carga pelo Jogador
Player->>AdjustablePowerDrawMenu: Digite valor e clique Submit
AdjustablePowerDrawMenu->>AdjustablePowerDrawBoundUserInterface: OnSetLoad(float watts)
AdjustablePowerDrawBoundUserInterface->>EntitySpawnPowerConsumerSystem: AdjustablePowerDrawSetLoadMessage
EntitySpawnPowerConsumerSystem->>EntitySpawnPowerConsumerSystem: HandleSetLoad → clamp DrawRate
EntitySpawnPowerConsumerSystem->>AdjustablePowerDrawBoundUserInterface: AdjustablePowerDrawBuiState(On, Load, estimatedTime)
AdjustablePowerDrawBoundUserInterface->>AdjustablePowerDrawMenu: Update(state)
end
rect rgba(0, 180, 100, 0.5)
note over EntitySpawnPowerConsumerSystem: Ciclo de Spawn (Update)
EntitySpawnPowerConsumerSystem->>EntitySpawnPowerConsumerSystem: AccumulatedEnergy += ReceivingPower * dt
EntitySpawnPowerConsumerSystem->>EntitySpawnPowerConsumerSystem: AccumulatedEnergy >= EnergyPerSpawn?
EntitySpawnPowerConsumerSystem->>EntitySpawnPowerConsumerSystem: SpawnEntity(Spawn) + reset acumuladores
EntitySpawnPowerConsumerSystem->>EntitySpawnPowerConsumerSystem: TryConsumeResources (Plasteel)
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Nitpick comments (2)
Content.Server/_NF/Power/Components/ChargingComponent.cs (1)
17-20: 🩺 Stability & Availability | 🔵 TrivialRemova
ChargerComponentdeChargingComponentse ele for apenas cache. O componente já guardaChargerUid; manter a referência direta pode ficar desatualizada quando o carregador mudar ou for removido, e não há uso desse campo no restante do código.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Content.Server/_NF/Power/Components/ChargingComponent.cs` around lines 17 - 20, Remove the cached ChargerComponent field from ChargingComponent if it is only duplicating state already tracked by ChargerUid; keep the UID as the source of truth and update any code that reads or assigns ChargerComponent to resolve the charger on demand instead. Check ChargingComponent and related charger/battery interactions for any remaining references to ChargerComponent, and replace them with logic based on ChargerUid so the component does not hold a stale direct reference.Content.Shared/_NF/Manufacturing/EntitySystems/SharedEntitySpawnPowerConsumerSystem.cs (1)
25-27: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winRestrinja o bloqueio ao slot configurado de saída.
Do jeito atual, qualquer inserção manual em qualquer
ItemSlotda entidade é cancelada. Isso ignoraSlotNamee pode bloquear slots adicionais da máquina. Limite o cancelamento ao slot configurado para output.💡 Ajuste sugerido
private void OnItemSlotInsertAttempt(Entity<EntitySpawnPowerConsumerComponent> ent, ref ItemSlotInsertAttemptEvent args) { - if (args.User != null) + if (args.User != null && args.Slot.Name == ent.Comp.SlotName) args.Cancelled = true; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Content.Shared/_NF/Manufacturing/EntitySystems/SharedEntitySpawnPowerConsumerSystem.cs` around lines 25 - 27, The insert-cancel logic in SharedEntitySpawnPowerConsumerSystem is too broad because it blocks any manual interaction with any ItemSlot on the entity. Update the handler so it checks the configured output slot name from the relevant setup/component and only sets args.Cancelled for that specific slot, leaving other slots unaffected. Use the existing slot-identifying symbols in this system, such as the slot/component access around the current args.User check, to scope the cancellation to the output slot only.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@Content.Client/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.cs`:
- Around line 5-8: The client-side entity system is declared as a standalone
EntitySystem instead of inheriting the shared implementation, so the shared
Initialize logic and subscriptions are not applied. Update
SharedEntitySpawnPowerConsumerSystem in
Content.Client._NF.Manufacturing.EntitySystems to derive from
Content.Shared._NF.Manufacturing.EntitySystems.SharedEntitySpawnPowerConsumerSystem,
and keep the client partial only for client-specific behavior if needed.
In `@Content.Client/_NF/Power/AdjustablePowerDrawMenu.xaml.cs`:
- Around line 46-48: The UI event handlers on PowerDropDown.OnItemSelected and
Load.OnTextChanged always call SetUnsavedChanges(), which causes programmatic
sync from Update() to be treated as user edits. Add a guard in
AdjustablePowerDrawMenu to distinguish internal UI updates from real user
interaction, and make Update() set Load.Text/select dropdown without triggering
SetUnsavedChanges() during synchronization. Ensure the handlers only mark
unsaved changes when the change comes from user input, not when SelectId or
Load.Text is being set by the control itself.
- Around line 131-132: The power status label in AdjustablePowerDrawMenu should
use this component’s new locale keys instead of the gas-pump ones. Update the
TogglePowerButton.Text assignment in the AdjustablePowerDrawMenu logic to
reference the adjustable-power-status enabled/disabled strings so the UI stays
consistent with the new translations and avoids leaving the new locale entries
unused.
In
`@Content.Server/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.cs`:
- Around line 130-138: The spawn cycle in EntitySpawnPowerConsumerSystem should
not be finalized before confirming TrySpawnInContainer succeeds, and
AccumulatedEnergy should preserve any overflow instead of being reset. Update
the logic around TrySpawnInContainer, TryConsumeResources, and the
spawn.AccumulatedEnergy / spawn.Processing handling so the batch only advances
after a successful output-slot spawn. Keep the completed progress if the spawn
fails, and subtract EnergyPerSpawn rather than clearing all accumulated energy
to avoid losing excess energy.
In
`@Content.Server/_NF/Manufacturing/EntitySystems/GasSpawnPowerConsumerSystem.cs`:
- Around line 41-42: The UI throttle in GasSpawnPowerConsumerSystem is currently
shared across all instances because _lastUiUpdate is a single system field, so
one machine/BUI update can suppress another and leave it without an initial
refresh. Move the cooldown tracking to per-machine/per-UI state in the relevant
update path (for example in the methods that handle BUI refresh/state sync
around the current return guard), and ensure each opened interface can send its
initial state independently even if another update happened within
UiUpdateCooldown.
- Around line 137-142: The GasSpawnPowerConsumerSystem spawn path can produce a
negative moles amount when the canister pressure is already above the maximum,
which then feeds a negative factor into the mixture scaling before merge. Update
the logic around the deltaP/maxMoles calculation to clamp the allowed spawn
amount at zero (or return early when the canister is over MaxOutputPressure)
before calling _mixture.Multiply and _atmos.Merge, using the
GasSpawnPowerConsumerSystem spawn flow and the molesToSpawn/maxMoles variables
as the key points to adjust.
- Around line 166-173: A curva de potência em
GasSpawnPowerConsumerSystem.GasPowerConsumer provavelmente está usando a fórmula
logarítmica de forma invertida, causando uma queda abrupta logo após
LinearMaxValue. Ajuste o cálculo no ramo else para que a transição a partir de
LinearMaxValue seja contínua e crescente, revisando os termos usados em
ent.Comp.LogarithmCoefficient, ent.Comp.LogarithmRateBase e
ent.Comp.LogarithmSubtrahend. Verifique o comportamento do método/trecho que
calcula actualPower para que valores logo acima do limite não colapsem para
poucos watts.
- Around line 92-93: The power state check in GasSpawnPowerConsumerSystem is
comparing the same NetworkLoad values twice in the same update, so
PowerDeviceVisuals.Powered never changes. Update the logic around
wasPowered/isPowered to compare the current network state against the previously
stored visual state or another persisted source, and then set
PowerDeviceVisuals.Powered only when that state actually changes. Use the
existing symbols GasSpawnPowerConsumerSystem and PowerDeviceVisuals.Powered to
locate the affected update path.
- Around line 132-145: The spawn limit logic in GasSpawnPowerConsumerSystem is
treating MaximumMolesPerSecond as a per-tick cap and then clearing all
accumulated energy, which drops excess work. Update the spawn calculation so the
per-second limit is scaled by the actual elapsed spawn interval (for example,
using SpawnCheckPeriod or the current tick delta) before clamping molesToSpawn.
Also change the AccumulatedEnergy reset so only the energy actually consumed by
the spawned moles is removed, leaving any remainder buffered for the next cycle.
In `@Content.Server/_NF/Power/EntitySystems/PowerTransmissionSystem.cs`:
- Around line 101-114: The deposit calculation in PowerTransmissionSystem.Update
is using only one DepositPeriod even when the server has fallen behind and
AccumulatedEnergy spans multiple elapsed periods. Update the logic around
xmit.NextDeposit and xmit.AccumulatedEnergy so payment is based on the real time
since the last deposit, or iterate through all overdue deposit intervals and
consume energy per period instead of paying the same backlog once before zeroing
it.
In
`@Resources/Locale/en-US/_NF/manufacturing/entity-spawn-power-consumer-component.ftl`:
- Line 2: The estimated-time label in entity-spawn-power-consumer-component.ftl
is formatting the TimeSpan with TOSTRING($time, "hh\\:mm\\:ss"), which wraps
after 24 hours and hides days. Update the localization string used by
entity-spawn-power-consumer-estimated-time so it formats long durations with
days included, and keep the change localized to the estimated-time output path
in the relevant manufacturing entity-spawn power consumer text.
In `@Resources/Prototypes/_NF/Entities/Structures/Power/smes.yml`:
- Around line 35-45: The SMES prototype has a charge-rate mismatch:
BatteryInterface.maxChargeRate is much higher than
PowerNetworkBattery.maxChargeRate, so the device advertises more charging
capacity than the network can actually apply. Update the PowerNetworkBattery
values in the smes prototype to match the intended BatteryInterface charging
limits, and keep the related charge/supply settings consistent so the runtime
behavior matches the prototype's advertised rate.
---
Nitpick comments:
In `@Content.Server/_NF/Power/Components/ChargingComponent.cs`:
- Around line 17-20: Remove the cached ChargerComponent field from
ChargingComponent if it is only duplicating state already tracked by ChargerUid;
keep the UID as the source of truth and update any code that reads or assigns
ChargerComponent to resolve the charger on demand instead. Check
ChargingComponent and related charger/battery interactions for any remaining
references to ChargerComponent, and replace them with logic based on ChargerUid
so the component does not hold a stale direct reference.
In
`@Content.Shared/_NF/Manufacturing/EntitySystems/SharedEntitySpawnPowerConsumerSystem.cs`:
- Around line 25-27: The insert-cancel logic in
SharedEntitySpawnPowerConsumerSystem is too broad because it blocks any manual
interaction with any ItemSlot on the entity. Update the handler so it checks the
configured output slot name from the relevant setup/component and only sets
args.Cancelled for that specific slot, leaving other slots unaffected. Use the
existing slot-identifying symbols in this system, such as the slot/component
access around the current args.User check, to scope the cancellation to the
output slot only.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 7a2ce547-a392-4bac-8fb0-055d0be0ddc4
⛔ Files ignored due to path filters (44)
Resources/Audio/_NF/Ambience/power-hum.oggis excluded by!**/*.oggResources/Textures/_NF/Objects/Power/big_ame_jar.rsi/inhand-left.pngis excluded by!**/*.pngResources/Textures/_NF/Objects/Power/big_ame_jar.rsi/inhand-right.pngis excluded by!**/*.pngResources/Textures/_NF/Objects/Power/big_ame_jar.rsi/jar.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi/dial-animated.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi/dial.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi/inserting.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi/material-good.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi/material-low.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi/panel-unlit.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi/slot-full.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi/slot-unlit.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/64x32.rsi/flywheel-animated.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/64x32.rsi/flywheel.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/64x32.rsi/press-animated.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/64x32.rsi/press.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/AMEFab/base.rsi/base.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/GasConverter/32x32.rsi/fan-animated.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/GasConverter/32x32.rsi/fan.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/GasConverter/32x32.rsi/front-panel-unlit.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/GasConverter/32x32.rsi/gas.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/GasConverter/32x32.rsi/panel-unlit.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/GasConverter/32x32.rsi/window-unlit.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Machines/GasConverter/base.rsi/base.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/TransmissionPoint/32x32.rsi/icon.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/TransmissionPoint/32x32.rsi/panel-unlit.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/TransmissionPoint/96x32.rsi/base-foreground.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/TransmissionPoint/96x32.rsi/base-unlit.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/TransmissionPoint/base.rsi/base.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-glass.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-oc0.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-oc1.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-oc2.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-og1.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-og2.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-og3.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-og4.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-og5.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-op0.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-op1.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-op2.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-open.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles-unlit.pngis excluded by!**/*.pngResources/Textures/_NF/Structures/Power/bles.rsi/bles.pngis excluded by!**/*.png
📒 Files selected for processing (35)
Content.Client/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.csContent.Client/_NF/Power/AdjustablePowerDrawBoundUserInterface.csContent.Client/_NF/Power/AdjustablePowerDrawMenu.xamlContent.Client/_NF/Power/AdjustablePowerDrawMenu.xaml.csContent.Server/_NF/Manufacturing/Components/GasSpawnPowerConsumerComponent.csContent.Server/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.csContent.Server/_NF/Manufacturing/EntitySystems/GasSpawnPowerConsumerSystem.csContent.Server/_NF/Power/Components/ChargingComponent.csContent.Server/_NF/Power/Components/MixedPowerRecieverComponent.csContent.Server/_NF/Power/Components/PowerTransmissionComponent.csContent.Server/_NF/Power/EntitySystems/PowerTransmissionSystem.csContent.Shared/_NF/Manufacturing/Components/EntitySpawnPowerConsumerComponent.csContent.Shared/_NF/Manufacturing/EntitySystems/SharedEntitySpawnPowerConsumerSystem.csContent.Shared/_NF/Manufacturing/SharedManufacturing.csContent.Shared/_NF/Power/SharedAdjustablePowerDraw.csResources/Locale/en-US/_NF/manufacturing/entity-spawn-power-consumer-component.ftlResources/Locale/en-US/_NF/manufacturing/gas-spawn-power-consumer-component.ftlResources/Locale/en-US/_NF/power/components/adjustable-power-draw-component.ftlResources/Locale/en-US/_NF/power/components/power-transmission-component.ftlResources/Locale/en-US/job/job-names.ftlResources/Prototypes/Catalog/Fills/Crates/engines.ymlResources/Prototypes/_NF/Entities/Objects/Power/antimatter_jar.ymlResources/Prototypes/_NF/Entities/Structures/Machines/ame_fab.ymlResources/Prototypes/_NF/Entities/Structures/Power/smes.ymlResources/Prototypes/_NF/Entities/Structures/Power/transmission_point.ymlResources/Textures/_NF/Objects/Power/big_ame_jar.rsi/meta.jsonResources/Textures/_NF/Structures/Machines/AMEFab/32x32.rsi/meta.jsonResources/Textures/_NF/Structures/Machines/AMEFab/64x32.rsi/meta.jsonResources/Textures/_NF/Structures/Machines/AMEFab/base.rsi/meta.jsonResources/Textures/_NF/Structures/Machines/GasConverter/32x32.rsi/meta.jsonResources/Textures/_NF/Structures/Machines/GasConverter/base.rsi/meta.jsonResources/Textures/_NF/Structures/Power/TransmissionPoint/32x32.rsi/meta.jsonResources/Textures/_NF/Structures/Power/TransmissionPoint/96x32.rsi/meta.jsonResources/Textures/_NF/Structures/Power/TransmissionPoint/base.rsi/meta.jsonResources/Textures/_NF/Structures/Power/bles.rsi/meta.json
| namespace Content.Client._NF.Manufacturing.EntitySystems; | ||
|
|
||
| /// <inheritdoc/> | ||
| public sealed partial class SharedEntitySpawnPowerConsumerSystem : EntitySystem; |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '1,120p' Content.Shared/_NF/Manufacturing/EntitySystems/SharedEntitySpawnPowerConsumerSystem.cs
sed -n '1,120p' Content.Client/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.cs
# Verifica onde existe herança explícita de SharedEntitySpawnPowerConsumerSystem
rg -nP --type=cs 'class\s+\w+\s*:\s*SharedEntitySpawnPowerConsumerSystem\b' Content.Client Content.Server Content.SharedRepository: Project-Dumont/Dumont-Station
Length of output: 1590
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspeciona arquivos relacionados e padrões similares de sistema compartilhado/cliente
sed -n '1,120p' Content.Shared/_NF/Manufacturing/EntitySystems/SharedEntitySpawnPowerConsumerSystem.cs
sed -n '1,120p' Content.Client/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.cs
sed -n '1,120p' Content.Server/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.cs
printf '\n--- usages ---\n'
rg -n --type=cs 'EntitySpawnPowerConsumerSystem|SharedEntitySpawnPowerConsumerSystem' Content.Client Content.Server Content.Shared
printf '\n--- similar client/shared patterns ---\n'
rg -n --type=cs 'public sealed partial class Shared[A-Za-z0-9_]+System\s*:\s*EntitySystem;' Content.Client Content.Shared | sed -n '1,120p'Repository: Project-Dumont/Dumont-Station
Length of output: 7120
Herda do sistema shared no cliente
Content.Client/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.cs define um EntitySystem separado em vez de derivar de Content.Shared._NF.Manufacturing.EntitySystems.SharedEntitySpawnPowerConsumerSystem; assim, a lógica comum de Initialize() e as subscriptions do shared não entram no cliente.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@Content.Client/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.cs`
around lines 5 - 8, The client-side entity system is declared as a standalone
EntitySystem instead of inheriting the shared implementation, so the shared
Initialize logic and subscriptions are not applied. Update
SharedEntitySpawnPowerConsumerSystem in
Content.Client._NF.Manufacturing.EntitySystems to derive from
Content.Shared._NF.Manufacturing.EntitySystems.SharedEntitySpawnPowerConsumerSystem,
and keep the client partial only for client-specific behavior if needed.
| PowerDropDown.OnItemSelected += x => PowerDropDown.SelectId(x.Id); | ||
| PowerDropDown.OnItemSelected += _ => SetUnsavedChanges(); | ||
| Load.OnTextChanged += _ => SetUnsavedChanges(); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Evite marcar alteração pendente durante sincronização de estado da UI
Em Line 78-99, o Update() altera Load.Text/dropdown programaticamente, mas em Line 46-48 esses eventos sempre chamam SetUnsavedChanges(). Isso gera falso “unsaved changes” e bloqueia futuras atualizações automáticas.
💡 Sugestão de correção
public sealed partial class AdjustablePowerDrawMenu : FancyWindow
{
+ private bool _syncingState;
@@
public void Update(AdjustablePowerDrawBuiState msg)
{
SetPowered(msg.On);
@@
if (!_unsavedChanges && msg.Load >= 0)
{
- if (msg.Load >= 1_000_000_000)
- {
- Load.Text = $"{msg.Load / 1_000_000_000:G3}";
- PowerDropDown.TrySelect(3);
- }
- else if (msg.Load >= 1_000_000)
- {
- Load.Text = $"{msg.Load / 1_000_000:G3}";
- PowerDropDown.TrySelect(2);
- }
- else if (msg.Load >= 1_000)
- {
- Load.Text = $"{msg.Load / 1_000:G3}";
- PowerDropDown.TrySelect(1);
- }
- else
- {
- Load.Text = $"{msg.Load:G3}";
- PowerDropDown.TrySelect(0);
- }
+ _syncingState = true;
+ try
+ {
+ if (msg.Load >= 1_000_000_000)
+ {
+ Load.Text = $"{msg.Load / 1_000_000_000:G3}";
+ PowerDropDown.TrySelect(3);
+ }
+ else if (msg.Load >= 1_000_000)
+ {
+ Load.Text = $"{msg.Load / 1_000_000:G3}";
+ PowerDropDown.TrySelect(2);
+ }
+ else if (msg.Load >= 1_000)
+ {
+ Load.Text = $"{msg.Load / 1_000:G3}";
+ PowerDropDown.TrySelect(1);
+ }
+ else
+ {
+ Load.Text = $"{msg.Load:G3}";
+ PowerDropDown.TrySelect(0);
+ }
+ }
+ finally
+ {
+ _syncingState = false;
+ }
}
}
@@
private void SetUnsavedChanges()
{
+ if (_syncingState)
+ return;
_unsavedChanges = true;
UnsavedChanges.Visible = true;
}Also applies to: 78-99, 120-124
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Content.Client/_NF/Power/AdjustablePowerDrawMenu.xaml.cs` around lines 46 -
48, The UI event handlers on PowerDropDown.OnItemSelected and Load.OnTextChanged
always call SetUnsavedChanges(), which causes programmatic sync from Update() to
be treated as user edits. Add a guard in AdjustablePowerDrawMenu to distinguish
internal UI updates from real user interaction, and make Update() set
Load.Text/select dropdown without triggering SetUnsavedChanges() during
synchronization. Ensure the handlers only mark unsaved changes when the change
comes from user input, not when SelectId or Load.Text is being set by the
control itself.
| TogglePowerButton.Text = Loc.GetString( | ||
| on ? "comp-gas-pump-ui-status-enabled" : "comp-gas-pump-ui-status-disabled"); |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Use as chaves de locale deste componente no status de energia
Em Line 131-132, a UI usa comp-gas-pump-ui-status-*, mas este PR adiciona adjustable-power-status-*. Isso deixa strings novas sem uso e pode quebrar consistência de tradução.
💡 Sugestão de correção
TogglePowerButton.Text = Loc.GetString(
- on ? "comp-gas-pump-ui-status-enabled" : "comp-gas-pump-ui-status-disabled");
+ on ? "adjustable-power-status-enabled" : "adjustable-power-status-disabled");📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| TogglePowerButton.Text = Loc.GetString( | |
| on ? "comp-gas-pump-ui-status-enabled" : "comp-gas-pump-ui-status-disabled"); | |
| TogglePowerButton.Text = Loc.GetString( | |
| on ? "adjustable-power-status-enabled" : "adjustable-power-status-disabled"); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Content.Client/_NF/Power/AdjustablePowerDrawMenu.xaml.cs` around lines 131 -
132, The power status label in AdjustablePowerDrawMenu should use this
component’s new locale keys instead of the gas-pump ones. Update the
TogglePowerButton.Text assignment in the AdjustablePowerDrawMenu logic to
reference the adjustable-power-status enabled/disabled strings so the UI stays
consistent with the new translations and avoids leaving the new locale entries
unused.
| if (spawn.AccumulatedEnergy >= spawn.EnergyPerSpawn) | ||
| { | ||
| // End current run. | ||
| spawn.AccumulatedEnergy = 0; | ||
| spawn.Processing = false; | ||
| TrySpawnInContainer(spawn.Spawn, uid, spawn.SlotName, out _); | ||
|
|
||
| // Try to start next run. | ||
| TryConsumeResources((uid, spawn)); |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Não descarte o lote antes de confirmar o spawn no slot.
Nas Lines 130-138, o ciclo é encerrado antes de checar o retorno de TrySpawnInContainer(...). Com o slot único output definido em Resources/Prototypes/_NF/Entities/Structures/Machines/ame_fab.yml nas Lines 128-139, basta deixar um jar no slot para a máquina zerar AccumulatedEnergy, perder o progresso concluído e potencialmente consumir mais plasteel sem produzir nada. Além disso, o = 0 descarta qualquer energia excedente do ciclo. Avance para o próximo lote só depois de um spawn bem-sucedido e preserve o excedente com -=.
💡 Ajuste sugerido
if (spawn.AccumulatedEnergy >= spawn.EnergyPerSpawn)
{
- // End current run.
- spawn.AccumulatedEnergy = 0;
- spawn.Processing = false;
- TrySpawnInContainer(spawn.Spawn, uid, spawn.SlotName, out _);
+ if (!TrySpawnInContainer(spawn.Spawn, uid, spawn.SlotName, out _))
+ continue;
+
+ // End current run.
+ spawn.AccumulatedEnergy -= spawn.EnergyPerSpawn;
+ spawn.Processing = false;
// Try to start next run.
TryConsumeResources((uid, spawn));
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (spawn.AccumulatedEnergy >= spawn.EnergyPerSpawn) | |
| { | |
| // End current run. | |
| spawn.AccumulatedEnergy = 0; | |
| spawn.Processing = false; | |
| TrySpawnInContainer(spawn.Spawn, uid, spawn.SlotName, out _); | |
| // Try to start next run. | |
| TryConsumeResources((uid, spawn)); | |
| if (spawn.AccumulatedEnergy >= spawn.EnergyPerSpawn) | |
| { | |
| if (!TrySpawnInContainer(spawn.Spawn, uid, spawn.SlotName, out _)) | |
| continue; | |
| // End current run. | |
| spawn.AccumulatedEnergy -= spawn.EnergyPerSpawn; | |
| spawn.Processing = false; | |
| // Try to start next run. | |
| TryConsumeResources((uid, spawn)); | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@Content.Server/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.cs`
around lines 130 - 138, The spawn cycle in EntitySpawnPowerConsumerSystem should
not be finalized before confirming TrySpawnInContainer succeeds, and
AccumulatedEnergy should preserve any overflow instead of being reset. Update
the logic around TrySpawnInContainer, TryConsumeResources, and the
spawn.AccumulatedEnergy / spawn.Processing handling so the batch only advances
after a successful output-slot spawn. Keep the completed progress if the spawn
fails, and subtract EnergyPerSpawn rather than clearing all accumulated energy
to avoid losing excess energy.
| private TimeSpan _lastUiUpdate = TimeSpan.Zero; | ||
| private static readonly TimeSpan UiUpdateCooldown = TimeSpan.FromSeconds(0.5f); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
O throttle da UI está global para o sistema, não por máquina/BUI.
_lastUiUpdate é compartilhado por todas as instâncias. Se duas interfaces forem abertas ou ajustadas dentro de 0.5 s, a segunda cai no return de Line 233-234 e pode ficar sem estado inicial, porque não existe refresh periódico fora dessas ações.
Also applies to: 230-236
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@Content.Server/_NF/Manufacturing/EntitySystems/GasSpawnPowerConsumerSystem.cs`
around lines 41 - 42, The UI throttle in GasSpawnPowerConsumerSystem is
currently shared across all instances because _lastUiUpdate is a single system
field, so one machine/BUI update can suppress another and leave it without an
initial refresh. Move the cooldown tracking to per-machine/per-UI state in the
relevant update path (for example in the methods that handle BUI refresh/state
sync around the current return guard), and ensure each opened interface can send
its initial state independently even if another update happened within
UiUpdateCooldown.
| var deltaP = Atmospherics.MaxOutputPressure - canister.Air.Pressure; | ||
| var maxMoles = deltaP * canister.Air.Volume / (_mixture.Temperature * Atmospherics.R); | ||
| molesToSpawn = MathF.Min(molesToSpawn, maxMoles); | ||
|
|
||
| _mixture.Multiply(molesToSpawn / _mixture.TotalMoles); | ||
| _atmos.Merge(canister.Air, _mixture); |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Canister acima da pressão máxima pode gerar molesToSpawn negativo.
Em Line 137-139, se canister.Air.Pressure já estiver acima de MaxOutputPressure, deltaP fica negativo, maxMoles também, e Line 141 multiplica a mistura por um fator negativo antes do merge. Isso pode remover/corromper gás do canister em vez de só impedir produção.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@Content.Server/_NF/Manufacturing/EntitySystems/GasSpawnPowerConsumerSystem.cs`
around lines 137 - 142, The GasSpawnPowerConsumerSystem spawn path can produce a
negative moles amount when the canister pressure is already above the maximum,
which then feeds a negative factor into the mixture scaling before merge. Update
the logic around the deltaP/maxMoles calculation to clamp the allowed spawn
amount at zero (or return early when the canister is over MaxOutputPressure)
before calling _mixture.Multiply and _atmos.Merge, using the
GasSpawnPowerConsumerSystem spawn flow and the molesToSpawn/maxMoles variables
as the key points to adjust.
| if (power <= ent.Comp.LinearMaxValue) | ||
| actualPower = power; | ||
| else | ||
| { | ||
| actualPower = ent.Comp.LogarithmCoefficient * MathF.Pow( | ||
| ent.Comp.LogarithmRateBase, | ||
| MathF.Log10(power / ent.Comp.LinearMaxValue) - ent.Comp.LogarithmSubtrahend | ||
| ); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
A curva logarítmica colapsa assim que passa de LinearMaxValue.
Em Line 170-172, com os valores default, power = 2_000_001 entra no ramo log e cai para ~2.5 W (800 * 2.5^(log10(1)-6.301)), enquanto 2_000_000 ainda rende 2 MW. Isso não suaviza a curva; ele praticamente desliga a máquina logo após o threshold.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@Content.Server/_NF/Manufacturing/EntitySystems/GasSpawnPowerConsumerSystem.cs`
around lines 166 - 173, A curva de potência em
GasSpawnPowerConsumerSystem.GasPowerConsumer provavelmente está usando a fórmula
logarítmica de forma invertida, causando uma queda abrupta logo após
LinearMaxValue. Ajuste o cálculo no ramo else para que a transição a partir de
LinearMaxValue seja contínua e crescente, revisando os termos usados em
ent.Comp.LogarithmCoefficient, ent.Comp.LogarithmRateBase e
ent.Comp.LogarithmSubtrahend. Verifique o comportamento do método/trecho que
calcula actualPower para que valores logo acima do limite não colapsem para
poucos watts.
| if (_timing.CurTime >= xmit.NextDeposit) | ||
| { | ||
| xmit.NextDeposit += xmit.DepositPeriod; | ||
|
|
||
| if (!float.IsFinite(xmit.AccumulatedEnergy) || !float.IsPositive(xmit.AccumulatedEnergy)) | ||
| { | ||
| xmit.AccumulatedEnergy = 0.0f; | ||
| continue; | ||
| } | ||
|
|
||
| float totalPeriodSeconds = (float)xmit.DepositPeriod.TotalSeconds; | ||
| float depositValue = GetPowerPayRate((uid, xmit), xmit.AccumulatedEnergy / totalPeriodSeconds) * totalPeriodSeconds; | ||
|
|
||
| xmit.AccumulatedEnergy = 0.0f; |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Atrasos de frame supervalorizam o depósito.
NextDeposit avança só um período por Update, mas AccumulatedEnergy pode representar vários períodos quando o servidor atrasa. Nessa situação, toda a energia atrasada é convertida usando apenas um DepositPeriod, o que credita mais dinheiro do que deveria antes de zerar o acumulador. Calcule o pagamento pelo tempo real transcorrido desde o último depósito, ou processe todos os períodos vencidos sem reaproveitar a mesma energia.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Content.Server/_NF/Power/EntitySystems/PowerTransmissionSystem.cs` around
lines 101 - 114, The deposit calculation in PowerTransmissionSystem.Update is
using only one DepositPeriod even when the server has fallen behind and
AccumulatedEnergy spans multiple elapsed periods. Update the logic around
xmit.NextDeposit and xmit.AccumulatedEnergy so payment is based on the real time
since the last deposit, or iterate through all overdue deposit intervals and
consume energy per period instead of paying the same backlog once before zeroing
it.
| @@ -0,0 +1,2 @@ | |||
| entity-spawn-power-consumer-examine = The machine is consuming [color=lightblue]{POWERWATTS($actual)}[/color]/[color=lightblue]{POWERWATTS($requested)}[/color] of power. | |||
| entity-spawn-power-consumer-estimated-time = Estimated time to produce one unit: [color=yellow]{TOSTRING($time, "hh\\:mm\\:ss")}[/color] | |||
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate the locale and system files mentioned in the review comment.
git ls-files 'Resources/Locale/en-US/_NF/manufacturing/entity-spawn-power-consumer-component.ftl' \
'Content.Server/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.cs'
# Show the relevant portions with line numbers.
echo '--- locale file ---'
cat -n Resources/Locale/en-US/_NF/manufacturing/entity-spawn-power-consumer-component.ftl
echo '--- server file excerpt ---'
sed -n '150,210p' Content.Server/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.csRepository: Project-Dumont/Dumont-Station
Length of output: 3189
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect surrounding definitions for the time source and formatting path.
rg -n "GetGenerationTime|Estimated time to produce one unit|TOSTRING\\(|TimeSpan" Content.Server Content.Shared Resources/Locale -S
# Find the exact locale string usages if any.
rg -n "entity-spawn-power-consumer-estimated-time|entity-spawn-power-consumer-examine" -S .Repository: Project-Dumont/Dumont-Station
Length of output: 50386
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read only the specific lines around the locale string and time formatting logic.
echo '--- locale file (top) ---'
sed -n '1,20p' Resources/Locale/en-US/_NF/manufacturing/entity-spawn-power-consumer-component.ftl
echo '--- system file (generation time and examine text) ---'
sed -n '160,190p' Content.Server/_NF/Manufacturing/EntitySystems/EntitySpawnPowerConsumerSystem.csRepository: Project-Dumont/Dumont-Station
Length of output: 1745
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the implementation of GetGenerationTime and any related fields/configuration.
rg -n "GetGenerationTime|GenerationTime|PowerConsumer|SpawnPowerConsumer|estimated time|adjustable draw|W/kW/MW/GW" Content.Server Content.Shared Resources -S
# If GetGenerationTime is present, print a wider window around it.
file=$(rg -l "GetGenerationTime" Content.Server Content.Shared Resources -S | head -n 1)
if [ -n "${file:-}" ]; then
echo "--- $file ---"
sed -n '1,260p' "$file"
fiRepository: Project-Dumont/Dumont-Station
Length of output: 27396
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Look for the power-adjustment UI and any bounds/clamping that would limit the generation time.
rg -n "W/kW/MW/GW|draw|power.*slider|adjust.*power|clamp|minimum.*power|maximum.*power|GetGenerationTime" Content.Client Content.Shared Content.Server -S
# Find any documentation or comments about expected output duration formatting.
rg -n "days|hh\\\\:mm\\\\:ss|TimeSpan|estimated time to produce one unit" Resources Content.Server Content.Shared -SRepository: Project-Dumont/Dumont-Station
Length of output: 50386
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the component values that determine the possible generation time range.
sed -n '1,220p' Content.Shared/_NF/Manufacturing/Components/EntitySpawnPowerConsumerComponent.cs
echo '---'
sed -n '1,220p' Content.Shared/_NF/Power/Components/AdjustablePowerDrawComponent.cs
echo '---'
sed -n '1,220p' Resources/Prototypes/_NF/Entities/Structures/Machines/ame_fab.ymlRepository: Project-Dumont/Dumont-Station
Length of output: 4738
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate the adjustable power draw definitions and relevant prototype values.
git ls-files | rg '_NF/.*/AdjustablePowerDraw|AdjustablePowerDrawComponent|EntitySpawnPowerConsumerComponent|ame_fab.yml'Repository: Project-Dumont/Dumont-Station
Length of output: 491
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the shared component that defines the minimum/maximum requestable power and energy per spawn.
cat -n Content.Shared/_NF/Manufacturing/Components/EntitySpawnPowerConsumerComponent.cs
echo '---'
# Read the UI component/prototype that may constrain the adjustable power range.
git ls-files | rg 'AdjustablePowerDraw'Repository: Project-Dumont/Dumont-Station
Length of output: 5796
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the component defaults and ranges for the spawn power consumer.
cat -n Content.Shared/_NF/Manufacturing/Components/EntitySpawnPowerConsumerComponent.cs
echo '---'
# Show the prototype instance that uses this component.
sed -n '90,150p' Resources/Prototypes/_NF/Entities/Structures/Machines/ame_fab.ymlRepository: Project-Dumont/Dumont-Station
Length of output: 7002
A estimativa esconde dias acima de 24h.
Na linha 2, TOSTRING($time, "hh\\:mm\\:ss") faz wrap do TimeSpan a cada 24h. Com MinimumRequestablePower = 500 e EnergyPerSpawn = 1.2 GJ, a estimativa pode passar de um dia, então o texto omite os dias e mostra um valor incorreto.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@Resources/Locale/en-US/_NF/manufacturing/entity-spawn-power-consumer-component.ftl`
at line 2, The estimated-time label in entity-spawn-power-consumer-component.ftl
is formatting the TimeSpan with TOSTRING($time, "hh\\:mm\\:ss"), which wraps
after 24 hours and hides days. Update the localization string used by
entity-spawn-power-consumer-estimated-time so it formats long durations with
days included, and keep the change localized to the estimated-time output path
in the relevant manufacturing entity-spawn power consumer text.
| - type: BatteryInterface | ||
| minChargeRate: 50000 | ||
| maxChargeRate: 1500000 | ||
| minSupply: 50000 | ||
| maxSupply: 1500000 | ||
| - type: Battery | ||
| maxCharge: 80000000 | ||
| - type: PowerNetworkBattery | ||
| maxSupply: 1500000 | ||
| maxChargeRate: 50000 | ||
| supplyRampTolerance: 50000 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
O limite real de carga ficou preso em 50 kW.
BatteryInterface.maxChargeRate permite 1.5 MW, mas PowerNetworkBattery.maxChargeRate continua em 50 kW. Na prática, o BLES vai anunciar uma taxa muito maior do que a rede consegue aplicar, o que deixa a máquina bem mais lenta do que o protótipo sugere. Alinhe os dois valores para evitar esse descompasso.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Resources/Prototypes/_NF/Entities/Structures/Power/smes.yml` around lines 35
- 45, The SMES prototype has a charge-rate mismatch:
BatteryInterface.maxChargeRate is much higher than
PowerNetworkBattery.maxChargeRate, so the device advertises more charging
capacity than the network can actually apply. Update the PowerNetworkBattery
values in the smes prototype to match the intended BatteryInterface charging
limits, and keep the related charge/supply settings consistent so the runtime
behavior matches the prototype's advertised rate.
O de fabricar combustível de AME acho ok. Mas o PTL não acho que seria bacana, pois é praticamente um rework do nosso PTL atual que é bem sem graça e que não incentiva os engenheiros buscar mais formas de fazer energia. |
Esse PTL novo é mapeado onde? Eu troco o nosso antigo por esse novo? |
Sim, você pode trocar o PTL antigo para o novo sem problemas. Mas faz o que tu achar melhor, vendo agora ele até parece que ocupa menos espaço do que PTL antigo. |
|
Deixar comentado aqui no Github, mas igual eu falei no Discord, tem diversas questões dessa PR que eu acharia que seria bom discutir sobre. |
Mais 72 horas 🥺 |
|
tá, algumas varias anotações que eu tivse sobre isso essas são problemas que vale colocar em mente, mas n é necessario pra esse pr:
agr esses problemas são problemas com esse pr que eu vi:
do jeito que está atualmente, não acho que é uma boa dar merge. possivelmente seria bom colocar o PTL como pesquisa da sci, ou nerfar a geração de dinheiro de alguma maneira. sobre o fabricador anti materia, eu n sei sinceramente voces podem me falar alguma coisa pra tentar me convencer, claro |
Respondendo algumas questões. Não acredito que uma "outra" forma de ganhar dinheiro vá prejudicar ainda mais a cargo, pois ela é quebrada de qualquer forma não importa o que você faça para balancear. Quando você atinge a marca de cinquenta mil ou até mesmo abaixo disso, a quantidade de dinheiro torna obsoleta(Particularmente Departamento de Cargo só é importante para parte material, pois de resto ela é totalmente... inútil. Poucas pessoas vão para cargo sabendo que pode fazer tudo o que quiser com cinco mil de aço no silo). Particularmente PTL atual vs PTL novo não ia mudar o problema da cargo, pois ela está no fundo do poço de qualquer forma(Um rework completo da cargo seria mt bom, mas isso é outro tópico). Eeh, eu acho legal fabricar AME. Acho mais um desafio do que um conteúdo propriamente legal mesmo, então particularmente nem ligo muito. Pode explodir. Pequenos problema:
Uns problemas: Aparentemente tem um fabrica de gas ai no meio e sem prototype. Aparentemente... enfim, acredito devo apenas expurgar todo code que tenha haver com isso, certo? Dps fazer commit com as mudanças. Junto disso, essa smes subframezada nem tem como fazer dentro do jogo pelo que eu notei, então sei la. Poderia ser uma pesquisa da sci ou coisa parecida, mas padrao de sprite foge mt. Sobre fabricar AME nao acho necessario mesmo tambem, entao vou remover dps commit. |
|
bem, a cargo estando na merda meio que n é desculpa pra deixar pior ainda. sobre o audio, confesso que prestei mais atenção ao fabricador, que n tem audio mesmo. o contador de dopamina se torna ainda melhor com um desafio invez de ser fácil que nem mamão, faz cada subida de numero ser mais satisfatorio. n tenho certeza sobre esse nerf da teg? posso checar isso dps |
Mas cara, então proponha uma solução melhor para toda a cargo. Pois se a cargo quiser ela pode vender todo material start round minerado e não precisa fazer nenhuma bounty, e tu ainda está considerando uma estação com toda fonte de energia feita, sendo que isso tu dificilmente vê isso dentro do jogo. Se perguntar para qualquer um o que mais vê é a estação rodando só de AME. Quero dizer, para tu ter uma quantidade igual PTL tu ia precisar gerar cerca de 1 MW constante. É mais desafio do que o atual, e ainda é mais legal do que o padrão. Eu mesmo que fiz o nerf. TEG tá gerando uma seis vezes menos agora. |
|
O sprite do PTL atual ele combina com o restante, o novo é um estilo industrial e bruto mais diferente do nosso. Questão de energia, SM e TEG são ápice, porém uma tesla consegue muito facilmente MWs, até a mais segura e básica das teslas. Fora questão visual, em funcional eu acho que deveria remover muita coisa não usada daí.
Acho que o PTP e Fab de anti matéria deveriam ser ambos pesquisas da Sci. Fabricador deveria ser significativamente mais caro pra fazer um frasco, porque AME é seguro e quase invalida outros geradores de energia na maioria das estações. O PTP eu achei o uso dele muito desinteressante. Não tem risco nenhum e nada de especial, é uma estrutura que aceita energia e sai dinheiro. PTL atual ele tem o risco de radiação e cria o laser que pode ser mal utilizado de forma ofensiva criando oportunidades antagonisticas. Dá mesma forma que não tem como roubar e se aproveitar da tentação de pegar o dinheiro, já que ele vai diretamente para a conta. Em geral só achei legal da PR o fabricador de anti matéria, que é bem nicho mas existe. Mas é simples demais, acredito que fabricar anti matéria de forma mais interessante por meio de algo atmosférico como o cristalizador seria mais temático e divertido. |
6 participants
Sobre a PR
Aonde foi portado: funky-station/funky-station#2330
Essa PR adiciona duas novas máquinas que usam a energia que está sobrando: uma para venda e outra para fazer combustível de AME.
Por quê? / Balanceamento
O nosso PTL atual é bem... paia. Não dá para configurar ele de forma decente, a quantidade de energia que a estação está gerando pouco interfere no valor pois sempre será 5% do PTL e sem falar da maracutaia para ele não comer a energia da estação. O PTL portado é totalmente configurável e gera de acordo com a energia que está sendo recebida. Ou seja, se tu está gerando 20 MW vai receber de acordo, se está gerando 100 KW vai receber de acordo, diferente do PTL que é um valor fixo. Agora os engenheiros têm um motivo para fazer diversos geradores (sem dizer que o dinheiro cai direto nas contas do departamento).
Sobre fabricar combustível de AME é bem interessante, mas acredito que talvez valha dar uma mudada. Pois o combustível fabricado tem bastante unidade, umas cerca de três vezes mais. Talvez adequar ao valor padrão, pois pelos meus testes, 1 MW de energia no fabricador dá um combustível de AME a cada 20 minutos.
Ok, muito divertido e tals... Mas essa mudança exige mapeamento. São duas máquinas ENORMES e que ocupam bastante espaço. Infelizmente, o nosso PTL atual está posicionado nos piores lugares possíveis... então deve fazer uma mudança para que fique legal. Eu resolvi jogar um mapa aleatório do Funky e notei que essas duas máquinas estão mapeadas no Box (só pra ter uma noção de qual mapa tem). Não acho que seja necessário ter uma em cada mapa, talvez ter o PTL novo já seja legal o suficiente.
Detalhes Técnicos
Foi meu primeiro Cherry-Pick e talvez tenha algum erro. Mas os arquivos modificados APARENTEMENTE não dão BO... eu acredito. Quando testei as duas máquinas funcionaram de forma perfeita sem erro.
Anexos
Requerimentos
Changelog
🆑