Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Robin Varley on September 10, 2003, 07:07:40 pm
-
Well, it's been a helluva long time since I posted here, but that's what you get when you don't have your own internet connection, anyhow, I saw that someone else (argv[-1]) was brave enough to post on what things he'd done to the source code, so I thought I'd see if you might like any of the stuff I've done. I can't promise anything earth-shattering, but some of it's quite cool, I think...
These four are all optional, in that to get them to have any effect you have alter the .tbls
Nebula Draw Distance
I don't how useful this would be as the Code Gods might redo the nebula code entirely, but basically what this does is add a box into the backgrounds window in Fred2, what ever number you put in the box multiplies the default draw distances, awacs ranges and weapons range modifiers. So if you put in a 2, the maximum distance you can see a fighter at would be the default (500m) x 2, so 1000m and you can use numbers between 0 and 1 to get even thicker nebula.
Beam Attenuation
This the thing Bobboau did, but is currently disabled in the source, I'm guessing it's been taken out until he figures a way of getting fighter beams to return a distance from the shooter to the impact point. The actual range section he did, which draws out the beam to how far you specify and adds a nice fade to black at the end, works brilliantly. Since I don’t use fighter beams and wasn't bothered about 'em attenuating, I slapped an if statement round it saying 'don't attenuate fighter beams'. Anyway, for those who don’t know what Bobboau's beam attenuation did, how it works is that you specify a range ( this is how far the beam draws to ), and an attenuation distance, if the
impact point is beyond the attenuation value, the damage done is scaled depending on far beyond the attenuation distance it is, at the max draw range the beam does zero damage. I did change this bit so it scales the damage according to:
1 / square root of ( the distance to the impact point/the attenuation value in the tbl )
so if I set my attenuation value to 1000, when a beam hits a target 4km away it does half damage - why did I do this?, err I don’t really know, but seemed a good idea at the time...moving swiftly on.
Tougher Bombs
Probably the simplest thing I did, you can now put 2 optional lines for a weapon entry, they are Bomb Hit points and Bomb radius multiplier, they are ignored if the weapon isn't a bomb, and if you don’t put either of them in, they default ( 50 hit points and x2 radius). So you can now make tough bombs the size of cruisers - and no, I don't have any clue on how to put shields on em, and if you want fancy evasion code, well I make them swarm weapons of 1 or corkscrew missiles of 1, seems to work.
Interceptor Weapons
The Babylon 5 project should love this. You've got 2 new flags, Interceptor and Shootable, any weapon with the Shootable flag can be targeted and shot at by an Interceptor flagged weapon, the only thing you can't do is beams, though I think with a bit of jigger pokery, it should be possible to make beam act as interceptors. At the moment I'm thinking of adding something in so you can say in the tables whether or not the interceptor shoots at fighters and such. To make them have a chance of shooting down fast moving missile and lasers interceptors are also about x4 more accurate.
The next 2 are 'always on' although first one could easily be made optional
Damage Scaling
In normal freespace 2, the damage a weapon does against a ship can be modified on what the target is, e.g. you can't damage 'big damage' ships below 10% hull unless the weapon is a bomb, what I wanted was more control over thing like this. So stealing heavily from D&D, we have Damage Resistance and Damage Ignore.
Resistance is a number between 0 and 1, it multiplies the normal damage done to the target by its value, it's sort back to front, a resistance of 1 ( the default if you don’t specify it ) does the same as normal damage, whereas a resistance of 0.01 does only 1% of normal damage to the target.
Ignore is any positive number, it gets subtracted of the normal damage ( no you cant do negative damage - though it might be cool, a sort of repair gun ), so shooting an HL-7 at a target with
damage ignore of 50, isn't going to harm it
To add some more control we have a before value, a middle value and an after value( this isn't as confusing as it sounds), the middle value is the current hull percentage, when a ships damaged and the hull is above the middle value, we use the before value, if the hull is below the middle we use the after value. I then extended this to cover shields and subsystems, so in theory a ship could have Ignore and Resistance values for bother shields, hull and subsystems, the middle values for
shields being the shield % and the middle for subsystems being the % strength of the subsystem hit.
Another thing to mention is, that because of where this gets called in the code, beam weapon damage can be modified to, before, beams always did full damage to any target, irrespective of whether it was a supercap, had an armour modifier of 0 and so on.
To counter this you can add to any weapon, anti-resistance or anti-ignore values for shield, hull and subsystem, in the case of anti-resistance it gets added onto the resistance value of the target and anti-ignore, subtracted off the ignore value of the target. So when that ship with the 0.01 hull resistance gets hit by a beam with an anti-hull resistance value of 0.9, it'll do 91% of it's normal damage to the ship. And there's obviously checks here to stop silly things like negative damage.
Note that hits doesn’t interfere with any of the original flags used for targeting purposes like 'huge' 'bomb' etc. But currently things like big damage and supercap don’t get a look-in when working out the damage.
Targeting Changes
Whilst looking through the code doing the Damage Scaling, I found the bits Unknown Player and Bobboau did with AI primary weapon selection, I basically upgraded this so it takes into account the ranges of the weapons and the number of gun points the primary bank has, I also added in bits to take account of my Damage scaling stuff, whether the weapon was good for defence missions, like the morning star with its ability to push away bombers and so on - it's pretty complicated but it does
work well, giving the AI some more I. I then went and put it in for the AI secondary weapon selection as well, and included stuff such as whether it was a swarm or spawning weapon as well.
And then I went and made it so it included many of these factors when the AI is deciding whether to link its primary weapons.
Another targeting change I put in was for turrets, I made it so that they don’t bother firing at ships which have started to explode, it always annoyed me when one of your ships wastes a shot of it's ultra mega death beam on an exploding cruiser.
I also changed it so turrets discount objects outside their weapon range, and made damn sure they won't shoot at bombs/fighters/bombers if the weapon has the 'huge' flag. The not discounting targets outside weapon range problem is really obvious when you make a long range big-assed bomb and fire it
at big ship, all the turrets facing the bomb lockup and do bugger all until the bomb comes into range, and 'cos of the huge beams firing at bombs bug, this included its main beam cannon. ( I think that the huge beam bomb bug was fixed by Phreak as well)
When was doing all of this stuff I came across a couple of bugs/weird things I fixed.
The first one only affected ships with 3 primary banks, the only standard FS2 one is the Seraphim, basically a piece of code to do with cycling through weapon banks meant it couldn't use its third primary bank, fixed this so now it can use all 3 and link all 3 if it wants, its also written so it take into account ships that have, say 5 primary banks or more - though I don’t know if that's actually supported yet.
The other bug was with how remote detonate/ spawn weapons are used - I discovered this when making the big-assed bomb mentioned above, it'd only fire at targets 1500m away, what I found is that it was assuming all spawn weapons were going to be like the piranha or synaptic, basically very short-ranged defensive weapons that only fire if there are a certain number of enemies within 1500m of the ship/turret, since I wanted a long range cluster bomb, it got changed so that remote detonate
weapons are used as spawn weapons were used before, leaving spawn weapons to be used as they were intended, monstrous weapons of major ass kicking.
Well, this isn't all that I've done, but the rest of it is mainly raising limits etc, if the Source Code Project wants any of the above stuff, just ask. I also have to say big congratulations to the Source Coders, cos what you've done is bloody amazing.
Robin.
-
my atenuated beams arn't working?! they should be
AI stuff sound great, and I know some people that will wet themselves with the Interceptors
-
People are going to LOVE you for the AI updates! :) Excellent work there!
Flipside :D
-
I think that the new damage scaling method is actually quite good and makes a lot of sense. It also accounts for a lot of ideas about how it should work. If this could be made an optional thing, it rather neat.
-
Originally posted by Robin Varley
The first one only affected ships with 3 primary banks, the only standard FS2 one is the Seraphim, basically a piece of code to do with cycling through weapon banks meant it couldn't use its third primary bank, fixed this so now it can use all 3 and link all 3 if it wants, its also written so it take into account ships that have, say 5 primary banks or more - though I don’t know if that's actually supported yet.
How recent is the code you're using? Because I think I addressed this a while ago.
-
join us Robin Varley :D
-
Originally posted by ChronoReverse
I think that the new damage scaling method is actually quite good and makes a lot of sense. It also accounts for a lot of ideas about how it should work. If this could be made an optional thing, it rather neat.
Actually I've been suggesting a system like that for almost 4 weeks. The only difference was that I used the Fallout system with treshold and resistance, but it's almost the same.
I'm all in favor of your changes Robin Varley!
I have but one suggestion: change anti-resistance to piercing or penetration. It's only a cosmetic change, but I think it gives a better explanation for everday FREDers and MODers about what it does.
I also think that the resistance/ignore could be calculated from the actual hull percentage.
You declare a maximum and a minimum factor.
The simpliest solution would be:
res/ign=min+hull%*((max+min)/100)
This setup is ugly but it gives an idea of the scaling. The system could be further refined if it used hit points from the ships.tbl instead the hull.
The hardcore simulation fans would demand some sort of gradual scaling instead this linear (some uber mucho maths). IMHO this linear setup would be good.
BTW I still believe your setup is very good, I just thought that the actual values could be floated between the criterias.
About the tageting changes::yes: :yes: :yes: :yes: !!!!
-
Originally posted by Robin Varley
Nebula Draw Distance
I don't how useful this would be as the Code Gods might redo the nebula code entirely, but basically what this does is add a box into the backgrounds window in Fred2, what ever number you put in the box multiplies the default draw distances, awacs ranges and weapons range modifiers. So if you put in a 2, the maximum distance you can see a fighter at would be the default (500m) x 2, so 1000m and you can use numbers between 0 and 1 to get even thicker nebula.
So, hypothetically, could this be used to eliminate the nebula entirely (or give the illusion of complete elimination) in a large area of the playing field?
Coz that would be awesome.
-
This all sounds amazing...and INTECEPTOR weapons....awesome! :)
-
Dude, stick around.... looks like you'll be really useful to the team here :nod:
-
:yes:
-
I have a grand idea (I'm no coder:( so it's an idea alone)!
Can the nebula thikness be changed in mission?
If yes we could solve a few localized nebula issues.
The nebula should have a center or a couple of center points.
You check the distance and the line of sight of the pilot.
When he's closer and/or looking at denzer parts of the nebula the value is incresed.
The only remaining problem with localized nebulas is exiting them, then looking back.
We could have a pof to determine the shape, then use its subobject for calculating the distance. When looking back you can see its texture, ergo the cloud from outside.
A 1 sided (transparent?) texture would solve the inside problem.
Once inside the method above could be used.
It's not the best, but I have a gut feeling it could work.
-
sorry, i didn't understand the bomb radius thing, though the hitpoint stuff is :yes:
-
contact Inquisitor for CVS acces,
NOW!
that stuff is way to good to be wasted.
-
Will this go in FS2_Opnen 3.6.0?
With _argv[-1] stuff and all the modifications the SCP people has done, it will be one awensome package!!!;7
-
Originally posted by Bobboau
my atenuated beams arn't working?! they should be
They are. I played last night and saw some attenuated beam hitting an Aeolus (I think) and ever so slightly damaging it (rather than blowing it away).
-
Originally posted by Robin Varley
Nebula Draw Distance
I don't how useful this would be as the Code Gods might redo the nebula code entirely, but basically what this does is add a box into the backgrounds window in Fred2, what ever number you put in the box multiplies the default draw distances, awacs ranges and weapons range modifiers. So if you put in a 2, the maximum distance you can see a fighter at would be the default (500m) x 2, so 1000m and you can use numbers between 0 and 1 to get even thicker nebula.
:cool:
Beam Attenuation
This the thing Bobboau did, but is currently disabled in the source, I'm guessing it's been taken out until he figures a way of getting fighter beams to return a distance from the shooter to the impact point. The actual range section he did, which draws out the beam to how far you specify and adds a nice fade to black at the end, works brilliantly. Since I don’t use fighter beams and wasn't bothered about 'em attenuating, I slapped an if statement round it saying 'don't attenuate fighter beams'. Anyway, for those who don’t know what Bobboau's beam attenuation did, how it works is that you specify a range ( this is how far the beam draws to ), and an attenuation distance, if the
impact point is beyond the attenuation value, the damage done is scaled depending on far beyond the attenuation distance it is, at the max draw range the beam does zero damage. I did change this bit so it scales the damage according to:
1 / square root of ( the distance to the impact point/the attenuation value in the tbl )
so if I set my attenuation value to 1000, when a beam hits a target 4km away it does half damage - why did I do this?, err I don’t really know, but seemed a good idea at the time...moving swiftly on.
It's already working. I know because I accidentally tested it last night. :lol:
Tougher Bombs
Probably the simplest thing I did, you can now put 2 optional lines for a weapon entry, they are Bomb Hit points and Bomb radius multiplier, they are ignored if the weapon isn't a bomb, and if you don’t put either of them in, they default ( 50 hit points and x2 radius). So you can now make tough bombs the size of cruisers - and no, I don't have any clue on how to put shields on em, and if you want fancy evasion code, well I make them swarm weapons of 1 or corkscrew missiles of 1, seems to work.
If you want a flying warhead, make a cruiser or something and set it to kamikaze. Having HP and radius on bombs is something I was wondering about in the back of my head. Good work.
Interceptor Weapons
The Babylon 5 project should love this. You've got 2 new flags, Interceptor and Shootable, any weapon with the Shootable flag can be targeted and shot at by an Interceptor flagged weapon, the only thing you can't do is beams, though I think with a bit of jigger pokery, it should be possible to make beam act as interceptors. At the moment I'm thinking of adding something in so you can say in the tables whether or not the interceptor shoots at fighters and such. To make them have a chance of shooting down fast moving missile and lasers interceptors are also about x4 more accurate.
Anti-fighter beams and small laser turrets already shoot at bombs. Maybe you could hack this code into your interceptor code to enable beams to shoot at Shootable weapons.
The next 2 are 'always on' although first one could easily be made optional
You'd better make damage scaling optional. Otherwise it'll break backwards combatability. :doubt:
Damage Scaling
In normal freespace 2, the damage a weapon does against a ship can be modified on what the target is, e.g. you can't damage 'big damage' ships below 10% hull unless the weapon is a bomb, what I wanted was more control over thing like this. So stealing heavily from D&D, we have Damage Resistance and Damage Ignore.
Resistance is a number between 0 and 1, it multiplies the normal damage done to the target by its value, it's sort back to front, a resistance of 1 ( the default if you don’t specify it ) does the same as normal damage, whereas a resistance of 0.01 does only 1% of normal damage to the target.
Ignore is any positive number, it gets subtracted of the normal damage ( no you cant do negative damage - though it might be cool, a sort of repair gun ), so shooting an HL-7 at a target with
damage ignore of 50, isn't going to harm it
To add some more control we have a before value, a middle value and an after value( this isn't as confusing as it sounds), the middle value is the current hull percentage, when a ships damaged and the hull is above the middle value, we use the before value, if the hull is below the middle we use the after value. I then extended this to cover shields and subsystems, so in theory a ship could have Ignore and Resistance values for bother shields, hull and subsystems, the middle values for
shields being the shield % and the middle for subsystems being the % strength of the subsystem hit.
Badass™
Another thing to mention is, that because of where this gets called in the code, beam weapon damage can be modified to, before, beams always did full damage to any target, irrespective of whether it was a supercap, had an armour modifier of 0 and so on.
I already fixed this -- beams without HURTS_BIG_SHIPS can't hurt big damage ships. Of course, that fix needs to be adapted to your new damage code.
To counter this you can add to any weapon, anti-resistance or anti-ignore values for shield, hull and subsystem, in the case of anti-resistance it gets added onto the resistance value of the target and anti-ignore, subtracted off the ignore value of the target. So when that ship with the 0.01 hull resistance gets hit by a beam with an anti-hull resistance value of 0.9, it'll do 91% of it's normal damage to the ship. And there's obviously checks here to stop silly things like negative damage.
Note that hits doesn’t interfere with any of the original flags used for targeting purposes like 'huge' 'bomb' etc. But currently things like big damage and supercap don’t get a look-in when working out the damage.
So, 'huge' and 'bomb' and whatnot only affect targeting now? If so, then the 'big ship' weapon flag now does nothing, since it only meant it hurts big ships (yes, I checked this, it doesn't affect which ships can equip it).
Targeting Changes
Whilst looking through the code doing the Damage Scaling, I found the bits Unknown Player and Bobboau did with AI primary weapon selection, I basically upgraded this so it takes into account the ranges of the weapons and the number of gun points the primary bank has, I also added in bits to take account of my Damage scaling stuff, whether the weapon was good for defence missions, like the morning star with its ability to push away bombers and so on - it's pretty complicated but it does
work well, giving the AI some more I. I then went and put it in for the AI secondary weapon selection as well, and included stuff such as whether it was a swarm or spawning weapon as well.
And then I went and made it so it included many of these factors when the AI is deciding whether to link its primary weapons.
Good! Now the stupid Shivs won't be firing their beams (I made the Shivan weapons beams) at me from way outside their range.
Another targeting change I put in was for turrets, I made it so that they don’t bother firing at ships which have started to explode, it always annoyed me when one of your ships wastes a shot of it's ultra mega death beam on an exploding cruiser.
I did this too. You might have some conflicts when you try to do 'cvs update' now...
I also changed it so turrets discount objects outside their weapon range, and made damn sure they won't shoot at bombs/fighters/bombers if the weapon has the 'huge' flag.
They didn't before, but I guess it can't hurt to be sure...
The not discounting targets outside weapon range problem is really obvious when you make a long range big-assed bomb and fire it
at big ship, all the turrets facing the bomb lockup and do bugger all until the bomb comes into range, and 'cos of the huge beams firing at bombs bug, this included its main beam cannon. ( I think that the huge beam bomb bug was fixed by Phreak as well)
Strange. I never saw this kind of bug show up. Maybe you created it accidentally?
When was doing all of this stuff I came across a couple of bugs/weird things I fixed.
The first one only affected ships with 3 primary banks, the only standard FS2 one is the Seraphim, basically a piece of code to do with cycling through weapon banks meant it couldn't use its third primary bank, fixed this so now it can use all 3 and link all 3 if it wants, its also written so it take into account ships that have, say 5 primary banks or more - though I don’t know if that's actually supported yet.
Good. This isn't something I would have noticed.
The other bug was with how remote detonate/ spawn weapons are used - I discovered this when making the big-assed bomb mentioned above, it'd only fire at targets 1500m away, what I found is that it was assuming all spawn weapons were going to be like the piranha or synaptic, basically very short-ranged defensive weapons that only fire if there are a certain number of enemies within 1500m of the ship/turret, since I wanted a long range cluster bomb, it got changed so that remote detonate
weapons are used as spawn weapons were used before, leaving spawn weapons to be used as they were intended, monstrous weapons of major ass kicking.
:yes:
Well, this isn't all that I've done, but the rest of it is mainly raising limits etc, if the Source Code Project wants any of the above stuff, just ask.
Again, be sure this stuff doesn't conflict with what I just committed. I've done a few such things too.
-
Looks like the two new Source Titans (tm) are starting to get accounted.
I wonder how this one turns out...
BTW
[spam] SPAM! SPAM! LOVELY SPAM![/spam]
_argv[-1] I think Robin's system is better, since it doesn't deal with flags instead it lets you customise each ship giving them their own apropiate strenghs and weaknesses.
BTW Robin what's your view on the linear scaling I mentioned earlier?
-
Well I'm glad people like what I've done :D .
Bobboau, your beam attenuation works, fine, although currently the bit which actually multiplies the damage by the attenuation coefficient is commented out in the code - looks like this:
return Weapon_info[b->weapon_info_index].damage /* aten*/;
And there's a note in the headers saying:
"disabled attenuation for beams, pending rework"
Anyway I wanted to try it out, so I uncommented the aten, bit, and it seems to be perfectly ok, its just that fighter beams wont return a distance from beam source to impact point, so they don’t attenuate.
Goober5000, I'm using the latest code, and I know which bit of code you mean, thing that was screwing up selecting the third primary bank was this little bad boy:
bank_to_fire = (swp->current_primary_bank+i)%2;
This stopped the ship ever selecting bank 3 or higher, the code appears in ship.cpp, in both ship_fire_primary and ship_stop_fire_primary, I got rid of the %2 and got it to use the number of banks that the ship actually has.
Flaser, sounds like a good idea, in fact it could be easily made so you could use either yours or my system, as yours doesn't use my middle value, what I could do, is say that if the middle value is
set to -1, use your way instead, pretty cool.
I'm afraid my Mad Code Skillz, aren't up to the task of doing quite what you suggested about nebulas. It might be worth mentioning for those who don’t know how the nebula thing works is that at the moment, the nebula is drawn from the location of the player, or where you are looking from, and the
nebula isn’t really a 'physical object'. it did get me thinking though, that it could be possible to have my draw distance modifier changed altered by Sexp's in mission but if you base the draw distance on where you currently are weird things happen, I'll try and show what I mean - my ASCII art 'aint up to much,
V <--- ok this v is player, at the draw distance for where they are is say 10x the amount, so you can see a fighter 5000m away
X <--- this a waypoint, when the player is within say 1500 m, the draw distance is the default one lets say the players 3000m away from it
B <--- this is a baddie, 500m beyond the waypoint and 3500m away from the player
Now, due to the draw distance of where the player is, the player can see the baddie, if the player goes to the external view of the baddie, the view distance will still be 10x amount. But when the
player flies within 1500m of the waypoint, the view distance gets banged down to the default level (we'll ignore the fact that this happens with no scaling), say the baddie flies over 1500m from the waypoint, and the player can still target it, when you go to the external view of the baddie, you'll have the default nebula view distance. Anyway what I'm trying to say is that unless you make the nebula draw distance based on where the 'camera' is, you'll get that problem, and anyway, it over-shadowed by the fact that to start with player can see the baddie, even though it's supposedly in dense fog. The only thing I think you could do, is make the draw distance alter over a time rather than location, with scaling this might suggest a 'windy' nebula, hell they have storms at the moment...
Basically, to do fancy localised fog in a nebula, let alone be able to exit one, the nebula section would need to totally re-writing, something I could hope to do, but looking at some the other posts on the forum, might be possible in the future, for those with fancy DX9 graphics cards anyway , I think ( I still wish I hadn't bought my, admittedly very good, GeForce 4 Ti1200 only 3 months before those new spangled FX cards out, doh!).
miniDwarf, the bomb radius is multiplier value, in normal FS2 all Bombs have their size multiplied by 2, this is to make 'em easier for turrets and things to shoot down, what I changed was make it so you can choose what multiplier to use, so if you put 1, it uses only the size of the actual model. I did it because when you have very large bombs it was blatantly obvious that although your shots hit the bomb, you hadn't aimed anywhere near it.
argV[-1], the problem with firing a long range bomb at a target and its turrets doing nothing until it's destroyed is in 'vanilla' FS2, I have to say that it does also depend on how much damage the
bomb is going to do, if it's only low damage the turrets will go on to another target, because that bomb isn't going to go to the top of the priority incoming bombs list, but say the bomb does like
20000 damage, then you notice it.
And yeah, I was going to make the damage scaling optional.
Anyway, what I'm going to do is get a fresh copy of the source off CVS, and then put my stuff into it, then I'll check it all to make sure it still works fine, which it should, I hope. Then I'll see about getting it added in.
Some things in the code I want to look at in future are, fighter beams, at the moment damage is applied every frame, not over time, although this way is ok, it seemed to make it take longer to
destroy an enemy on my lower spec computer 'cos the framerate is lower. The other thing I want to try and do is put in an addition to make weapons explode when any enemy comes within a user specified distance, when only the weapons target comes within a distance, and make it so that you can specify a 'cone' into which spawn weapons spawn their submunitions. Whether I can do any of them, is a different matter...on a final note, what happened to the tbl options that were going to allow you to create a shotgun like effect with primaries? I couldn't find it in the source when I looked.
Robin
Edit - damn TAB key posted the bloody thing before I'd spaced it out properly, arrgh!
-
I know the nebula is only an effect and has no actual pof assigned to it or whatever.
What I ment was to create a null-object that would determine the way the effects managed to give the illusion of actually going through thicker or softer gas.
BTW I think that there's a mathematical formula to compute the "blaket curce" for 3 or more stats on a scale so there could be numerous ways to control the resistance/treshold of a ships armor.
sidenote: I'm no coder, and would only like to start learning C, though I do have programming experience (except for modern graphic methods - I'm copletly clueless how to actually code them).
-
I think the problem is that the [V] nebula was never designed to be seen from the outside. If I read the ASCII art right, it just doesn't work that way, you end up being able to see things that are miles away whilst bumping into your wingmen almost.
I still think particle emitters and volumetric fog are the way to go, but I'm pretty sure that V-Fog is only supported by DX9 cards. And I'd also hazard a guess that we can completely forget about something like that until HT&L is more implemented.
-
Actually, V-Fog can be done just fine by DX8-class cards. And for some reason the M$ V-Fog example isn't working on my Radeon 9800 Pro. Excersice to self: fix it.
-
Interceptor Weapons
The Babylon 5 project should love this.
You bet.
Has anyone tested this yet? There was talk about performance hits etc. and having so many targets to track, seen any bugs? I suspect there can be some, just like having too many asteroids in mission makes some ships let weapon shots through them as the collision detection system got too much work.
At the moment I'm thinking of adding something in so you can say in the tables whether or not the interceptor shoots at fighters and such. To make them have a chance of shooting down fast moving missile and lasers interceptors are also about x4 more accurate.
Interceptors shoot at fighters etc, that is, work in offensive roles as well as in defensive - just like in the show. There's probably some need for AI stuff, so that a ship attacking aggressively doesn't bother intercepting incoming shots and uses it's interceptors for offence as well. Normally incoming shots should be prioritized over fighters in targeting.
-
Originally posted by Flaser
_argv[-1] I think Robin's system is better, since it doesn't deal with flags instead it lets you customise each ship giving them their own apropiate strenghs and weaknesses.
Pardon? Which of my flags do you not like?
-
Originally posted by _argv[-1]
Pardon? Which of my flags do you not like?
Your flags are great and fine.
It's the flag system based ship distinction that I don't like from the begining.
-
Hmmmm, some good ideas here for my Quantum Reality game engine. I'm impressed with the Beam attenutation, but I thought the idea of Beam Cannons is that the energy doesn't attenuate that much...
-
it was mostly for fighter beams, but think about it even for capships, if you've got a ship that is 40,000 meters away you're not going to have the same punch as if it was 4 meters away, also there is (or there was last time I looked at it, phreak disabled the damage attenuation about a month ago for some reason) code that sets the end of the beam as being dark so it seems to fade, but it takes into acount the length of the beam so when it hits something the beam won't sudenly get dim
-
And the best part is that this is a good way to set a beam range. It's better than having the beam extend to infinity or disappear suddenly. Speaking of which, is it possible to do something like this for primaries, other than it'll slow things down since the bolts go further and last longer?
-
Originally posted by Flaser
It's the flag system based ship distinction that I don't like from the begining.
What's wrong with it? What would be better?