This announcement is outdated. Please refer to this thread for the latest realease!
- Sentinel

Windows | Mac | Linux

Another week, another build. Not a lot of changes since 0.2.0-a8. Mostly just a bunch of bugfixes, including the particularly irritating log deleter bug.

Windows x86_64 users, please note that I also managed to get stacktraces to be possible in Windows x86_64 builds, so go ahead and use those for bug reports now. Also note that Windows x86_64 is at r16 rather than r15 because of a minor last-minute bugfix that only affected 64-bit Windows users.

In other news, there's a lot of activity going on in the 'next' branch, where we are staging some pretty neat changes. I've been going through and adding OpenMP where it's possible, and saving the game will go up to twice as fast on dual core machines (and even faster on quad core!).

Also, we're currently debating the future of Onlink. This conversation started because we were thinking of ripping out the current shoddy graphics subsystem and using the ARC++ graphical subsystem, but then we realized that some really ugly design flaws in the original Uplink code were limiting our progress. As a result of this realization, we're considering doing a rewrite of Onlink from scratch and making it an open source project (license to be determined). Any thoughts on this?

I like the idea of updated graphics (or alternate graphics), something to reflect those obviously not real (I think?) OS systems that we always see in the movies or tv shows. Not only can I feel like I'm hacking, but I'm hacking for a top-secret government branch! ooooooh.

Hm... I'm not sure what to think about that. As much as I love the current Uplink interface, a change would be welcome. And I would really love to be able to contribute.

Just wondering if there was a changelog for stuff added between a7 and a8? The only thing i've noticed is now .cpp and .makefile files are different colours to other files, so I assume the C++ interface is working, but i can't find it in the Uplink ISS or labs software sales.

Moar bug reports!

Alright. It's nice that mods now work from the appdata folder rather than the main game folder and all, but it's buggy. Unless I'm not supposed to drop 'em in the %APPDATA%\Onlink\ folder?

Anyway, I wanted to test custom gateways, so I just took the Morpheus since that's the only one I found, dropped it in the main folder like previous versions - Oh, doesn't work? - deleted that, dropped it in the appdata folder instead, started the game, and there it is in the gateway list. However, when I click on that gateway, I get...



and the CrissCross console shows the following message:



Happens both with a new or already-existing account, and both in the regular gateway purchase panel or the aux. gateway purchase panel. I am obviously running the x86-64 version, as shown in the first screenshot.

EDIT: Tested with the x86 version, and it does the same but apparently I can't get the crisscross error message and backtrace from it, since it doesn't appear while the message box is up (unlike x86-64) and the program is killed when I press OK on that message box.

Oh, and also, for reference purposes, I'm using the "fixed" Morpheus NiTRO Gateway found here: viewtopic.php?p=12901#p12901

Well, it couldn't load the gateway image files.

That should reasonably throw a warning, not an error though.

I've found a bug in the databank system, especially related to buying software. I purchased a whole bunch of new software, and it is in my program menu, but it is not in my databank.


Click for full size - Uploaded with plasq's Skitch

EDIT: Thumbed file to avoid stretching etc. -M

The way I see it, your program selection is taken from your actual gateway, no matter which machine you select for your databank in the Admin Panel. To me, this makes sense, since even if you're using another machine's hard disks, you're still running on the main gateway and can only run software that is currently on that machine. To run any software, its program must be in memory (unless you're using a complex network-parsing system, but that's... hard to code and inefficient). Sure, there might be a way to copy it automagically from your aux to your main, keeping it in RAM temporarily instead of hard memory (like some corporate networked systems do), but that's a feature that's currently not in Onlink from what I can see.

If you meant to say that what we see there IS your actual gateway on which you bought the software, then yes that's a problem, but if that's an aux databank, then to me it sounds more like the above realistic "feature".
I'm well aware of that. The thing is, it does that no matter where the image files are located. There's a copy of them in %APPDATA%\Onlink\graphics\, in %APPDATA%\Onlink\graphics\gateway\, in %APPDATA%\Onlink\data\, in %APPDATA%\Onlink\data\graphics\, in %APPDATA%\Onlink\graphics\graphics\ and in %APPDATA%\Onlink\data\gateway\graphics\. Did I miss the location they're actually supposed to be even with all that?

And as Miah said, it should throw a warning, not a CTD error.

Hell, I never remember looking if this is already in the Bugzilla or not... when you buy software, if you have another gateway selected as "databanks" while your main one is selected as "next update" in the admin panel, you get the program - working fine, btw, and you do spend the amount of money it costs - but without taking up space on your memory banks. The only drawback on this exploit is when you start facing those pesky ACSs...

...And what happens when you tell your panel that the main one is the databank? 'Cos all your stuff would be in there.

Yup. What he said. When you select an aux as your databank and go purchase software, the software is actually simply sent to your main gateway, y'know, the one you're actually running on and that you have to launch your software from? Purchasing software and having them sent by default to a databank where you can't use those program without having to copy them over would be annoying.

Here, try it: Get an aux, switch your databank to it, go buy some random piece of software (i.e. the dictionary hacker), and notice that it's not in your memory. Then switch the databank back to your main gateway, and check your memory again. Voilà! A magical dictionary hacker program taking up space in your main gateway. If you don't see it after returning to your main gateway, *then* it's a bug. So far, though, software has reliably forced me to upgrade my main gateway's memory banks whenever I got a little too much.

No, this is a genuine bug. My aux was selected as next update, but my main was selected for memory banks. Later on, I got a decrypter v7 which is supposed to take up 5 gqs. It is not compressed in any way, but instead it takes up only 1, since the rest of the spaces have been overwritten by other software purchases. I don't know if this is because my aux was selected for next update, or simply a bug in the software purchase or databank system.

Sort-of-triple bug report this time! Yeah, "sort of".

Alright, I'll start with the most peculiar: The Ferrous Moon ACS, and presumably other ACSes too under the right conditions (which I'm not sure what they are), is permanently down in "maintenance mode".

What happened was: Okay, so I like doing stuff the wrong way just to see if it'll break things. Because, y'know, my debugging instincts tell me to do it. So I do. So, I hack the FM ACS. I try to get all the way to the console, but fail, get kicked out, okay, it's locked, then after that it's in maintenance mode. No big deal. I erase my logs and fast-forward a few hours. Then I log back on it. I hack it all the way again, this time not horrendously failing. I enter the console, and I delete \sys\ then reboot. Cool, it goes down, and as expected I still don't have program authorization on other machines. Erase logs, fast forward again a bit, and poof, the ACS is back up. This time after hacking it, I put in Denial and run it before rebooting the system.

Okay, I have an incredibly-expensive very advanced Denial Zombie Machine. But - oops? The ACS goes into maintenance mode when I try to reconnect to it. And it loses the Denial Client status. No big deal. Same routine, logs and FF. Then I reconnect and hack my way through again. This time, just to be a thorough pain in the ass, I put on Denial, run it, then delete the \sys\ folder, THEN reboot.

As expected, the system fails its Kernel routine and kicks me off. And again as expected, it goes in maintenance mode immediately after. However, what's unexpected this time is that I still see the red outline in the world map indicating a Denial Zombie, and my Denial host program still shows the +1 zombie. Logs/FF routine, then reconn- wait, what? It's still in maintenance? Maybe I didn't wait long enough. Logs/FF again, this time making sure I fast-forward a whole day. Oh hey, what the hell is this, it's still in maintenance mode? Doesn't the screen say "six hours max"?


Left and right are the same. Basically just showing the clock in top-left that shows that the server isn't coming back up even after well enough time has been given.

First thing that comes to mind is: Okay, this is some weird new feature they just brought in or something, and I have to *actually* send an ingame email to the administrator like the screen says. But of course not. I get an invalid email recipient response from the ingame mail server and that idea is foiled. It's not like the in-game Steven Noonan would want to help a random uplink hacker get access to his ACS anyway - which beckons me (with a gun pointed at my face... or something) to bring up the "Social Engineering in Onlink" idea that, after second thought, sounds like it would be a hell of a lot of work (but with a potentially proportional addition to gameplay depth, if properly exploited... but then, you've got other, more important things to work on in onlink than entirely new game concepts that were never even part of the onlink game design in the first place).

So, anyway, back to my ACS problem. I log out of the game and back in, making sure to fast-forward, and... nope, ACS still down. Exit game and come back? ACS still down. Jail then liberate Steven Noonan? Nope, ACS still down. Launch a Denial attack on the ACS? Heh, that just fails no matter what, presumably because it still sees it as a client or something. In any event, the ACS system is just stuck there irreparably, effectively stalling the nagi quest.

--------------------------------------------------------------
(this line intentionally noticeably ugly)

As for bugs #2 and #3, well, as you know I'm running the 64-bit windows client. At some point during the game, I didn't notice when, I started getting ridiculously long autosaving times like others have reported - 8, 10, even up to 15 seconds at times just for the collection thread to complete, then another 3 to 20 seconds for the WriteToDisk thread.

After this point, however, though a little while after I noticed the autosaving stops, I started getting completely random crashes on pressing some button or another. I presume it was only when pressing certain UI elements under certain conditions while the saving thread(s) was starting, but I can't be sure - each time, all I get is the default windows "This application has stopped functioning" popup, and CrissCross is non-responding, with the last thing it displays invariably being an autosave message (a normal autosave message, though often incomplete, i.e. cutting off in the middle of the line, but otherwise identical to others - no error or warning messages in sight).

Somewhat in relation to that bug, when I restart Onlink and reload my save after that (yes, the same save file that I assume it crashed while in the middle of writing it), I almost always get incredibly huge spams of various logs that weren't there, and blank-space logs. And I mean *huge* spams. This screenshot doesn't even begin to express the sheer amount of blank logs there are - and this happens on every server in the game at the same time, including the gateways:
If you look very closely, you can see the (rather small) scrolling bar to the right. It's very small, indicating a lot of logs. Well, that's not even the half of it. If I want to clear that log, it'll take me around 2min20sec of repeated, intense clicking (despite having über CPU power all maxed on the log deleter allowing for quasi-instant deletion of logs). I know, because I've actually done it right after taking that screenshot.

And that's just the InterNIC server, which I had cleaned not long before (the routing logs you see there are the only logs of mine other than my "connection initiated" log at the very top"). I'm sure you'll also notice the wrongly-ordered log entries from their time stamps - and no, those aren't just modified logs, I made sure to unmodify them to be sure. If there's some way this could be normal and I just don't know it... then you're the ones who know.

This has obviously resulted in a LOT of clutter in my savegame, making autosaving and loading times even worse. Here's a link to my save file: http://www.filefront.com/14091573/DaFranker.xml.gz

Watch out, though. It's huge. The uncompressed file went well past the 100MB mark a while ago, and that's when I stopped checking. That particular save was copied while the game was still running (though I made sure the autosave wasn't running). I can provide the save file taken after closing the game, too. However, the uncompressed xml of that one goes well over 400MBs (!!), so I don't even dare take a peek inside, lest I be stuck with an unresponsive computer for an hour or two (Windows' notepad is particularly inefficient when it comes to opening large files, and other text processors I've tried haven't fared any better so far). So here it is: http://www.filefront.com/14092033/DaFranker.xml.gz

EDIT: And here come the Bugzilla entries, spread out in three since I don't know if they're three separate bugs or all one and the same:
http://www.ferrousmoon.com/bugzilla/show_bug.cgi?id=123
http://www.ferrousmoon.com/bugzilla/show_bug.cgi?id=124
http://www.ferrousmoon.com/bugzilla/show_bug.cgi?id=125

Wow, thank you. I was planning on pointing out the second 2 of those bugs when I got around to it, but I've been really lazy lately. The XML savefile has several bugs, including the large blank spaces in every log file upon save and reload, the loss of shortcut keys, occasional loss of bounce routes, etc. I believe those 3 are the only ones that I've encountered so far.

On a separate note, one thing that might make save files smaller is to use a modified xml format. If you take a look at the iTunesDB file used on the iPod, or the tag system in Halo (both systems I'm overly familiar with - long stories both of them, PM if you are interested ), they both use 4-letter headers instead of full words. The iTunesDB file uses a variant of XML, instead of being plaintext with <tag>value</tag>, it's binary with a 4 character header opening, then the binary value, then a 4 character matching close. While this may not seem like the best thing in the world, by simply using a binary format, you eliminate the <></> (5 bytes) for every tag. Also, big numbers become 4 bytes instead of however many digits they are. And by trimming the tag names down to about 4 characters, you eliminate that many extra bytes each time a tag is used. While it may not seem like much, it adds up. I know you guys just finished moving the save system to XML (and promised all saves would be backwards compatible) so you might not want to move in this direction, it was merely a suggestion. Take a look at the iTunesDB format and you might see something you like.