Half-Life for Dreamcast has some functional multiplayer components

This is actually becoming pretty cool

I've obviously been looking more at the internal networking of the engine. Something I want to try is configuring the RAS dialer to use IPX instead of TCP/IP. But that may have to be done on the DreamPi @kazade is it possible to have the Pi assign the Dreamcast an IPX address instead of a TCP/IP address? I was looking at what IPX does and it seems likely that network testing using an internal IPX LAN network could have been done

While looking into the binary for references to IPX, there isn't much but one of the three strings with IPX is coupled in this string block

This is what that string block is in the engine


You can clearly see where the tcp/ip : %s ipx : %s lines would go. So that's good enough reason to believe those do actually work somehow. Also all of the console commands related to multiplayer/server are grouped in one area very close to the string block quoted above, 200 strings down ( out of 18305 strings )

I also looked at this

And that should be the console output for the 'getsv' and 'bgetsv' commands. '%s' I'm pretty sure is the masterlist. Because before I use the 'setmaster' command, having no masterlist set, 'getsv' and 'bgetsv' do nothing. But when I set the masterlist, then run those commands I get a datatype misalignment exception and the engine crashes. 'getsv' doesn't crash, but the engine halts. Probably because it's requesting a serverlist from "loopback"

I think the engine is supposed to be setup internally a certain way to use all of those commands and display the tcp/ip / ipx addresses those commands, and use the 'setmaster' command without it defaulting back to 'loopback". There's a bunch of internal engine calls that you cannot get to from the console for prespawning, file downloading, 'Host_Map' etc

Here is some stuff for loopback, some internal engine calls etc

The bold italic underlined large font part is the strings for the client connection protocol. I was doing packet capturing for this yesterday and when I was trying to connect from PC version to the Dreamcast server and the packet the PC was sending was "getchallengesteam". So when the server receives a "getchallenge" packet, it knows another GoldSRC client is trying to connect and probably sends the client parsing packets back to the connecting player 2

All this stuff is there and works, I'm almost certain now. We'll just have to see what happens with parameter testing

 

Wow that could work. Maybe If I run a .reg file by that multi-exe program it will append that to the registry, but there's also a tool in the SDK to merge the kernels main .reg files with something like that

 

I left 'getsv' as the engine halted for awhile and it eventually gave this output


I'm not sure how long that took. But the engine kept requesting the server list from itself, I read here http://forums.steampowered.com/forums/showthread.php?t=132594 that loopback is actually just a fancy word for localhost or 127.0.0.1

But it shows the engine is actually trying to get a server list, and isn't just a null/defunct command. It'd be nice if I had another CD
If i figure out how to disable the loopback perhaps that is why half-life cannot use the internet connection i established

 

I tried most of the command line parameters with strings today. And I found information about the ones i was unsure of

Turns out it looks like all of the visible command parameter strings in the binary are strings leftover from quake
http://www.quakewiki.net/archives/console/commands/quake.html#h-4

didnt mean to put as code but too lazy to fix

Code:

-cachedir

    Status: Disabled

    Type: Parameter

    Syntax: game.exe -cachedir (fully qualified path)

    Description: The location of game cache files.

Code:

-hipnotic

    Type: Parameter

    Description: Start the game with the Hipnotic mission pack.

    Note: When this parameter is used the game will be started as if using the '-game hipnotic' parameter instead.

Code:

-proghack

    Status: Unknown

    Type: Parameter

There's also this command, which is also in half-life

When I run that in-game, it says 'cmdline "0"'. Meaning the engine does not recognize any command line switches. Unless the method of which I'm passing them by the command shell won't work. Though it does work for RAS.EXE/MRASDIAL.EXE

I still want to try a bunch of the options listed on valve dev wiki
----
In the documentation for Windows CE, there's tutorials for setting up a RAS connection over serial connection using Windows NT 4.0. Meaning I can connect to the internet over the serial port. I can also directly monitor every byte sent and received

But there's absolutely no bytes/packets transfered when connected to the internet. I tried a crapload, and nothing works. Though that shouldn't underplay that the concept of connecting to the internet while half-life is running has been proved, as well as running command line parameters without a katana. Even if they seem to have no effect
----

I also tried putting the new hl.dll file as a module in the WinCE image config tool. If you use a PC/x86 dll the image render will fail. It will only work for the one compiled for CE/SH4

Everytime Half-Life loads up, it crashes just before any video is displayed. But the crash is not immediate. This only happens with the dll as an OS module. Meaning it is loaded in memory, and has effect on half-life

-------


So I think this may be the end of my testing and research into this, so I guess my conclusion is:


Everything for multiplayer is in the engine, in tact, and seems to work as it should. It just cannot see any outside internet connection

Even though GoldSRC cannot see the connection, you can connect to the internet alongside Half-Life

You can have complete control over the Windows CE kernel, registry, and command line using the Windows CE SDK

The only way to load a GoldSRC extension DLL is by loading it as a module in the Windows CE Dreamcast image config tool. I'm not certain of this, but if loading that way crashes the engine, then the engine seems to be aware of it


Multiplayer and full mod support is probably very possible. Here's my opinion how:
The following is assuming a highly skilled programmer was attempting this


Try 1st: Cleanly port the hl.dll from Valve's HLSDK source code on their GitHub. Tasos who compiled the one I have said he did a bunch of hacks to get it to build. Which was why he couldn't give me the further modified source, it would have taken awhile to find everything and organize it. It 's possible that even though the dll did build, it didn't build properly due to improper porting. Loading a cleanly ported hl.dll from the Windows CE image tool could actually run

Essentially what I mean is, the HLSDK code is supposed to do exactly what we're trying to do. Making it work on a foreign platform is going to be the challenging part. We have an essentially completed engine port, and the expansion source code

If the dll loads, the functions for reading the network flashrom information, dialing the modem, adding mic/bba support, using winsock or wininet, and porting full GoldSRC mods can be coded into it For absolute sure

if someone has the skill they can probably use the registry to their advantage

There's also probably a way to disable the loopback, maybe then the ras.exe connection can be visible



----------------






SO that is almost absolutely all I can do on this subject. I continued to bump this with logs of my research so if somebody with the skill wants to take a look at this, this thread is probably the best documentation of the GoldSRC engine for the Dreamcast on the internet. If I thought this actually couldn't be done, then I wouldn't have put all of the time into it as I have

It would be cool to see others try to get further, and see their research updates and further the documentation. But I cannot do anymore without coding knowledge. And learning c++ will take a very long time to attempt anything on a level of this

@Trident6 It's up to you lol

What do other people think about this?

But yes this is the conclusion to my research on this

 

I know I said the previous post was the conclusion, but I found some really interesting stuff today

There's a bunch of network monitoring tools. I even found one that only activates once the 'connect' command is run. It's 'cl_adaptive'


The graph is r_netgraph, the only valid values are 2 and above 'r_netgraph 1' has no effect
After finding this i'm almost sure that there is a way to connect to the internet. I'm not sure if these are also in the WON version

There's also CPU/RAM/SPU cache monitoring by typing 'profilemeter <1-14>' and some kind of meter by typing 'profilescale <1+>'

I did more stuff because I used the client.exe and server.exe sample applications using two Dreamcast's to see if I can get packets to transfer. But no data was transferred at all even between the samples

While calibrating a laser (which was a massive pain to do) I got the engine to not crash one time with the hl.dll included in the OS. The engine still crashed but it didn't reboot. This is what it looked like

I'm pretty sure this means the DLL is attempts to load. Maybe someone else can share their thoughts on why this happens

 

The last picture is very neat... I have no idea why it would do that unless you were possibly writing to the screen buffer without trapping the MMU.

Anyway, there are a lot of reasons why text might show up in a binary but not be accessible or referenced at runtime. Usually on debug builds, optimizations aren't enabled, nor is dead code pruning. The Microsoft compilers have historically (especially at the time this was built) been far behind GCC and Clang in terms of optimization effectiveness. So I wouldn't jump to conclusions that just because some text is in the binary it means that it shows up in the game somewhere.

However with that said it does look like they were pursuing network support in some capacity. I am still interested in working through this but I am slammed at the moment with real-life responsibilities and things probably won't change for the next six months or so. I don't even have a TV set up at my current place, never mind an entire workstation.

Definitely keep at it though, and hopefully once the summer is over I'll have time to look into it more closely.

 

Also learning C++ really isn't going to help you a ton for this project, past getting the project setup to build. IDA Pro (6.5+ ?) can read the binary perfectly, you would probably be better off getting a copy of that and working on learning SH4 from the disassembly if you really want to know what the binary is doing, and where the text strings are used within the executable.

 

I've actually had an ASM file of the disassembled binary for a long time

I looked into it using Notepad++ since I don't have the VM with Hex Rays anymore. All of the multiplayer engine functions seem to be also grouped into one area. And you can see all of the 'svc_' functions. Which seem to be internal engine function calls and cannot be accessed from the console

It's too long to quote. I think the ASM is well over one million lines
http://pastebin.com/JWCwhXff
Press CTRL+F and type 'svc_' to see all of them

There's also this which looked interesting. Syntax for an alternative 'connect' command it looks like. There's three references to it

Code:

loc_246D4:                ; CODE XREF: sub_244EC+1BAj
        mov.w    #h'560, r3
        add    r14, r3
        mov    r3, r4
        mov.l    #aCCCCconnectIII, r5 ; "%c%c%c%cconnect %i %i %i %i %i \"%s\" \"%s"...
        mov.w    #h'FF, r6
        mov.w    #h'FF, r7
        mov    r15, r1
        mov.w    #h'FF, r2
        mov.l    r2, @(h'10,r1)
        mov    r15, r3
        mov.w    #h'FF, r1
        mov.l    r1, @(h'14,r3)
        mov    r15, r2
        mov.l    #asc_1BE11C, r3    ; "'"
        mov.l    @r3, r3
        mov.l    r3, @(h'18,r2)
        mov    r15, r1
        mov.l    #unk_33C180, r2
        mov.w    #h'2384, r0
        mov.l    @(r0,r2), r2
        mov.l    r2, @(h'1C,r1)
        mov    r15, r3
        mov.l    #unk_33C180, r1
        mov.w    #h'2388, r0
        mov.b    @(r0,r1), r1
        extu.b    r1, r1
        mov.l    r1, @(h'20,r3)
        mov    r15, r2
        mov.l    @(8,r14), r3
        mov.l    r3, @(h'24,r2)
        mov    r15, r1
        mov.l    @(h'C,r14), r2
        mov.l    r2, @(h'28,r1)
        mov    r15, r3
        mov.w    #h'160, r1
        add    r14, r1
        mov.l    r1, @(h'2C,r3)
        mov    r15, r2
        mov.l    #unk_33C180, r3
        mov.w    #h'2CCA, r1
        add    r1, r3
        mov.l    r3, @(h'30,r2)
        mov.l    #_sprintf, r2
        mov.l    @r2, r2
        jsr    @r2
        nop
        mov.w    #h'560, r3
        add    r14, r3
        mov    r3, r4
        mov.l    #_strlen, r0
        jsr    @r0 ; _strlen
        nop
        mov    r0, r1
        mov.l    r1, @(h'DA8+var_D74,r15)
        mov    #0, r4
        mov    r1, r5
        mov.w    #h'560, r2
        add    r14, r2
        mov    r2, r6
        mov    #h'2C, r3
        add    r14, r3
        mov    r15, r1
        add    #h'10, r1
        mov.l    r1, @(h'20,r14)
        mov.l    @r3+, r2
        mov.l    r2, @(h'1C,r14)
        mov.l    @r3+, r8
        mov.l    r8, @(h'10,r14)
        mov    r1, r9
        mov.l    r2, @r9
        mov    r1, r2
        mov.l    r8, @(4,r2)
        mov.l    @r3+, r8
        mov.l    r8, @(h'14,r14)
        mov.l    @r3+, r9
        mov.l    r3, @r14
        mov.l    r9, @(h'18,r14)
        mov    r1, r2
        mov.l    r8, @(8,r2)
        mov.l    r9, @(h'C,r1)
        mov.l    @(h'28,r14), r7
        mov.l    #sub_1242E4, r0
        jsr    @r0 ; sub_1242E4
        nop

loc_2477C:                ; CODE XREF: sub_244EC+94j
                    ; sub_244EC+1B6j
        mov.w    #h'D60, r2
        add    r14, r2
        lds.l    @r2+, pr
        mov.l    @r2+, r9
        mov.l    @r2+, r8
        mov    r2, r15
        rts
        mov.l    @r15+, r14
; End of function sub_244EC

I quoted the whole ASM block where the second reference is in case it's useful

Code:

; ---------------------------------------------------------------------------
word_247EC:    .data.w    h'103           ; DATA XREF: sub_2478C+38r
word_247EE:    .data.w    h'2394          ; DATA XREF: sub_2478C+30r
word_247F0:    .data.w    h'560           ; DATA XREF: sub_244EC:loc_246D4r
                    ; sub_244EC+244r ...
word_247F2:    .data.w    h'C4            ; DATA XREF: sub_244EC+1E0r
word_247F4:    .data.w    h'160           ; DATA XREF: sub_244EC+22Cr
word_247F6:    .data.w    h'D60           ; DATA XREF: sub_244EC:loc_2477Cr
word_247F8:    .data.w    h'2384          ; DATA XREF: sub_244EC+20Cr
word_247FA:    .data.w    h'F6FC          ; DATA XREF: sub_2478C+8r
word_247FC:    .data.w    h'2388          ; DATA XREF: sub_244EC+216r
                    ; sub_2478C+46r
word_247FE:    .data.w    h'FF            ; DATA XREF: sub_244EC+1F0r
                    ; sub_244EC+1F2r ...
word_24800:    .data.w    h'2CCA          ; DATA XREF: sub_244EC+1D2r
                    ; sub_244EC+236r
        .align 4
off_24804:    .data.l    _sprintf    ; DATA XREF: sub_244EC+1C8r
                    ; sub_244EC+23Cr
off_24808:    .data.l    sub_165324    ; DATA XREF: sub_244EC+19Cr
off_2480C:    .data.l    aModelsPlayerGo    ; DATA XREF: sub_244EC+19Ar
                    ; "models/player/gordon/gordon.mdl"
off_24810:    .data.l    aCouldNotFindMo    ; DATA XREF: sub_244EC+1AEr
                    ; "could not find models/player/gordon/gor"...
off_24814:    .data.l    unk_2EE160    ; DATA XREF: sub_2478C+1Ar
off_24818:    .data.l    aD_0        ; DATA XREF: sub_244EC+1C4r
                    ; "%d"
off_2481C:    .data.l    aModelcrc    ; DATA XREF: sub_244EC+1D8r
                    ; "*modelcrc"
off_24820:    .data.l    unk_1BDA4C    ; DATA XREF: sub_2478C+28r
off_24824:    .data.l    aCCCCconnectIII    ; DATA XREF: sub_244EC+1EEr
                    ; "%c%c%c%cconnect %i %i %i %i %i \"%s\" \"%s"...
off_24828:    .data.l    asc_1BE11C    ; DATA XREF: sub_244EC+202r
                    ; "'"
off_2482C:    .data.l    aLocalhost_0    ; DATA XREF: sub_2478C+36r
                    ; "localhost"
off_24830:    .data.l    off_1650AC    ; DATA XREF: sub_244EC+18Er
off_24834:    .data.l    sub_3D774    ; DATA XREF: sub_244EC+1E2r
off_24838:    .data.l    sub_36884    ; DATA XREF: sub_244EC+1B0r
off_2483C:    .data.l    _strncpy    ; DATA XREF: sub_2478C+3Ar
off_24840:    .data.l    unk_33C180    ; DATA XREF: sub_244EC+1D0r
                    ; sub_244EC+20Ar ...
off_24844:    .data.l    _strlen        ; DATA XREF: sub_244EC+24Ar
off_24848:    .data.l    sub_1242E4    ; DATA XREF: sub_244EC+28Ar
; ---------------------------------------------------------------------------

This seems to be the function definition

Code:

aCCCCconnectIII:.sdata "%c%c%c%cconnect %i %i %i %i %i " ; DATA XREF: sub_244EC+1EEo
                    ; sub_2478C:off_24824o
        .data.b    h'22
        .sdata "%s"
        .data.b    h'22
        .sdata " "
        .data.b    h'22
        .sdata "%s"
        .data.b    h'22, h'A, 0
        .align 4

 

Now I can see that "%i" in "%c%c%c%cconnect %i %i %i %i %i" is the ip, and the last %i is the port. But what's interesting is the "%c". Meaning another set of variables can go before 'connect'?

There's another command which I cannot figure out what it does, "wc". But there are these references

Code:

        nop
        mov.l    #sub_35854, r0
        mov.l    #aWc, r4    ; "wc"
        mov.l    #off_4C380, r5
        jsr    @r0 ; sub_35854

Code:

aWc:        .sdata "wc"             ; DATA XREF: sub_4C880+AEo
                    ; sub_4C880:off_4C9F8o
        .data.b    0
        .align 4

Code:

off_4C9F8:    .data.l    aWc        ; DATA XREF: sub_4C880+AEr
                    ; "wc"

I'd really like to know what that one does so it can be ruled out

I attached the full ASM, open with Notepad++ if anyone wants to take a look. Anything more you'll need a copy of Hex Rays. Again I think it's way over two million lines of text, or two hundred thousand but I'm not sure. so it'd be impressive if someone looked through the whole thing. But anyone can glance at it and clearly see there are a whole lot of functions for server networking that are obviously not for singleplayer/localserver

-------
There's also zero references to hl.dll. But many for client.dll. Also another resource of Half-Life mods. Perhaps the hl.dll is a red-herring. And we actually need a client.dll. Perhaps client.dll is responsible for loading hl.dll. I will do more research on that

Maybe someone with ASM experience can glance at it and let us know what they find or what they can see

 

Client.dll references
Many

Code:

loc_22BAE:                ; CODE XREF: sub_22728+47Cj
        mov    #h'40, r0
        mov.w    @(r0,r14), r9
        tst    r9, r9
        bt    loc_22BBE
        mov.l    #aClient_dll, r4 ; " +client.dll"
        mov.l    #sub_36884, r0
        jsr    @r0 ; sub_36884
        nop

Code:

off_22CE8:    .data.l    aClient_dll    ; DATA XREF: sub_22728+48Er
                    ; " +client.dll"

Code:

loc_288AC:                ; CODE XREF: sub_287E4+3Ej
                    ; sub_287E4+8Cj ...
        mov    #4, r3
        add    r14, r3
        mov    r3, r4
        mov.l    #aCl_dllsClient_, r5 ; "cl_dlls\\client.dll"
        mov.l    #_sprintf, r1
        mov.l    @r1, r1
        jsr    @r1
        nop
        mov    #h'1C, r2
        add    r15, r2
        mov    r2, r4
        mov.l    #off_1650AC, r0
        jsr    @r0 ; off_1650AC
        nop
        mov    #h'1C, r3
        add    r15, r3
        mov    r3, r4
        mov    #4, r1
        add    r14, r1
        mov    r1, r5
        mov.l    #sub_165324, r0
        jsr    @r0 ; sub_165324
        nop
        mov    r0, r2
        mov.l    r2, @(h'5C+var_44,r15)
        tst    r2, r2
        bf    loc_28900
        mov    #1, r4
        mov.l    #aCouldnTCrcClie, r5 ; "Couldn't CRC client side dll %s.\n"
        mov    #4, r1
        add    r14, r1
        mov    r1, r6
        mov.l    #sub_3855C, r0
        jsr    @r0 ; sub_3855C
        nop
        mov.l    #aDisconnected_1, r4 ; "Disconnected"
        mov.l    #sub_41DAC, r0
        jsr    @r0 ; sub_41DAC
        nop
        mov    #0, r0
        bra    loc_28916
        nop
; ---------------------------------------------------------------------------

Code:

loc_28900:                ; CODE XREF: sub_287E4+FCj
        mov.l    #unk_31E1E0, r3
        mov.l    #loc_1BDE8, r0
        mov.l    @(r0,r3), r3
        mov.l    @(h'5C+var_40,r15), r1
        cmp/eq    r1, r3
        bt    loc_28914
        mov.l    #aMismatchedClie, r4 ; "Mismatched client.dll, proceeding...\n"
        mov.l    #sub_36884, r0
        jsr    @r0 ; sub_36884
        nop

Code:

off_28988:    .data.l    aCl_dllsClient_    ; DATA XREF: sub_287E4+CEr
                    ; "cl_dlls\\client.dll"

Code:

off_28990:    .data.l    aCouldnTCrcClie    ; DATA XREF: sub_287E4+100r
                    ; "Couldn't CRC client side dll %s.\n"

Code:

loc_379A8:                ; CODE XREF: sub_37968+Ej
        mov.l    #_sprintf, r1
        mov    #h'10, r4
        mov.l    @r1, r1
        mov.l    #aCl_dllsClien_0, r5 ; "cl_dlls\\client.dll"
        jsr    @r1
        add    r15, r4
        mov.l    #sub_3B448, r0
        mov    #h'10, r4
        jsr    @r0 ; sub_3B448
        add    r15, r4
        mov.l    #sub_27EC0, r0
        mov.l    #aScreenshake, r4 ; "ScreenShake"
        mov.l    #sub_15CC1C, r5
        jsr    @r0 ; sub_27EC0
        nop
        mov.l    #sub_27EC0, r0
        mov.l    #aScreenfade, r4 ; "ScreenFade"
        mov.l    #sub_15CC70, r5
        jsr    @r0 ; sub_27EC0
        nop
        mov.w    #h'210, r2
        add    r2, r15
        lds.l    @r15+, pr
        rts
        mov.l    @r15+, r8
; End of function sub_37968

Code:

off_37A98:    .data.l    aCl_dllsClien_0    ; DATA XREF: sub_37968+46r
                    ; "cl_dlls\\client.dll"

Code:

loc_37D28:                ; CODE XREF: sub_37C94+86j
        mov.l    #sub_12341C, r0
        mov    #1, r5
        mov.w    #h'98, r1
        mov.l    @(h'44+var_24,r15), r2
        mul.l    r2, r1
        mov.l    #aDProjHalflif_9, r6 ; "D:\\proj\\halflifedc\\src\\engine\\eng_cdll_"...
        mov.w    #h'192, r7
        jsr    @r0 ; sub_12341C
        sts    macl, r4
        tst    r0, r0
        bf/s    loc_37D4A
        mov    r0, r12
        mov.l    #sub_3BC8C, r0
        jsr    @r0 ; sub_3BC8C
        nop
        bra    loc_37E3A
        mov    r12, r0

Code:

off_37E54:    .data.l    aDProjHalflif_9    ; DATA XREF: sub_37C94+9Er
                    ; "D:\\proj\\halflifedc\\src\\engine\\eng_cdll_"...

Code:

loc_60DFC:                ; CODE XREF: sub_607AC+63Ej
        mov.l    #_sprintf, r2
        mov    #h'30, r4
        mov.l    @r2, r2
        mov.l    #aCl_dllsClien_0, r5 ; "cl_dlls\\client.dll"
        jsr    @r2
        add    r15, r4
        mov.l    #off_1650AC, r0
        mov    #h'28, r4
        jsr    @r0 ; off_1650AC
        add    r11, r4
        mov.l    #sub_165324, r0
        add    #h'28, r11
        mov    #h'30, r5
        add    r15, r5
        jsr    @r0 ; sub_165324
        mov    r11, r4
        tst    r0, r0
        bf    loc_60E32
        mov.l    #sub_36884, r0
        mov    #h'30, r5
        mov.l    #aCouldnTCrcCl_0, r4 ; "Couldn't CRC client side dll:  %s\n"
        jsr    @r0 ; sub_36884
        add    r15, r5
        mov.l    @(h'80+var_54,r15), r2
        mov    #0, r0
        bra    loc_60FA4
        mov.w    r0, @r2
; ---------------------------------------------------------------------------

Code:

; ---------------------------------------------------------------------------
word_60F06:    .data.w    h'98            ; DATA XREF: sub_607AC+6E8r
word_60F08:    .data.w    h'1EC           ; DATA XREF: sub_607AC+720r
word_60F0A:    .data.w    h'D4            ; DATA XREF: sub_607AC+68Er
word_60F0C:    .data.w    h'D8            ; DATA XREF: sub_607AC+628r
                    ; sub_607AC+698r
word_60F0E:    .data.w    h'B4            ; DATA XREF: sub_607AC+726r
dword_60F10:    .data.l    h'1B0E4         ; DATA XREF: sub_607AC+6A8r
off_60F14:    .data.l    off_1A0E4    ; DATA XREF: sub_607AC+6ACr
off_60F18:    .data.l    sub_1C0E4    ; DATA XREF: sub_607AC+6C2r
off_60F1C:    .data.l    _sprintf    ; DATA XREF: sub_607AC:loc_60DFCr
off_60F20:    .data.l    sub_165324    ; DATA XREF: sub_607AC+664r
off_60F24:    .data.l    off_19A68C    ; DATA XREF: sub_607AC+742r
off_60F28:    .data.l    sub_13A5D8    ; DATA XREF: sub_607AC:loc_60E96r
off_60F2C:    .data.l    unk_29D608    ; DATA XREF: sub_607AC+6B8r
                    ; sub_607AC+734r
off_60F30:    .data.l    unk_2EE160    ; DATA XREF: sub_607AC+626r
                    ; sub_607AC+68Cr ...
off_60F34:    .data.l    off_1650AC    ; DATA XREF: sub_607AC+62Er
                    ; sub_607AC+65Cr
off_60F38:    .data.l    sub_36884    ; DATA XREF: sub_607AC+640r
                    ; sub_607AC+674r
off_60F3C:    .data.l    sub_165330    ; DATA XREF: sub_607AC+634r
off_60F40:    .data.l    sub_3E968    ; DATA XREF: sub_607AC+6AEr
off_60F44:    .data.l    sub_127154    ; DATA XREF: sub_607AC:loc_60E32r
off_60F48:    .data.l    aCouldnTCrcServ    ; DATA XREF: sub_607AC+642r
                    ; "Couldn't CRC server map:  %s\n"
off_60F4C:    .data.l    unk_2A1720    ; DATA XREF: sub_607AC+6E0r
off_60F50:    .data.l    aCl_dllsClien_0    ; DATA XREF: sub_607AC+656r
                    ; "cl_dlls\\client.dll"
off_60F54:    .data.l    _memset        ; DATA XREF: sub_607AC+714r
off_60F58:    .data.l    aCouldnTCrcCl_0    ; DATA XREF: sub_607AC+678r
                    ; "Couldn't CRC client side dll:  %s\n"
; ---------------------------------------------------------------------------

Code:

aCl_dllsClient_:.sdata "cl_dlls\client.dll" ; DATA XREF: sub_287E4+CEo
                    ; sub_28924:off_28988o
        .data.b    0
        .align 4

There's a couple more, but you guys get the point. Perhaps the client.dll is what we need, not hl.dll

 

%c is most likely a char, aka 8bit or a raw byte.

 

Ah okay here we go. Here is the assembly block for the connect command

Code:

aCCCCconnectIII:.sdata "%c%c%c%cconnect %i %i %i %i %i " ; DATA XREF: sub_244EC+1EEo
                    ; sub_2478C:off_24824o
        .data.b    h'22
        .sdata "%s"
        .data.b    h'22
        .sdata " "
        .data.b    h'22
        .sdata "%s"
        .data.b    h'22, h'A, 0
        .align 4
aLocalhost_0:    .sdata "localhost"      ; DATA XREF: sub_2478C+36o
                    ; sub_2478C:off_2482Co
        .data.b    0
        .align 4
aCl_resend:    .sdata "cl_resend"      ; DATA XREF: sub_2478C+D4o
                    ; sub_2478C:off_249ECo
        .data.b    0
        .align 4
aCl_resend_0:    .sdata "cl_resend"      ; DATA XREF: sub_2478C+FAo
                    ; sub_2478C:off_249FCo
        .data.b    0
        .align h'10
aLocal_0:    .sdata "local"          ; DATA XREF: sub_2478C+146o
                    ; sub_2478C:off_24A04o
        .data.b    0
        .align 4
aLocalhost_1:    .sdata "localhost"      ; DATA XREF: sub_2478C+15Co
                    ; sub_2478C:off_24A08o
        .data.b    0
        .align 4
aS_12:        .sdata "%s"             ; DATA XREF: sub_2478C+15Ao
                    ; sub_2478C:off_24A0Co
        .data.b    0
        .align 4
aBadServerAdd_0:.sdata "Bad server address" ; DATA XREF: sub_2478C+180o
                    ; sub_2478C:off_24A18o
        .data.b    h'A, 0
a27015_2:    .sdata "27015"          ; DATA XREF: sub_2478C+19Co
                    ; sub_2478C:off_24A20o
        .data.b    0
        .align 4
aConnectionFail:.sdata "Connection failed after %i retries." ; DATA XREF: sub_2478C+1D2o
                    ; sub_2478C:off_24A24o
        .data.b    h'A, 0
        .align 4
aLocalhost_2:    .sdata "localhost"      ; DATA XREF: sub_2478C+204o
                    ; sub_2478C:off_249D0o
        .data.b    0
        .align 4
aConnectingToS_:.sdata "Connecting to %s..." ; DATA XREF: sub_2478C+21Eo
                    ; sub_2478C:off_249D8o
        .data.b    h'A, 0
        .align h'10
aRetryingS___:    .sdata "Retrying %s..." ; DATA XREF: sub_2478C:loc_24A28o
                    ; sub_24B14:off_24B60o
        .data.b    h'A, 0
aCCCCgetchallen:.sdata "%c%c%c%cgetchallenge" ; DATA XREF: sub_2478C+2BEo
                    ; sub_24B14:off_24B64o
        .data.b    h'A, 0
        .align 4
aCanTRetryNoPre:.sdata "Can"            ; DATA XREF: sub_24AC0:loc_24AD4o
                    ; sub_24B14:off_24B70o
        .data.b    h'27
        .sdata "t retry, no previous connection"
        .data.b    h'A, 0
        .align h'10
aConnectS:    .sdata "connect %s"     ; DATA XREF: sub_24AC0+26o
                    ; sub_24B14:off_24B74o
        .data.b    h'A, 0
aCommencingConn:.sdata "Commencing connection retry to %s" ; DATA XREF: sub_24AC0+3Eo
                    ; sub_24B14:off_24B78o
        .data.b    h'A, 0
        .align h'10
aUsageConnectSe:.sdata "usage: connect <server>" ; DATA XREF: sub_24B14+16o
                    ; sub_24B14:off_24B80o
        .data.b    h'A, 0
        .align 4
a_:        .sdata "."              ; DATA XREF: sub_24B14+E4o
                    ; sub_24B14:off_24D24o
        .data.b    0
        .align h'10
aLocal_1:    .sdata "local"          ; DATA XREF: sub_24B14+2CAo
                    ; sub_24E58:off_24E84o
        .data.b    0
        .align 4

As mentioned before. 'steamgetchallenge' is the packet the steam version of half-life sends when attempting to join a server. So "%C" variable in "%c%c%c%cgetchallenge" in the case of steam is 'steamgetchallenge'

So you can see, the engine knows to send 'getchallenge' to the server. And all of the different variables for the output of the connect command are in there. Including "Commencing connection retry to %s"

So if we use this as an example to base that find off of. We can see that the server list request gets looped back (it takes about a half-hour to get that output) until it overflows. So the 'getsv' is actually working, it's just looping back to localhost. But the function is there and operational, nearly undeniably

Now I know someone who's better at assembly can somewhat simply just go look to see if those functions are actually there and do something. If they are there, like the 'getsv' function is there. Then HLDC confirmed, it'd be difficult to convince me now that this won't work

Edit: Time to do some Half-Life WON edition packet capturing

 

After some brief packet capturing I found the following

First I tried going to internet --> join game --> lan address. The packet it sends is 'infostring'. This is probably a query for server information before the engine connects using the main menu

There are references to infostring

Code:

loc_3D8F0:                ; CODE XREF: sub_3D774+174j
        mov.b    @r12, r3
        tst    r3, r3
        bf    loc_3D90E
        mov.l    #sub_36884, r0
        mov.l    #aInfoStringLeng, r4 ; "Info string length exceeded\n"
        jsr    @r0 ; sub_36884
        nop
        bra    loc_3D970
        nop
; ---------------------------------------------------------------------------

loc_3D902:                ; CODE XREF: sub_3D774+150j
        mov.l    #sub_36884, r0
        mov.l    #aInfoStringLeng, r4 ; "Info string length exceeded\n"
        jsr    @r0 ; sub_36884
        nop
        bra    loc_3D970
        nop
; ---------------------------------------------------------------------------

Code:

off_3DA60:    .data.l    aInfoStringLeng    ; DATA XREF: sub_3D774+184r
                    ; sub_3D774+190r
                    ; "Info string length exceeded\n"

I understand though that an infostring could be a very general pronoun in terms of a game engine

Then I tried connecting from console. Then it sends the 'getchallenge' packet

It's hard for me to tell but the function seems to be defined and there's a bunch of calls to it


I actually think this is pretty significant and I'm not going to bump this with anymore asm stuff. I want to hear from others what they think

It might just be a matter of making the loopback point to ras.exe's internet connection, or probably just call the functions from a DLL within WinCE to make it even more lightweight, because we now know that can be done fairly easily. This could be where the registry comes into play, if somehow half-life is running on a WinCE localhost network. Then testing a ported client.dll (also hlsdk source)

 

%c is a one-byte format identifier. Generally what is happening here is a packet is being constructed with a combination of binary and text library calls to concatenate different types of data together before it is sent out on the wire. You will notice that all the calls you found have the same pattern prior to the string, namely %c%c%c%c. This is creating a four byte header, which appears to be always 0xffffffff. You can see this as the first four bytes in preceding the string in the raw packet capture are always 0xffffffff. I don't recall the standard Dreamcast libs having stdint.h, which would include UINT32_MAX. Using the macro would probably be an easier approach than letting snprintf() deal with it, but I'm sure they had their reasons. Usually headers are used as a quick way to check for corruption or partial sends, etc.

Anyway I told you this before a while back, but GoldSrc is heavily based on the Quake 1 engine, which is open-source. A lot of the low-level network code is 1:1 from the version of Quake that is on GitHub and what I saw from reversing the DC version of Half-Life in IDA. I would probably look at the C code from Quake to get a good idea of what is happening, along with some comments, instead of trying to work directly from the assembly in this case. Plus the Quake network stack is very well documented around the internet, for all versions of the game.

(Interestingly however this code roughly appears to come from Quake 3, which was also on DC at this time with network support... somewhat curious if true):
http://www.tilion.org.uk/2011/11/quake-3-network-format/

 

If I could read the assembly like you can I'd be looking to see if the client.dll parsing functions are indeed on there also. If you have an extra hour at some point, see if there's anything about the dlls

Even the quake 3 page you linked has mostly identical cvars of the few on that page. But since I cannot code, it would not help me much. All I'm trying to do is prove the concept without hacking. If then that cannot be done at all it will be interesting to see what you come up with when you have the time to really look into this lol

Also related to this:
Main developer of this mod replied to my question of how he made a new .exe for goldsrc, he said he used this https://github.com/Nagist/metahook. Maybe that will be of some use

Edit I was hoping that was just going to be a link not a huge ass box lol

 

I'm going to be moving anymore R&D on this over to http://hldc.dreampipe.net
I setup it's own board because all of the information I put on there in the last few days makes you see why it needs it's own board. I can't post 20+ threads here documenting GoldSRC without pissing everyone off lol

But I bump this because I've managed to figure out how to create PVR WADs and ported cp_orangesdk from Chicken Fortress 3/Team Fortress 2. It's pretty cool to actually be playing this on Dreamcast. It feels like you're playing the PC version when I got this to work





I've played a few hours of this map on Team Fortress 2 awhile back, so it was a unique experience playing it on Dreamcast in essentially a perfect PC engine port

I may be joining the Chicken Fortress 3 team as a mapper to port some maps from TF2 to CKF3 to Dreamcast. I'm going to see if I can also port as much as I can from CKF3 to Dreamcast. And if anyone figures out loading the HLSDK extensions, this will be ready to go. I think "Dream Fortress" is a perfect title for said project

This may be the last time I bump this thread with anymore updates on this. So one of the projects on HLDC-DEV is an HLDC-SDK. A large collection of tools to allow complete ports of PC mods, or create your own new mod for Dreamcast, all in one kit. This would also include 100% compile ready ports of the HLSDK source code, and a bunch of HLSDK extension mod tools (new shaders and other external mod extensions) I will be adding the tools and scripts I've found for making PVR wads within the next few days

If anyone is interested in programming, mapping etc, to help develop the HLDC-SDK and create a library of ported mod assets. Just register over on the board and start helping

 

Amazing things can be done with this engine

That's pretty amazing considering it's the Dreamcast

 

This will probably be my final update/bump here

I've figure out how to add registry keys to the Dreamcast Windows CE kernel

Info on doing that here: http://hldc.dreampipe.net/viewtopic.php?f=19&t=23

The registry settings don't do anything for Half-Life, but the keys in the picture are a bunch of keys from Half-Life WON PC version. Though it does show new registry keys can be added

I really cannot think of anything more to try for loading HLSDK dlls or getting GoldSRC to see an internet connection. There is an "autodial" function in Windows CE that can be added to the registry, meaning perhaps the connection would be established by the OS rather than RAS.EXE. But if that also does not work then we need programmers


Since I cannot try anything more for DLLs/multiplayer, I will be shifting focus to porting maps from Team Fortress 2 to Chicken Fortress 3 on PC then to Dreamcast. As well as porting all assets from Chicken Fortress 3 to Dreamcast. While documenting how to do all of that to help Dreamcast GoldSRC development


--------------
So in conclusion, the GoldSRC engine is entirely completed. It just lacks an obvious way of loading new HLSDK client.dll/hl.dll for new mods, and connecting to the internet. Though it is very likely a programmer can hack the Dreamcast binary for Half-Life to load new HLSDK extensions. If that can be done, GoldSRC on Dreamcast can be almost infinitely expanded. Most of the existing mods can be ported, new addons like metahook can be added to the engine, handling of internet can be added, hardware support can be added, the possibilities can go on and on

I have stated that many, many times throughout this thread. And for good reason. Even though no progress as far as multiplayer or HLSDK loading has been made since the initial post, I have proved many, if not all of the theories I have presented throughout this thread:

-The connect command functioning with a patch to re-enable it
-The inner workings behind the multiplayer/networking related commands are present and operate http://assemblergames.com/l/threads...tiplayer-components.57318/page-16#post-877338
-You can connect to the internet within Windows CE on Dreamcast, outside of HALFLIFE_DC.EXE
-You can manipulate the Dreamcast's Windows CE registry
-You can debug Half-Life by connecting to PC via coders cable


This officially concludes my research using this thread. If some highly skilled programmers were interested enough, they could probably get HLSDK extensions to load

Anymore updates on this topic can be found at http://hldc.dreampipe.net. I hope others join me there to help finish GoldSRC for Dreamcast

-Dr_Teamcast

 

Aww man, don't stop updating this. Nobody here is pissed off about you posting your findings. In fact you get likes on almost every new post you make.

 

Well it's not that anyone is pissed off it's that I really don't know what else I can do that doesn't require coding. If I can figure out how to get a working transport layer using the serial port to use the WinCE SDKs remote tools for registry, process viewing, command line then I can do a lot more

I'm more or less saying, yeah it can totally probably be done. But I can't do it, and I'm shifting focus to documenting all of this and documenting how to port mods to Dreamcast. As well as actually porting assets from mods than need the HLSDK stuff. Then if someone can actually give it a go and attempt loading HLSDK extensions then we're way ahead of the game

Also:
There's also a new client.dll that needs to be ported/compiled and tested with this. As posted before there's many references to client.dll, but not to hl.dll. Perhaps client.dll is what needs to be tested rather than hl.dll, as thought before. Again at some point we need a programmer on board to help with that, without one that's about all I can do lol