Half-Life for Dreamcast has some functional multiplayer components

Discussion in 'Sega Dreamcast Development and Research' started by TerdFerguson, Jul 13, 2015.

  1. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
    [​IMG]

    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
     
    Last edited: Apr 22, 2016
  2. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
  3. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    I left 'getsv' as the engine halted for awhile and it eventually gave this output
    [​IMG]

    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
     
    sa1 and Anthony817 like this.
  4. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
     
  5. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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'
    [​IMG]

    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
    [​IMG]
    I'm pretty sure this means the DLL is attempts to load. Maybe someone else can share their thoughts on why this happens
     
    treyldog, Anthony817 and BLUamnEsiac like this.
  6. Trident6

    Trident6 Spirited Member

    Joined:
    Oct 17, 2015
    Messages:
    119
    Likes Received:
    55
    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.
     
  7. Trident6

    Trident6 Spirited Member

    Joined:
    Oct 17, 2015
    Messages:
    119
    Likes Received:
    55
    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.
     
  8. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
     
    Anthony817 likes this.
  9. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
     

    Attached Files:

    Anthony817 likes this.
  10. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
     
    Anthony817 likes this.
  11. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,097
    Likes Received:
    1,046
    %c is most likely a char, aka 8bit or a raw byte.
     
  12. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
     
    Last edited: Apr 28, 2016
  13. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
    [​IMG]
    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
    [​IMG]
    It's hard for me to tell but the function seems to be defined and there's a bunch of calls to it
    [​IMG]

    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)
     
  14. Trident6

    Trident6 Spirited Member

    Joined:
    Oct 17, 2015
    Messages:
    119
    Likes Received:
    55
    %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/
     
  15. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
     
    sa1, spinksy and Anthony817 like this.
  16. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
    [​IMG]
    [​IMG]
    [​IMG]
    [​IMG]

    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
     
    spinksy, Anthony817 and BLUamnEsiac like this.
  17. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    Amazing things can be done with this engine
    [​IMG]
    That's pretty amazing considering it's the Dreamcast
     
    Anthony817, sa1 and BLUamnEsiac like this.
  18. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    This will probably be my final update/bump here

    I've figure out how to add registry keys to the Dreamcast Windows CE kernel
    [​IMG]
    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
     
  19. Anthony817

    Anthony817 Familiar Face

    Joined:
    May 12, 2010
    Messages:
    1,124
    Likes Received:
    596
    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.
     
    sa1 likes this.
  20. TerdFerguson

    TerdFerguson ls ~/

    Joined:
    Apr 27, 2015
    Messages:
    755
    Likes Received:
    466
    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
     
    spinksy and Anthony817 like this.

Share This Page