0.6 plans
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: 0.6 plans
I've got another way to attack this problem: ability to stockpile. You should be able to carry extra ammunition as cargo, with the dangers it carries.
I think scarcety of munition types is a good thing to have in VS. It makes the system feel more realistic, and it makes choosing among the different weapons an interesting thing to do. But the above feature is missing, to make it complete.
That, and really fixing some weapons that are way too scarce. And perhaps warn the user about availability on the item's description.
I think scarcety of munition types is a good thing to have in VS. It makes the system feel more realistic, and it makes choosing among the different weapons an interesting thing to do. But the above feature is missing, to make it complete.
That, and really fixing some weapons that are way too scarce. And perhaps warn the user about availability on the item's description.
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: 0.6 plans
And let's not forget the weapons balance is broken anyway. Capship weapons for example, have no fire power. And there's like three times more beam weapon than guns. And all the guns are basically machine guns (there's no slow rate of fire and/or slow exit velocity guns). You can't find capships weapons anywhere, no turrets almost anywhere and you can't find light weapons and few medium weapons at fighter barracks even though most fighters sold there need to use them. The list goes on...klauss wrote: I think scarcety of munition types is a good thing to have in VS. It makes the system feel more realistic, and it makes choosing among the different weapons an interesting thing to do. But the above feature is missing, to make it complete.
We need to make all weapons readily available for 0.5.2. Then they need to be well balanced and tested for 0.5.3 while exposed to the light of player availability. After that we can discuss which weapons in the now balanced arsenal should be scarce or what types of places you should or should not find them. And while we are at it, let's do the same thing for turrets, because they are a mess too.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: 0.6 plans
I agree. But let me disagree on the machine guns thing: there are none. Think Battlestar Galactica rate of fire like. There are none to few that fast, and a large part of the blame you can attribute to sounds, for making them sound right or simply not annoying is difficult in VS.Deus Siddis wrote: And let's not forget the weapons balance is broken anyway. Capship weapons for example, have no fire power. And there's like three times more beam weapon than guns. And all the guns are basically machine guns (there's no slow rate of fire and/or slow exit velocity guns). You can't find capships weapons anywhere, no turrets almost anywhere and you can't find light weapons and few medium weapons at fighter barracks even though most fighters sold there need to use them. The list goes on...
We need to make all weapons readily available for 0.5.2. Then they need to be well balanced and tested for 0.5.3 while exposed to the light of player availability. After that we can discuss which weapons in the now balanced arsenal should be scarce or what types of places you should or should not find them. And while we are at it, let's do the same thing for turrets, because they are a mess too.
We can find a fix for that. But there should be far greater dynamic range in that aspect: some real MG-style guns should be very very fast, it makes sense in space where barrages increase the likelihood of hitting something, and some should be really powerful with low cadence, that make you think twice before hitting the trigger. I think ranges should go from 30 rps MG, to 0.5 rps canons.
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: 0.6 plans
Alright then, I will roll this improved weapon availability patch into my larger super-patch.klauss wrote: I agree.
That is basically what I mean, except maybe go down to a 0.3 rps for a heavy cannon.We can find a fix for that. But there should be far greater dynamic range in that aspect: some real MG-style guns should be very very fast, it makes sense in space where barrages increase the likelihood of hitting something, and some should be really powerful with low cadence, that make you think twice before hitting the trigger. I think ranges should go from 30 rps MG, to 0.5 rps canons.
And then some anti-capital focused weapons that take a minute of cool down between shots (and enormous reactor energy) but delivers a tenth the damage of a torpedo for no ammunition cost (possibly a Rlaan weapon).
And some lower exit velocity weapons that are hard to deliver but very punishing when they hit something.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: 0.6 plans
Sorry i've been away for a while again. Android is taking all my time. I just wanted to give everyone a heads up that changes in the way multi-arch is done on OS's like debian are temporarily (hopefully) breaking cmake. I have fixes that can work around them but the Find modules for opengl and glut aren't able to be easily moved into the source tree (they include a bunch of other modules). Meaning, the fixes can't be implemented in the repo at this time.
Solutions are to either roll our own heavily modified Find modules or wait it out and hope cmake gets updated to reflect the inconsistencies. This is all on Debian Unstable so if you're not running that you will unlikely be affected anytime soon.
Solutions are to either roll our own heavily modified Find modules or wait it out and hope cmake gets updated to reflect the inconsistencies. This is all on Debian Unstable so if you're not running that you will unlikely be affected anytime soon.
Ed Sweetman endorses this message.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: 0.6 plans
Thanks for the heads up. But unstable is really just in diapers, so we better wait for them to fix cmake. I doubt our project is the only one hit by these changes.safemode wrote:Sorry i've been away for a while again. Android is taking all my time. I just wanted to give everyone a heads up that changes in the way multi-arch is done on OS's like debian are temporarily (hopefully) breaking cmake. I have fixes that can work around them but the Find modules for opengl and glut aren't able to be easily moved into the source tree (they include a bunch of other modules). Meaning, the fixes can't be implemented in the repo at this time.
Solutions are to either roll our own heavily modified Find modules or wait it out and hope cmake gets updated to reflect the inconsistencies. This is all on Debian Unstable so if you're not running that you will unlikely be affected anytime soon.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: 0.6 plans
Aaand we've got split CSVs. I'll test and commit Deus's CSVs shortly.
Thank this tiny virus I've got for the surplus in free time
Thank this tiny virus I've got for the surplus in free time
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: 0.6 plans
Yay!
With split CSV, eye cancer will be a thing of the past.
With split CSV, eye cancer will be a thing of the past.
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: 0.6 plans
It looks like it has been well over a year and a half since the last release. We could really use a new one.
Also:
Also:
Did this get fixed?klauss wrote: Bolts or beams don't query the collision mesh yet. Safemode had plans to fix that IIRC.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: 0.6 plans
No, he never finished it.Deus Siddis wrote:It looks like it has been well over a year and a half since the last release. We could really use a new one.
Also:
Did this get fixed?klauss wrote: Bolts or beams don't query the collision mesh yet. Safemode had plans to fix that IIRC.
I'm tempted to overhaul physics and damage models (and upgrade mechanisms) currently.
If the latest rebalance is OK in terms of gameplay, I could do a release before doing that. How's the playtest of the latest SVN going?
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: 0.6 plans
I would say the balance is stable enough that it is ready to be in a minor/beta release of the game to facilitate wider testing, like a 0.5.1r2 or such.klauss wrote: I'm tempted to overhaul physics and damage models (and upgrade mechanisms) currently.
If the latest rebalance is OK in terms of gameplay, I could do a release before doing that. How's the playtest of the latest SVN going?
What changes are you planning for damage and upgrades, by the way?
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: 0.6 plans
I'd say 0.5.2 (an r2 would have to have the same gameplay, ie, be a bugfix only).
For damage/upgrades, I was planning to overhaul the system to force damage to be applied to upgrades. No more damaging an intrinsic stat of the ship.
Lots of repairability bugs stem from the chaos that is undoing damage. It's tough. It's error prone. If damage is applied to the upgrade (as a whole), we can track damage by upgrade, and reconstruct stats by applying damaged values on top of the pristine ship's base stats.
So, many ship stats that are currently inline would have to be extracted into an upgrade to make them damageable. Like thrust values, for instance.
That's tricky, since no single upgrade could work for many ships, and having per-ship thruster "upgrades" would be a maintenance nightmare, so I'll probably rework the way modifier upgrades work. Biggest issue is with the price of those upgrades. It would be nonsense for an "armor" upgrade of a Clydesdale to cost the same as for an Entourage (yeah, just an example). I'd probably come up with various multiplier types, like "mass*3" relating to mass, or "volume*3", something like that. So individual columns would specify being a multiplier (base*3, for instance, would be 3 times the ship's base stats), instead of the hackish "mult_" or "add_" prefixes.
In-engine, upgrades would simply be a few vectors of numbers specifying how to alter those specs, and a vector of damage factors for each upgrade, which would make re-computing the stats a speedy matter, so it can be efficient when applying damage.
For damage/upgrades, I was planning to overhaul the system to force damage to be applied to upgrades. No more damaging an intrinsic stat of the ship.
Lots of repairability bugs stem from the chaos that is undoing damage. It's tough. It's error prone. If damage is applied to the upgrade (as a whole), we can track damage by upgrade, and reconstruct stats by applying damaged values on top of the pristine ship's base stats.
So, many ship stats that are currently inline would have to be extracted into an upgrade to make them damageable. Like thrust values, for instance.
That's tricky, since no single upgrade could work for many ships, and having per-ship thruster "upgrades" would be a maintenance nightmare, so I'll probably rework the way modifier upgrades work. Biggest issue is with the price of those upgrades. It would be nonsense for an "armor" upgrade of a Clydesdale to cost the same as for an Entourage (yeah, just an example). I'd probably come up with various multiplier types, like "mass*3" relating to mass, or "volume*3", something like that. So individual columns would specify being a multiplier (base*3, for instance, would be 3 times the ship's base stats), instead of the hackish "mult_" or "add_" prefixes.
In-engine, upgrades would simply be a few vectors of numbers specifying how to alter those specs, and a vector of damage factors for each upgrade, which would make re-computing the stats a speedy matter, so it can be efficient when applying damage.
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: 0.6 plans
Why not to do it the way other stuff works: divide into generic types. Not panacea, but easily wraps them by an order of magnitude and then some. Especially, seeing how VS itself doesn't need to follow pre-existing stats, so the difference between 7500 and 8500 is no big deal, and if really necessary, it can be compensated by other values anyway.klauss wrote:That's tricky, since no single upgrade could work for many ships, and having per-ship thruster "upgrades" would be a maintenance nightmare
"Two Eyes Good, Eleven Eyes Better." -Michele Carter