Mostly out of curiosity,

1) How hard have it been to make Uplink compile Mac? Does it use the same libs as the Linux version?

2) How hard have been the port from the 1.31 codebase to 1.54? How did you proceed?

3) Does Onlink create on crash (on Windows) the following files?
- ERRORLOG.TXT = Crash stack with registers (can be useful with dumpbin.exe and .pdb files)
- CRASH.DMP = Debugging crash dump

1) We had to port it. Mac works quite differently to Linux for GUI stuff, plus there's the big-endian thing to worry about.

2) Basically, we wiped and started again from the 1.54 codebase (as far as I can tell)

3) Steven?

Prophile is correct about 1 and 2.

3) No. Just a debuglog. Want to lend a hand and implement such crash dumps?

Thanks for the answers,
Isn't SDL directly usable on Mac?
I guess I could, but all the needed code is already in DevCD 1.54/1.55.

uplink/src/ExceptionHandler.cpp
uplink/src/ExceptionHandler.h
uplink/src/GetWinVer.cpp
uplink/src/GetWinVer.h
uplink/src/MiniVersion.cpp
uplink/src/MiniVersion.h

uplink/src/uplink.cpp, Just check all places where #ifdef CRASH_REPORTS is used.


Also you if have some questions on the source, I could probably answer them. (ex: why some changes where made, ... )

Not really. Macs handle things called Frameworks that basically act like DLLs on PCs. There's also that pesky thing about macs coming with both big endian and little endian based processers, so we basically compile every file twice for any one framework/application. We could omit including the framework if people have an SDL framework in their library. Thing is, there isn't one there by default, so we don't assume.
Actually, I was wondering why you didn't use the WolfIRC mod. There's an exploit in Uplink that would allow me to crash a game remotely if I felt particularly mean.

Message me, and I'll detail it.

I wasn't aware of this problem, a couple of IRC bugs were patched in the newer version, perhaps the one you are referring to was patched (I'll send you a message). Also I tried to modify the Uplink source as little as possible, this is the main reason the tosser/data library wasn't modified. The goal was to provide maximum stability and to easier existing Dev CD Mod upgrade process.

Actually, the tosser library, save for a single cpp file in Uplink, is hot-pluggable at this point.

It wasn't when we offered it, but we figured we should fix that. So we did.

First, great job on Onlink so far.. hadn't played Uplink in years and it was good to see something new for it..
However, I think the IRC Client in the game does need work.. I know it isn't a problem for most of those connecting to the default IRC server, but the lack of proper protocol support still bugs me. The WolfIRC mod was an ok fix for a few of the problems. But in my opinion, don't import that to your current code, you can do better. Aside from the obvious that the WolfIRC mod fixed, (i.e. /msg, /me, /<raw>). The client needs a bit more support for numeric events, and more importantly, a proper ping event handler.
As a couple of examples,
The numeric event 443 :Nickname in use. Users should be alerted to this so they can choose a new nick.
Server PING events on servers are not all just as simple as responding with a plain old PONG.
Many servers will send the first PING event with a :value after it as the first PING after the USER/NICK commands are recieved. A simple check for that value, or even just replacing the PING with PONG in the packet and sending it back will easily fix that. Without this, the client (as it is now and with the WolfIRC mod) will just hang.

I know it may seem like a bit of a hassle, or rather pointless.. especially considering that regular IRC users prefer to use their standard client anyway, as I do. However, I like to see any client show that it can handle more than just the standard commands.

If you decide to do this, cool. If not, it doesn't matter, the rest of the game so far is looking great and that is all that really matters.

Sorry for the rant,
~Red