mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-10-05 13:41:36 +02:00
Published models often deviate from the stock Bambu profile on purpose - five walls, 100% infill, a 0.1mm first layer. Re-slicing one for a different printer discarded all of it: the picked process preset overrides the file's embedded settings, and that override is precisely what makes cross-printer re-slicing work, so it cannot just be dropped. "Slice as designed" (#2611) does not help - it is all-or-nothing and only offered when the picked printer already matches the design's target. The deviation list does not have to be computed. Bambu Studio writes it into the 3MF as different_settings_to_system, laid out as [process, *filaments, printer] - verified against real files at 2, 3 and 4 filament slots. The parser refuses any file whose array length contradicts its own filament count rather than guessing an index, since reading the printer slot as the process slot would carry the designer's machine_start_gcode onto a foreign printer. The slice dialog now lists exactly which print settings the author changed and what each was set to, with a checkbox per setting. Design intent - wall count, infill, layer and first-layer height, supports, seam, brim, ironing - is ticked by default. Printer-specific values - speeds, accelerations, jerk, fans, temperatures, prime-tower geometry - are listed with a badge but start unticked: tuned for the author's machine, they can be merely wrong on the target or outside the range its profile accepts, which fails the slice outright. Only ticked keys are sent, and only keys the source actually flags as changed are applied. Values are written into the outgoing process JSON, the same mechanism the support carry-over has used since #1881: for a Standard preset pick that JSON is an inherits stub, so the patch is the child in the chain and wins over the flattened parent. Process slot only - filament picks are honoured as chosen. The wiki's "this is not a settings merge" note under Slice as designed described the gap this closes; rewritten to point at the new panel. Translated in all locales; wiki updated. Covered by backend and frontend 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...
},
},
])