Page 2 of 2
Posted: Fri Aug 03, 2007 4:06 am
by Tkela
KGJV wrote:QUOTE (KGJV @ Aug 2 2007, 10:54 PM) The actual code to render the explosion is in ClusterSiteImpl::AddExplosion (wintrek\trekigc.cpp). You'll notice they dont use the ExplosionType but directly the values (we should fix this one day...) so it's a bit confusing and hard to find the matching. (c_etProjectile=2, so it's 'case 2'. you'll notice they force the explosion radius to 1
).
At one point (pre-alpha) the explosion radius was equal to the blast radius but that didn't work very well: the target on the receiving end of a skycap had their view filled with big explosions, dropping their framerate to a crawl.
As a historical note, a side effect of demonstrating the problem led to the formulation of Ribski's rule: "exploits can only be used against the game designer once." /laugh.gif" style="vertical-align:middle" emoid=":lol:" border="0" alt="laugh.gif" />
Posted: Fri Aug 03, 2007 5:13 am
by KGJV
Me like Ribski's rule /laugh.gif" style="vertical-align:middle" emoid=":lol:" border="0" alt="laugh.gif" />
Yeah, radius 1 is fine for projectile i guess. Problem is that for missiles, it's the same explosion type (c_etMissile = c_etProjectile) so we get a radius of 1 too.
If we want big missiles explosions (for nuke for instance) we'll have to distinguish missile explosion and projectile explosion.
Better, we could add the 'explosion rendering radius' to the core as well as the texture(s), giving more freedom to core devs.
Posted: Fri Aug 03, 2007 9:42 am
by madpeople
Tkela wrote:QUOTE (Tkela @ Aug 3 2007, 05:06 AM) As a historical note, a side effect of demonstrating the problem led to the formulation of Ribski's rule: "exploits can only be used against the game designer once." /laugh.gif" style="vertical-align:middle" emoid=":lol:" border="0" alt="laugh.gif" />
wasn't there also
"the best/fastest way to get a exploit fixed is to use on the game's developers"
Posted: Fri Aug 03, 2007 4:13 pm
by Tkela
madpeople wrote:QUOTE (madpeople @ Aug 3 2007, 04:42 AM) wasn't there also
"the best/fastest way to get a exploit fixed is to use on the game's developers"
Both are different forms of Ribski's rule. I'd previously quoted Ribski's rule as the one above. /blush.gif" style="vertical-align:middle" emoid="
" border="0" alt="blush.gif" /> We never formalized the phrasing of the rule so it keeps shifting through wetware rot.
As far as explosions go, you might be able to avoid a core format change by having missiles use their blast radius as the explosion radius. Missile explosions should be sufficiently rare that they won't have the same "obscure the view" problems that projectiles do.
Posted: Tue Aug 07, 2007 1:13 pm
by w0dk4
QUOTE The explosion anims are all preloaded into 'WinTrekClient::m_vpimageExplosion' , see WinTrekClient::Initialize.
So atm, there is 'explosion' setting in core (and ICE) for projectiles, they all use c_etProjectile (explosion type 2) and only for projectiles with AOE effect.[/quote]
It would be cool to have at least a setting for one other explosion type in ICE.. currently we only have that blue explosion bitmap, but it would be really cool, especially for the BSG Core, to have the choice between explosion type 2 (blue explosion) and type 1 (exp23bmp)
With the other explosion we could make something that looks similar to this:
" border="0" alt="blush.gif" /> We never formalized the phrasing of the rule so it keeps shifting through wetware rot.