FUZE sendBadge() - FEATURE REQUEST

[fgalliat]

Hi again, I wish a simple http method that could be called sendBadge( uri, badge )

• url should be any URL (using HTTP-GET) (w/o QueryString) ..but..
• badge should be a 16max chars long String (the only allowed payload)

ex. sendBadge("www.myserver.com:8088", "AACDFERT")

With that 'badge-length' limitation, Users couldn't post message that may be discriminant for anybody (Cf Nintendo policy) & that should be enought to make NS able to control some external resources, such as Rpi WebServer, ESP32
... so it could extends NS action perimeter w/o risks of free text submition.

I really understand Nintendo limitations impact your work, but If you could prompt them that kinda idea it may be fun.
Thanks for reading

[PB____]

allowing the URL
You could also send data through the URL of the request. You could also use the path in stead of a query string, for example: sendBadge("http://localhost:28910/uploadImage/iVBORw0KGgoAAAANSUhEUgAAAB8AAAAHAgMAAACNRX5cAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJUExURf75%2BtYmT9YoUAveQB8AAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAvSURBVBjTLYuBCQAwDMJ6hPtLwf7%2FSt06giBB67gvLEJgKFloyM%2FY3yRO4W721Ry%2B%2Fw5kqlgjuQAAAABJRU5ErkJggg%3D%3D", "image/png;base64")

This is especially useful in get requests, where the body typically is not used.

These days it's really common for web services to use REST to communicate. So it might be worth to look into that a little :)

limiting the body size
By limiting the size of the body of the request, you effectively limit the speed of communication. If you can only send and receive 1 or 0, you can effectively communicate any digital information. But it would probably introduce lag in your gameplay.

about the feature request
As a fellow user, I 100% understand the wish for a feature to support online multiplayer. And like you already mentioned, I also understand that Nintendo wants to protect their ecosystem.

It's not up to me to make decisions or advice in this matter. I don't know what the objections of Nintendo are regarding network communication, and I don't know much about the strategy of FUZE themselves either. But I'm not holding my breath.

EDIT:
To save people the trouble, the base64 I used in this post, results in the following image:

[fgalliat]

Hmm ... I know what is a REST Controller, thanks
My idea was not for networking an MMORPG,
I just suggested a draft with much limitations that I could, 'cause I'm pretty sure that Nintendo will never allow a full free URL w/ Base64 content in QueryString,
simple short message could rather allow little mailboxing system, progress saving or external device controlling such as robot wired to an Rpi, ESP32, ...
-> then (I miss to mention it : return of sendBadge( {host, port}, badge ) is only a simple String) so you could even query a Home Weather Station in your own LAN, or anything that you could imagine.

[PB____]

Keep in mind that I'm just a user. I would like to think along in solutions, but at the same time, I really don't want to inspire false hope by doing so. The post below is just sharing my current thoughts on the subject.

If internet support would be included in FUZE, personally I'd prefer it if it would be an implementation that supports multiplayer games. If that is the case, the communication is always between the same game on different devices, so there would be no need for an URL. FUZE would need to do the heavy lifting for the implementation in this scenario.

If there would be support for communication with a custom end point (URL outside of the FUZE environment), then I still see many ways that could be used for unforeseen use cases if the host and/or port of the url can be dynamically modified. Considering that the Switch doesn't have a web browser, I suspect that would be a concern.

The best way around this that I can see, is that there would be an approval system much like for code. Where you can submit the URL of an endpoint, with a description on how it can be used. Where you agree that your internet traffic is monitored so it can be checked if the end point is used as described. That submission would then get an ID (just like your game would get an ID) and you would be able to use that ID within your code. Then as long as the submission is approved, it would be possible to use that endpoint within your code.

I don't see much use in limiting the body size that tightly, since offensive words tend to be short enough to fit. Limiting the body size mostly limits how it can be used for good, but less so how it could be used for bad...