landon@destiny Log

Getting particle systems hammered down is finicky, case in point:

Torpedo Whoops!

While I was testing out torpedoes (new weapon with a heavy particle effects bent!) I noticed several things had become broken wrt basic use of the battleviewer. :( So today I've been debugging and cleaning those right up.

Also, here's my latest youtube video:

Short update, links to some screenshots of recent progress:
Warping In
Warping In, closer view
And another
And another...
Almost done warping
Battleship fleeing the scene
Rear view
Scout and Frigate

The past few days I've been working on particle effects. So far I have effects suitable for:

• Laser firing
• Engine trails
• Warping in

I still need to work one out for explosions, but that shouldn't be too hard. Right now though, I'm working on getting the engine trails in place and firing properly when move events occur. There was a heck of a bug where the trails would show up on top of everything, but that was caused by a bad .material file for the flare texture I was using. Now it's just down to per-ship placement, which only needs to be done for the frigate's model now (6 seperate trails, urgh.) This has been taking a little longer than I wanted, but now that I know what's going on with particles, I should have a majority of this stuff done over the weekend and be able to focus on the other prettifying aspects of the client!

Short post here, this is just to show off the new video:

Has it really been almost 10 days since my last blog post? What a hectic week.

To start off, I've worked and worked and worked on collision detection. It works now! In theory you can now have 20 frigates all jostling each other for the right to be at spot (0,0,0)

Aesthetic improvements? I've finally bit the bullet and split the battleviewer up into several files from its previous monolithic .py file setup.

Actionwise? Hitting next round actually queues up the correct rounds events now instead of reusing round 1 over and over and over again.

Oh, and now you can select the XML file you want to load at startup with the -f/--file option on the command line

This week I'm going to (looks at task chart), split up the scope of the viewer even more to accomodate reloading in-viewer, find a way to highlight the current event going on, and check into borrowing overlays from the main 3d client to represent damage with (oh, that reminds me, I need to look into particle effects too!)

A blog post talking about the past few days of work should be up here sooner or later, unless I pass out at the keyboard again.

Since my last update, I've:

• Changed the controls from buttons to StaticImages which are mostly transparent (looks great!)
• Revamped the progression system so that it moves by events now, which have the option of delaying the progression if they need to take a while (such as more elaborate Fire events might in the future or Move events.)
• Finished collision detection just far enough to notice that there is a much much better way to be doing that I will try to implement on Sunday or Monday. Right now I loop through and check all entities against the moving entity and if their spheres overlap I give the obstacles a push so they drift around the side. Kudos if you can name the immediate problems with this. One: Hackish. Two: Since drifting back to their original position is also treated as a sort of Move event, the obstacle and moving ship will push each other around until one drifts over to the side and they snap into place. The improvement I'm looking at is using Ogre's intersection queries so ee if any bounding boxes are overlapping and then do a check against their bounding spheres. I have also found a way to set certain flags on objects so I can exclude all objects moved by actual Move events and give them the priority when it comes down to moving obstacles out of the way. Other than that though, the function to bounce the obstacle back will be the same and translate it back so the spheres are not overlapping anymore.
• I've also done a little preliminary work on loading other battlexml files, but this one is puzzling me and may require more of a rewrite than I'm comfortable with. Unless of course I ask in the command line, but who would want that?

Today I've been working on revamping the laser system so it works smoothly with the round progression ( I never noticed that if you go forward to a fire event and then back up, the laser will still be there... d'oh! ) As an added bonus, ALL of the lasers in one round are shown!

The next few things I'm going to be getting done before bashing my head against the collision problem include icons for the control buttons, choosing a BattleXML file to load, and possibly getting ship textures fixed/replacing ships!

Today I was able to make it so that Entities will float back to their intended position if pulled away (or hopefully in the future, pushed away by a collision.) However, working out collisions is turning out to be much more finicky than I thought. I can find out if one Bounding Sphere intersects another, but not by how much. The formula (radius_one+radius_two)-distance should give me the overlap, but instead it keeps giving me a constant! I'll tackle this in the morning and hopefully have a lot more cool things to show tomorrow, like a video!