ClassiCube

it's not a java app anymore (for a few years already) so they can't,

you can also get wine, but im pretty sure you'll need to get crouton as well (or the android version of wine if it will launch on your chromebook)

There exists no solution for connecting JavaScript to a real tcp socket.

That would be the primary issue keeping us from pooping an in-browser version out. There are other issues, but that's a pretty big blocker.

Okay cool

id be active a hell of a lot more often

Add it back to browser pls or provide download link for the old java file please?

You can get the old client jar from here.

Ohhh thanks so much! I was looking for this!

(Automerge)

Now if i can find a way to host it and point to a server lol!

(Automerge)

Initially what i was trying to do was use my python builderbot to work with minecraft, but since its no longer on the site, the bot no longer can connect.

There's a program called websockify that proxies between web sockets and TCP. It could run on each game server to allow connections from a web client, or probably even integrated into the server software.

I have an old working prototype client that can connect, load the level and use chat.

Yeah but without support in the server software, all connections will appear to come from localhost/wherever the tunnel may lie.

That's only an issue for IP banning people, right? Could be fixed by adding a new packet that sets the real IP, with security to prevent forgery of course.

It's an issue for verifying via ip, grouping people together by ip (tracking alts) and all that other fun stuff.

If a CPE extension for IP forwarding were to be made, there wouldn't be an issue. The big issue then is proving that it's not a false packet.

The IP packet implementation could actually be internal to the server, although the ID should be well defined so it doesn't conflict with anything. A CPE extension probably won't work since servers may need to use the IP before the CPE handshake. Breaking compatibility isn't a problem because it's a completely different connection method.

1. Web client connects to server:45565, starts sending normal login packets as web socket messages.
2. Server receives web socket connection, opens a TCP connection to localhost:25565. Before forwarding the client packets, the proxy inserts another packet containing the client IP from the websocket connection.
3. IP packet is ignored if one has been received already.
4. IP packet is ignored if the source address is not localhost.
5. The source address is used if no IP packet is received (current behavior).

Update: I've gotten the ClassiCube C client to compile to JavaScript using emscripten, using the existing multi-platform system so it doesn't break the normal build. Doesn't do anything yet but I'm going to keep working on this.