Aegidian devlog

Oolite (progress)

2004

April

April 7th, 2004

Oolite - WTF? [Apr. 7th, 2004|10:03 am]

[Current Mood|accomplished]

Oolite is a traditionally styled space sim game, written for Mac OS X in Objective C using Cocoa and OpenGL.

It was written as my response to the withdrawal of Elite - The New Kind from the internet. Although inspired by the work of Christian Pinder, following David Braben and Ian Bell, the work is an independant reverse-engineered interpretation of the original game.

The game and source-code will be offered for free under the GNU GPL. As one of my priorities for development was to separate the game engine from the game materials (graphics, models, AI, text-strings and such) I might additionally reserve the right to offer additional game materials (bonus-packs) as shareware.

Questions and queries about the state of development are very welcome, as is anyone who would like a binary for beta-testing (URLs for these will only be made available via email, I won't post them here until a release is ready).

Today's progress: [Apr. 7th, 2004|10:13 am]

Squished a bug or two in the unimplemented parts of buying equipment, which will be the next and final part of the GUI for me to complete.

Tweaked the save/load game interface and the ship-kills to rating routine.

Screenshot of the day: rogue cobras attack with plasma cannon. [image]

April 8th, 2004

Colour [Apr. 8th, 2004|10:09 am]

Keyed the planet colours (land, sea, polar land, polar sea) for procedural texturing into the legacy pseudo-random number generator. Happily, Lave gets a sea with a slight tinge of pinkish/purple.

TODO: - add procedural clouds and cut out the early popping of the atmosphere when flying to/from the planet.

TODO: - add a pauseAI function to the standard AI suite.

Picture of the moment: Lave, a few seconds after launch. [image]

April 14th, 2004

Oooh my head spins... [Apr. 14th, 2004|03:33 pm]

[Current Mood|exhausted]

I've spent too much of the last 48 hours on this.

Added:-

More gauges (all working), working missiles, working witchspace jumps, improved pirate AI (including the pauseAI directive), atmosphere effects (removing the early 'pop' as you enter the system from witchspace).

Also struggled to deal with memory allocation/deallocation problems as some poorly thought out programming lead to objects that recursively deallocated each other. That really sent my poor synapses into collapse!

Picture of the Day: Approaching Zaonce. [image]

AI [Apr. 14th, 2004|09:10 pm]

[Current Mood|accomplished]

Sort of a FYI update.

I'm using a simple state-machine implementation for ship AI. The state machines are stored as xml property lists:- a dictionary (associative array) of states, each state comprising a further dictionary of responses to messages the state machine can respond to while in that state. The messages 'ENTER' 'EXIT' and 'UPDATE' are standard for each state, and the responses to them occur when the state is entered, left, or the AI is requested to update (currently about 8 times a second). The state machine has a standard state it begins in called 'GLOBAL'.

The responses correspond 1:1 with methods for the ship objects within the game, which made implementing the state machine based AI a piece of cake.

Here's a simple example of this, the AI for a simple homing missile, not in xml but described as an ASCII property list: ( cut for screen width with pre-formatted code )

missileAI.plist
{
   "ATTACK_SHIP" = {
       "DESIRED_RANGE_ACHIEVED" = ("setStateTo: EXPLODE"); 
       ENTER = ("setDesiredRangeTo: 20.0", performIntercept); 
       EXIT = (); 
       "TARGET_DESTROYED" = ("setStateTo: EXPLODE"); 
       "TARGET_LOST" = ("setStateTo: EXPLODE"); 
       UPDATE = (); 
   }; 
   EXPLODE = {
       ENTER = ("setDesiredRangeTo: 250.0", dealEnergyDamageWithinDesiredRange, becomeExplosion); 
       EXIT = (); 
       UPDATE = (); 
   }; 
   GLOBAL = {
       ENTER = ("setSpeedFactorTo: 1.0", "setStateTo: ATTACK_SHIP"); 
       EXIT = (); 
       UPDATE = (); 
   }; 
}

As you can see, this AI never has to respond to an 'UPDATE' message, relying entirely on messages sent to it as a result of its behaviour eg. when it passes within the desired range set for the performIntercept behaviour that method sends the AI the 'DESIRED_RANGE_ACHIEVED' message.

April 15th, 2004

Painting... [Apr. 15th, 2004|02:39 pm]

[Current Mood|artistic]

Programming was sapping my will, so I thought I'd take the opportunity to improve the art.

First off, I'd messed up my original mapping of texture onto the dodecahedron I was using as a sky box, so I grabbed some graph paper and remapped the texture. Which worked up to a point - now the edges of the dodecahedron were all too obvious. It became clear I'd have to replace the stock space background (courtesy of idevgames) with one of my own. I grubbed out my graphics tablet and fired up the Gimp.

Bah. I didn't have time to learn a different interface, no matter how free.

So I dug out Corel Painter and worked from there with an airbrush or two and a mask generated from OmniGraffle for my texture map. The result was a little too bright, but retouching brightness, contrast and sharpness in Graphic Converter did the trick.

I think I'm going to have to do another seven of these, one for each of the galaxies in trad-Elite.

Picture of the day: Space scape background. [image]

April 16th, 2004

Whoof... [Apr. 16th, 2004|04:57 pm]

[Current Mood|chipper]

I was testing programming the laser routines and tidying up stuff when I chanced to laser away a ship upon which I had already launched a missile. Kabloom. We crashed.

Not good, but thinking about it I had a revelation. I was making a mistake when I decided to use absolute references to objects for things like a missile or ship's target, owner, last-aggressor, that sort of thing.

Because I can't check from a simple pointer if the object at that memory location has been deallocated!

D'oh!

This has been causing me many headaches, but there was a simple solution. Keep an index of the objects in the universe referenced by an independent and unique id for each object, updated whenever an object gets added to or removed from the universe. Then I can store that id rather than the pointer for targets, owners etc., and dereference when necessary through the grand index. Thus, instead of a pointer to a block of memory that may be inaccessible, if an object has gone from the universe, a null pointer is returned instead. And I can (and already do) check for null pointers.

Yay! And *kicks brain for not having thought of this earlier*.

Lasers [Apr. 16th, 2004|11:37 pm]

Oh yeah, I'd forgotten how feeble I made those plasma cannon I had as a test weapon. Pulse lasers are far more unforgiving, and now the pirates have missiles too, my test flights aren't always a sure victory. Time to write in the ECM systm.

April 19th, 2004

Minor progress made. [Apr. 19th, 2004|10:26 pm]

Done:-

ECM, expanded cargo holds, weapon purchasing (TODO: weapon refunds), experiments with the procedural cloud effects (unproductive), added stations and navigation buoys to list of a-la-carte ships, wiped out a few more direct references causing crashes.

Todo:-

Routine to extract base cargo space for a given ship model. Routine to extract base price for a given weapon (for weapon refunds). Left, Right & Rear weapon activation. More a-la-carte ships, routines to place them at suitable locations in space, routines to vary the planet/station/sun locations.

Too tired for a screenshot today.

April 20th, 2004

Wootage [Apr. 20th, 2004|02:09 pm]

Done:-

• Weapon refunds (including the dictionary routines).

• Weapons firing to all four available aspects (Forward, Aft, Port, Starboard).

• Player base ships added to the ship database.

UPDATE: Added some more screenshots to the website.

Soundclip of the day: ECM activation sound [dead link] (done with SoundBuilder)

April 21st, 2004

Good work [Apr. 21st, 2004|07:31 pm]

[Current Mood|pleased]

Got the intro screens working (the ones that show first your ship, then a selection of other ships from the game).

This prompted me to get the texture-map importing from Meshwork working.

Which lead to further debugging - including getting the reusability of Entity objects up to par, which should lead to more efficient use of objects in future.

Picture of the Day: Star spangled Adder. [image]

April 22nd, 2004

Today, I has been mostly... [Apr. 22nd, 2004|05:29 pm]

[Current Mood|artistic]

Making sure the legal_status of the player works fine. As ever, which of the freely configurable commodities are illegal gets an xml plist.

Then painting cobbling together skins for the Viper, Asp, Anaconda, etc. Some of them work better than others, trying to convey a sense of scale for the larger ships is difficult. Putting a label on cargopod.inc's barrel was fun though. [image]

Incidentally, the tools I'm using for this are:

Meshwork, to set the initial texture uv points, a quick window-grab from the 'Display Texture' window (command-shift-4 space-bar mouse-click) then provides a rough outline.

The meshwork model is run through a droplet I made with DropScript which levers a python script to convert the .mesh file to a .dat elite-style file Oolite can read.

Graphic Converter is used to trim the top and bottom off the window grab to cut and paste into...

OmniGraffle: taking the imported texture map as a guide, I then apply custom shapes in a variety of colours and colour gradients. The final composition is then exported as a png for use in Oolite. Possibly getting a further tweak from Graphic Converter.

With the files all in place I check out the ship in Oolite's second intro screen.

For amusement value [Apr. 22nd, 2004|05:54 pm]

An early pic from when I was testing the flight engine in March: [image]

April 23rd, 2004

Changes under the hood [Apr. 23rd, 2004|02:52 pm]

[Current Mood|relieved]

Some stuff was left over from early full-screen OpenGL experiments I was doing, and it seemed to be coming back to bite me with odd unexplained crashes relating to my somewhat customised main runloop. So I canned all that code and replaced it with a simple, old-fashioned GameController object working a timer off the main runloop. Ten minutes work, a few moments fervent prayer, and success. Rar!

April 24th, 2004

Minor progress [Apr. 24th, 2004|11:05 pm]

[Current Mood|tired]

Energy bomb implemented.

Despite my changes to simplify things, there are still some occasional, inexplicable crashes in the main runloop. I'm guessing it's something to do with the timing of when objects get deallocated. Time to bring in the developer power tools...

April 25th, 2004

Rats! [Apr. 25th, 2004|01:07 am]

[Current Mood|annoyed]

A memory leak, and it's not even my fault goshdarnit.

I was using glutSolidSphere to draw the sun and its 4-layered corona. Looks like this implementation of glutSolidSphere mallocs some memory and doesn't clear up nicely afterward. This could be the cause of the intermittent crash. I'll replace it with a simple circle drawing routine, cached in a display list, and see how that affects the memory usage.

UPDATE: Profiling suggests that using the glut routines is a drag. Definitely time to cut my losses on these (at one time convenient) routines and move to my own home baking.

Leak update [Apr. 25th, 2004|10:52 am]

[Current Mood|uplifted]

Yup. That nailed it down nicely.

D'y'know, it felt good to comment out the '#import <OpenGL/glu.h>' and '#import <GLUT/glut.h>' lines too. Makes me feel I've taken a big step away from my early proof-of-concept days with this.

And I got a nice email from Christian Pinder yesterday, encouraging me for my work so far.

That sort of stuff really helps when 1.00 am brings memory leaks to battle.

UPDATE: Intensive testing has shown a great improvement in stability: NO more crashes (yet!) and no whirring from the hard drive as pile upon pile of virtual memory are released when the game is quit. w00t!

Progress crawls on... [Apr. 25th, 2004|08:19 pm]

[Current Mood|listless]

Implemented sun-skimming with the fuel scoops. Implemented, and then had to über-debug, Entity recycling. Not sure if this is really worth the candle, but it can stay for now.

Pics of the day: Approaching a planet again, four pictures that show the Level-of-Detail code working to generate finer and finer detail on the planet's surface. [image]

April 26th, 2004

[Apr. 26th, 2004|05:02 pm]

Slightly frustrated today. I wanted to get the Escape Capsule routines all working, but couldn't seem to get into the creative groove.

• Debugged the entity recycling routines further, this time checking the ref-count for the objects to make sure they were on the point of being deallocated when checked in for recycling

• Skinned and modelled the escape capsules, which are tiny!

• Killed a bug where missiles were remaining targeted on ships that had already been killed

• Added escape capsules to other ships (not the player) and have them eject and be collected as slaves, they get the homeAI.plist which flies them slowly to the planet otherwise.

I suppose that's really not bad for a day when I felt like I wasn't getting going. I'll complete the escape sequence tomorrow then.

April 27th, 2004

Abandon ship! [Apr. 27th, 2004|10:12 am]

[Current Mood|accomplished]

Yeah!

Got the player escape capsule launch and dock sequence done.

UPDATE: Also the Galactic Hyperdrive is now done.

With all the main systems in place, I now have to think about creating and maintaining the population of a system. Specifically, I want action to continue while the player is in the space station (which means NOT removing all the other entities while this happens) and to create the great variety of ships and AI's necessary to fill space.

UPDATE++: Gah, whenever I get self congratulatory remind me to check for bugs. One simple retain/release problem in the second intro screen code had me frazzled all afternoon!

Picture of the Day: Whoops. [image]

April 28th, 2004

AI and schtuff... [Apr. 28th, 2004|02:14 pm]

Implemented a routine to dump cargopods one at a time.

Working on the station AI, it's bright enough to ignore getting shot once, but getting shot twice within a certain timeframe will raise its alert level enough to activate the launchPolice routine against the aggressor. It also scans for debris (escape pods, cargo, and later alloys as well) and will send out a scavenging ship if there's none within range.

Also implemented a routine to allow the AI's to switch their own stateMachines, so once a scavenger has filled its hold its AI can switch to the standard dockingAI rather than duplicate the code across several files. I guess I'll be writing a small suite of standard routines for common activities like these.

Progress and testing... [Apr. 28th, 2004|07:00 pm]

Got the station AI working so that it'll launch a Viper at sufficiently naughty attackers.

I also got an email from my first potential alpha/beta/rc tester. In my reply I laid out what I expect from people testing stuff for me and I think it'd be useful to copy it to here.

First off, I'll need to know about the computer(s) you'll be running Oolite on. Oolite is Mac OS X only and uses OpenGL a lot, nevertheless I'd still expect it to run on an old G3 iMac, albeit slowly. I need to know what machine you have, its processor type (G3, G4 or G5), its speed (400MHz,1.6GHz, whatever), how much memory you have, the version of Mac OS X you are using (10.1, 10.2, 10.3), and ideally the type of graphics board your machine has (GeForce FX 5200 or whathaveyou). All this information can be found in System Profile by clicking the 'More Info...' button on the 'About This Mac' display from the Apple Menu, and the easiest way to get the information to me is to choose 'Export -> Rich Text...' option from System Profile's 'File' menu (this will take a few seconds) and attach the resulting .rtf file to an email to me. Next, I'll send you in response to your email telling me about your computer, a URL for the latest version of Oolite, probably as a .dmg file for you to download. This URL will probably be valid for a few days, after I send it, but I can't guarantee it: things are moving fairly swiftly. Read any 'readMe' file I send with the game. You'd be surprised how many people don't do this. I'm assuming that you know how to play Elite, but Oolite's key layout is a bit different and information about how to play will be in the 'readMe' file. Run the game. If it doesn't run, let me know. If it crashes, then I'd like to know as much detail about how it crashed as possible. This information is going to be in a crash log located in your home file area at ~/Library/Logs/CrashReporter/Oolite.crash.log, attach this to the email you send me explaining what you were doing in the game when it crashed and I'll be very grateful. If it runs okay, let me know about that too. Next, if I'm at a particular stage of testing I might have some particular things I want you to do, particular questions about the game that need answering. At this stage I need general information, particularly what frame rates the game is getting on your system. The FPS (frames per second) is currently displayed at the top left of the screen, if you could let me know the highest rate you get (most likely in the station at the start of a game) and the lowest (most likely viewing a planet close to, or when lots of ships are on-screen). Again email me the info, I won't be annoyed to get lots of emails. Finally, let me know what you think of the game so far, let me know about things that do and don't work. Some stuff I'll already know about, check the online journal at http://www.livejournal.com/~oolite for what has and hasn't been implemented yet. Right then. I look forward to getting your email with your computer's set-up and sending you the URL for the very first alpha of Oolite-test in response.

https://oolite.livejournal.com/5854.html

Progress Snapshot [Apr. 28th, 2004|07:27 pm]

What's done:-

Pretty much everything that's in Elite is working now, with the exceptions noted below...

In addition, conversion utilities for converting between .dat files (used by Oolite and some other Elite clones) and .mesh files (used by the lovely Meshwork 3d modelling program) are very usable.

Some additional functions have been added to the control of the players ship (most notably the dump-cargo button).

AI, ship descriptions, planet descriptions and lot more of the game text are all in external files, capable of being augmented or replaced by add-on bundles.

What's incomplete:-

• Still haven't worked through populating systems with space-craft. Which means not all the models have been textured and tested yet. Instead, the same three evilly equipped pirates lurk just outside the station in each system. This will probably change in the next few days of programming, it's my biggest TODO.

• Missions are missing. They are hard-coded into the previous versions of Elite and I want to avoid that if possible, so they'll have to be recoded as some form of script, not too difficult but definitely on the back-burner at the moment.

Full screen support: we're currently running at 640x480 in a window. I want to add support for full-screen play in different resolutions.

• OpenAL: This will replace the current use of NSSound as soon as the game is running with populated systems.

How's work going, when can I play?:-

On a good day I get a few hours of programming done. Most days see some progress. The current state of the application is testable now, so anyone wanting a URL for it should get in touch.

April 29th, 2004

[Apr. 29th, 2004|12:16 am]

Wrote the first ReadMe file, copied the development build and readme file into a disc image. Posted URL to interested parties.

Then...

Fixed bug with cursor coordinates not being updated after loading a saved game. Ah well, at least it wasn't a showstopper.

It's a bug-hunt! [Apr. 29th, 2004|10:54 am]

Fixed a crashing bug when ships switch AIs by synchronising the process. This bug is reproducable in oolite-test1 by letting a Viper shoot you dead, whereupon it tries to switch to the dockingAI and crashes.

Ships emerging from the station are now queued so that multiple police ships can be launched.

Ships can be selected by the roles they can play so multiple types or set-ups of police ship (for example) could be selected to be launched.

UPDATE: Also implemented effects on legal_status of shooting ships with the role of 'police', and remembered to put in the 'Right On, Commander' message at every 256 ship kills. Also replaced hard-coded references to the scanner range limit with macros.

Picture of the Day: Oo's been a naughty boy den? [image]

SO very cool! [Apr. 29th, 2004|05:01 pm]

[Current Mood|jubilant]

It's like watching feeding time at the zoo!

I implemented having the stationAI launch scavenger ships when it detects nearby debris. Then to test I took out a Cobra full of food cargo pods and scattered them around. I have a grin so wide the top of my head might fall off if I move too quick.

Picture: An Adder docks after scavenging... [image]

April 30th, 2004

Tweaks [Apr. 30th, 2004|12:37 pm]

Tweaked the Adder's speed and manouvreability. The lollipop sticks of the scanner get a 0.33 alpha value to avoid confusing stick-clutter. Stations don't launch ships when other ships are on approach. Got a compliment for being 'eco-friendly' by having scavengers to clear up space debris.

Today's progress [Apr. 30th, 2004|09:38 pm]

Much more work on the AI subsystem. AI's now stack, so that advanced navigation routines can call upon each other to work out simple courses around obstacles.

Much of this work came from refinements to the traffic-control routines for the space stations. It made no sense to me, in the original Elite, that shuttles would appear in your path while you were on automated approach. To avoid this some simple traffic control has been implemented avoiding the launch of civilian vehicles during the approach of other traffic, and (TODO) aborting and diverting the approach of oncoming traffic if Vipers need to be launched.

It could be argued (by the impatient) that tweaking like this is inessential, however refinements to the AI subsystem and bug-fixes to collision behaviour have directly benefited from this work.

Picture: Interstellar litterbug! [image]

May

May 1st, 2004

Taking a rest day... [May. 1st, 2004|08:16 pm]

Work on Oolite confined to some art (Boas and Pythons) and some scribbling into notebooks ideas about adding exhaust plumes, and possibly a zoom option for the main viewer.

Picture: Sometimes the graphics engine throws up a beautiful gem of a planet, this is Sobite in Galaxy 2... [image]

May 3rd, 2004

Tomato skins [May. 3rd, 2004|06:04 pm]

Despite swearing off hard work for the weekend, some more progress happened.

Code for stations has been rationalised so that future systems with multiple planets and stations will work okay. This should also let me present Rock-Hermits as a rudimentary sort of space station. And (with gratitude to Jannah) write an expansion script to drop a clapped out Coriolis station into the Diso system.

Also skinned a Cobra Mk 1, while I was bored. Hence the Starsky and Hutch Tribute paintjob: [image]

May 5th, 2004

The statistics of heuristics: [May. 5th, 2004|12:32 am]

Work progressed rapidly this morning:

Entities (ships and stuff) now persist outside the station. Missile targetting now works in all view directions. Ships on approach are auto-docked before the player ship launches. More work was done on ships' basic AI routines to cope with multiple stations or planets.

This afternoon I added timed shuttle services between a planet and its space station, then began work on the hazard-avoidance navigation by having the planet's shuttle always launch from the far side of the planet.

Owiee.

My first few attempts worked up to a point - the point usually being when either my machine settled into an infinite loop, or the shuttle settled into a smouldering crater on the planet.

In the end I had to try new ideas for heuristics to break up and divert the flight around obstacles. My final divide and conquer algorithm triumphed, semi-circumnavigating the globe using only two waypoints and 20 minutes flight-time.

Excelsior!

ZZZZZzzzzzzzzzz..... thud!

Score.. [May. 5th, 2004|02:39 pm]

[Current Mood|tired]

Heuristics 3 : Sleep nil.

But the latest routines works well, I'd made some bad assumptions in the previous ones. Now they're resolved it's just a bug-hunt.

Progress Entries [May. 5th, 2004|05:52 pm]

[Current Mood|tired]

Smart navigation routines tested and debugged. This took a blinking age and involved many pages of graph paper plotting out courses as the AI's reported waypoints. The final planet/hazard avoidance routines break the journey from the far side of the planet into a smooth curve with six waypoints.

Shuttle rising from planet AI written.

Shuttle descending to planet AI written.

Timed shuttle services from planet and station working (TODO: load rising shuttle with cheap produce and descending shuttle with expensive imported supplies).

Some refactoring so ship data files are only loaded once per ship type. Some debugging messages in thoroughly tested code commented out.

Picture: Yes, this Adder has come from the other side of the world. [image]

May 6th, 2004

Minor work. [May. 6th, 2004|02:04 pm]

Some further tidying to smart navigation.

Added cargo to shuttles according to their destination.

Revised how the scanner determines if a ship is hostile.

Added salvagable alloy plates thrown out by exploding ships (carbon scoring optional).

May 7th, 2004

Flying planets [May. 7th, 2004|12:25 pm]

Rewrote the set_up_space routines to place planets, suns and spacestations randomly within the system. It works like this: you always exit witchspace with the planet approximately ahead of you. The sun is a fixed distance (in terms of planetary radii) from the planet, as is the station.

There have been knock-on effects in other parts of the code where assumptions were made about these locations, but I think I've got them sorted now.

One major effect is that there's a 50% chance the station will be behind the planet when you arrive in a system. Finding it may require some extra flight. However as these positions are keyed to the pseudo-random number generators they are fixed for each system and can be learned.

May 8th, 2004

Apologies [May. 8th, 2004|02:39 pm]

[Current Mood|stressed]

I'd intended to get oolite-test3 out this Friday. As it was I implementing the population of space with traders, pirates and such and rather overdid things. FPS dropped to under 10, even on my super-fast machine, and some unacceptable waits crept in around exiting stations/witchspace.

I'm reworking the relevant routines now...

UPDATE:

Memo to self - unnecessarily crashing several huge cargo ships into the planet will create clouds of debris that takes the processor a lot of time to deal with. D'oh!

May 9th, 2004

oolite @ aegidian . org [May. 9th, 2004|11:19 am]

[Current Mood|angry]

My ISPs at namehog.net are letting me down dreadfully at the moment and all email to my usual address is bouncing.

I hope to have this resolved today. It's just not good enough!

Progress check. [May. 9th, 2004|04:35 pm]

[Current Mood|accomplished]

Populate space routine working. I was a little confused at some black lines popping up every so often, but these turned out to be laser battles going on in the far distance. I adjusted the viewable distance for lasers accordingly.

I seem to be getting 50FPS even with 35 ships making their individual ways around the system, which is a speed I'm happy with. The testers will have to see how well it works on slower machines.

Pirates scan-for-merchantmen routine debugged (Python flying pirates would attack each other!).

Missiles properly lose target when it moves off the scanner.

Cargo containers are only loaded as necessary, not as routine.

Some extra sanity checking on Station's traffic control.

Extra AIs written and adjusted for traders.

TODO: maintain the number of traders in the system. Have traders leave the station and warp out. Have traders warp into the system. Add bounty hunters and cop patrols to the population.

Picture of the day: Eclipse. [image]

Post test3 bug-check [May. 9th, 2004|07:02 pm]

Okay, pirates now have appropriate bounties set for them. Whoops.

May 10th, 2004

Post test3 feedback... [May. 10th, 2004|11:27 am]

[Current Mood|calm]

• Laser entities have been adjusted to be properly invisible at long ranges (instead of showing up as strange flashing black lines).

• A similar tweak has marginally improved the appearance of the space-dust effect.

• The numbers of traders/pirates/law ships have been allowed to randomly vary.

• Trader AI adjusted to allow them to retaliate when attacked.

• aegidian.org still down. Namehog.net still unresponsive. Rats!

Grrrrrrrrr... [May. 10th, 2004|04:59 pm]

[Current Mood|aggravated]

Re: Email to aegidian.org bouncing.

Despite a detailed request to their sales team to note my change of address and email, Namehog.net closed down aegidian.org because of outstanding invoices - emailed to my old yahoo account (inactive for over two years!). I finally got through to them today and gave them bloody hell for it, but was persuaded to give them my credit-card details for renewal too. Email should return shortly.

May 11th, 2004

Today [May. 11th, 2004|08:05 pm]

[Current Mood|relaxed]

I've mostly been playing and tweaking while waiting for aegidian.org to return (it hasn't yet).

Added the Worm and Transporter ships to the lists of available shuttles. And played with the laser line entities until they behaved to my satisfaction. Also removed more debugging output (from the recycle routines). Still have to add asteroids, rock hermits, bounty hunters and galcop patrols, so still no illegal mining yet.

May 12th, 2004

This morning's work: [May. 12th, 2004|12:03 pm]

Implemented docking-abort-all at station viper launch.

Ceased to keep universal references for particle entities (no point in keeping target id's for things that can't be targetted, removes a lot of book-keeping).

Added regular launching of traders en-route to other systems from stations. (TODO: when they warp out have other traders warp in, witnessing one means the other won't be witnessed and this will maintain a balance among the ships in-system).

Adjusted atmospheric LoD to keep pace with planet LoD, avoiding multiple 'blinks' as we go from one LoD to the next.

Sanity checked cargo_flag on scooping canisters.

Increased the blur sprite's resolution 8 fold (from 32x32 to 256x256 for less-blocky explosifications).

Increased the specularity of the sea. Decreased the range at which ships can appear hostile.

UPDATE: Picture of the day: Biramabi, Galaxy 1. [image]

May 13th, 2004

A morning's work [May. 13th, 2004|11:40 am] Specular experiment deemed a failure, although the specular highlight on the planet seas looked great the specular shadows created at the same time showed up the granularity of the planet model. Not good. Hey Ho.

Fixed a bug where the sun wasn't mass locking hyperspeed.

Revised the lasers again. Now they're drawn as two quads (effectively a beam .5m wide and 10km long), with no culling and in an emissive only material, this looks way better and deals with ALL the distance problems I was having.

Pretty happy with the random encounters the space populating routines are throwing up. It's nice to watch distant battles and see sudden clouds of debris appear. The interactions between AIs looks good.

Textured and added the gecko, couldn't get the texture quite like the manual illustrations, but close!

UPDATE:

• Fixed a bug where salvageable alloys were being identified as commodity type -1 rather than as Alloys.
• Beefed up some of the ships, adding more energy, faster energy recharging and heavier-energy-delivery lasers while trying to remain within the spirit of the ship descriptions in the manuals. I felt I wasn't getting enough of a combat challenge.
• Scaled up the scanner by 25% and increased its resolution.

Picture of the day: Gecko, echo echo! [image]

Bouncing Boas! [May. 13th, 2004|07:03 pm]

Yikes, watching some traders come in I realised that some ships are simply too big to dock at the stations, even with scaling the stations to 1km across.

Now I'm going to have to write something far more complex: Parking a large cargo-carrier close to a station and having shuttles perform the cargo transfers!

UPDATE:

• In addition I discovered the old plasma cannon weren't working properly. They've been eliminated for NPC ships, being replaced with pulse or beam lasers.
• Fixed bug where captured escape craft yielded Alloys rather than Slaves.

May 14th, 2004

And hurrah! [May. 14th, 2004|02:02 pm]

[Current Mood|relieved]

aegidian.org is back online!

Implemented the bounty hunters and police patrols now.

Added an interceptAI designed for reuse across other AIs.

Debugged AI stacking as a consequence, there was a retain/release problem with restoring a previous statemachine.

If destroying a police ship earns you 64 points worth of illegality, what amount should I assign for merely shooting at one: 64 points for attempted custodicide!

Picture of the day: Leestian coppers ahoy! [image]

post test4 tweaks [May. 14th, 2004|05:53 pm]

This next week, in addition to bug-fixing, I'm giving time to adding little effects: engine exhausts, witchspace entry/exit displays, and tweaks to the main game engine.

First off is the implementation of smooth shaded models for objects like asteroids (done).

...

And I'll probably do the Fer-de-Lance model too.

May 15th, 2004

[May. 15th, 2004|11:15 am]

• Did the Fer-de-Lance.
• Fixed a bug where enemy ECM wasn't triggering the appropriate noise.
• Chatted more about Oolite on a.f.e

May 17th, 2004

Monday, monday [May. 17th, 2004|06:27 pm]

[Current Mood|hot]

Added the krait this weekend, and more rocks for when mining gets implemented.

Worked today mostly on making engine exhaust flares look right. This has taken a fair bit of fiddling with colors and alpha values, but I think I'm mostly there. Next I have to find a neat way to add engine flare positions and shapes into the ship database.