Hello i changed to 4.22 now i get always this warning UEDPIE_0_Farm.Farm:PersistentLevel.DonMeshPainterGlobalActor_0 : StaticMeshComponent_1 has to be ‘Movable’ if you’d like to move.
Hi,
The following code changes should resolve your issue:
-
Copy the plugin to your project folder for modifications following the instructions on this page.
-
Open the file DonMeshPainterGlobalActor.cpp
-
Below Line 129 add the following code statement:
captureMesh->SetMobility(EComponentMobility::Movable);
- Recompile the plugin, the issue should now be resolved.
Let me know! 
Hi! I recently purchased this plugin to try to have a system of multiple paint colors that can overwrite each other and have tags, and I’ve encountered an issue that may be a bug? If not, then I may be doing something wrong.
Basically, I have a material meant for floors using your node that’s set up like this:
Using this material, I seem to be able to paint multiple colors that are able to overwrite each other (which is the behavior I want) and erase them using the Paint Stroke node’s erase mode.
This is all done in the first person example template (the blueprint version) and I have the character modified to be able to select from one of three different projectiles that are modified from the default first person example projectile; red paint, blue paint, and water (essentially an eraser). Those each look like this:
With the only difference between them being the brush stroke color, the collision tag, and erase mode being enabled for the “water” ball. Red and Blue have Red and Blue as their collision tags respectively and have the brush colors to match (pure red and pure blue), and the water projectile has no collision tag, is set to pure white for the brush color, and has erase mode turned on.
When using the projectiles (the player is set up to switch between them using the 1-3 keys) red and blue are properly able to paint the surface and overwrite one another, and the eraser is properly able to erase both red and blue paint visually.
However, the player is also set up with an alt-fire that runs multiple Paint Query nodes, and checks for the Red & Blue tags and returns whether the resulting spot is Red or Blue. It works by running two paint queries on the same location using a Sequence node and then a branch connected to the boolean output of each query that when returning true triggers a print string to let me know what the result is; if both return false, nothing is printed. The problem lies in that if I overwrite or erase existing paint, and then Paint Query the spot that has been overwritten, the query results still return true for the tag matching the original paint stroke at that location.
Additionally, if I erase a spot where both colors have been, or overwrite one color with another, the Paint Queries I have set up in the trace return that the area retains the tags of BOTH colors of paint.
Am I doing something wrong here? It there a different or intended method of removing / erasing tags that I’m not seeing or is this a bug?
Hi @NFinET,
Thanks for your well written query, appreciate the effort.
Erase functionality currently does not support erasure of any collision data. Erasure was added in a recent release in response to a user request for simple paint erase functionality.
However, this functionality should be reasonably easy to build out with some minor code additions. I’m not sure when the next engine release is, but if possible I’d like to wait until that point to add this functionality.
If you need it sooner and are comfortable with coding you may be able to inspect the logic in UDonMeshPainterComponent::SetupPaintingPrerequisites and simply add some logic which checks whether Stroke.bEraseMode is true and if so, remove the stroke instead of registering it.
If you need help with implementing that on your own for now, do let me know!
I see , thank you for the response!
I’m not really much of a coder aside from using blueprints at the moment, so for now I’ll see if I can wait for the next engine and/or plugin release.
I assume you mean the next release in general and not 4.23? (Unless it ends up being 4.23 anyway I suppose)
It wouldn’t hurt to have it sooner but I’d be willing to wait for either of the above cases. Although unlikely I’ll consider maybe looking into that and seeing if I can handle it or ask for help on it, but as I said for now I’m willing to wait.
Thank you very much for the plugin, the response, and the offer to help if I try to implement that myself! Much appreciated!
Thanks @NFinET, greatly appreciate your patience.
Yes I did mean 4.23 to be clear 
Ahh I see, that’s all right.
I’ll start working on other parts of my concept like the visuals and actual paint application first then and worry about the tagging and gameplay driving later (Unless I attempt the implementation, though that’s kinda unlikely to be honest, haha).
Thank you very much!
is it possible to make a feature request for a future update?
I’ve noticed while playing around that when using a decal for the brush stroke node, the decal is used visually, but has no effect on the tagging functionality of the stroke. The tag instead appears to take the shape of the default brush stroke, a circle. (Unless I’m doing something wrong, which is certainly a possibility)
Is there any way to add a feature to optionally make the tagged area conform to the shape of the decal for more precise applications?
If anyone else has issues with the AttachParent/AttachChildren pairing being wrong, got a fix.
Same area as the one mentioned above actually
[SPOILER]
DonMeshPainterGlobalActor.cpp:
if (!captureMesh)
{
captureMesh = NewObject<UPrimitiveComponent>(this, Mesh->GetClass(), NAME_None, RF_NoFlags);
if (USkeletalMeshComponent* TargetSkelMeshComponent = Cast<USkeletalMeshComponent>(captureMesh))
{
USkeletalMesh* SourceSkeletalMesh = Cast<USkeletalMesh>(meshKey);
TargetSkelMeshComponent->SetSkeletalMesh(SourceSkeletalMesh);
}
else if (UStaticMeshComponent* TargetStaticMeshComponent = Cast<UStaticMeshComponent>(captureMesh))
{
UStaticMesh* SourceStaticMesh = Cast<UStaticMesh>(meshKey);
TargetStaticMeshComponent->SetStaticMesh(SourceStaticMesh);
}
[/SPOILER]
With Mesh as a template object in the NewObject() call, Mesh’s AttachChildren array is copied.
Various UE4 functions to exactly the same thing, but use a private struct that is friendly to the USceneComponent class to manually clear the AttachChildren after the fact.
Since we can’t do that here, did the above instead.
No idea if it has any affect on the code that follows 
Hope you’re ok with me sharing the fix here. If not, let me know.
Sorry about the long ■■■ delay, Figured I’d post some of the older demonstration results here for you. Great work on this plugin.
Warning, NSFW(violence)
Video’s demonstrating some exaggerated high caliber rounds to show off the effect to a fuller extent.
Again, thanks for the help earlier.
Thank you so much for sharing this, sorry for the late reply
Will look into integrating this for the next update after taking a closer look.
Thank you
Thanks for sharing your work @**thelazylion, **appreciate it!
I’m unaware of how to implement seamless decal projection. If someone can share any information or hints on this I may be able to take it up at some point. Currently this is looking unlikely.
Persistence is definitely possible, you will be able to save any and all effects you create with this plugin.
If you do not have control over UV Map creation it is necessary that your creation tools have created UV0 without any overlapping faces. If that condition is fulfilled you will be able to use the Don Mesh Paint UV0 nodes without issues (seamless decals still won’t be possible as you noted though).
There should be no issues as afar as I can tell, however I do not have a PS4 kit to test this myself. That is the reason this platform isn’t listed as being officially supported.
Appreciate your interest in the plugin!
Thanks a lot for the information and update, appreciate it!
Hi There, Fantastic plugin - I am going to purchase on 4.23 release, but first I want to make sure that my painted decals will work with any chaos fractured meshes in my game?
Thanks!
Excellent! Thank you for getting back on this!
Hey there. You’ll have to assume it doesn’t work for now, as it is unlikely that a pre-existing system will work flawlessly with a new one, especially where things like fractured meshes are concerned. There’s so many things to consider here, eg: Can you paint before fracture, after fracture, will the texture UVs be retained post fracture, etc. I probably won’t be able to look into this any time soon as I’m preoccupied elsewhere atm.
As for 4.23 release ETA, I’d like to implement some outstanding user requests from earlier this year (specifically multi-layer support for pixel collisions). I’ll probably need at least 1 week or more to submit.
Appreciate your interest and visitor message
Awesome thanks for the reply. Looking forward to picking it up next update 
hi there, i am curious if this can be ceployeng on android / oculus quest
Hey does that works using render targets?