nikon SUHHHCKSSSS

The short answer: you’re not imagining it — the Nikon Z7II does accumulate “virtual” dial turns in P (Flexible Program) when you hit the end of the aperture/shutter range with Auto ISO active.* This is normal behavior for Nikon’s implementation, but it’s undeniably clunky and feels wrong in use.

Below is a clear explanation of why it happens, what’s going on internally, and what you can do to avoid or mitigate it.

🎯 Core takeaway

When Auto ISO is enabled, Program Shift stops updating once the camera hits a hard exposure boundary (minimum shutter speed, minimum ISO, maximum aperture, etc.). But the camera still counts your dial rotations, even though it can’t change the exposure triangle any further. So when you turn the dial back, you must “rewind” all those stored steps before the camera can resume changing aperture/shutter.

This behavior is confirmed in Nikon documentation and analysis of Flexible Program mode. 

🧠 Why Nikon behaves this way

1. Flexible Program (P\) is designed to track a “shift offset”*

Nikon’s P\* mode doesn’t directly rotate through aperture/shutter pairs. Instead, it maintains an internal shift index — a number representing how far you’ve shifted from the default program line.

When you hit a limit (e.g., max aperture), the camera can’t change exposure anymore, but the shift index continues to increment.

This is why the camera “remembers” how many clicks past the limit you turned.

2. Auto ISO creates hard walls

With Auto ISO active, Nikon imposes strict boundaries:

• Minimum shutter speed (from Auto ISO settings)

• Minimum ISO

• Maximum aperture

• Maximum shutter speed

Once the camera hits any of these, it refuses to change the other parameters to compensate — a behavior Nikon explicitly documents. 

So P\* runs out of valid exposure combinations, but the shift index keeps moving.

3. Nikon does not “clip” the shift index at the ends

Some brands (e.g., Canon) clamp the shift so that turning past the limit does nothing and does not accumulate.

Nikon does not.

This is why you must unwind the dial to get back into the valid range.

🛠️ Is this a bug?

It’s not classified as a bug — Nikon considers it normal behavior for Flexible Program with Auto ISO. But many users consider it a usability flaw.

✔️ Practical ways to avoid the problem

1. Set a slower Auto ISO minimum shutter speed

This gives P\* more room before hitting the wall.

Try: Menu → Photo Shooting → ISO sensitivity settings → Minimum shutter speed

2. Disable Auto ISO when using P\*

With fixed ISO, P\* works exactly as expected and does not prematurely hit limits. Nikon documentation confirms this difference. 

3. Use A or S mode instead

If you want:

• Aperture control → A mode + Auto ISO

• Shutter control → S mode + Auto ISO

These modes behave more predictably with Auto ISO.

4. Assign ISO to a dial and manually adjust ISO when needed

This avoids the P\* dead-end while keeping exposure flexible.

📌 Bottom line

You’ve correctly identified a real quirk of Nikon’s P\* implementation: the camera keeps counting dial turns even when it can’t change exposure, forcing you to unwind them later.

It’s not fixable in settings, but you can avoid it by adjusting Auto ISO behavior or using A/S modes when Auto ISO is essential.

If Program Shift behavior is important to you — especially avoiding Nikon’s “dial overshoot” problem — then:

Sony, Olympus, and Panasonic are the cleanest and least confusing.

Fuji is also clean, but Program Shift is less central to their design.

Nikon is the only major brand with the hidden shift-index behavior.

It’s a legacy of how Nikon DSLRs implemented P\*

either/or

so much of usability and user experience is so bad that i now assume 90% of the stuff is made by either

idiots

or

assholes

node

is a ghetto

non-sense

https://github.com/processing/p5.js/wiki/Getting-started-with-WebGL-in-p5

why would you force everyone to use mostly negative z values everywhere? (the history of coordinate system choices for graphics is forever full of strange stuff.)

never forget

 #ODWALLAKILLEDPEOPLE

oh, i loathe steam

The short answer: Steam is warning you because something in your app’s configuration still counts as “changed but not submitted,” even if you already published a build. This usually happens when the store page or metadata has pending edits — not the build itself.

Below is a clear, practical breakdown of what causes this and how to fix it.

---

Why Steam says “This app has unpublished changes”

Steam distinguishes between content builds and store metadata. Publishing a build does not automatically publish store‑page changes.

The warning appears when any of the following still have unsent edits:

• Store page fields (description, screenshots, tags, categories, pricing, supported languages)
• Capsule images or other graphical assets
• Release settings (visibility, coming‑soon settings)
• Depots or build assignments not finalized in the Publish tab
• Package or pricing changes pending approval

Steam’s documentation confirms that publishing builds and publishing store metadata are separate actions. Steamworks

---

How to fix it (step‑by‑step)

Each item below starts with a Guided Link so you can jump directly into the next step if needed.

• Check the Publish tab — Go to Steamworks → Your App → Publish. Look for any section marked with a yellow warning icon. Even a single unconfirmed field will block publishing.
• Review store page sections — Open Store Page → Edit Store Page. Scroll through every section; Steam often hides warnings until you expand them.
• Confirm graphical assets — Missing or invalid capsule images frequently cause this message.
• Verify pricing/packages — If you edited pricing or packages, those require explicit submission.
• Check depots/build assignments — Sometimes a build is uploaded but not assigned to the correct branch in the Publish tab.
• Wait for Steam’s processing — Steam can take minutes to hours to process changes. Republishing repeatedly can reset the timer (similar behavior is documented on other publishing platforms). kdpcommunity.com

---

Non‑obvious causes (these catch many devs)

• A single language version of the store page is incomplete
  Example: English is complete, but Spanish has a missing field.
• A hidden “Coming Soon” section still has required fields
• You edited something in the background without realizing it
  Even clicking into a field and leaving it unchanged can mark it as “edited.”
• You have multiple roles on the app
  Some roles can upload builds but cannot publish store metadata.

---

Quick diagnostic checklist

Use these Guided Links to jump to the relevant checks:

• Is the store page fully approved?
• Are all assets validated?
• Is the build assigned to the correct branch?
• Are there pricing/package changes pending?

---

If everything looks published but the warning persists

This happens occasionally due to Steamworks caching.

Try:

• Clear the Publish tab by toggling a field
  Change a field (e.g., add a space), save, remove the space, save again.
• Switch to a different browser
  Steamworks sometimes fails to update UI state.
• Ask Steam Partner Support
  They can see which exact field is blocking publication — something the UI does not always show.

---

Want me to help you pinpoint the exact cause?

If you tell me:

• Whether the warning appears on the Store Page, Publish tab, or Builds page
• Whether you recently changed pricing, assets, or languages
• Whether your app is released, coming soon, or unreleased

…I can walk you through the exact place to look.

Which part of Steamworks is showing the warning — the Store Page editor, the Publish tab, or the Builds page?

fumb ducks

> Your Google Pixel Android system update may pause due to sleep settings or battery-saving features, which limit background activity. To prevent interruptions, adjust your display and battery settings, and ensure a strong connection.