Low Entry Plugins

I did remove the “:” as i figured it is adding it automatically. if i can add more then one header than it should be ok.
I will gladly pay 500 euro for HMAC. It should work with any LE hash method right? As I would have to use sha-256 /512 and others depending on the api Im using.
Jus tell me how and where to transfer the funds. paypal? Bitcoin? Wiore transfer? (if in europe shouldn’t be a problem)

Oh and… how fast could You do it?

Yes multiple headers shouldn’t be a problem.

The plugin will contain HMAC blueprints for MD5, SHA1, SHA256 and SHA512.

You could either send the money as a donation to [EMAIL=“paypal@.com”]paypal@.com, or I can send you an invoice to be paid as a bank transfer (IBAN).

The HMAC code will be done within a couple days, releasing the plugin update to the marketplace can take up to a week (depends on how fast Epic is).

If you use the source code version of the LE Extended Standard Library you won’t have to wait for Epic to release the plugin update to the marketplace.

DONE. Check your paypal :slight_smile:
Hopefully if I need some small assistance you will help me out mate? :slight_smile:

I see I’ve received the payment, the HMAC blueprints will be done in a few days from now.

If you need any help (with this or with anything else), just let me know.

@** **

I’m using a few of your plugins for a project.
I was trying to export a 64bit version for Android.
But I found out that the binaries for 64bit are not available in the package.

I built the binaries for myself, but it would be nice to see them in the package.

PS. Love your plugins by the way :slight_smile:

Epic handles packing the binaries with the package.

Either way though, if you package your game, you will always have to compile the C++ of the plugins, regardless of whether the plugin has the right binaries available for it or not.

The HMAC blueprints have been added to the LE Extended Standard Library plugin (see https://code…com/Applicatio…tandardLibrary).

The update has been send to Epic and will eventually be available through the marketplace.

Hi, just want to confirm, the LE Socket Connection does not support websocket. I’m trying to connect to a websocket server, and the request fails.

Well, depends on what platform you’re using, and what protocol you’re using.

The ‘raw’ socket blueprints use either TCP or websocket depending on what platform it is being used on. HTML5 uses websockets, everything else uses TCP.

The ‘normal’ socket blueprints use the Low Entry protocol, which requires you to use the Java library to create your server with. With that protocol, every platform (including HTML5) will be able to communicate with the server.

It is recommended to use the Java library to create your server with, unless you have very specific technical demands, in that case you’ll have to basically create your own protocol that deals with all of this.

The Java library can be download here: http://public…com/files/LowEntryUE4/java

The tutorial on how to use the library (in case you’re new to Java) can be found here: https://tutorials…com/getti…-with-eclipse/

I hope that helps.

I was using another websocket library (websockt-sta) for server, and I notice the initial handshake is not normal websocket, which cause it to fail to connect.

@

It seems that UE4 still has no way to get input from microphone on Android :frowning: Do you think it would be possible to add this functionality to LE Extended Standard Library plugin? (I know if wasn’t possible back then, but maybe it’s possible with 4.19 )

Hmm, maybe, but it would probably be quite some work, since it needs both C++ and Java, haven’t done anything like that yet.

I did find this however: A new, community-hosted Unreal Engine Wiki - Announcements - Epic Developer Community Forums

Maybe that has what you’re looking for?

Well, I’d buy a standalone plugin from you :wink:

Yeah, but that one was for Windows only. It got recently ported to Android, but I believe it relies on native microphone input (and since UE4 doesn’t have it for Android natively, I can’t even test that speech recognition plugin).

I might, but I’m very busy currently.

Several freelance projects, plus a new service and UE4 plugin I’m working on, after that I’ll make a LUA plugin, after that I could do this.

I don’t know if I’ll ever get to that though, not in this year at least.

@

Hey, I’m currently using 3 of your plugins and they are great, so thanks for that. But I am having trouble with one node in your LE Extended Standard Library.

It works fine on desktop and android, but not on HTML5. I’m not sure if you offer support for this platform but I’d figured I’d ask.
The node that isn’t working on HTML5 is ImageToBytes (TextureRenderTarget2D), but I expect the actual issue could be with your PixelsToBytes function.

I’ve made a test project to show the issue, as below:
I’m using 4.18.3, it’s a source version, but only so I could package the HTML5 version with your plugin. No changes have been made to the code.

  • I’ve got a spectator pawn blueprint, which has a SceneCaptureComponent2D component. I add the following function:

  • I add a widget blueprint which has a button to grab a screenshot and then the display the screenshot. It calls the GetSaveScreenshot on the pawn, which returns the bytes etc.

  • Here is the result on desktop, working as expected:

**- And then on HTML5, the image is corrupted:

**

Now, I’ve determined that the issue is not with the BytesToImage node (or at least not solely). The menu on the left reads a Base64 string I pre-generated as bytes, and it works. Albeit with the R and B channels reversed, but I believe that is an issue on Epic’s side (since it affects their Download Image node in HTML5 too). Maybe it is exasperating the problem though. I’ve include a link to a HTML5 packaged version you can try, and also uploaded the project files (it should open in 4.18.3 binary).
(Just so you know why I even need to do this, the above is a simple version, but I am storing save game thumbnails as blobs in a SQL database, using your nodes to do the conversion. And we will be targeting HTML5).

Would you have any idea where I should be looking to try fix this?

Project files (~1MB):
https://www.dropbox.com/s/msjbsxyjh9…dTest.zip?dl=1

Packaged HTML5 (~33mb):
https://www.dropbox.com/s/xgct0wpzcn…HTML5.zip?dl=1

No idea why this is happening, it seems like there are some problems in the UE4’s HTML5 code when it comes to retrieving the pixels from a texture.

Anyway, in your case, isn’t there a better way of doing things? Couldn’t you set the brush texture to the render target? Plus, if you stop automatically updating the render target, and call update on it manually, you would be able to build the same functionality, without the byte conversion steps. I haven’t tried this myself though, so I could be misunderstanding something here, but if not, could you try that out to see if that would work?

That would work in this case yep, but in my actual project I am storing the byte data on a server so I need the output (above is just an example of the problem). Thanks for the quick reply though, I’ll look into it a bit more, but I too feel it’s probably an issue with the engine.

Ah I see, so that was only a test.

Anyway, did you already post this on the UE4 answerhub? Could you post the link to it here (for reference)?

I would like to follow the progression of this, since if the bug cannot be found or fixed, I’ll try to further investigate the problem myself as well.

I haven’t posted it there yet, as was thinking they would just say to contact you about it since I’m using your plugin. I’ve also not submitted a bug report for that reason, though there seems to be an engine bug somewhere.

I’ve come across some posts that may be related (mostly to do with Epic’s Download Image node), and an issue on the issue tracker which is marked as backlogged. I haven’t seen anything about the corrupted image though, it’s more about the red and blue channels being flipped.

AnswerHub post about flipped channels in Download Image: https://answers.unrealengine.com/que…n-html5-p.html
Flipped channels here again in a ColorPicker plugin: https://answers.unrealengine.com/questions/704935/html5-some-umg-images-are-flipped.html
Issue tracker, Not much detail here: Unreal Engine Issues and Bug Tracker (UE-38351)
Forum post about the Download Image node: https://forums.unrealengine.com/deve…download-image
I also found this issue, but I don’t know if this is by design: https://answers.unrealengine.com/que…b8a8-flip.html

(All on HTML5 except the last)

Right now I think a bug report will either be marked as a duplicate because of UE-38351, or I will be told it is an issue with the plugin. But I feel like all of the above are linked somehow.

I’ve done some messy workarounds to get the flipped channels working on your ImageToBytes node, just testing really. There’s a line in jpgd.cpp:


//@UE3 - use UE3 BGRA encoding instead of assuming RGBA
#define DECODE_TO_BGRA 1

I wrapped this with some preprocessor directives to define it 0 if the platform is HTML5. This works for .jpgs. I’m just not sure why this needs to be the case to “work” for the HTML5 textures, maybe they are being flipped twice at some point.

But yeah, I will get some sort of AnswerHub post up, or bug report, if I can determine a bit better where the issue is.

@ Here’s something else I’ve noticed, which is perhaps related to my above issues.

(This is a a test case with likely no actual use case)

If I have a Texture2D variable, and I call, ImageToBytes, and then BytesToImage on it, and then try to use that resulting Texture2D asset. it will work fine on PC. But on HTML5 will be corrupted, as above.

Unless, I set the Compression settings of that texture to be UserInterface2D (RGBA), or, VectorDisplacementMaop (RGBA8) (Others could work but I haven’t tried them, but at the least TC_Default doesn’t work). If the compression is set as either of those on the texture asset, the above works fine on HTML5 and on PC. And even the red and blue channels are no longer reversed.

This is what I did. Where “Texture” is a Texture2D variable with a default value of a texture I’ve imported from my PC.

So that fixes the issue for this case, but not for render targets. I’m not sure why that fixes it. I’ve also tested printing some variables from the FPixelFormatInfo of the render target on HTML5 and on PC. They all return the same except for PlatformFormat (uint32) which on PC returned 90, and on HTML5 returned 0.

Which leads me to believe it has something to do with this platformdata, or in the compression or interpretation of the compression on different platforms. ?