You can now run the test HTTP server by calling:
scons p=web serve
If you also wish to run the browser, call instead:
scons p=web run
The default listen port is 8060, but can be overriden via the env
variable GODOT_WEB_TEST_PORT which must be a valid integer.
It was failing due to generated files being referenced in
.NET projects but the files are missing because they are
generated by `godot --generate-mono-glue` or
`build_assemblies.py`.
Previously, only forward basis distance from the camera was used.
This means that unnecessarily high LOD levels were used for objects located to the side of the camera.
The distance from the camera origin is now used, independently of direction.
The Godot API (gdnative_interface.h) allows methods to be registered on
extension classes with
`classdb_register_extension_class_method`
a `GDNativeExtensionClassMethodInfo` can be provided to this function
along with a `get_argument_info_func` which according to the comment
indicates that argument names should be definable here.
Unfortunately, setting the name field in the `GDNativePropertyInfo`
struct has no effect on the editor documentation, which continues to
display "_unnamed_arg" for each argument.
I discovered that `get_argument_info` is responsible for this as it
always overrides the `info.name`. I've added an if condition that will
only override the name when it is empty. I've tested this with my
GDExtension module and I can confirm that with this commit, the argument
name shows up in the builtin docs. eg. in Lookup Symbol.
On X11 we rely on ConfigureNotify event to update rendering context
window size, but we don't get such event when resizing
programmatically, only when done "manually" by resizing the window
etc.
Uses html-eslint for HTML file and eslint-plugin-html for inline
JavaScript.
Use HTML5 (not XHTML), remove CDATA and trailing slashes for self
closing tags.
Add format checks to CI.
This commit is a huge refactor of the websocket module.
The module is really old, and some design choices had to be
re-evaluated.
The WebSocketClient and WebSocketServer classes are now gone, and
WebSocketPeer can act as either client or server.
The WebSocketMultiplayerPeer class is no longer abstract, and implements
the Multiplayer API on top of the lower level WebSocketPeer.
WebSocketPeer is now a "raw" peer, like StreamPeerTCP and StreamPeerTLS,
so it emits no signal, and just needs polling to update its internal
state.
To use it as a client, simply call WebSocketPeer.coonect_to_url, then
frequently poll the peer until STATE_OPEN is reached and then you can
write or read from it, or STATE_CLOSED and then you can check the
disconnect code and reason).
To implement a server instead, a TCPServer must be created, and the
accepted connections needs to be provided to
WebSocketPeer.accept_stream (which will perform the HTTP handshake).
A full example of a WebSocketServer using TLS will be provided in the
demo repository.
