Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: _argv[-1] on January 17, 2005, 03:29:14 am
-
Diff (http://aoi.dyndns.org/~alex/fs2_open/surfshld/fs2_open_surfshld.diff), release build (http://aoi.dyndns.org/~alex/fs2_open/surfshld/fs2_open_r_surfshld.zip), debug build (http://aoi.dyndns.org/~alex/fs2_open/surfshld/fs2_open_d_surfshld.zip), test mod (http://aoi.dyndns.org/~alex/fs2_open/surfshld/fs2_open_surfshld_testmod.zip).
This is a reimplementation of the old "surface shields" feature I wrote back in the day. This code is not currently in the CVS repository. This allows a ship without a shield mesh to have a shield. Shots that strike the hull of a surface-shielded ship will simply disappear and do damage to its shields rather than the hull, as though they struck a shield mesh instead of the hull.
Note that there is no graphical impact effect for surface shields. Some types of shots (laserish weapons, like the Subach HL-7) will simply disappear when striking a surface shield, while others (missiles, beams) will make an explosion effect.
This patch also gives an implicit surface shield to ships with a normal shield (i.e. the kind with a shield mesh). This is to work around a very mysterious bug in which shots will sometimes pass right through the shield mesh when they shouldn't (because the shield is up and should have absorbed it). Shots that pass through the shield mesh like this will strike the surface shield instead of damaging the hull (unless the shield is depleted, obviously).
The implicit surface shield could conceivably pose a compatibility issue because this means you can't fly through a shield mesh and fire at a ship's hull from inside its own shield. Your shots will then strike the implicit surface shield instead of its hull. In order for this to matter, you would have to have a shield mesh big enough that you can fit a fighter inside of it. As far as I know, nobody has ever done this. For this reason, I do not believe this is a problem. If the purity police demand it, though, the implicit surface shield can be removed.
To test surface shields, load up the included test mod in one of the test builds. In the tech room mission simulator, run the single mission "Surface Shield Test". You'll be put in a Bakha (because I like Bakhas :D) with four different ships that will just sit still. They are a Cain (modified to have a surface shield), a Rakshasa (with no shield), a Seraphim (with a normal shield), and a Mjolnir (which is specified to have shields in the table but has no shield mesh -- a :v: oversight that causes it to have no shield in the retail game, and it does not have a surface shield only because the "surface shields" flag is not present in ships.tbl). Use the change primary weapon type cheat (type "www.freespace2.com" while in game to enable cheats, then hit 0 while holding down ~ repeatedly to change your primary weapon) to change your primary to SRed, which I've changed to be relatively weak and not shield-piercing. You can use it to test how the surface shields work with non-shield-piercing beams. Beams that do pierce shields, like LRed, are not affected by surface shields at all, and you can test them this way too.
Please post comments. If everyone approves, I will commit this to CVS.
Added to the website.//redmenace
-
Cool, just what we needed!:yes:
-
if you've got everything other than rendering sorted out I could probly get that working.
-
Awesome :) If this gets CVSed, TI will be making use of it - it works exactly how we described Aesir shield tech. :yes:
-
This will be optional feature, right?
Since TBP fighters do use shields but without shield mesh, only to protect against shockwaves and explosions.
-
Just replace the shield hit sound and anim with an empty file.
-
Originally posted by Mr. Fury
This will be optional feature, right?
Since TBP fighters do use shields but without shield mesh, only to protect against shockwaves and explosions.
Yes. Use ships.tbl flag "surface shields" to enable, otherwise uses normal behavior, which is a bit quirky, but whatever hacks you come up with will still work, with the exception that you cannot fly inside a ship's shield mesh and hit its hull from under its shields.
Is this okay? Should I commit it?
-
Yeah, please commit it. WCS is in dire need of it, and it wouldn't hurt TBP either as far as I see.
-
It's AWESOME, i could include my X wing model without assigning shield into the model :D
-
Surface shields have been committed to CVS.
-
hey could you do me a favor, make a stub function called add_surface_shield_hit(ship* shipp, vector *position, matrix*orientation, float radius, int life) and call it with the apropriate data when ever your system is used, I'll build a rendering system next time I update my code, unless someone beats me to it
and for everyone else, is it ok if the texture is defined on a per ship basis as a static bitmap (ie not an ani but a single texture that fades out)? it will make things _vastly_ easier and faster to the point that I don't think it's realy it
-
Okay, looking at the code I have...
Basically the function you're asking for would be something like add_shield_point but for surface shields.
I can give you a ship *. Straightforward.
The position and orientation will come out of an mc_info struct, as is the case for add_shield_point. Is that okay?
I don't know what to give you for radius and life. add_shield_point has no such thing. What should I do here?
-
add something to the weapon table entry or use some procedural code (like the head radius)
-
wasn't someone asking for a way to simulate the grav wells in the New Jedi Order books? this may very well be a viable solution.
-
Originally posted by Bobboau
add something to the weapon table entry or use some procedural code (like the head radius)
The head radius is only present on laser-like weapons. Other weapons will not necessarily have surface shield specific parameters in the table. Then what do we use?
Unless I'm mistaken, normal shields use a hit effect with a fixed life and radius. Is there some reason we can't do the same thing for a surface shield hit effect?
-
is there a way to make the decal render slightly off the hull so that it looks like its hitting an imaginary forcefield.
-
yeah, well I want to do this new system diferently
-
Okay, then, but we still have a compatibility issue. What do we do when no radius / life parameters are given in the table?
And are you sure it's okay that surface shield hit effects will look so different from normal shield hit effects?
-
yeah
well... ok for missles use the models radius
model_get(a_wepon_pointer->modelnum_or_whatever_the_variable_was)->rad
make a default life of /*pulls number out of ass*/ 1100 (ms)
this is basicly a totaly new effect so it can be done however I/you/we like. and for the problem with going under another ship's sheild if youu are looking for a way to get around this simply do a check to see if the polymodels sheild mesh has any triangles if it does then don't use surface shields
-
Actually it's set to give surface shields to all ships that either specify it in the table or do have a shield mesh, in order to fix the mysterious bug I described above. So if somebody yells about this, I can just change it so that it won't give a surface shield to ships just because they have a shield mesh.
-
I think the "mysterious bug" is caused by the shield mesh not having enough polies, or something. I'd rather restrict it to only ships that have the ship flag, as a matter of principle.
What ship did you notice this bug on?
-
All of them, I think. Just fly any mission for a while, and you and AI ships will take hull damage every now and then without the shield being down. It happens seemingly randomly but fairly frequently. This shouldn't happen. The implicit surface shield fixes this problem.
I personally consider this a really big issue, so if you want the implicit surface shield to not be there, I would appreciate it being figured out for real. The implicit surface shield is just a hackish workaround. When I coded this, I felt that the potential compatibility issue was acceptably minor given the severity of the problem it solves.
-
Um... I've never ever had this problem. :wtf: You sure it's not something with your codebase or your computer?
-
every now and then the sheild colision detection will miss a hit, and the underlying hull colision check will catch it, it happens more commonly with realy realy fast weapons, or realy tight meshes.
you could just not add a hit effect if there is a sheild mesh,
though, actualy, do you think you could allow for a seperate sheild system that goes along the hull so you can have bubble sheilds _and_ surface sheilds? (this being a seperate resivior, or the main one)
-
Well, there are plenty of fast weapons in the FS2 universe (e.g. Maxim). If it's prevalent as you say, then it would break balance. So that settles it... no surface shields unless the flag is added.
-
Please find a way to implement that. WCS really needs that feature.
A question: Would surface shields only cover the main body or turrets as well? There should be a way to exclude turrets from being shielded.
-
Originally posted by Bobboau
every now and then the sheild colision detection will miss a hit, and the underlying hull colision check will catch it, it happens more commonly with realy realy fast weapons, or realy tight meshes.
you could just not add a hit effect if there is a sheild mesh,
Um, I've seen it happen with the Subach HL-7 and its ilk, and probably even Terran Turret and the like. I've also seen it happen with probably every ship. It's happened in retail FS2, stock fs2_open since day one, etc. The only time I've ever seen it not happen is after I added surface shields.
Here's something you might want to try to demonstrate the bug. I haven't tried this myself, but in theory, it'll work. Change the table so that some ship you fly has some absurdly strong shield that nobody will ever manage to penetrate (e.g. $Shields: 100000 or something). Then fly a mission (in a version without the surface shield code I just committed). Nobody ever even scratches your shield, but you'll probably still take hull damage occasionally, and not from collisions or beams or anything else that normally goes through shields. That's the bug. I still contend that this really shouldn't happen.
though, actualy, do you think you could allow for a seperate sheild system that goes along the hull so you can have bubble sheilds _and_ surface sheilds? (this being a seperate resivior, or the main one)
The implicit surface shield that's there now is exactly that -- another layer of shielding under the shield mesh. Unless you want a separate HP count for surface shields?
Originally posted by Goober5000
Well, there are plenty of fast weapons in the FS2 universe (e.g. Maxim). If it's prevalent as you say, then it would break balance. So that settles it... no surface shields unless the flag is added.
:hopping:
It's a bug, Goober. Nobody expects it to happen, you didn't even know about it, and I'll be amazed if anyone relies on it, balance-wise.
Originally posted by Lynx
Please find a way to implement that. WCS really needs that feature.
Which feature?
A question: Would surface shields only cover the main body or turrets as well? There should be a way to exclude turrets from being shielded.
Covers turrets too. Excluding them sounds really hard.
-
id like a protection factor, the amount of damage the shield would absorb. that way i could have ships with partially effective shilds which only dampen enemy fire, but doesnt stop it copletely. i could use it on my pirate vessels, tbp could use it on ships like the whitestar and so on.
-
Originally posted by _argv[-1]
Which feature?
Uuuh, surface shields? That thing the whole thread is about?
-
Blech.
Adding surface shields, automatically, if a ship has a shield mesh is limiting modding opportunities - you can't fly under a shield and shoot a ship. No one's actually done this, AFAIK, but it will be impossible with surface shields.
If it's really a problem, I hate to say it, but 'command line flag'. It hasn't seemed like a bug to me, I figured it might have even been on purpose to simulate damage to the ship from sheer kinetic energy. The view DOES shake around when you get hit, you'd figure that over time things would rattle around a bit.
From what people are saying, a separate $Surface shield strength field sounds like a good idea. Bobboau's idea of an emergency shield, for example - this could be used by the SWConv to simulate backup Mon Cal shield generators.
One final thing, surface shields could also be a problem now that hangar bays are getting more popular...especially now that Goober hates us all. Any capship with shields would also have them in the hangar bay.
-
Originally posted by _argv[-1]
It's a bug, Goober. Nobody expects it to happen, you didn't even know about it, and I'll be amazed if anyone relies on it, balance-wise.
Okay, I didn't know about it. If it happens, fine, it happens. But if it occurs as often as you say, then it will make a significant difference in how any given battle turns out. Mission designers will expect a ship to take X amount of damage in Y amount of time. Surface shields will change this; hence they will break balance.
And breaking balance is a no-no. Need I remind you of the last time you broke the balance?
EDIT: And what WMC said, too. But it should stay as a ship flag, not a command-line flag.
-
Why don't you guys design a subsystem call function, looking for a subsystem flag in ship.tbl (which can only be found on ships, regardless of size or class) and follow this with creating a on-hit function.
For example:
On-hit initiated,
If projectile contacting shield does not have subsystem flag
{
Initiate a shield effect. <-- your flags effect this.
Continue on weapon effect function.
}
Else If contact on hull is desicovered without associating subsystem flag
{
Cordinate angle of hull contact.
Obtain mesh cordinates which are paralell to angle of hull contact.
Initiate a shield effect on mesh cordinates <-- your flags effect this
Redirect weapon effect function on mesh cordinates.
Continue on weapon effect function
}
Else
{
Ignore all action.
Continue on weapon effect function.
}
Also, this could be a merical in the feature. Here's why I believe this to be so.
You got an object which is allowed to go through the shields. Currently, this object is intersecting the shield mesh. Now, the shields are hit by something that isn't allowed. What happens to the program when it can't do anything about the object intersecting the shield mesh? Well, if there is only one function handling this, then I think you would call that a memory leak, which quickly turns into a logic error, which is followed by a very unhappy user.
Of corse, my knowledge of C++ is by far to small to be seen in the same room as you guys, so let me take my leave and hope for the best. Good luck folks. :lol:
-
sheilds failing every now and then doesn't seem too buggy, in fact I've always liked it, it made it seem more real as you wouldn't expect a sheild to be 100% effective all the time.
-
Originally posted by Bobboau
sheilds failing every now and then doesn't seem too buggy, in fact I've always liked it, it made it seem more real as you wouldn't expect a sheild to be 100% effective all the time.
I agree with you only on the condition that shield failure is a desirable thing. However, I would much rather code it as a flag with a % modifier then a convient bug. There are some instances of which I would not want the shields to fail, and a convient bug would prove to be unconvient at this time.
-
Originally posted by xenthorious
I agree with you only on the condition that shield failure is a desirable thing. However, I would much rather code it as a flag with a % modifier then a convient bug. There are some instances of which I would not want the shields to fail, and a convient bug would prove to be unconvient at this time.
Also, in support to any Star Wars Projects, ship flight speeds and projectile speeds will be very fast. From what I have read, this bug is far more frequent on fast projectiles then it is on slow ones. This could be a problem because it means any game made by a Star Wars Project will experience a very buggy design. I feel leaving this flaw as is, would cause an unfair advantage favoring projects, such as, TBP and WCS. No one should be left behind.
-
And I'm worried that fixing this flaw will throw off balance in old campaigns that were designed to rely on it. Not just for the player ships, but for enemy ships as well.
-
Originally posted by WMCoolmon
One final thing, surface shields could also be a problem now that hangar bays are getting more popular...especially now that Goober hates us all. Any capship with shields would also have them in the hangar bay.
I think there should be a way for submodels to make them uncovered by shields even if the ship has surface shields. I don't know about the other mods, but I'll make the hangarbays subobjects to take advantage of Bobb's detail box thingy.
-
2 Simple ideas:
Will it throw off balance? Let's test then debate.
If it does? So what. Make it optional - for projects a'la SWC - problem solved.
If it doesn't screw up anything else I don't see why another "sleeping" feature can't be added to the CVS.
My 2 cents.
-
1) It throws off balance.
2) It screws up the feature where you can fly underneath shields and shoot at ships.
So it should remain optional.
-
Originally posted by Goober5000
And I'm worried that fixing this flaw will throw off balance in old campaigns that were designed to rely on it. Not just for the player ships, but for enemy ships as well.
Assume you wanted to keep the flaw for the sake of simulating an environment of which supports the design of an old model. How can you achieve this while it is parallel toward resolving a bug subsequencially, and without monochromatic objectives?
Well, let us first review the current flaw. Infrequent moments (more frequently with increased projectile speed); the shields fail to preserve protection to an object (ship).
Assuming this is resolved, how could it be regenerated into an optional flag to preserve backwards compatibility?
shieldEffectiveness = Number of times shield has been effective.
shieldFailureCondition = Generated unknown value within known range using rand().
shieldFailure = rand( shieldEffectiveness % shieldFailureCondition) == 1 ? True : False;
Or in English, setup a conditional and optional flag allowing the generation of shield failures at random moments of impact from the projectile.
Also, you could later create a feature in the program which uses the shields as a partial absorption condition, absorbing 80% (or any percentage desired) of all damage caused by a projectile
Then use both flags combined to allow spontaneous shield absorption without making a ship completely protected from impact by a projectile.
-
Originally posted by xenthorious
Assume you wanted to keep the flaw for the sake of simulating an environment of which supports the design of an old model. How can you achieve this while it is parallel toward resolving a bug subsequencially, and without monochromatic objectives?
Well, let us first review the current flaw. Infrequent moments (more frequently with increased projectile speed); the shields fail to preserve protection to an object (ship).
Assuming this is resolved, how could it be regenerated into an optional flag to preserve backwards compatibility?
shieldEffectiveness = Number of times shield has been effective.
shieldFailureCondition = Generated unknown value within known range using rand().
shieldFailure = rand( shieldEffectiveness % shieldFailureCondition) == 1 ? True : False;
Or in English, setup a conditional and optional flag allowing the generation of shield failures at random moments of impact from the projectile.
Also, you could later create a feature in the program which uses the shields as a partial absorption condition, absorbing 80% (or any percentage desired) of all damage caused by a projectile
Then use both flags combined to allow spontaneous shield absorption without making a ship completely protected from impact by a projectile.
God, I feel like a dork with glasses; someone smack me! lmao
-
Enterprise & Hull Plating here we come.
-
*smacks xenthorious*
That's unnecessarily complicated. Tying it exclusively to a flag will solve all the problems.
Unless anyone else has anything to add, I think this thread has run its course.
-
Yes, make it a ships.tbl flag. Flying through the hangars of enemy capships and so circumventing their shields was a, well, not exactly MAJOR feature of WC3/4, but still not an unimportant one.
Originally posted by Goober5000
Um... I've never ever had this problem. :wtf: You sure it's not something with your codebase or your computer?
It surely isn't. I had it already with retail FS2.
Originally posted by Goober5000
I think the "mysterious bug" is caused by the shield mesh not having enough polies, or something. I'd rather restrict it to only ships that have the ship flag, as a matter of principle.
What ship did you notice this bug on?
Right. As far as I can tell it's something with the shieldmesh. Though I'd say it usually is when the distance hull-shieldmesh becomes too large.
I initally ran into this when I tried to give Shivan capships shields by importing them with DM modelview from FS1 freighters and scaling them up so they would fit the entire ship (this was several years ago). As the overall shape of the freighters usually wasn't quite the same then on the Shivan caps, the shield bubble sometimes extended VERY far away from the ships; the bug then hit on really large - the shíelds worked only if shot at from a 30°-arc in front, from everywhere else the shots would pass right through the shields. Also usually the game crashed after a while in missions where someone/-thing shot at those shields.
With the shieldpacks from Inferno's site as well as with the SSD Diablo such things never happened to me. So, as their shieldmeshs are rather close to the hull (in some cases actually even SMALLER than it), I'd say that the bug is caused the way I stated above.
Learning from this I also already created a beta shieldmesh for one of WCS' capships, and (except where it isn't complete) it worked perfectly.
I have a bit more of trouble solving this bug for fighters, though, and so I would like to be able to set surface shields in the tbl for those fighters that have major trouble with it.
*Greetings everyone*
-
Just out of curiousity, could it be happening when the shield mesh reaches outside the bounding box by a significant amount? Such that the shield never gets checked? The outer bounding box shouldn't be a problem, but what I'm guessing are the BSP bounding boxes come awefully close to the shield mesh, one way or another. The other obvious question is could the ship be getting checked before the shield for projectile collisions? This makes more sense if projectile speed is directly correlated to accidental penetration, since it'd be more likely to penetrate far enough in a frame to "collide" with both.
-
Originally posted by Lynx
Uuuh, surface shields? That thing the whole thread is about?
It's already there. It's in CVS. It's missing a rendering routine to make a fancy graphical effect. Bobboau will make one once I've gotten him what he needs for it.
Originally posted by WMCoolmon
Adding surface shields, automatically, if a ship has a shield mesh is limiting modding opportunities - you can't fly under a shield and shoot a ship. No one's actually done this, AFAIK, but it will be impossible with surface shields.
Forward compatibility is no problem. I was thinking about this. If we decide to keep the implicit surface shield, then I'll add a "no implicit surface shield" flag to the table. But this exposes any such ship to shots randomly piercing its shield, which is the bug I was trying to work around.
It hasn't seemed like a bug to me, I figured it might have even been on purpose to simulate damage to the ship from sheer kinetic energy. The view DOES shake around when you get hit, you'd figure that over time things would rattle around a bit.
It's still a bug. If that's what you want, then either have the shield absorb some % of damage, and/or have some % reliability factor (e.g. absorbs 90% of shots, 10% go through). This bug causes shots to go through the shield pseudo-randomly, which is not cool.
Originally posted by Goober5000
Okay, I didn't know about it. If it happens, fine, it happens. But if it occurs as often as you say, then it will make a significant difference in how any given battle turns out. Mission designers will expect a ship to take X amount of damage in Y amount of time. Surface shields will change this; hence they will break balance.
No, it will break undue player annoyance. Any mission designer that expects a ship to take X damage in Y time without using sexps to make it so is a fool because you can't rely on what the player or AI might do to deal or avoid taking damage. It wouldn't have worked in retail FS2 and it won't work in fs2_open 3.6.5 and it won't work now.
And breaking balance is a no-no. Need I remind you of the last time you broke the balance?
What are you saying? That you're going to go berserk on me every time I code something? That every single change I ever make is going to cause a battle to the death with you?
Originally posted by Bobboau
sheilds failing every now and then doesn't seem too buggy, in fact I've always liked it, it made it seem more real as you wouldn't expect a sheild to be 100% effective all the time.
Okay, if we're going to talk about realism, think about where this shield technology comes from. Yes, the Shivans. The Great Destroyers, the ones the Ancients couldn't even touch.
"Only these were not like the others. They did not die."
Only during the battle in which the Shivans destroyed the GTSC Plato and PVC Taurus did God...uhh, I mean Alpha 1 finally manage to overwhelm the shields on one of the Shivan fighters and destroy it.
These shields are supposed to be utterly reliable. That's the idea. A faulty shield system is not fitting of the Great Destroyers.
Originally posted by xenthorious
From what I have read, this bug is far more frequent on fast projectiles then it is on slow ones.
Actually, I just ran some testing and I can't seem to reproduce the bug in a controlled test environment, which consists of a Maxim that does 1 shield damage and 10000 hull damage per shot. The idea is that if the gun ever manages to puncture a shield, ever, the target's going to take major damage and probably go down right there.
Running in fs2_open 3.6.5 (without surface shields at all), the first test was to blast at a Seraphim with such a Maxim. I never managed to destroy it save by hitting it hard enough to bring down its shields. The second test was for a hostile Herc II to blast at me with such a Maxim. Once again, it had to take down my shields first. The third test changed the Maxim to have some insanely high velocity, which didn't change anything. In a fourth test, I changed the enemy fighter to carry normal Kayers and changed the Herc II (which was both the enemy fighter and mine) to have 9999 shields and 1 HP, and same thing.
:confused: :wtf: :confused: :wtf: :confused:
The shot isn't going through the shield because it's going too fast, nor is collision detection somehow missing it. If this were the case, it would have happened by now.
Ideas? Anyone?
Originally posted by Goober5000
And I'm worried that fixing this flaw will throw off balance in old campaigns that were designed to rely on it. Not just for the player ships, but for enemy ships as well.
What old campaigns?
Originally posted by Lynx
I think there should be a way for submodels to make them uncovered by shields even if the ship has surface shields. I don't know about the other mods, but I'll make the hangarbays subobjects to take advantage of Bobb's detail box thingy.
Now that I think about it, special handling for surface shield hits on subobjects might be doable. What should we do about hull / shield / subsys damage to the parent ship and its other subsystems? Absorb it by the shield as usual but do subsys damage to the subobject that was hit as though there were no shield over it?
Originally posted by Flaser
2 Simple ideas:
Will it throw off balance? Let's test then debate.
If it does? So what. Make it optional - for projects a'la SWC - problem solved.
If it doesn't screw up anything else I don't see why another "sleeping" feature can't be added to the CVS.
My 2 cents.
It's already in CVS. The bug is irritating but I don't think fixing it is enough to throw off balance, whether it's accomplished by an implicit surface shield workaround or by fixing the bug itself.
Originally posted by Goober5000
1) It throws off balance.
In theory. I should not have to remind you of this. It's very theoretical until someone comes up with a real case of it.
<:mad:>
And since you're so hot on theoretical balance breakage, I should point out that the modified TAG behavior that fs2_open introduced, wherein TAGged ships will receive higher priority for turret fire, has a much greater impact on balance than this. Yet it's perfectly acceptable. It also has yet to actually break anything, but I'm pretty sure you'd be dragging me off in compatibility police handcuffs if it were my idea.
2) It screws up the feature where you can fly underneath shields and shoot at ships.
That can be avoided by turning it off with a table flag, or just by fixing the underlying bug, whatever it is.
Originally posted by StratComm
Just out of curiousity, could it be happening when the shield mesh reaches outside the bounding box by a significant amount? Such that the shield never gets checked? The outer bounding box shouldn't be a problem, but what I'm guessing are the BSP bounding boxes come awefully close to the shield mesh, one way or another. The other obvious question is could the ship be getting checked before the shield for projectile collisions? This makes more sense if projectile speed is directly correlated to accidental penetration, since it'd be more likely to penetrate far enough in a frame to "collide" with both.
Shield impacts (seem to) happen thus: If a projectile collides with a shield mesh, and it's not supposed to pierce the shield, the shield is checked for enough strength to absorb the projectile. If it does, then the shield takes damage, a pretty shield hit effect and sound are made, and the projectile disappears. Otherwise the projectile passes through unscathed, and will probably hit the hull. It might miss the hull instead, which is quite possible and often happens with ships like the Seraphim and Manticore -- with these, it's much easier to bring down the shields of the ship than it is to damage its hull, simply because its hull is so much smaller / thinner than its shield bubble.
-
Originally posted by _argv[-1]
Okay, if we're going to talk about realism, think about where this shield technology comes from. Yes, the Shivans. The Great Destroyers, the ones the Ancients couldn't even touch.
Reverse engineered though. Realisticly you wouldn't be able to recreate more advanced technology 100%. That can't be the argument.
Actually, I just ran some testing and I can't seem to reproduce the bug in a controlled test environment, which consists of a Maxim that does 1 shield damage and 10000 hull damage per shot. The idea is that if the gun ever manages to puncture a shield, ever, the target's going to take major damage and probably go down right there.
So then are we absolutely sure that it's a bug and not some feature that no one has noticed yet. Just because we can't explain it shouldn't mean it's automatically a bug.
That can be avoided by turning it off with a table flag, or just by fixing the underlying bug, whatever it is.
Yes but then it has to be turned off. What I get from this thread is that it's assumed to be a bug since the reason is unknown. Whether or not the behavior makes sense it is the default behavior. I'm not suggesting that this isn't a bug but before changing the default behavior we should probably have a better excuse than opinion. Yes I get that other things have been changed that are against default behavior but most of those will undoubtedly get re-examined at some point in the future to see if they should be a non-default flag or something. Various things already have. It would save every developer future trouble if we can agree this is a bug in the code now rather than having this discussion later this year or next year or someone just complaining about the change and we have to go looking for what's causing it.
Shield impacts (seem to) happen thus: If a projectile collides with a shield mesh, and it's not supposed to pierce the shield, the shield is checked for enough strength to absorb the projectile. If it does, then the shield takes damage, a pretty shield hit effect and sound are made, and the projectile disappears. Otherwise the projectile passes through unscathed, and will probably hit the hull. It might miss the hull instead, which is quite possible and often happens with ships like the Seraphim and Manticore -- with these, it's much easier to bring down the shields of the ship than it is to damage its hull, simply because its hull is so much smaller / thinner than its shield bubble.
Shield pass through is percentage based. It's not all or nothing and some weapon damage can pass through the shield to hit the hull. Normally the hull would be zero in that quadrant afterwards but it could recharge a little at about the same time and look like it's still up. I could be imagining this but I seem to remember something about partial damage pass through if shields drop to a certain point. That may not have been from lasers but code is somewhere. You also get splash damage from missiles which don't think even hits the shield and goes straight to the hull.
-
Originally posted by taylor
Reverse engineered though. Realisticly you wouldn't be able to recreate more advanced technology 100%. That can't be the argument.
Very true. Almost every Shivan fighter/bomber has shields that are much stronger than anything in the GTVA arsenal.
An interesting exception is the Terran Mara, which has stronger shields than the Shivan original.
Incidentally, Shivan fighters (but not bombers) also have very fragile hulls. Once again, the absurdly powerful Terran Mara is the exception, which has a hull that's stronger than any other fighter in the game (I think).
So then are we absolutely sure that it's a bug and not some feature that no one has noticed yet. Just because we can't explain it shouldn't mean it's automatically a bug.
It looks like it to me. I never found anything in the code that causes the shields to randomly ignore shots that strike them.
Yes but then it has to be turned off. What I get from this thread is that it's assumed to be a bug since the reason is unknown. Whether or not the behavior makes sense it is the default behavior. I'm not suggesting that this isn't a bug but before changing the default behavior we should probably have a better excuse than opinion. Yes I get that other things have been changed that are against default behavior but most of those will undoubtedly get re-examined at some point in the future to see if they should be a non-default flag or something. Various things already have. It would save every developer future trouble if we can agree this is a bug in the code now rather than having this discussion later this year or next year or someone just complaining about the change and we have to go looking for what's causing it.
I agree that the implicit surface shield is a brutal hack. I would much prefer to know what's really going on and why collision detection is occasionally ignoring shields. There's some possibility that it's supposed to be this way, but I've not seen anything suggesting that.
Things I know it isn't:
- Completely random. The tests I did suggest it's not. A lot of shots were fired, and none penetrated the shield when they shouldn't have.
- Caused by high projectile velocity. Same reason as above.
- Caused by splash damage. I was recently killed by a Terran Turret with full shields and 1% hull. Ouch. These do not have splash damage.
- Only happening given low shields. Like I said, I had full shields and was killed by a Terran Turret. It was with my hacked tables, but in this case, I only increased the turret weapon's velocity, not the damage. It would have taken more than one hit at that point to bring my shields down. Instead the shot went right through them.
- Caused by beam weapons. I don't think I've ever had beams go through my shield (unless the beam is shield-piercing, obviously).
Shield pass through is percentage based. It's not all or nothing and some weapon damage can pass through the shield to hit the hull.
Only if the shield is too low to absorb it all.
Normally the hull would be zero in that quadrant afterwards but it could recharge a little at about the same time and look like it's still up.
I'm aware of that. This is normal and perfectly acceptable behavior. This is not the bug I'm talking about.
I could be imagining this but I seem to remember something about partial damage pass through if shields drop to a certain point.
No, you're not. It's there. If shields are too low to absorb all of the damage from the shot, the shields will absorb as much as possible, and the rest goes to the hull.
That may not have been from lasers but code is somewhere. You also get splash damage from missiles which don't think even hits the shield and goes straight to the hull.
Possible, but that's not the only case. See above about the Terran Turret.
-
Look, argv. Whether it's a bug or not, whether it happens rarely or frequently, whether it was intended by :v: or not... it's still a deviation from the original behavior. We had a similar discussion to this a year ago about whether beams should pierce shields or not.
Perhaps missions with a single ship won't change much. But over the course of time, with many ships, balance will change enough to make a difference. It's a change in the original behavior that's significant enough to notice. And it could sabotage mods that rely on the player being able to fly underneath shields.
As for the other AI changes, we're in the process of rolling back every AI change so that it matches default FS2 behavior. Any SCP "enhancements" will be enabled by a table flag, a command-line option, or something else. They haven't all been rolled back yet, but they eventually will.
-
The problem with this is that it's not really a fix for the problem.
Assuming this stays implemented, what will happen instead? The player will be firing at a ship and the shield hit effect won't appear, there will be no indication of damage at all. Or, the shield effect will appear on the hull. It's not so much as fixing a bug as switching it out for another one.
If this modification had some code to check whether the point where the weapon was fired had been inside the shield and draw a shield hit effect if it hadn't been, I wouldn't really care. (Could be done by checking on the firing of the weapon and setting a pointer to the shield the firer was inside)
Whether or notit's a bug or a feature in the code, it's simply more intuitive to have it be explicitly defined somehow, to prevent annoyance when someone tries to create a ship with shields you can fly inside and discovers that for some reason there shots do no damage.
-
ERm...so what's the status of the code now?
When will we have a build available with surface shields + the corresponding hit effects? And the shield absorbtion factor'
-
Okay, I give up. I'll remove the implicit surface shield next time I get to coding. Then I'll do up the surface shield hit routine Bobboau wants.
TrashMan: Adding the absorption factor is a bit trickier, so I hope you can wait on that.
-
Could it have something to with a laggy system, eg the weapon's position is incremented too far in a given frame and the collision checking doesn't catch it (As the weapon shouldn't have moved as far in the last frame).
-
That's possible. It only seems to happen in busy situations with lots of ships shooting at each other (i.e. a typical mission, as opposed to my test mission or a relatively quiet one like in FS1 when the player first meets the Shivans).
Edit: But I'm not sure about this.
-
Originally posted by StratComm
Just out of curiousity, could it be happening when the shield mesh reaches outside the bounding box by a significant amount? Such that the shield never gets checked? The outer bounding box shouldn't be a problem, but what I'm guessing are the BSP bounding boxes come awefully close to the shield mesh, one way or another. The other obvious question is could the ship be getting checked before the shield for projectile collisions? This makes more sense if projectile speed is directly correlated to accidental penetration, since it'd be more likely to penetrate far enough in a frame to "collide" with both.
That might be it; it somewhat explains the behaviour I encountered so far; and I also think I remember Bob (or someone else, am not sure) to mention something similar a year or two ago.
Still, I don't really know what these 'bounding boxes' are all about. :shaking: (I think they can be seen in modelview, but that's next to all I know about them.... :( )
Originally posted by _argv[-1]
That's possible. It only seems to happen in busy situations with lots of ships shooting at each other (i.e. a typical mission, as opposed to my test mission or a relatively quiet one like in FS1 when the player first meets the Shivans).
Edit: But I'm not sure about this.
Don't think so. I also am not sure, but I think I also encountered it in missions with a rather low ship count.
-
Originally posted by Mav
That might be it; it somewhat explains the behaviour I encountered so far; and I also think I remember Bob (or someone else, am not sure) to mention something similar a year or two ago.
Still, I don't really know what these 'bounding boxes' are all about. :shaking: (I think they can be seen in modelview, but that's next to all I know about them.... :( )
Don't think so. I also am not sure, but I think I also encountered it in missions with a rather low ship count.
Bounding boxes are simplified geometry of the model used for collision detection - AFAIK simply boxes bound together to more or less cover the entire ship.
-
I've been fraggin' busy lately, so no chance to do all the fancy stuff that's required of me, but I removed the implicit surface shield for now, so no more compatibility problem.
Sorry for being so slow. :(
-
Okay. I'm finally getting to writing up that add_surface_shield_hit function and related code. Sorry it took so long. :(
Anyway, Bobboau. Do you want the position in world coordinates, or what?
And where do I get the orientation from? The mc_info struct's orient member appears to be the orientation of the object (i.e. ship) that was collided with.
-
local space
and as long as you get the orientation with a fvec pointing in the same direction as the polygon that was hit (not the weapon that hit it) that's all I need, if all you can get is the normal of the hit polygon (I haven't worked with the colision code for a while, don't remember what's available) you can use vecor2matrix (or something like that) to convert it to a proper matrix.