mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-09-30 19:21:33 +02:00
maziggy
b1f5ec9642
Two features in the slice dialog read as one. "Use the file's built-in settings" slices a 3MF the way its designer set it up, ignoring the picked profiles. The per-option "from file" ticks beside each setting carry the designer's individual deviations onto the profile you picked, and those arrived pre-ticked whatever the checkbox said. So a slice run deliberately without the file's settings still took sixteen values out of it -- the reporter's log names them, enable_support and support_type among them, landing on a process preset they had chosen on purpose. The ticks now follow the checkbox. Off, nothing comes out of the file until it is asked for by name; on, every setting the file changed shows ticked, because on that path the file really does drive the whole slice. Taking the designer's work in bulk is still one click, from a line at the top of the panel that says how many settings the file changed -- it is the only way left to reach them without hunting for chips across six pages of 348 options -- and it still leaves the machine-tuned keys and the two that are the picked preset for a per-key decision. The panel greys out options the slicer's own rules switch off, and it was evaluating those rules against what the user had typed alone, falling back to the compiled-in schema defaults for the rest. A preset with supports on therefore read as enable_support: false and greyed out the whole Support page while the slice ran supports. A greyed row greyed its tick too, which is how the reporter's screenshot shows a support type marked "from file", applied to the slice, and impossible to clear. The rules now see what the slice will actually run with: the preset's values, the file's values for the keys that are on, and anything typed on top. The tick is no longer gated on those rules at all -- it answers a different question, not whether an option is in play but where its value comes from. Underneath both, the support carry-over ran outside the ticks entirely, lifting four keys out of any 3MF that had supports on with nothing on screen able to decline. It now stands down for the keys that were offered and turned down, which the request can say for the first time: an empty design_overrides list means the caller was shown the file's settings and took none, where no list at all is a caller that predates the choice. That distinction is what keeps the carry whole for sources with no deviations to tick, an OrcaSlicer export among them, rather than trading one silent default for another. Worth knowing: a Bambu Studio file with supports enabled no longer switches supports on for you. Tick Enable support, or the checkbox above the panel. Measured against the reporter's own sixteen keys, and covered by backend and frontend tests -- reverting any one of the three changes fails tests.
React + TypeScript + Vite
This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.
Currently, two official plugins are available:
- @vitejs/plugin-react uses Babel (or oxc when used in rolldown-vite) for Fast Refresh
- @vitejs/plugin-react-swc uses SWC for Fast Refresh
React Compiler
The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see this documentation.
Expanding the ESLint configuration
If you are developing a production application, we recommend updating the configuration to enable type-aware lint rules:
export default defineConfig([
globalIgnores(['dist']),
{
files: ['**/*.{ts,tsx}'],
extends: [
// Other configs...
// Remove tseslint.configs.recommended and replace with this
tseslint.configs.recommendedTypeChecked,
// Alternatively, use this for stricter rules
tseslint.configs.strictTypeChecked,
// Optionally, add this for stylistic rules
tseslint.configs.stylisticTypeChecked,
// Other configs...
],
languageOptions: {
parserOptions: {
project: ['./tsconfig.node.json', './tsconfig.app.json'],
tsconfigRootDir: import.meta.dirname,
},
// other options...
},
},
])
You can also install eslint-plugin-react-x and eslint-plugin-react-dom for React-specific lint rules:
// eslint.config.js
import reactX from 'eslint-plugin-react-x'
import reactDom from 'eslint-plugin-react-dom'
export default defineConfig([
globalIgnores(['dist']),
{
files: ['**/*.{ts,tsx}'],
extends: [
// Other configs...
// Enable lint rules for React
reactX.configs['recommended-typescript'],
// Enable lint rules for React DOM
reactDom.configs.recommended,
],
languageOptions: {
parserOptions: {
project: ['./tsconfig.node.json', './tsconfig.app.json'],
tsconfigRootDir: import.meta.dirname,
},
// other options...
},
},
])