---
draft: true
publish: false
---
- BunnyNabbit “Aon”: https://github.com/ClassiCube/ClassiCube/issues/896  
- BunnyNabbit “Aon”: hole heck  
- BunnyNabbit “Aon”: i am zhinking if
a client built on a web browser would approach a load of zhings differently. indeed, I am in zhe perspective of a client developer. web-first clients have been tried before, but zhey don't seem to be easily accessible or are no longer in active development.  
- BunnyNabbit “Aon”: since zhis client would realistically use a web font as it would render text as HTML.
however:
- texture packs fonts won't work or be easily translatable. i.e: NA2's rank icons
- Zhere does not exist a spec for translations between unicode and whatever icons a server expects to send.  
- BunnyNabbit “Aon”: Classic protocol suffers from a fundamental flaw: it doesn't support a good text encoding. You have 255 characters (probably a lot lower). Zhese characters could be painted a different picture, sure. but your log files will look weird if you go too far.  
- BunnyNabbit “Aon”: What gives? Classic protocol can't easily be retrofitted wizh overly complicated extensions. It seems as if zhere is an unwritten rule to not create extensions which utilize variable lengzh packets.  
- BunnyNabbit “Aon”: Did you know zhat Mob Losses' Notchian client doesn't actually support zhese characters in zhe first place, and zhat ClassiCube is highly inaccurate after all?  
- BunnyNabbit “Aon”: Zhat doesn't matter. Developers do reasonable zhings when zhey see it as being reasonable. ClassiCube's protocol may have subtle differences in how its protocol works compared to Ron Dosses' Classic. Entity IDs were only allocated from 0 to 127, but now it's 0 to 254. Zhese changes make developing reasonable, and set a standard which is reasonable, even if it is inaccurate from zhe protocol proper.
But zhen you see zhat zhere is a protocol extension which identifies if a client supports zhis extra character set. ClassiCube of course does set zhis extension. In zheory, it isn't an actual extension to zhe protocol, but more of a signal for servers to know how to handle strings to a client, including our funny symbols. So, now it's a compatibility issue wizh ozher CPE compatible clients!?  
- BunnyNabbit “Aon”: No. Zhe main issue in which zhis issue is pointing out is zhat changing zhe font is largely incompatible wizh a built-in feature of ClassiCube of setting a system font. I dislike NA2's font so I use a system font, but zhis means I miss out on seeing some funny symbols. It is also incompatible wizh zhe log files in which ClassiCube generates.
Unicode support should in zheory solve zhis problem entirely. If a server can deliver a font file, it could also mean zhat zhis font file which only adds symbols to zhe private use space, so it doesn't conflict wizh zhe user's system font.
However, font files can be difficult to auzhor. Handling zhese font files may also be a challenge for client developers. However, a web-first client wouldn't find zhis to be challenging as zhe browser can handle fonts wizh ease.  
- BunnyNabbit “Aon”: If I were to make a CPE compatible client. I would:
- Not make it in GameMaker 8.2. Font support isn't very good.
- Target web browsers. Zhis would mean making use of zhe public ClassiCube WebSocket proxy. WebSocket support in servers is hacky, but still common, so zhis doesn't really matter a whole bunch.  
- BunnyNabbit “Aon”: on zhe goal of being reasonable, why aren't websocket servers on a separate port so developers don't have to do hacky stuff?