Vendetta Online

Monday, June 22, 2009	Detail Textures: Before and After
We've only implemented detail textures on a few object types, so far, although as I mentioned in my last newspost, expanded usage of this and the texture compression feature will be ongoing. Some of the Detail Texture effects can be a bit subtle, the intent being to present detail as though it's a part of the object, not to draw attention to itself. Here is a before and after comparison, for those who would like to see. Try to ignore the shadow brightening of the background asteroid, that's unrelated, an artifact of how these screenshots were taken. (images adjusted for brightness only, no sharpening) Without Detail Textures With Detail Textures I'd suggest opening those in separate tabs, and flipping back and forth between them. As you can see, the difference is substantial, but has been tuned to blend with the material overall.. not be "in your face". The intent here is to use the effect to provide a more detailed in-game reality, but one that can be taken for granted by the player, not as a showcase in and of itself.
Saturday, June 20, 2009	Vendetta Online 1.8.77
VO 1.8.77 includes: - Added Detail Textures to some asteroids. These can significantly increase surface detail when nearer to the object, under some circumstances. Only compatible with Shader 2.0 hardware, or better. See Dau G11 for example. - Turrets on player-owned ships can no longer be a part of weapon firing groups.
Thursday, June 18, 2009	Changes big and small.
We've had a busy month, and have some cool changes in the works. My own presence around the office has been a little spotty, lately: I was at an investor conference for most of last week, so in the meantime we moved up some important tasks that didn't require too much design input or oversight. In this particular case, getting some graphical changes in place for the greater "universe redux". Michael is also working on his Event Registration web-app, but for the purposes of this post I'll mostly be discussing some graphical changes. First and foremost, I had Ray drop detail textures into the engine. This is a feature that allows the primary texture on an object to be modulated with a secondary "high detail" texture; so when the first begins to look blurry, the second comes through and creates the impression of increased surface detail. Combine this with specularity and bump shaders, and you can add a lot of detail. This is particularly important with Very Large Objects, since they tend to have much more obviously "blurry" textures. Large or small, however, detail textures can have a big impact on the perceived visual quality of objects in the universe. Adding detail textures only took him a few hours, but handling the more aesthetic tradeoffs and balancing that against shader performance has been an ongoing process. We had been planning to add this feature for years, but just "hadn't gotten around to it". Although they have general applicability on any object, the need for detail textures tends to be greatest with large objects. For this, and other reasons, we've historically tended to avoid "really large" objects, preferring clusters of smaller objects to yield more detail. However, as part of the greater "Universe Redux" process, I'm looking at getting some physically-bigger content into the galaxy. If I'm going to spend the time to repopulate most of the galaxy with more asteroids, I would just as soon add in some new types of asteroids, and giant ice, and other features that can add to the tactically complex environments that will become that much more central to future gameplay. Aside from this, you'll also begin to see a lot of added detail on ships like the HAC and Constellation, as well as our stations and the like. Some of the current asteroids, like the broken tan-color chunks, will be among the first to get the added improvement. All in all, detail textures add a significant bit of enhancement for a relatively small amount of development work, which is exactly the sort of graphical update that is worthwhile when convenient (despite all our pressing gameplay needs). Detail textures will only be visible to people with "fairly" modern hardware (ie, only six years old, heh), as it will only be present for shader 2.0 capable cards. This brings me to my next subject: revamping a small area of the VO graphics engine, and some of our graphics assets. As many of you know, we started development in 1998. Our original engine was our own custom software renderer, and we soon added support for the then-new 3dfx Voodoo and the marvel that was "3D hardware acceleration". From then on, as hardware progressed, we would add features to take advantage of it. Nvidia released the original "GeForce" card, which supported DOT3 bumpmapping, part of what would later become known as the "fixed function pipeline" (differentiated from modern shaders, which are an entirely programmable pipeline). Although I had to (virtually) beat our then-graphic-artist over the head to get him to use bumpmaps, since he had disliked the earlier EMBM we had used with Matrox cards, our DOT3 support eventually led to the object-space asteroids we all know so well. Things evolved, and we ended up using tangent space normal maps more often, but we still kept our object-space maps around and continued support for both methods into the world of Pixel Shaders (1.1, 1.4, and 2.0). As a result, a person can run our game today on a machine with a GeForce1, and still see all the bumpy lighting detail on the Training Sectors asteroids. However, the time may have come for us to revamp how we support different hardware, to the betterment of everyone (including older machines). Part of the problem has stemmed from our large textures, and our increasingly heavy use of complex pixel shaders (2.0, for newer cards). Large textures put a lot of stress on texture memory, and also on the memory bus of any videocard in moving data to and fro in order to display all the pixels you'd like to see. Texture compression helps, but we have studiously avoided compressing our normal maps, because historically, it tended to make them look horrible. Advancements were made a few years ago, with Doom3 and some clever ways of compressing normal maps without making them look entirely like crap. Further improvements have built on that, making it an even more attractive prospect. Compressing our normal maps would considerably reduce video memory overhead, allow faster load times (anyone noticed how long it takes to load the Training sectors?), and lastly, consume less videocard memory-bus bandwidth. The last one is becoming a bigger issue as we keep adding more shader-driven features, like detail textures and so on. Any given videocard only has so much bandwidth to move textures around and operate on them in such a way as to display the Neat Stuff we send to it. Obnoxiously large, uncompressed textures can make that a lot more challenging, and reduce framerates. The tradeoff: We're still considering a bunch of options, but it's possible that we'll just drop normal map support for anything earlier than Shader 2.0 model hardware. Ie, machines with GeForce3/4s or Radeon 8500/9000s would no longer get to see the snazzy bumpy stuff. On the other hand, those machines are really struggling to keep up with some of our newer content, like the big battles in Dynamic Warfare, and removing some of this overhead could improve that situation. Plus, it allows us to optimize more heavily for the areas we do support, making things faster for people who do have the "newer" (read: 6-year-old) hardware. Vendetta Online is known to run on an amazing variety of older hardware, possibly making us one of the most client-scalable modern MMOs out there, and I do not intend to change that. We're not dropping support for anyone, and like I said, if anything it may make older machines run a bit better.. but at a small graphical cost. We're basically looking at shuffling around some of the graphical "glitz" in the interest of making the game run faster and better for everyone, and look cool for most people. Ray is in the midst of implementing the new normal map compression features, in between tweaking detail textures and other things for me, and while we still have some testing to do there.. hopefully you'll see it before long. As he churns out the features, I'm revamping our graphics assets to use them effectively. I also have some unrelated work to do in updating how some of our current assets are loaded into the game. Another sign of relatively old heritage in the MMO community: our use of Hoppe progressive mesh degredation. Back in the 90s, the difference between 200 polygons and 400 polygons was a.. big one. So we engineered the "Level of Detail" system to allow people to configure different numbers of onscreen polygons, to allow their systems to work better. These days (and for a long time), hardware has dealt much more efficiently with fixed sets of optimized polygons, rather than dynamically-changing sets of un-optimized polygons (which the dynamic meshes tend to be). So while I'm reworking some of the asteroids, I'll also be re-exporting them as static meshes, and creating static LODs for them. This should hopefully also speed things up on some machines, even with higher polygon counts, and lead to a better situation for drastically increasing asteroid density in the universe. We'll make sure to keep plenty of options for game scalability (it has to be playable on my Pentium III 933mhz w/GeForce3 basement linux-box), but the nature of the options may change a bit. *"Ok, but where is the gameplay?"* We haven't forgotten any of our pressing needs with our economy, faction system, mining, missions, dynamic warfare, and the myriad of other topics that yell angrily at me from my TODO list. This graphics update is not very lengthy or time consuming, is already half finished, and should be of significant benefit to the "universe redux": the repopulation of the galaxy with vastly increased asteroid densities, statically fogged areas, and other content that will directly impact on the economy, grayspace traffic, piracy and other areas. Our new universe build tree and fully dynamic economy will stem from some of the new minerals and ores that come with the redux. Plus, it will make certain combat (such as fighter-level Dynamic Warfare instances) a hell of a lot more exciting. All in all, it should be a good use of two weeks. Plus, it makes the game prettier and potentially faster. If that isn't a win-win, I don't know what is. In other news, we also have a cool new intern (Paul) who is producing some nice new icons for us, and will be taking point on a general "icon redux" project, to update a few graphical aspects of our station UI that have been left incomplete. Not heavy stuff, but very welcome. Hopefully we'll get him involved with more art as we move forward. That's about all I have for now. In theory, by Friday we will hopefully have some cool detail-textured asteroids for you all to check out, as well as a new Event Registration application in testing (ie, for people to register upcoming player Events, potentially to get pushed out to a future mailing list, as well as requesting Guide assistance and the like). I can't promise much more than that, I wanted to do some new Badges, but I'm up to my ears in shaders and normal mapping. As always, please post feedback on the forums. Things are coming along pretty well here, I'm really looking forward to some of this stuff, which has been on the "horizon" for so long, and now is starting to look like it's finally "right around the corner". -Incarnate
Sunday, June 14, 2009	Vendetta Online 1.8.74-76
This past weekend, VO 1.8.75 and 76 include: - Fixed Voice Chat volume control. - Slightly optimized inventory menus for players that have large inventories. Released last week, VO 1.8.74 included: - New weapon: the Shield Turret. This defensive weapon may be equipped only to vessels with Turrets (Atlas, Behemoth), and fires a small shielded area to deflect incoming fire. Available in Odia M14 (expensive) or the UIT Capitol stations (much more cheaply). - "Next Border Engagements" mission indicates when the next set of Dynamic Warfare missions will start, and what size the will be. - Fixed crashing bug when logging off with a damaged Atlas ship. - Fixed lua error when logged in and a character hasn't been chosen yet and a Border Skirmish sector was conquered at the same time.
Saturday, May 30, 2009	Vendetta Online 1.8.73
VO 1.8.73: - Navmap conquered sector cells are now more transparent. - Navmap rendering atrifacts at certain scale factors have been fixed. - Server-side memory usage has been made more efficient. - Fixed message stating that player entered a given station. - Fixed misc rare client crashes.
Saturday, May 23, 2009	Vendetta Online 1.8.72
Version 1.8.72: - Dynamic Warfare in Deneb! The Serco and Itani vie for control of sectors in a weeklong conflict. Conquered sectors are indicated in the nav map. - Pilots now always show up as friendly in the gunner's radar. - NFZ indicator now appears on gunner's HUD when in a no fire zone. - Fixed free repair for players who take part of any Border Skirmish type of missions. - Fix to disable shaders for Intel GMA 950 chipsets on Windows.
Saturday, May 16, 2009	Vendetta Online 1.8.71
VO 1.8.71 includes: - Atlas turret has been moved to the stern. - Turrets are now visible on player ships. - Gunners aren't asked to buy back last ship when they leave the ship. - Leaving a ship as a gunner now has a 10 second countdown so you cannot leave in a hurry. Typing /gunner leave a second time will cancel the countdown. - Pilot and all gunners are counted as a PK when the ship is destroyed. - Fixed a mentor bug. - Fixed gunner leadoff/autoaim targeting. - Message now says 'Entering player's ship' instead of 'Entering player'. - The pilot now always shows up as green to the gunner.
Saturday, May 09, 2009	Vendetta Online 1.8.70
VO 1.8.70: - Multi-player ships are now available. Pilots of Behemoth and Atlas class ships (except the Behemoth XC) may now invite other players to join their vessels and help defend them via turrets. Certain ship variants have up to three turrets, allowing four players to cooperatively defend a single ship. Pilots must all be docked at the same station to initially join, and be invited by the pilot of a given ship via new "/gunner" commands. More involved interfaces, features and weapon options will become available as we move forward.
Tuesday, April 28, 2009	Finally, a news update.
Hi there. I haven't posted a news update recently.. we had some billing system outages and a rather extensive economy discussion, all of which left me a bit distracted from the regularity of newsposts that I've been trying to maintain. Anyway, hopefully I can get back to doing this weekly, again. *What HAS* been happening...** We've made some significant improvements to the server-side performance of capital ships and content related to capital ships. I've mostly illustrated this usage for Border Skirmish, but this is really a much larger picture than simply Border Skirmish or Dynamic Warfare. The improvements we've made are going to make it far easier to have capships as user-owned items. The problems that plagued Border Skirmish would not have been any easier with a bunch of player-owned capships, so hopefully you can appreciate that the development steps we've taken in that direction should have long-range impact. We're now wrapping up this "optimization" period, it largely has been wrapped up for awhile, but we've still had other testing going on in the background while we debugged a few outstanding issues. If all goes well, we should roll out LuaJIT on all sectors this week (Fri) and push Border Skirmish back to being a "normal" sector instead of a specialized test-case with its own dedicated server. This also lets us get on with expanding Border Skirmish gameplay and moving towards the Dynamic Warfare concept we've been discussing. We've also made some big changes to the way new players are handled in the game, specifically creating the new "Training" sectors and forcing those regions to be newbie-only. There has been some controversy over these choices, but we believe that having a relatively-protected early training environment, where a new player can get a handle on the game, without being "griefed", is critical. This initial training period can be quite brief, for those who wish to skip it when making alts, but can also be lengthy for those who really wish to take their time and learn how to fly and shoot before venturing into the "greater galaxy". This also fits into my long standing plan for changing how newbies are handled within the game, and I think will make a much better experience for new people, while keeping an acceptable tradeoff for most of our veteran players. Of course, I can never please all of the people all of the time, but I am quite certain that these changes are in the best interests of the game as a whole. Relating to the billing system. Our recent outage was not our fault (our credit-card processing site went down); but we have decided to make our billing back-end more robust to these kinds of outages. This requires some tradeoffs on our end, but they should be transparent to the subscriber, which is our goal. Since we're touching on Billing-related functionality anyway, we're also going to try and build some improvements into the interface itself. It should become far more informative and helpful, while still retaining the simplicity and functionality that (aside from a day or so, recently) it has been known. We're also still looking at rolling in the independent PayPal payment methods, and some other changes, but those are not necessarily going to appear on the same immediate timescale. Hopefully we should have billing improvements in place by this coming Friday. *What's GOING* to be happening... I'm doing some marketing-related work, setting up some promos with a few sites, and things of that nature, and haven't had a lot of time for untangling some knotty design problems we face (one of which: our faction system, the vast inane mess that it is). Completion of the the faction/FF redux is, aside from billing-outages and server-performance-problems and other unpleasant things, our highest official priority. However, since I'm kind of stalling that development until I finish with some Business stuff, I've pushed people off to other projects that I think will be.. appreciated. As a result, Ray is now working on making multi-player ships** a reality in the near future. I can't say how near of a future, because we don't know yet; but if all goes well.. as early as this Friday, if not, then next week. This is a critical stepping-stone as we move towards the goal of Player Capships. In the near-term, you can expect some sort of small "heavy" that has the potential for turrets, such as a Behemoth. This functionality has been planned for a really, really long time, but there may still be some issues with the mechanics as we put this into place, so please have patience with any issues that crop up. Despite the possibility always being there, we've never actually done this before.. which is why dockable capships are always NPCs, and dev-flown capships have never been dockable. Of course, for the first version we'll just be focusing on smaller ships, as I said, where the owner of a given multi-player-capable ship may "invite" other players to join his vessel, while docked in a station. Dynamically joining and leaving these sorts of ships, outside of stations, will not be possible.. you'll have to wait for capships with docking bays for that to happen. Anyway, I think this'll be really cool, and open up a lot of potential for gameplay possibilities. As I said, the mechanics are still in flux, so things like grouping will have to be done independently of which players join which ships. If people want to take grouped missions as multi-player vessels, then they'll need to group themselves as a separate stage. Michael is also working on a new system to allow scheduling of Events and coordination with a volunteer Guide, which will hopefully let us host and organize more events, and have the information clearly available. Hopefully we'll have some version of this by Friday, but I don't know if we'll make it visible or not, we may yet do some testing with the Guides. That's all for now.. Please continue to give us feedback about the game, particularly the Border Skirmish sector. Hopefully we'll have that sorted out fairly well by the end of the week, and "Border Skirmish testing" will be over and done with. Thanks everyone, for your patience. I hope you're as excited by some of this stuff as I am. - Incarnate
Saturday, April 25, 2009	Vendetta Online 1.8.69
VO 1.8.69 includes: - Escort missions now pay less within the space of a single Nation. - Luxury goods now more valuable in deep grayspace, less valuable elsewhere. - Organic Solvents have new grayspace routes. - Newbie sectors now only allow new players. Other players entering those sectors will be fired upon. - Linux right-ctrl/alt keys are now bindable. - Further testing of server-side performance enhancements in Border Skirmish sector (please report any issues).
Saturday, April 04, 2009	Vendetta Online 1.8.66
VO 1.8.66 includes: - Fixed bug in Training V mission, text error in Training IV. - Fixed bug where bots would fly into asteroids. - Trial expiration message is now displayed when trial expires. - Damaged ships now sell for less based on repair cost. - Mission list now says that it is receiving a mission list instead of saying there are no missions available. - Character names with similar letters can no longer be created. For example, using lower case L to look like an upper case I to spoof someone else's name no longer works. Other combinations include O vs. 0, Z vs. 2, and B vs. 8.
Thursday, April 02, 2009	Making forward progress.
Another short heads-up about what we're doing (no this is not an April Fools post, I happened to have time to write an update today). We spent about a month working to improve server-side performance and scalability, related to Border Skirmish and other large-scale battles (Hive Skirmish, etc). By and large, we succeeded, although there has still been some fallout of new bugs and issues that have cropped up as a result of the changes (NPCs flying through asteroids occasionally, etc). This week, we've started to get back to doing non-optimization work, with the general idea of being back on track for the FF/Faction/Economy changes in the near term, along with the various other stuff we had been working before the unplanned "debugging / optimization period". In the meantime, there have been a lot of things that have cropped up, which fell by the wayside due to lack of development resources; so we're also spending a certain amount of time cleaning up some Billing interface stuff, and other areas. Aside from this, there are some other issues that require addressing before we should move forward with expanding Border Skirmish into first-generation "Dynamic Warfare", which was our project focus about a month ago. We've been "temporarily" running the Border Skirmish sector in Deneb persistently on a unique server, to allow us to do performance analysis without other sectors running on the same machine and clouding our results. Now that we're fairly confident in the performance improvements, we want to move back to distributing the sectors dynamically based on cluster-server load. This is particularly important with the "expanded" Skirmish concept, since there may be several skirmishes happening simultaneously in different sectors. At the same time, however, we don't want the CPU-intensive skirmish sectors to impact other relatively-lightweight-but-critical sectors, such as the capitols or the newbie sectors. We've long planned to subdivide our server cluster distribution: "high expected CPU usage" sectors running off of one cluster, while "regular" sectors run off of others. This keeps the low-intensity and high-intensity sectors from running on the same machines at the same time, and makes the game better for everyone. We hammered out a design for the improved system on Monday, and work has begun this week. Hopefully this'll be in place by next week some time, and we can start to expand on Border Skirmish without impinging on other areas of the game. Work on the economy is also coming along, mostly in the form of doing some analysis of trade routes, and building some tools to watch what happens. I still fully intend to push a lot more traffic into gray; I know that hasn't really happened yet, but that's still what we're working towards. We dropped Friendly Fire restrictions, first in Odia/Sedina/Bractus, and then throughout Grayspace, and the changes have been very well received. We will be continuing to move forward on the FF/Faction changes laid out long ago, with the next big thing being the disentanging of many of our weird faction system rules, and how they interact with the client Radar. Fixing strange stuff like radar coloration based on who is the "enemy" of the local faction, instead of the "enemy" of the actual player. Plus a lot of other changes, mentioned in the associated RFC thread. We will be continuing to remove FF restrictions, as well. I may leave them in place in the starting newbie sectors, or around Capitol stations, but I am aiming to remove them as much as possible. On the "longer-term" view, I am starting to rework some of our milestones to take into account the recent optimization work, and I expect to post a 1.9.0 bulletpoint list before long. This will probably go up here, as well as going out to the usual news sites. Whenever I'm getting a chance, I'm re-organizing our high-level goals with an eye towards this, a 2.0 bulletpoint list, and a public Trac system (no, I'm not promising a timeframe on that last one). Of course, this takes time away from my day-to-day work.. if only project management / design was my job, instead I have like fifty jobs to juggle. Anyway, end result being, I think we'll be seeing 1.9 in the near term, as well as some more information about The Plan. On the short-term front, I don't want to over-promise anything, but if we're lucky we may see: 1) Expanded Border Skirmish, 2) Most of the FF/Faction fixes, and 3) some significant economy/trade-route changes, before the end of April. No, that isn't an April fools thing, and I'd say it's more likely that we'll do two out of three, but it's possible that we'll get to all of them. It really depends on what bugs and nastiness happens along the way. For instance, Michael has been working on some low-key changes to handling of groups in Skirmishes (so they don't automatically break up at the end, and people can continue chatting, etc), and today discovered a nasty bug that actually causes the game server to exit. These sorts of things happen, you spend time working on X, and suddenly discover Y orthogonal nasty bug. So, let's keep our fingers crossed and hope things go smoothly over the next couple of weeks. We'd really like to get some of this stuff out of the way, so we can look at really expanding gameplay in earnest. Building and optimizing "engines" is all very well and good, but it doesn't really get interesting until you start to do something with it, and that's the bit I think we're all looking forward to. Take care all, thanks for your patience and support. -Incarnate
Saturday, March 28, 2009	Vendetta Online 1.8.65
VO 1.8.64/65 (both this week) included: - Friendly-Fire restrictions removed from all of gray space. - More server-side Border Skirmish performance enhancements. - Server-side performance enhancements are now used everywhere. - Border Skirmish now features live countdown timer in mission description. - Fixed HUD component size issues. - Improved client-side collision detection in highly active areas such as Border Skirmish. - Fixed bug that caused ship radar blips to turn blue when binding a joystick button to a command when the joystick button already had a command bound to it. Also fixed other possible crashing bugs with joystick menu. - HUD is centered in the middle 4:3 aspect region on the screen by default when starting the game in 1920 widescreen. This option can be turned on and off in the Interface HUD options menu.
Saturday, March 21, 2009	Hi, I've been too busy to write a Newspost.
Just a little quick info about what we've been doing. The last few weeks have been somewhat frustrating for us, as we've been debugging the whole server-side Border Skirmish performance issues. We found the original "trigger" problem relatively quickly, but after fixing that we still saw sub-par performance, and analysis indicated that there were.. a lot of different issues to look into. Some avenues, like LuaJIT, ended up not working out for us for the time being (LuaJIT is very cool, but we make extensive use of coroutines, which are suboptimal in the released 1.x version). Other work just didn't really produce the results we were hoping for, and after two weeks of screwing around with sector code, we've been really wanting to get back to things like.. oh.. adding gameplay. So anyway, this week we attacked this issue anew, to try and really nail it down, and we've been working pretty intently.. hence the lack of news updates on my part. I've been more directly involved than in past weeks, as I'm the only person equipped to do stuff like model new collision hulls (more on that later). After some use of FreeBSD's very cool PMC Tools (basically the FreeBSD equivalent of Linux's oprofile), we discovered some issues in our spatial partitioning code. We use an Octree to subdivide space and give us certain regions where certain objects should be checked for collisions (but others should not), and the like. In situations like capital ship battles, so many shots are being fired from capship turrets that the octree code was becoming sub-optimal. We're now experimenting with a Sweep and Prune implementation that seems to yield much better performance in the specific "giant space battle" case, but may be less optimal for other, more generalized situations. We have constructed several benchmarks and are continuing to experiment. Aside from this, I've also been producing more efficient collision hulls, for use only on the server-side. Games use separate models for "visual" detail versus "collision" and "physics" usage. The visual model includes all the pretty and intricate detail that makes an object visually interesting. The collision hull only needs to have the parts that are important to actually.. colliding with other objects (such as enemy shots, rockets, big rocks, or that docking bay that you swear moved). On small ships, there's a lot of leeway.. collision models can lose a lot of surface detail without actually causing any noticeable or combat-relevant change to object collisions. Large ships, on the other hand, are much more challenging cases for "optimized" collision hulls. Think of a stack of ten equally-sized legos: if you remove one lego, the overall size of the object is not that dramatically different. However, to a creature the size of an ant, it might be significant; by the same token if you scaled the lego object up to the size of a skyscraper, that "one" lego you removed might be hundreds of feet in difference. The same issue holds true when creating collision hulls for physically "large" objects in games: if you remove some detail that looks irrelevant when zoomed out, all of a sudden someone's torpedo is now missing its target, flying "through" some visual geometry; or perhaps striking geometry that isn't visually apparent. There is a desire, on the part of the game developer, to have the minimum number of polygons necessary to provide an accurate collision surface. Collisions can be computationally intensive, especially between complex objects. This is particularly the case on the server-side, where a single machine may be simulating collisions for a vast number of NPCs in a particular sector battle. To date, we have used the same collision hulls on the client as we did on the server. The client-side objects have relatively high polygon counts, as the large "detail" is really necessary. However, now we're experimenting with server-specific hulls, which will only really be apparently in NPC-to-NPC collisions. These very-low-poly hulls should drastically improve certain worst-case-scenarios, where ships are in close proximity and are firing vast numbers of turret shots back and forth. At the same time, evidence of the reduced collision hull detail won't be very obvious to the player, as the client will still use the high-detail hulls. On a sidenote, I have also done some tweaking to the client hulls, so some of them may yield better performance on people's computers, but I'm not sure that this will be noticeable. Turrets have also been optimized, specifically the collision of their shots to objects, a very common case in these large battles. We could simply reduce the number of shots, of course (or the number of capships, or force the capships only to sit far away from one another), but that would detract from the type of "crazy-ass space battle" that we're trying to generate. Results from the above tweaking have been optimistic, so far, at least in our benchmarks. We've also run into some weird bugs, so this BS-optimization work will be continuing into next week; but we expect we'll be able to wrap things up within the coming week, and get back to "new gameplay development". Some of the recent improvements seem to indicate a possible ~50% general performance increase; while other "extremely bad" cases may be improved much, much more. Still, we'll have to see how it goes. Tonight we're (hopefully) going to release the optimized collision hulls, but still using the octree code path. The sweep and prune code may debut next week, we need to do some more testing, and perhaps optimization of certain areas. I'm afraid I've been too busy to make anything particularly cool to release into the game tonight. Hopefully "improved BS performance" is worth something. There has been a lot of great Suggestions Forum activity lately, I've been following it but not responding as of yet. Please keep this up. Also, I'd like more feedback about Friendly Fire in grayspace, which we enabled last week; I've created a special forum thread for related feedback. That's all for now, we'll be aiming to have some more significant and interesting releases next week, and be getting back on track for further Friendly Fire / Faction system changes, as well as expansions and improvements to Dynamic Warfare and the Economy. Thanks for your patience during this unplanned and highly undesired debugging period.. hopefully this work will give us a better foundation on which we can build crazy new gameplay. -Incarnate
Saturday, March 14, 2009	Vendetta Online 1.8.62
VO 1.8.62 includes: - New Ship: Corvus Greyhound, a Warthog Interceptor only available in Odia. - One new PCC mission: CtC Information for the Itani. - Friendly Fire has been enabled in all of Odia, Sedina, and Bractus. - Testing more performance enhancements in Border Skirmish sector.