After what can only be described as a "considerable" stall in development, I have rediscovered coding Onlink. I haven't bothered to update the task list yet, as the number to 0.2.0 has increased considerabily. This was to be expected as I had mentioned before; a major task has been split into many more smaller tasks.
Allow me to introduce the product of a 30 minute conversation and 1,500 lines of code over the last two days: the Development HUD.
Click for full size - Uploaded with plasq's Skitch
Click for full size - Uploaded with plasq's Skitch
This behemoth is the framework for the new interface and is one of the more complex subsystems to be developed in Onlink, hooking into a huge number of other classes. Very little is functional after 1,500 lines of code, but the general idea is becoming apparent.
The day before yesterday, I admitted to Tycho that I felt entirely without direction for this interface. This was a rather large problem, since the new storyline requires its existance in some form or another. He floated an idea and I started coding again. I knew I kept him around for something
I shall now go over the basis for the new mockup. Feedback is, as always, welcome. I plan to do a videocast of this system (All Good Things) once these systems actually work.
Overview
The Development Interface behaves as the IRC and LAN interfaces in that it takes up far more than their smaller cousins. Once opened, it encompasses the entire screen (assuming you are running at 1024x768).
Section 1
This piece of the interface deals with research into algorithms along the lines of folding@home, distributed.net or Prime95. Computers are taken over by the player to be used as part of a distributed processing farm. Products of research can allow faster code breaking, more sophisticated security breakers, or other more advanced tools.
This is aided by two processes: taking over computers and completing missions. While hacking a machine, the computers on the network observe systems and counter systems and calculate accordingly.
Section 2
These quick-access buttons encompass the entirety of the development interface three days ago, part of why I was in such a funk. It was very boring alone, but remains for its use. Unlike the Legacy Onlink releases, you are not required to use the console for everything. Libraries can be compiled by launching the library compiler and selecting a library source file, programs can be built by selecting the makefile for the program and so on.
Section 3
Players will need to install trojan-like programs on other machines to take them over while doing hacks. Or for the hell of it.
This area will show your throughput from the machines you control. The complexity of a system (systems that utilize the "Listing", usually 5 to 8 companies in the world, are the most complex) will greatly aid in your production, though the number of computers in your network decreases the throughput. In simple terms, don't have weak level ISMs on your network if you're bringing LANs on.
"Computer Worth" will be measured in MIPS/BIPS/TIPS. Losing a system can hamper already completed research, so be sure to maintain the computers you control.
Section 4
The Console for legacy releases makes a return. Along with the ability to everything the quick-access tools can, the console, if properly used, can allow more complex procedures such as symbol replacement (which could, for instance, take a legitimate program and embed a virus into it).
Section 5
Nothing terribly special here, just a alternate databank display for your computer marked as primary development in the admin interface (see progress blog). Files that relate to development are coloured here, meaning that program and data files that normally show red and green will instead show grey here.
Anyway, this is mostly a skeleton framework and may change drastically as time goes on. It's bound to be the largest source file in the project barring the world generation class by the time it's done.
I want it. I want it now. Make it faster 
)
be happy