Snowstorm is a great tool that I use to preview the particles, however I prefer to write them as code. I usually have a spit screen with code on the one side and Snowstorm on the other side. A shortcut that lets hide Snowstorm's sidebar would greatly improve my workflow by making the preview bigger and removing the part of the screen that I don't use anyway.

An additional config option to make the .particle.json files open in code editor by default would also be very helpful for people, whose primary interaction with these files is in the code editor.

EDIT:
I found an option in VS Code that lets you change the default editor.

"workbench.editorAssociations": {
    "*.particle.json": "default" // Overwrite x11.snowstorm
},

You can still open Snowstorm editor by using CTRL+P -> >View: Toggle Editor Type option while having *.particle.json file open. So adding this feature to Snowstrom configuration would be redundant.

Addition of these features would enable following workflow:

1. Open particle file as code to edit something
2. Press some kind of shortcut to open preview (ideally with the sidebar closed)
3. Switch to code if you decide to apply some changes based on the results in the preview.

The community currently has no great accessible options for visual particle editors for Java edition; this is probably an expected and inevitable suggestion, but support for particles in a Minecraft Java Edition-readable format would be immensely appreciated. The incredible work done on Snowstorm (as well as 1.19 Java animation compatibility in Blockbench via plugin) gives me hope that this is possible. Thanks a bunch!

Description

When using builtin particle variables, such as variable.particle_age, Snowstorm will not properly evaluate the variable unless it is entered using the full name, variable.particle_age. The standard shorthand v.particle_age is not properly evaluated.

Reproduction Steps

• Create a default particle
• Enter a builtin variable in the form variable.<builtin> into any field that would produce a visual change, such as direction
• Observe that this variable is properly evaluated
• Change the variable to the form v.<builtin>
• Observe the variable is no longer evaluated

Affected Platforms

Tested in both the web version and VSCode extension

Video Demonstration

I tested the following expressions and some variations, I assume all alternative molang expressions behave the same

v.curve * molang expression returns 0

molang expression * v.curve works correctly

molang expression * v.curve * v.curve returns 0

molang expression * v.curve * molang expression returns 0

The Import feature does not work. You click import, and navigate to the particle file. Upon opening it, nothing changes and nothing is imported.

Particle JSON:

{
	"format_version": "1.10.0",
	"particle_effect": {
		"description": {
			"identifier": "hf:jet_ski_jet",
			"basic_render_parameters": {
				"material": "particles_alpha",
				"texture": "textures/particle/particles"
			}
		},
		"components": {
			"minecraft:emitter_local_space": {
				"position": true,
				"rotation": true
			},
			"minecraft:emitter_rate_steady": {
				"spawn_rate": 100,
				"max_particles": 500
			},
			"minecraft:emitter_lifetime_looping": {
				"active_time": 1
			},
			"minecraft:emitter_shape_point": {},
			"minecraft:particle_lifetime_expression": {
				"max_lifetime": 2
			},
			"minecraft:particle_initial_speed": 0.5,
			"minecraft:particle_motion_dynamic": {
				"linear_acceleration": [
					"query.log(query.modified_move_speed)",
					"50*query.modified_move_speed*Math.sin(150+(variable.particle_age*70))",
					3
				]
			},
			"minecraft:particle_appearance_billboard": {
				"size": [
					0.1,
					0.1
				],
				"facing_camera_mode": "lookat_xyz",
				"uv": {
					"texture_width": 128,
					"texture_height": 128,
					"uv": [
						0,
						16
					],
					"uv_size": [
						8,
						8
					]
				}
			}
		}
	}
}

Minimal JSON to reproduce:
The particle should flash between square and rectangular every half second, but it stays square.

{
	"format_version": "1.10.0",
	"particle_effect": {
		"description": {
			"identifier": "test:operator_equals",
			"basic_render_parameters": {
				"material": "particles_alpha",
				"texture": "textures/blocks/wool_colored_white"
			}
		},
		"components": {
			"minecraft:emitter_rate_steady": {
				"spawn_rate": 1,
				"max_particles": 100
			},
			"minecraft:emitter_lifetime_looping": {
				"active_time": 1
			},
			"minecraft:emitter_shape_point": {},
			"minecraft:particle_lifetime_expression": {
				"max_lifetime": 1
			},
			"minecraft:particle_initial_speed": 0,
			"minecraft:particle_motion_dynamic": {},
			"minecraft:particle_appearance_billboard": {
				"size": ["v.particle_age >= 0.5 ? 2 : 1", 0.2],
				"facing_camera_mode": "rotate_xyz",
				"uv": {
					"texture_width": 16,
					"texture_height": 16,
					"uv": [0, 0],
					"uv_size": [1, 1]
				}
			}
		}
	}
}

Like Blockbench is it possible to make Snowstorm accessible offline

Snowstor variant: VS Code
Description:
Parametric functions on the rotation aren't saved in Snowstor VS code. The rotation mode in the saved file is brounght automatically to Dynamic.

https://youtu.be/wPW7Q-2J1UM

Snowstor variant: VS Code
Description:
If a particle is renamed removing the .particle (or just the in between dot) to the name of the particle it will make that particle file unreadable for the plugin even if .particle is readded.

eg.
If the particle rain.particle.json is renamed in the following order
rain.particle.json>rain.json>rain.particle.json
the particle won't be opened with the snowstorm plugin.

This also affects renaming older particles with names not ending for .particle.json

I can't find any documentation on how this extension works. When I open a particles.json file, it just opens in VScode. When I open the extension from the Extensions panel, it just shows me basic readme information, which has led me here, but I don't see any info how this extension is activated.

After importing knockback_roar.json vanilla particle, I noticed, that it uses minecraft:particle_initial_speed component with an array as a value to define separate speeds for each axis. Snowstorm completely ignored that and instead treated those values as a direction.

Example from knockback_roar.json

"minecraft:particle_initial_speed": [ "15 * Math.random(-1.0, 1.0)", "15 * Math.random(-1.0, 1.0)", "15 * Math.random(-1.0, 1.0)" ],

When making a particle and setting facing_camera_mode: "direction_z", it renders Y direction incorrectly.

For particle with those components:

	"minecraft:particle_motion_parametric": {
		"direction": [0, 1, 0]
	},
	"minecraft:particle_appearance_billboard": {
		"size": [0.5, 0.5],
		"facing_camera_mode": "direction_z",
		"uv": {
			"texture_width": 128,
			"texture_height": 128,
			"uv": [0, 0],
			"uv_size": [128, 128]
		}
	}

The particles are visible when looking from the top, but when the same particle is created in Minecraft, it's visible only from the bottom. This causes me to always have to negate Y direction before using particles in Minecraft.

Sidenote: It may be very well Minecraft bug, because the way snowstorm renders it feels more correct, but it's like that in 1.16 and 1.17, so I don't see it fixed any time soon.

When using material particles_alpha, snowstorm still renders semi-transparency, when it should be either opaque or transparent completely. Due to this, I often forget to change the material before checking it in Minecraft, and wonder why particles don't show up.

Version: 2.3.2 in VSCode

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace. Custom editors are special in that if they cannot at least render in an untrusted state then they will be replaced by a lightweight message telling the user to enable trust. This means that users of your extension will not be able to see their editors and there may even be cases of data loss.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

We are planning on enabling this by default in the near future (most likely next release). To prepare for that day, we want to work with you to allow your editor to work seamlessly alongside the trusted workspace experience

Our Asks

The main features that should work for custom editors in an untrusted folder is rendering, viewing, and saving (if applicable). After reviewing your codebase, I believe that your extension doesn't rely on user contents in a way that could be taken advantage of if the files were malicious. My initial assessment would be to adopt supported:true and allow your extension to operate in untrusted workspaces.

Please let me know if you have any question or would like to meet up via voice chat as I would be happy to assist you in getting your extension ready for workspace trust!

Not exactly sure how to describe this accurately, so I will just provide steps to reproduce the bug:

1. Open a text box
2. Type a variable, math function, query, or temp variable
   eg: v.abcdefg
3. Move your cursor back with the arrow keys so that you are between characters in the variable
4. Press Enter
   result (from my example after pressing left 4 times before enter): v.abcdefgdefg

other possible results are:
inserting the name of an existing variable or molang querey / function
inserting a seemingly random character

This appears to be an autocomplete problem

where should I put textures in project? the extension does not load textures I put in project

According to the documentation, there are the components
minecraft:particle_lifetime_events
minecraft:emitter_lifetime_events
as well as the option "events" in the "minecraft:particle_motion_collision".

As far as I can tell, these are not implemented in snowstorm so far, but are an extremely powerful tool to make more complex or timed particles, as they can fire sounds or other particles.

There are two options on how to include them:
Minimal Version: Give the user the option to input the respective parameters without displaying them
Best Version: execute particle events in snowstorm if the respective files exist in VSCode (not going to work for the web version)

Greetings,
Chris

Platform: Android
Browser: Chrome for Android (Version 84.0.4147.89)

I experience a great frame rate drop when the 'Grid View' is enabled. However, the grid view is pretty useful to be disabled in my use case. I thought that this may be a bug as I've been using it lately on Android.

It only does it on Android, since I have tested the Grid View on a Chrome running on Windows 10 and I have found no issues at all.

Thank you for reading, and hope this to be fixed!

(Also, I would like to suggest a mobile-friendly view and a proper UV mapper for convenience similar to Blockbench.)

Snowstor variant: VS Code
Description:
Clicking on the View Code button, VS code will split the screen opening a new instance of the same particle without showing you the actual code

I spend 2 hours trying to run it but you cant put * into files for some reason and .particle.json dosent work

In a molang expression 0.5f should be allowed. See the endrod particle

Notifies about issues with the particle effect in real time. Shows small warning icon in bottom bar that extends into dialog

• Parametric motion, but not in local space
• Using opacity, but material not set to blend

For some reason, Snowstorm can't open JSON particle files that has some any form of comments inside it.

Steps to reproduce:

1. Create a particle, or use an example one.
2. Add comments to that JSON particle file in the form of // on any existing or new line.
3. Try importing it into Snowstorm.
4. For control, remove the comment and try importing it again.

At first I thought maybe there was just a delay importing it but I believe this is what's causing the issue. I hope to get this fixed! Unless otherwise if this is intended, then please change it.

Cheers!

It would be nice to have some default values for curves and gradients.

For curves: it would be nice to have variable. filled into name, variable.particle_age into Input, and variable.particle_lifetime into Range.

For gradients: it would be nice to have variable.particle_age / variable.particle_lifetime as default Interpolant, and 1 for Range.

That's my personal suggestion (as in not objective), I don't know about how other people use curves and gradients, but for me, whenever I use them, I always base off my particle effects off these values. Anyways, it's just a minor suggestion. Thank you for attention!

I like this software very much. Can we provide I18N interface for community members to translate into their own language? I think it's very helpful for the promotion of this app.

A suggestion here: the ability to preview multiple particle effects at once would be an incredible addition, and could be helpful in allowing users to create some elaborate multi-part effects.

Snowstorm cannot recognize texture .tga

The minecraft:particle_lifetime_expression component can be left empty to make a particle live indefinitely
https://bedrock.dev/docs/stable/Particles#Particle%20Lifetime%20Expression%20component

But when opening a particle system with no "max_lifetime" in Snowstorm, this component is automatically filled with max_lifetime": 1 (in the Snowstorm UI, it's "Max Age", under "Lifetime")

Putting "0" for the "Max Age" of the particle currently works to leave minecraft:particle_lifetime_expression empty, having that instead of 1 would work to fix this issue. Something more explicit could be nice, since a lifetime of 0 is unintuitive for beginners

If you open up a particle with vscode, all of snowstorm's option fields are set to default values.

While working with the Spawn Shape "Box" it would be useful to have a toggle to display/hide the actual Box Shape/Square in the preview.

I don't know whether you're actively support mobile version, but I noticed a couple of bugs regarding mobile and math expression fields, so here is my report:

Autocomplete bug

Whenever you do an autocomplete, when you click on the suggestion it will have an extra character in the beginning. So if you've typed v.em and then I click on emitter_age, it would insert v.eemitter_age.

Cursor mismatch

When field's math expression becomes longer than its width, it starts bugging out in sense of:

1. The typing cursor sometimes mismatches what you actually type. For example, your cursor is at the end of the math expression, but it appears like this: math.sin(v.emitter_age) * (v.part|icle_random_1 * 0.5 + 0.5) where | is the cursor.
2. The horizontal scrolling width becomes limited. Even if the cursor behaves correctly, I am not able to scroll through till the end of the text field's content whenever I space-holding moving the cursor. It just gets stuck as if had overflow: hidden;.

These bugs occurred to me on iOS 16.3.1.

Before opening snowstorm:

{
	"format_version": "1.10.0",
	"particle_effect": {
		"description": {
			"identifier": "sirlich:tile",
			"basic_render_parameters": {
				"material": "particles_opaque",
				"texture": "textures/particles/tile"
			}
		},
		"components": {
			"minecraft:emitter_rate_instant": {
				"num_particles": 1
			},
			"minecraft:emitter_lifetime_once": {
				"active_time": 1
			},
			"minecraft:emitter_shape_point": {},
			"minecraft:particle_lifetime_expression": {
				"max_lifetime": 1
			},
			"minecraft:particle_initial_speed": 2,
			"minecraft:particle_appearance_billboard": {
				"size": [0.2, 0.2],
				"facing_camera_mode": "direction_y",
				"direction": {
					"mode": "custom",
					"custom_direction": [1, 0, 0]
				},
				"uv": {
					"texture_width": 2,
					"texture_height": 1,
					"uv": [0, 0],
					"uv_size": [1, 1]
				}
			},
			"minecraft:particle_appearance_tinting": {
				"color": [1, 1, 1, 1]
			}
		}
	}
}

After opening snowstorm:

{
	"format_version": "1.10.0",
	"particle_effect": {
		"description": {
			"identifier": "sirlich:tile",
			"basic_render_parameters": {
				"material": "particles_opaque",
				"texture": "textures/particles/tile"
			}
		},
		"components": {
			"minecraft:emitter_rate_instant": {
				"num_particles": 1
			},
			"minecraft:emitter_lifetime_once": {
				"active_time": 1
			},
			"minecraft:emitter_shape_point": {},
			"minecraft:particle_lifetime_expression": {
				"max_lifetime": 1
			},
			"minecraft:particle_initial_speed": 2,
			"minecraft:particle_appearance_billboard": {
				"size": [0.2, 0.2],
				"facing_camera_mode": "direction_y",
				"direction": {
					"mode": "custom",
					"custom_direction": [1, 0, 0]
				},
				"uv": {
					"texture_width": 2,
					"texture_height": 1,
					"uv": [0, 0],
					"uv_size": [1, 1]
				}
			},
			"minecraft:particle_appearance_tinting": {
				"color": [1, 1, 1, 1]
			}
		}
	}
}

When you try typing anything into the expression bar while any of the tick variables or start variables are being edited, all of the variables from the same category (if you edit a variable from tick variables, all Tick variables will be removed, and same with Start variables) will be wiped out.

It can be reproduced by creating one or more variables in tick or start variables, input anything in there, then focus to expression bar and input any character. After that all variables in the same category will be removed.

P.S.: I saw the message in #bb-feedback, so I thought I would report here as well.

window.screen.orientation && window.screen.orientation.type.includes('portrait') not working in safari ios => portrait_view not working.

-> Recommend using screen width or window.outerWidth

ios safari error: css hover not working -> menu not working
sample issue :https://stackoverflow.com/questions/35187970/css-hover-not-working-on-ios-safari-and-chrome

-> Recommend add @click="" to <li v-for="menu in Menu" :key="menu.id">
-> <li v-for="menu in Menu" :key="menu.id" @click="">
@JannisX11

The horizontal range is being taken into account when a curve is in Bezier Chain mode. This is however not the case in-game, and it's mentioned in the documentation. It also mentions that the range field is deprecated.
https://bedrock.dev/docs/stable/Particles#Curves

As much as I love this plugin on VS Code, whenever I try to make particles and edit the input fields or modify the particle, it always interrupts and goes to the end of the text or makes actions on its own. It's greatly affecting user experience.

Bug/issue in action

This video footage shows how quite frustrating it is to modify the Color & Light appearance of the particle. You would have to be quick about your actions otherwise the plugin would just interrupt and try to correct your mistakes even though you haven't finished inputting your stuff yet:

Resolution suggestion

You can perhaps make a toggle that would control the rate of these "auto-actions" - or perhaps even disable it completely and return errors for the particles like you would normally do as "warnings" (as displayed on the image below), instead of interrupting the user's input forcefully.

Additional input and feedback

Please reply to this post should you seek or have further information.

Having an emitter with zero particles can be useful, for example a particle whose only purpose is to run a timeline of events that spawn other particles.
However, when "amount" is set to 0 in snowstorm, the num_particles field is left out instead of being saved as 0. If the file initially had this field when being loaded, it gets deleted.
This causes a content log error in-game:

[Effects][error]-particles/test.particle.json | ParticleEffect::_extractComponents | minecraft:emitter_rate_instant | EmitterRateInstantComponent | num_particles | required field does not exist

Here is my reference particle:

{
	"format_version": "1.10.0",
	"particle_effect": {
		"description": {
			"identifier": "test:particle",
			"basic_render_parameters": {
				"material": "particles_alpha",
				"texture": "textures/items/apple"
			}
		},
		"events": {
			"event": {
				"particle_effect": {
					"effect": "minecraft:endrod",
					"type": "particle"
				}
			}
		},
		"components": {
			"minecraft:emitter_rate_instant": {
				"num_particles": 0
			},
			"minecraft:emitter_lifetime_once": {
				"active_time": 2
			},
			"minecraft:emitter_lifetime_events": {
				"timeline": {
					"0.00": "event",
					"0.50": "event",
					"1.00": "event",
					"1.50": "event",
					"2.00": "event",
					"2.50": "event",
					"3.00": "event",
					"3.50": "event"
				}
			},
			"minecraft:emitter_shape_point": {
				"direction": [0, 0, 1]
			},
			"minecraft:particle_lifetime_expression": {
				"max_lifetime": 1
			},
			"minecraft:particle_appearance_billboard": {
				"size": [0.25, 0.25],
				"facing_camera_mode": "lookat_xyz",
				"uv": {
					"texture_width": 16,
					"texture_height": 16,
					"uv": [0, 0],
					"uv_size": [16, 16]
				}
			}
		}
	}
}

I have made an uv based upon a random value.
but snowstorm keeps adding 0.5 * (2 * to the value.

      "minecraft:particle_appearance_billboard": {
        "size": ["0.05*variable.size", "0.1*variable.size"],
        "facing_camera_mode": "lookat_y",
        "uv": {
          "texture_width": 8,
          "texture_height": 8,
          "uv": [
            "0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (math.floor(variable.particle_random_1 * 2) * 4))))))))))))))))))",
            0
          ],
          "uv_size": [4, 8]
        }
      },

1. Create a particle with a gradient tint.
   

2. View code
   
   both colours have an extra "FF" at the start of them.

That would be useful for particles making use of queries.

To give an example, currently when a particle uses "!q.is_sneaking" in its Kill Expression, it will return true and immediately kill the particle, forcing you to temporarily change out the kill expression to preview the particle system.

Whenever a particle is saved with Expression mode for color, it wraps the expression with Math.clamp(, 0, 1), even if that expression is made up of several expressions and a return statement, causing a syntax error. It should only wrap the return value, not the entire field.

Example (in the Red field of the color expression):
v.index = Math.mod((v.index ?? -1) + 1, 10); return v.index / 10;

After saving:
Math.clamp(v.index = Math.mod((v.index ?? -1) + 1, 10); return v.index / 10;, 0, 1)

Expected:
v.index = Math.mod((v.index ?? -1) + 1, 10); return Math.clamp(v.index / 10, 0, 1);
(or no change at all)

When using look at direction, the specified custom direction does not end up in the exported JSON file.

Repro steps:

1. Open up a new particle file
2. Navigate to Particle>Lifetime
3. Change Mode from Time to Expression
4. Save

Expected result: The mode stays on Expression
Actual result: The mode switches back to Time

Note: This only happens if Time is set to anything non-zero.

Related: If both time and expression are 0, next time the file is opened it defaults to Time 1

I'm on windows 10, the most recent chrome browser, and no extensions applied. I cannot select or copy any of the code, no matter what I try!