I haven't tried it but you should be able to use a for-each loop on the pop-float node.
Announcement
Collapse
No announcement yet.
[Plugin] OSC for UE4
Collapse
X
-
-
Hi [MENTION=614263]JuL17[/MENTION],
You might find that it's that the ports are hard-wired (to 8000 I think) in the 'packaged' versions of the plugin and you'll have to change them in the source code (It's easy), or change your ports in TouchOSC.
Best!
Dan
Comment
-
-
Hi [MENTION=614263]JuL17[/MENTION].
I'll try to write a better response shortly - i'm quite busy today.
You're right that you want to drive your camera's world position in this way but you're sending your camera on a diagonal path through your scene I expect.
You need to make discrete x, y and z variables for your camera's position and only update the one you're adjusting.
You have tx, ty and tz switches - so you need each one of them to call a 'set' on only the x, y and z variables appropriately, then i'd say you could join up those execution chains (tx, ty and tz) into a set world location based on the values of those variables.
I'd use a 'Map-To-Range-Unclamped' node rather than your multiplier - the float output will likely produce a scalar value between 0 and 1 - if you plug that into the 'value' node, then set In Range A to 0 and Range B to 1 (the min and max for the float) - then you can set OutA and OutB to the coordinate range of your choosing - like (-1000 to 1000) - that way if you get a 0 from the float your camera will move to -1000 or if it gets 0.5 (half) it'll go to 0. Do this for each axis - you might want the mimimum range for Z to be 0, otherwise it might go through the ground.
Also you could use a spring arm with your camera attached to produce a smooth motion when you adjust these values. In this case you move the world position of your spring arm rather than your camera.
I'll try to post a BP grab at some point.
Comment
-
I tests on 4.14 and it works just fine, except one thing:
In the .uplugin file, the plugin is marked as disabled by default.
Before 4.14, it was loaded anyway...
Now, it's not anymore: if you experience strange behavior, check that the plugin is loaded in the "Plugins" window.
I also pushed an update that make the plugin enabled by default from now on.
Comment
-
Comment
-
Hi [MENTION=22242]monsieurgustav[/MENTION]
Hope you are well. Is there any reason that a long string sent into the engine would cause a crash? I'm trying to get a node.js OSC module to send in a long base64 string and it crashes the editor:
Assertion failed: TCString<TCharType>::Strlen(InName)<=NAME_SIZE [File:\Build\++UE4+Release-4.14+Compile\Sync\Engine\Source\Runtime\Core\Private\UObject\UnrealNames.cpp] [Line: 582]
Here's my string!
V2hhdCUyMGlzJTIweW91ciUyMGZhdm91cml0ZSUyMHR5cGUlMjBvZiUyMGJpc2N1aXQ/XypfdW5kZWZpbmVkXypfbnVsbF8qX251bGxfKl9udWxsXypfdW5kZWZpbmVkXypfdW5kZWZpbmVkXypfdW5kZWZpbmVkXypfdW5kZWZpbmVkXypfNF9TUExJVF9fL19FbGVtZW50MF8qXyJodHRwOi8vNjUubWVkaWEudHVtYmxyLmNvbS81ZmIyNTQ4OTNkNTE1ZTQwYTY1ZWFjNmRhNjZkNzZjZi90dW1ibHJfaW5saW5lX216ZG96ZHhIVm4xc254emN3LmpwZyJfKl8lQzIlQTAlQzIlQTBDdXN0YXJkJTIwQ3JlYW0lQzIlQTAlQzIlQTBfKl9fKl9fL19FbGVtZW50MV8qXyJodHRwczovL21vcm5pbmdiaXNjdWl0bG92ZS5maWxlcy53b3JkcHJlc3MuY29tLzIwMTIvMDgvMjAxMjA4MTEtMTMyNzQyLmpwZyJfKl8lQzIlQTAlQzIlQTBDaG9jb2xhdGUlMjBEaWdlc3RpdmUlQzIlQTAlQzIlQTBfKl9fKl9fL19FbGVtZW50Ml8qXyJodHRwOi8vd3d3LmhpbGxiaXNjdWl0cy5jb20vMjEtMjMtYmlzY3VpdC1pbWFnZS9oaWxsLWdpbmdlci1udXRzLTE1MGcuanBnIl8qXyVDMiVBMCVDMiVBMEdpbmdlciUyME51dCVDMiVBMCVDMiVBMF8qX2NlbnRlciBjZW50ZXJfKl9fL19FbGVtZW50M18qXyJodHRwOi8vd3d3LmNvbmZlY3Rpb25lcnluZXdzLmNvbS92YXIvcGxhaW5fc2l0ZS9zdG9yYWdlL2ltYWdlcy9wdWJsaWNhdGlvbnMvZm9vZC1iZXZlcmFnZS1udXRyaXRpb24vY29uZmVjdGlvbmVyeW5ld3MuY29tL21hbnVmYWN0dXJlcnMvYnVydG9uLXMtYmlzY3VpdHMtbmVlZHMtc2hvcHBpbmctc3ByZWUtdG8tc3RheS1jb21wZXRpdGl2ZS1zYXlzLWFuYWx5c3QvODU4MzIxNS0xLWVuZy1HQi9CdXJ0b24tcy1CaXNjdWl0cy1uZWVkcy1zaG9wcGluZy1zcHJlZS10by1zdGF5LWNvbXBldGl0aXZlLXNheXMtYW5hbHlzdC5qcGciXypfJUMyJUEwJUMyJUEwSmFtbWllJTIwRG9kZ2VyJUMyJUEwJUMyJUEwXypfXypfX1NQTElUX1JlczJfZF9CYXNlIFZvdGVfZF80MF9kXzMwX2RfMjBfZF8xMF9sX1JlczNfZF9NZW5fZF8xMF9kXzIwX2RfMzBfZF80MF9sX1JlczRfZF9Xb21lbl9kXzI1X2RfMzVfZF8yOV9kXzExX2xf
It's just a few configs and some urls.
Cheers!
Dan
Comment
-
I think it must be an RX buffer set to 1024 somewhere - I tried changing the global buffer but it didn't fix it.
Comment
-
OK, it totally makes sense but I haven't seen it coming.
The OSC plugin stores OSC strings as FName objects. (as you can see, PopString actually returns a Name value)
It would make sense to use FString here, but it would cause a lot of buffer copy (every Pop* function call, etc.) if used naively.
A less naive approach would be to store those strings in a shared container and store a pointer to it.
Which is basically what FName does.
Unfortunately, FName content is limited to 1024 characters.
Hum.
I see 2 issues here:
- It will take some work to remove this limitation. Not a lot, but some.
- It will break old OSC related blueprints, as PopString will actually return a FString now. (instead of FName)
Comment
-
Oh well, Ive worked around it by sending multiple messages and appending them in the engine - it's not perfect but it works for me. Presumably this limit is per element? I could send several string messages in the same osc message and pop each one?
Thanks for the help! At least it's a known issue now.
Dan
Comment
-
Probably worth at least setting up something to catch this rather than a crash. I could imagine it could catch someone out in the future.
Comment
-
Definitely: post an issue on Github to keep track of it.
I'll fix de crash ASAP, then think about the best solution to fix it for good.
Indeed, it is a "per parameter" limitation, so you can stack up many string parameters on a single message.
Comment
-
Comment
-
You need to pop each value - so add another 5 pop floats in a chain each from the output of the previous.
Comment
Comment