Half-Life for Dreamcast has some functional multiplayer components

That is the same code in the HLSDK. Compiling it outputs a new game DLL like what was attempted before. Not the full engine source, if we had that there wouldn't be a need for something like Xash3D

Edit: Even if that was the full source; Porting Xash would be better since its an upgraded engine

 

Well I did some poking around with adding imports to an exe. I found a program to do so and I successfully added the imports from wininet.dll. But I have no idea what i'm doing and broke the exe in the process. So when I render a new cdi it doesn't get passed the produced by/licensed from splash screen. But I can verify the imports were added




I think the exe broke because I added the imports at a different address than the exe import table. But in string view the entire import table was moved, maybe that is the issue also. The import table for the halflife_dc.exe starts on address 0x0017F40E and ends at 0x0017F507. I'm unsure how to add space between that and when the next set of data begins. Maybe someone who know's what they're doing can try to add the imports properly without breaking the exe. I attached a zip of the tool I used

I understand this has slim likelihood of actually being pulled off. But it hasn't exactly been proven impossible yet, there's still a fair amount to work with

The reasons I still have a hunch:

1. All networking for local server is in the game. The game could potentially establish a connection and interact with an external server with internet. Strings and functions for text chat, server browser, server.cfg, motd, multiplayer maps etc could have been removed if multiplayer wasn't intended. Inclusion was deliberate
2. A wrapper application to dial modem and run half-life within the wrapper remains untested
3. Manipulation of the Windows CE registry for the purpose of A.) establishing an internet connection automatically within the Windows CE OS to emulate a networking environment similar to x86 PC B.) Adding support for broadband adapter to test purpose A remains untested
4. The imports/exports of wininet.dll and winsock.dll for Windows CE on Dreamcast match the imports/exports of the WON version of half-life on PC
5. Theory of connect commands functioning with binary hacking was proven correct. I thought pinging a server or master list had a higher probability of working
6. Hacking imports from WON half-life into half-life dc could allow the game to function like the PC version

If I had the skills to do any of that I would've proved myself right or wrong by now. But all I can do is research and post what I find here. This isn't just any game this is half-life we're talking about here
https://mega.nz/#!jMp10abJ!7_oRteS-WNe-wBcM9ZLBMhvFPHoTGnYs-_w0upNZC-w

 

I found what seems to be the official Xash3D forums in russia. I asked about making an engine fork for Dreamcast. They gave me this link for Xash3D ported to SDL. Which the dreamcast supports. But I know KallistiOS isn't exactly optimized

https://github.com/SDLash3D/xash3d

The multiplayer isn't working yet. But is there anything that can be done with this? Having a functional engine could give us a headstart for when the multiplayer aspect of the engine is written and completed/functioning. There's source for CS 1.6 client.dll also but for android I think https://github.com/SDLash3D/cs16-client

I know mods must be ported as well. But it's a start
Opinions?


Edit: If someone wanted to help me get setup on a proper programming environment to do this and provide me reference material for porting i'll do this myself
Edit 2: I tried setting up a KOS environment and quickly realized i have no idea what i'm doing so nevermind

 

So, I've had a quick look at the code - and the engine doesn't appear to use shaders which is good. It doesn't look like it would be too much work to port the SDL version especially as it seems to use SDL 1 and not 2.

I'm going to be looking at porting my own game engine over Christmas (which is SDL2 and uses shaders so that's a bigger job). Once I get the toolchain set up I might be able to have a go at porting this. Depends how much time I have (probably not a lot).

 

This would be incredible. If and after the engine runs, the challenge would be porting that android client.dll, adding support for the modem,bba and microphone. But then we just wait for the multiplayer/networking to be finished. It'd enable anyone to port single player mods that perhaps couldn't before in the meantime

I can help in anything that doesn't require coding. So if maps/models need to be converted I can handle all that. I'm also familiar with porting textures to powerVR if need be. A few months ago I spoke to the developer of chicken fortress 3. I'll ask him if he can open source his client.dll for the purpose of this port if anything happens. He wants to implement item drops like TF2 PC and stuff. PC-DC cross compatibility could even be possible but I don't want to get ahead of ourselves. But awesome, if you make any progress let me know

I'll put some money aside for motivational donations in a few months

 

PVR on the Dreamcast has a fixed-function pipeline, so that won't be a trivial undertaking.

I looked into this a bit this evening, and my conclusion is that the high-level network communication logic is almost certainly present. Loading up the .exe in IDA shows that all the connection and packet handling functions are moderately complex and not stubbed out. Furthermore all the connection and packet routines fall back to a function call at 0x00036884 (which I have named func_connect() locally, but has no associated symbol) . This appears to be where all outbound connections are initiated from. For a request to connect, it appears as if some checking is done to see if the requested connection is on localhost/loopback, if the connection is a retry or a new connection, and then func_connect() is called.

Further supporting this conclusion is the fact that all the high-level packet serialization and inspection routines appear to be present. I obviously can't validate this but a cursory examination of any of the functions around the packet error strings will indicate that they aren't stubs.

What is not present, as you guys have already noted, is the low-level network code. None of the dplay or wininet .dll's are present in the import table so the game has no concept of the hardware necessary for raw socket communication (which is how I'm assuming the PC version used the network layer). I'm also not sure if any of the engine multiplayer code is there. It may be and probably is; I'm not familiar enough with the engine architecture to say one way or the other however. I imagine it is since it seems like Gearbox or whoever did the port went for as close to a 1:1 implementation of the PC version as they could. I.e., only hardware-layer type code was changed as much as was feasible.

My take on what it would require to get multiplayer up and running:
1. Get the modem or ethernet adapter working. This might not be as difficult as it sounds. I took a look through the WinCE docs from the SDK and it appears that it is pretty easy to get the hardware up and running in raw socket mode. You would need to make a standalone .exe that initializes the hardware and maps inbound packets to a specific address, either through pointer casting or a linker script. You would then need to take the relevant generated assembly and inject it into game .exe; there appears to be plenty of space left on the disk so this wouldn't be a huge issue. You would need to ensure that where your socket is living in RAM is not used anywhere by the game however. Alternatively you could write some bit-banging code in C/assembly to do the same thing with the ethernet adapter directly as a patch to the game .exe.

2. Make the game aware of the data from the socket. This would probably be the harder of the two steps (for me anyway). My pure assumption is that GoldSrc has some kind of HAL that separates physical packets from the hardware from logical packets that the game is aware of. You would need to determine what this mapping is and provide the relevant code to make it happen. You would also need to determine if the process is polled or interrupt driven, and provide a WinCE task/thread or appropriate ISR to emulate the behavior.

Neither of these things would be trivial to do, but they are within the realm of possibility for an appropriately skilled and motivated person in my opinion. My advice would be to look at the PC version as much as possible to discern what type of behavior you need to emulate. GoldSrc is closed source, but remember it was based on the Quake engine originally, which has been open-sourced by Carmack and id, and can be found on GitHub. It has been extensively documented and I doubt the network code was changed too much.

Unfortunately I am not very skilled with SH4 assembly and I have enough real-life programming projects to keep me busy so this is as far as I am going to go with it. Also I have no dev experience on actual Dreamcast hardware, this is all from static analysis and reading the SDK docs so some of my conclusions might be a bit off. I'm happy to answer any questions however.

 

What a delight to read this. Fantastic research. But if you don't mind I have a few questions

As you say since the engine side networking seems to be present in entirety, so yes make the new .exe, but to eliminate the need to inject code into the game.exe to look for packets, just make all the changes in the Windows CE OS to be as similar as possible as PC in terms of networking? On the PC version, it doesn't handle the networking within itself, it runs off of the Windows internet.

Then the only injecting that would need to be done would be a wininet.dll and other imports/exports/dependancies from the PC? My theory is at that point, the engine would already know how to use them, It would fool the engine into thinking it was running on a 32-bit Windows PC. Would this not eliminate the second step you mentioned? I have no practical ability for this so I could be very wrong, but I understand the logistics of how everything operates

It was very cool to read that. Thanks for taking the time to look into this. This helps tremendously

 

Well I am making a fair number of assumptions here, but I have written a few network protocols in the past and I write device drivers mostly for work these days so I don't think they are totally unfounded. In my experience this is typically how something like this is structured:

1. High-level "logical" packets. This is what the game engine is aware of and services during execution. The engine internally seems to refer to this as it's "protocol" (which might also be a console command BTW, it was tough to tell from the disassembly alone). All of this code seems to be present.

2. Low-level "physical" packets. In this case, TCP/IP. None of this code was present.

3. Network hardware and device driver interfaced. None of this seemed present, but in the case of WinCE on the Dreamcast it would be handled by the OS.

In the case of a full-featured OS with promiscuous networking, the operating system is responsible for providing levels two and three through internal kernel functionality and/or device drivers. The application is usually only aware of the physical layer to the extent that it needs to initiate a connection (i.e., an IP address). The OS then provides a highly abstract "socket" object that application is aware of, and knows how to get data (logical packets) from.

WinCE on the Dreamcast seems to follow this model as well, with the corresponding functionality present in wininet.dll and winsock.dll. However since neither of these .dll's are present in the import table, it can be concluded that the compiler found no functions from these libraries at link-time that it needed to resolve, and left them out. In short, the logic in the game necessary to configure the network hardware was probably commented out, and discarded by the compiler at compile time.

Simply adding the imports back into the import table won't accomplish much as you still need to call the initialization routines in the correct place. You could go through the assembly and try to work this out, but I think it would be easier to make a standalone executable and then take the relevant code and inject it back into the game executable. But there are many ways to skin a cat. Also of note is that the WinCE kernel seems to support up to 32 concurrent processes, so you could possibly launch your networking executable alongside Half-Life with the socket address setup to point to a fixed memory location that you modify the HL executable to look at. But that is pure speculation.

I think the wininet.dll has been a bit of a red herring personally, if you read the SDK docs it is mostly responsible for high-level internet functionality like web pages, etc. The real socket communication is done in winsock.dll (accept(), recv(), bind(), connect(), etc.). The SDK says that wininet.dll ends up calling winsock.dll for everything request it gets, but I'm familiar enough with the Windows linking procedure to know if it would get added to the import table as a .dll or not. Also of note is the the SDK provides static libraries alongside all the dynamic ones, so it is possible (but unlikely) that Gearbox statically linked in the entire winsock library to the game executable. I'm not sure how Windows handles symbol resolution on statically linked libraries, and if the function names get stripped or not. I did search for bind() and connect() but I didn't find any symbols for them.

 

Thank you for your insight and clarifications. I'll probably start gathering info about how the WON verison of PC half-life handled it's networking since that's what our build derives from

You mentioned some stuff about localhost/loopback. When I try to change the masterlist among other things in console, it defaults back to loopback. Do you think this is another lockout like the connect <ip> commands that required the binary to be patched? Could another patch be made to manipulate those functions without defaulting to loopback? I've been looking for console commands to disable this

If and when someone makes that .exe I think the first thing to do would be getting the game to ping a masterlist. Then get the return server list or some type of return data

 

Okay so cool find, saved on my memory card was 'halflife.cfg'. I copied that over to my PC and opened the VMS files in Notepad++, it seems to be the master config file when the game binary initially loads. I added a bunch of commands, like binding the chats, decal sprays, etc. But nothing can be done as far as server variables like your player name, since that must be done in-game once the server loads

What i'm thinking is since the liblist.gam file for loading a new dll doesn't work on-disc. This must be done via the halflife.cfg file on the memory card before the game loads. This should be tested with a new dll immediately. I if you need the SH4 sources I acquired for a new game dll, send me a PM

I attached a zip of the save file (which after i tested isn't needed but its there anyway) and halflife.cfg. Edit the VMS file in Notepad++ then upload to the internet and download on a browser or use VMU tool over BBA. I'm going to test some more stuff, it's possible the game looks for other .cfg files too like liblist.gam or server.cfg. This may be how custom spray decals would be done also. I'm almost certain this is how we'd load a new dll making this a whole lot easier

 

This is a console command. Typing 'protocol' outputs 'protocol is 39'

 

Yes I think this would be pretty simple to do, the conditionals in the connect area seem to be pretty straightforward.

 

(Sorry for the multipost, the reply is longer than the 10000 character max)

I don't think this will do what you are thinking it will. Here is a list of all the places where *.cfg is hardcoded in the executable however:

Code:

Address        Function   Instruction
-------        --------   -----------
.text:000284B4 sub_28480                  mov.l   #aServer_cfg, r5 ; "server.cfg"
.text:00028674 sub_28598                                          ; "server.cfg"
.text:0002977A sub_29694                  mov.l   #aExecConfig_cfg, r4 ; "exec config.cfg\n"
.text:00029782 sub_29694                  mov.l   #aExecPreset_a_c, r4 ; "exec preset_a.cfg\n"
.text:0002978A sub_29694                  mov.l   #aCdRomValveHalf, r4 ; "/CD-ROM/valve/halflife.cfg"
.text:0002979A sub_29694                  mov.l   #aExecHalflife_c, r4 ; "exec halflife.cfg\n"
.text:0002984C sub_297C4                                          ; "exec config.cfg\n"
.text:00029858 sub_297C4                                          ; "exec preset_a.cfg\n"
.text:00029860 sub_297C4                                          ; "/CD-ROM/valve/halflife.cfg"
.text:00029868 sub_297C4                                          ; "exec halflife.cfg\n"
.text:00035300 sub_352AC                  mov.l   #aAutoexec_cfg, r5 ; "autoexec.cfg"
.text:00035312 sub_352AC                  mov.l   #aHwOpengl_cfg, r5 ; "hw/opengl.cfg"
.text:00035324 sub_352AC                  mov.l   #aJoystick_cfg, r5 ; "joystick.cfg"
.text:00035336 sub_352AC                  mov.l   #aGame_cfg, r5  ; "game.cfg"
.text:00035384 sub_352AC                                          ; "autoexec.cfg"
.text:0003538C sub_352AC                                          ; "hw/opengl.cfg"
.text:00035398 sub_352AC                                          ; "joystick.cfg"
.text:0003539C sub_352AC                                          ; "game.cfg"
.text:000422D8 sub_422B4                  mov.l   #aSkippingConfig, r4 ; "skipping config.cfg output, no keys bou"...
.text:000422E4 sub_422B4                  mov.l   #aHalflife_cfg, r4 ; "halflife.cfg"
.text:000422F8 sub_422B4                  mov.l   #aCouldnTWriteCo, r4 ; "Couldn't write config.cfg.\n"
.text:0004235E sub_422B4                  mov.l   #aHalflife_cfg_0, r4 ; "halflife.cfg"
.text:000424F0                                                    ; "skipping config.cfg output, no keys bou"...
.text:000424FC                                                    ; "halflife.cfg"
.text:00042508                                                    ; "Couldn't write config.cfg.\n"
.text:00042524                                                    ; "halflife.cfg"
.text:00044BEA sub_44850                  mov.l   #aExecPreset_a_0, r4 ; "exec preset_a.cfg\n"
.text:00044BFA sub_44850                  mov.l   #aCdRomValveHa_0, r4 ; "/CD-ROM/valve/halflife.cfg"
.text:00044C0A sub_44850                  mov.l   #aExecHalflife_0, r4 ; "exec halflife.cfg\n"
.text:00044E08                                                    ; "exec preset_a.cfg\n"
.text:00044E1C                                                    ; "/CD-ROM/valve/halflife.cfg"
.text:00044E24                                                    ; "exec halflife.cfg\n"
.text:0006187A sub_61868                  mov.l   #aSBanned_cfg, r5 ; "%s/banned.cfg"
.text:000619C4 sub_61974                                          ; "%s/banned.cfg"
.text:00061C52 sub_61C38                  mov.l   #aSListip_cfg, r5 ; "%s/listip.cfg"
.text:00061D38 sub_61CF0                                          ; "%s/listip.cfg"
.text:0009C0A8 sub_9B410                  mov.l   #aExecSkill_cfg, r4 ; "exec skill.cfg\n"
.text:0009C104                                                    ; "exec skill.cfg\n"
.text:0009C762 sub_9C75C                  mov.l   #aExecGame_cfg, r4 ; "exec game.cfg\n"
.text:0009C800                                                    ; "exec game.cfg\n"
.text:00117004 sub_116F34                 mov.l   #aExecPreset_C_c, r5 ; "exec preset_%c.cfg"
.text:00117088                                                    ; "exec preset_%c.cfg"
.text:001221A6 sub_1221A0                 mov.l   #aExecConfig_c_0, r4 ; "exec config.cfg\n"
.text:001222B8 sub_122234                                         ; "exec config.cfg\n"
.data:001967FC            aServer_cfg:    .sdata "server.cfg"     ; DATA XREF: sub_28480+34o
.data:00196DD4            aExecConfig_cfg:.sdata "exec config.cfg" ; DATA XREF: sub_29694+E6o
.data:00196DE8            aExecPreset_a_c:.sdata "exec preset_a.cfg" ; DATA XREF: sub_29694+EEo
.data:00196DFC            aCdRomValveHalf:.sdata "/CD-ROM/valve/halflife.cfg" ; DATA XREF: sub_29694+F6o
.data:00196E18            aExecHalflife_c:.sdata "exec halflife.cfg" ; DATA XREF: sub_29694+106o
.data:00197AD8            aAutoexec_cfg:  .sdata "autoexec.cfg"   ; DATA XREF: sub_352AC+54o
.data:00197AE8            aHwOpengl_cfg:  .sdata "hw/opengl.cfg"  ; DATA XREF: sub_352AC+66o
.data:00197AF8            aJoystick_cfg:  .sdata "joystick.cfg"   ; DATA XREF: sub_352AC+78o
.data:00197B08            aGame_cfg:      .sdata "game.cfg"       ; DATA XREF: sub_352AC+8Ao
.data:0019A868            aSkippingConfig:.sdata "skipping config.cfg output, no keys bound"
.data:0019A898            aHalflife_cfg:  .sdata "halflife.cfg"   ; DATA XREF: sub_422B4:loc_422E4o
.data:0019A8A8                            .sdata "t write config.cfg."
.data:0019A8E0            aHalflife_cfg_0:.sdata "halflife.cfg"   ; DATA XREF: sub_422B4+AAo
.data:0019AE9C            aExecPreset_a_0:.sdata "exec preset_a.cfg" ; DATA XREF: sub_44850:loc_44BEAo
.data:0019AEC0            aCdRomValveHa_0:.sdata "/CD-ROM/valve/halflife.cfg" ; DATA XREF: sub_44850+3AAo
.data:0019AEDC            aExecHalflife_0:.sdata "exec halflife.cfg" ; DATA XREF: sub_44850+3BAo
.data:0019ED1C            aSBanned_cfg:   .sdata "%s/banned.cfg"  ; DATA XREF: sub_61868+12o
.data:0019EE64            aSListip_cfg:   .sdata "%s/listip.cfg"  ; DATA XREF: sub_61C38+1Ao
.data:001A5CE8                            .data.l aServer_cfg_0   ; "server.cfg"
.data:001A5CFC                            .data.l aListenserver_c ; "listenserver.cfg"
.data:001A71F0            aServer_cfg_0:  .sdata "server.cfg"     ; DATA XREF: .data:001A5CE8o
.data:001A720C            aListenserver_c:.sdata "listenserver.cfg" ; DATA XREF: .data:001A5CFCo
.data:001A87AC            aExecSkill_cfg: .sdata "exec skill.cfg" ; DATA XREF: sub_9B410+C98o
.data:001A8E64            aExecGame_cfg:  .sdata "exec game.cfg"  ; DATA XREF: sub_9C75C+6o
.data:001BAEB4            aExecPasscode_c:.sdata "exec passcode_c1a0.cfg"
.data:001BAED8            aExecPasscode_0:.sdata "exec passcode_c1a1.cfg"
.data:001BAEFC            aExecPasscode_1:.sdata "exec passcode_c1a2.cfg"
.data:001BAF20            aExecPasscode_2:.sdata "exec passcode_c1a3.cfg"
.data:001BAF44            aExecPasscode_3:.sdata "exec passcode_c1a4.cfg"
.data:001BAF68            aExecPasscode_4:.sdata "exec passcode_c2a1.cfg"
.data:001BAF8C            aExecPasscode_5:.sdata "exec passcode_c2a2.cfg"
.data:001BAFB0            aExecPasscode_6:.sdata "exec passcode_c2a3.cfg"
.data:001BAFD4            aExecPasscode_7:.sdata "exec passcode_c2a4.cfg"
.data:001BAFF8            aExecPasscode_8:.sdata "exec passcode_c2a4d.cfg"
.data:001BB020            aExecPasscode_9:.sdata "exec passcode_c2a5.cfg"
.data:001BB044            aExecPasscod_10:.sdata "exec passcode_c3a1.cfg"
.data:001BB068            aExecPasscod_11:.sdata "exec passcode_c3a2.cfg"
.data:001BB08C            aExecPasscod_12:.sdata "exec passcode_c4a1.cfg"
.data:001BB0B0            aExecPasscod_13:.sdata "exec passcode_c4a1a.cfg"
.data:001BB0D8            aExecPasscod_14:.sdata "exec passcode_c4a2.cfg"
.data:001BB0FC            aExecPasscod_15:.sdata "exec passcode_c4a3.cfg"
.data:001BB120            aExecPasscod_16:.sdata "exec passcode_c5a1.cfg"
.data:001BB144            aExecPasscode_b:.sdata "exec passcode_ba_security1.cfg"
.data:001BB174            aExecPasscod_17:.sdata "exec passcode_ba_canal1.cfg"
.data:001BB1A0            aExecPasscod_18:.sdata "exec passcode_ba_yard1.cfg"
.data:001BB1CC            aExecPasscod_19:.sdata "exec passcode_ba_xen1.cfg"
.data:001BB1F8            aExecPasscod_20:.sdata "exec passcode_ba_power1.cfg"
.data:001BB224            aExecPasscod_21:.sdata "exec passcode_ba_teleport2.cfg"
.data:001BB3B0            aExecuteDebug_c:.sdata "Execute DEBUG.CFG"
.data:001BB3C4            aExecDebug_cfg: .sdata "exec debug.cfg"
.data:001BC748            aExecPreset_C_c:.sdata "exec preset_%c.cfg" ; DATA XREF: sub_116F34+D0o
.data:001BDA70            aExecConfig_c_0:.sdata "exec config.cfg" ; DATA XREF: sub_1221A0+6o

 

Cool, here are the other console commands from that area of the executable (0x0004c880):

Code:

menu
startgame
c0dez
screensaver
getcertificate
notify
getsv
bgetsv
bgetmod
pingsv
protocol
logos
crc
killserver
soundfade
wc
status
changelevel2
reconnect
map
maps
restart
reload
changelevel
connect
say
say_team

(I had to type these by hand, let me know if one doesn't work). Hope this helps.

 

A few of those are new commands for the DC build i'm pretty sure that aren't listed here http://sr-team.clan.su/K_stat/hlcommandsfull.html

I'll find out which ones aren't listed later

I was hoping there'd be a way to load another dll because I think we could load any new engine changes there than needing a new exe. there are a few references to dll in the exe but like you say there doesnt seem to be much of a way to load them. But using the vars from liblist.gam in halflife.cfg on the memory card could potentially work. That would be the only place it would

 

Notify - Not listed in var/commandlist, closes console and locks the game up, i can move the camera but can't move pause or toggle the console
getsv - Not listed, no console output
bgetsv - Not listed, no console output. Likely similar to 'bgetmod' = "request batch mod status"
pingsv - Not listed, no output. Probably similar to 'pingservers'
wc - Not listed, no output

Not sure if that's useful info but as far as packets and protocol there's stuff like 'cl_shownet' and 'showpackets'

 

Two things, at the foot of the VMU CFG file, there's this
(hex value)

Code:

e7 d5 ec 94 c2 55 68 82 a6 a9 c5 ca 70 b7 54 af
84 26 5e c8 bf 2c 6d a7 cf db c9 aa 37 16 4b 45
c6 e7 36 72 d5 61 67 9a f4 a2 fc cb 74 66 3b f5
46 55 17 73 65 91 ca f4 50 a9 42 ec 89 fb 76 6e
b9 ce e7 0a 7c 10 50 fd 96 70 d8 6a 05 99 0d 56
fe 72 f5 2f 57 79 ef c9 78 bf fa db 3f ca 73 95
40 c6 7f c4 a6 02 d0 df d7 a8 cc 08 d5 57 48 4a
a9 9e bd 19 e1 54 f1 4a 4a b2 32 9a 0d 15 7f cd
9d 6a 21 fb 8e ec 3d ff 09 fa 02 37 c8 d3 c4 09
ae b5 3a 8e 95 8c 1a b9 04 54 f3 b2 c5 4e 0d 66
f2 5b 38 f7 9e b7 1b d5 d5 68 7f 5b d2 85 c3 a0
1c 33 fa ba f9 28 62 64 25 22 c4 8f af 63 49 92
7f 38 c3 40 76 46 47 5e 12 04 89 88 6e fb 44 ae
d8 8d 14 fa fc e4 f5 0f 0b f0 56 69 74

(as text)

Code:

çÕì”ÂUh‚¦©ÅÊp·T¯„&^È¿,m§ÏÛɪ7KEÆç6rÕagšô¢üËtf;õFUse‘ÊôP©Bì‰ûvn¹Îç
|Pý–pØj™
Vþrõ/WyïÉx¿úÛ?Ês•@ÆĦÐßרÌÕWHJ©ž½áTñJJ²2š
͝j!ûŽì=ÿ    ú7ÈÓÄ    ®µ:Ž•Œ¹Tó²ÅN
fò[8÷ž·ÕÕh[Ò…Ã 3úºù(bd%"ď¯cI’8Ã@vFG^‰ˆnûD®ØúüäõðVit

Is there any way of finding out what that data does?

And there's a command 'startgame' that's used to load either half-life or blue shift (startgame valve \ startgame barney). This could perhaps be used to load another folder for example called "mod" by running 'startgame mod'. I have some stuff to try when I have CDs

 

Also after taking a closer look at the server browser strings, it looks like it may have been compatible with windows and linux, either by the server or cross platform by the " - win32 \ - linux" strings. The " - listen " string wouldve obviously been other Dreamcast clients while " - dedicated " would be PC servers

Code:

------------------
%i %s %s %i/%i
Adr:  %s - Dir:  %s
  dedicated -
  listen -
  type (%c) -
win32 -
linux -
os (%c) -
password
nopasswd
pw (%c) -
+serverside
+client.dll
Mod info:
Info URL %s
DL URL %s
Ver. %i, size %i
No local servers in list.
Try 'slist' to search again.
empty slot
------------------

Also below those strings above, it seems to have the whole server connection method in the engine. And all of the errors it expects between each step. I thought that was significant

Code:

------------------
%i %s %s %i/%i
Adr:  %s - Dir:  %s
  dedicated -
  listen -
  type (%c) -
win32 -
linux -
os (%c) -
password
nopasswd
pw (%c) -
Mod info:
Info URL %s
DL URL %s
Ver. %i, size %.2f MB
%i.%i.%i.%i
%4i:  %s:%i
%i total servers
end-of-list
more-in-list
%3i %5i %s
%i servers
more-in-list
Done.
%i.%i.%i.%i
%i servers
Done.
loopback
Connection accepted by %s
The server requires that you be validated through WON.net.
Could not obtain WON authentication.
BADPASSWORD
BADPASSWORD
BADPASSWORD
BADPASSWORD
Invalid server password.
Ping took %.3f ms.
Unknown command:
%s: Runt packet
%s:sequenced packet without connection
Server connection timed out.
Can't cl_print_custom, not connected
D:\proj\halflifedc\src\engine\cl_main.c
Unable to allocate %i client frames
dropclient
2534835307254
Key has no meaning on dedicated server...
Bogus key length on CD Key...
local
localhost
Bad server address
27015
models/player/gordon/gordon.mdl
could not find models/player/gordon/gordon.mdl
*modelcrc
%c%c%c%cconnect %i %i %i %i %i "%s" "%s"
localhost
cl_resend
cl_resend
local
localhost
Bad server address
27015
Connection failed after %i retries.
localhost
Connecting to %s...
Retrying %s...
%c%c%c%cgetchallenge
Can't retry, no previous connection
connect %s
Commencing connection retry to %s
usage: connect <server>
local
start
Long timecheck gap between %s and %s
Long timecheck gap after %s
spawn %i %s
CL_Signon 1
begin
CL_Signon 2
CL_Signon 3
No demos listed with startdemos
playdemo %s
EMPTY
%s:%2i  (%5.1f,%5.1f,%5.1f) [%5.1f %5.1f %5.1f]
Snapshot
%s%04d.bmp
startmovie <filename>
Started recording movie...
No movie started.
Stopped recording movie...
You must set 'rcon_password' before
issuing an rcon command.
You must either be connected,
or set the 'rcon_address' cvar
to issue rcon commands
Unable to resolve rcon address %s
27015
rcon "%s"
cl_view entity#
Current %i
View entity set to %i
Skipping upload...
custom resource list not valid -- not connected
CL_SendResourceListBlock_f from different level
custom resource list request out of range
customrsrclist %i %i
Too many resources on client.
pldecal.wad
custom.hpk
Client downloading enabled.
Client downloading disabled.
Client uploading enabled.
Max. upload size is %i
Client uploading disabled.
HudText
Client Rep. of Player Logos ===
SELF ====================
SELF ====================
==========================
usage: fullserverinfo <complete info string>
--------------------------
Time %.3f
Drop %.2f%%
Avg. Latency %.2f
Load K/s %.2f
Upd/s %.2f
Rate %.2f
cl fps %.1f
unnamed
topcolor
bottomcolor
fullserverinfo
retry
disconnect
snapshot
startmovie
endmovie
entities
cl_view
cl_messages
cl_bitcounts
cl_usr
pingservers
slist
clearlist
resources
cl_allow_upload
cl_allow_download
upload
allowupload
skipdl
skipul
cl_print_custom
D:\proj\halflifedc\src\engine\cl_main.c

 

We really need to rig an internet connection that the half-life process can see. After that this may just work without further hacks/modification

 

The more I have thought about this over the past few weeks the more interested I get...

Just for kicks I checked some of the reversed HL source against the Quake code on id's GitHub and they match up almost one to one. If I were to approach it I would set up the BBA and get it working on a LAN first, as this would obviate the need for two native development environments to test the network code. BBAs are a bit on the expensive side for a project that I don't know if I will take on or not, but I may end up getting a few regardless.

I would also probably need one of the official HKT-01xx series dev boxes. Paying for one of these would be less of an issue since I have been meaning to get one anyway, but I don't see them up for sale very often for a reasonable price. And when they do come up, they are usually snatched by collectors pretty quickly.

I am still busy with real-life work but if the stars align and I can get the hardware, I might try to make this work.