Everything seems to work the same until RenderTarget->ReadPixels(). So that may be the point I would report a bug.
Interesting. I would report that as a bug indeed, seems unlikely that thatās desired/expected behavior.
Someone at GDC go kick the Epic guys in the shins and tell them to push the plugin updates to the Marketplace.
They are working on it, but something is failing in the iOS building process, so the code plugins will first be released for all platforms except iOS.
After theyāve fixed it, the code plugins will become available for iOS as well.
are there any good examples of using the JSON stuff? - example project? screenshots of actual workings?
i use that on daily basis and believe me its so easy you donāt need to be guided just check the screenshot for nodes - their names are self explanatory.
Hello,
Iāve been trying to send udp message to my server but it doesnt seem to work.
My blueprint is like this:
On server I use the code from āExampleSocket1ā example. I did change the udp port to match the one in blueprint.
Listening: SocketServer[PyroServer[127.0.0.1:7780], PyroServerUdp[127.0.0.1:7667]]
am i doing something wrong? I never used udp before but I dont think I need to execute connect right?
tcp works fine.
Hi, from what I can see, you forgot to use the [Connect] blueprint.
Normally UDP is connection-less, meaning you donāt need a connection, but the Low Entry Socket protocol requires a connection (a TCP connection) so the client can send its UDP port to the server, so the server can send unreliable messages (UDP packets) to the client as well.
If you would use the Raw Socket Connection blueprints, then you wouldnāt need a connection to send data over UDP, but I wouldnāt recommend that, since you will have to figure out yourself how to get the clients UDP port to the server then.
Anyway, in short, call [Connect] before sending the unreliable message and it should work.
Thank you, it works now.
<3
Iād like to solicit suggestions for an issue that I am having. This is a particular and perhaps unique use case of the LE Socket plugin.
In our compiled game, the issue does not present. It only occurs in editor, with dedicated server and multiple clients. It occurs with a single process or not a single process.
Weāve had no issues with multiple clients running on separate machines connecting and retrieving and sending data at the same time (relatively speaking.)
In brief, we use the plugin and java server to interface with our db. Most of the data is accessed in the GameMode and a portion of it is used to create the character (descriptive data such as sex). By design, if the data does not load properly, the character is not created and the game exits.
With multiple clients in editor, only the last created client loads all of its data successfully. Weāve added a verbose output capability to our version of the server and by watching that, I can see that on occasion, a portion (multiple function calls are used) of the data for another client will load.
It appears that the newly created clients abort in some fashion the previous function calls. I believe this occurs on the testing machine rather than the server. Weāve tested both with the java server online and here on another machine on our LAN.
As it would vastly improve our testing turn around times (1 hour compile + download) for testing iterations, we would like to be able to test the game in editor with multiple clients. Many bugs do not present in editor with only one client.
All of the function calls are in wait loops that require completion to exit. I have learned previously that sending another function call while one is in process will abort the previous, and that appears to be what is happening in editor with multiple clients.
I have tried increasing the timeout value, but this hasnāt produced any change.
All suggestions are appreciated!
Hi, I see what you mean. Just to validate, you mean calling a Function Call blueprint several times will cause only 1 of them to execute right?
I think currently that blueprint cannot handle running more than once at a time. I should perhaps rework this so this is possible, but then the question is, how will it work with latent function call blueprints? If you call cancel on it, will all calls cancel?
Anyway reworking the blueprints will require a lot of time so this isnāt likely to happen in the next few weeks, but it is something I would like to have done one day, so it is definitely on my list.
A way to work around it by the way is by using messages, and then handling responses that way. Itās messier, which is why I would like to rework the function call blueprint, but that should work with multiple calls at the same time.
Maybe Iāll make some time free to do this in about a month from now. Not 100% certain if itās doable to have multiple latent calls running at once (in the same blueprint), but Iāll try to get it working, I think I know a way that might work.
Yes, a function call to the java server has to complete before another can be sent. The wait loops take care of this in our compiled game and we donāt expect any problems with the compiled server and client.
Being able to test multiple clients in editor would be extremely useful to us. I have thought of using a hack to work around the function call conflicts ā using an in editor switch to load dummy values and not accessing the character descriptions at all ā but this might introduce unforeseen bugs.
I see. What I did in my case was I made an array of byte arrays (array of structs, the struct contains a byte array field), and then what I did was this:
Before calling the function call, I added the byte array (the data I wanted to send) to the array. If the array then had a length of 1, I would run the function call with those bytes. If it didnāt (length > 1), do nothing.
Then after the function call, you remove the first element of the array (which should be the bytes it has send), then you check if the array has more entries (length > 0). If it does, call the function call with the bytes from the first entry of the array.
This will basically create a queue. Instead of calling the function call directly, you add the bytes to the queue, and then you let the queue run itās entries one by one.
Anyway it would be better if the function call blueprint just supported multiple calls at the same time, so I will still implement this one day, just need to find the time for it.
I hope that helps.
Hi ,
really enjoying your marketplace plugins!
Iām using your LE File Manager to help me make a little program for managing a custom render workflow. I wanted to ask if it would be possible to add a blueprint node in LE File Manager to also execute files? It seems pretty easy (Is there a way to execute external .exe files from unreal? - Programming & Scripting - Epic Developer Community Forums), but I would like to keep my program blueprints-only. I want to use the function to execute .bat files. Is there a chance to add that functionality?
Cheers!
Hi, seems do-able, Iāll add it within a day or two from now.
Thatās amazing! Thank you so much!
Itās done, Iāve uploaded it to the marketplace, now youāll just have to wait for Epic to publish it (maybe 1-2 days).
Iāve added 2 blueprints (well 4 actually, 2 for low level, 2 for high level). The two blueprints are ExecuteFile and ExecuteFileAsync.
The ExecuteFile blueprint will execute a file and wait till itās done, then itās output will be available in blueprint.
The ExecuteFileAsync blueprint will execute a file, but it wonāt wait till it is done (so it wonāt lag the game), but, that also means the output of it will not be available in blueprint.
Maybe Iāll add functionality one-day to access the process and such (the async blueprint returns the process ID which will be needed for that), but that would be a lot of work, enough work for it to be its own plugin.
Anyway, I hope these 2 blueprints will allow you to do what you wanted to do.
Thanks a lot!
Is the update on the marketplace? I havenāt gotten an update on my end here. Donāt see the new nodes either.
Cheers!
Yeah it was released on monday the 22th. Are you using 4.20?
Jup, Iām using 4.20.3 (4.20.3-4369336).