If the pre-compiled plugin you are using was compiled using the GitHub version of UE4 and you’re using the Launcher version of UE4 you may see strange behavior/crashes.
Also, make sure to put the plugin into the Plugins folder (either Engine/Plugins or “Game”/Plugins) and not any sub-folders there such as Runtime, Editor, etc…
How does your license work, 1 per account?
It depends, if you are purchasing for yourself then it’s per account. Otherwise it is per-studio/group. I wanted to be less restrictive with my licensing.
Awesome, it’d be pretty convenient for us if we could have multiple accounts permitted to download the marketplace plugin. Anyhow, Warcabbit gave me a copy of whatever he got and I’m still having the problem of the editor crashing when I hit Play/PIE.
- I have completely uninstalled and re-downloaded/re-installed UE 4.14.3
- I have no other plugins installed
- This is with the sample project freshly downloaded from the marketplace page (https://drive.google.com/file/d/0B5xs9WuumfxwTHhvbFVaXzRaLUE/view)
- The plugin is unzipped in F:\Program Files\Epic Games\UE_4.14\Engine\Plugins\Marketplace\VICODynamicsPlugin
- I can play other project files without this sort of crash
Is there a dependency on a specific Visual C++ runtime version or anything like that?
e: let me pick out the crash log and attach that, if you want it
also here’s the Edit->Plugins screen, so the plugin does seem to be in the right directory at least
Crash log (including minidump etc) attached
I think I know what’s causing your crash, what CPU are you running? I suspect it does not support a certain SSE instruction I’m utilizing. We can work around this, but I’ll wait to hear from you before I explain it all.
Intel qx6700, and if you tell me which type of instruction it is, I’ll check to see whether it’s enabled/disabled (I remember XD and one other specific one exposed in BIOS)
e: yeah, XD and C1
this is what they are currently set to and have been since I built the OS, I haven’t changed them since.
No those are not related to this, the CPU itself does not support SSE4 (See Features section: http://www.cpu-world.com/CPUs/Core_2/Intel-Core%202%20Extreme%20QX6700%20HH80562PH0678M%20(BX80562QX6700).html). I’m utilizing the _mm_dp instruction in VICODynamics which requires SSE4 support. I did add a way to compile with an alternate code path for CPUs that do not support SSE4 by uncommenting a define in the physics library, I can go in-depth on how to do this if you’d like or drop me an email and I’ll get a test build to you to test.
Thanks, I PMd you my email address. I’m very glad you explained this, we’ll make sure to keep an eye on this for eventual deployment.
Not a problem! A little late on the reply 
Hi, quick question. I’m trying to use the Rebuild Rope Attached node and it requires a “component reference structure”, which is something I’ve never seen before. How would I go about creating a component reference structure from, say, a static mesh component that’s in the same blueprint as the dynamic rope component?
Does it not allow you to create it inline anymore? Let me check on this for you.
In the meantime, try creating it as a variable and setting its properties before passing it into Rebuild Rope Attached.
Yeah, when attempting to connect it I get the error message “Static Mesh Component Reference is not compatible with Component Reference Structure”. Creating it as a variable produces the same results unfortunately. I’m using a custom build of 4.14.3 if that helps to explain anything.
How is replication support looking? Any plans for the near future? When it comes to physics, default replication methods are more costly than they need to be usually. More thought needs to be put into what the server updates(not just how often), what the client can simulate locally and how it will blend into updates from the server.
You are absolutely right, replication of physics systems is a fine art. I do not have an ‘out-of-the-box’ solution yet mainly because there two ways it could be done:
- The simulated objects are scenery/non-gameplay critical, in which case only the creation, initialization, property edits and destruction needs to be replicated. In this scenario, running the simulation on the clients only will work just fine.
- The simulated objects are gameplay critical, this is more complicated to replicate and a proper solution would run the simulation on clients and server. And would use correction logic to fix any deviations in location and velocity every few frames, as you said. This should work well because the simulation is stable and individual machines should not deviate too much. This is all in theory of course, I have yet to test this. But an immediate issue that comes to mind is the possibly large number of particles that will need to be synced if your scene is using tens of thousands. Each simulating particle would require two 3D vectors (24 bytes) . Sending only deltas would be a possibility and they could be shrunk down to Half-floats, but this would assume little to no deviation between server and client.
I’m sure I’m missing something, but without actually testing it I can’t be certain. Any suggestions are welcome!
Ok, the Component Reference Struct is no longer an ideal way to setup attachments. I’m going to refactor that function a bit so that you can pass in a component or actor straight into it. Thank you for bringing this to my attention!
Are you using the Marketplace build of VICODynamics or the GitHub version? If GitHub, what branch?
Great, thank you for looking into it! I’m using the Feature Update 2 branch on Github.
Perfect! I’ll try to get a rev pushed this weekend for you to try.
Awesome, I really appreciate it!
Is this close to what you are after?
If so, I’ll push this up to the repo.