|
|
|
|
|
|
Re: Absurdly small code changes[message #320787]
|
Sat, 25 May 2013 16:32
|
|
Sam Hotte |
|
Messages:1965
Registered:March 2009 Location: Middle of Germany |
|
|
ParkanIs it possible to made Bonus AP points without rising Firing Ap cost from weapons?As for me i don't understand opportunity of bonus Ap,It will allow only a little longer to run during combat,but this lus of bonus AP is nothing.Any possibilities to made such feature on\off in ja2_option.ini?
No, the current concept of APs wouldn't allow for it (though it could be possible to code this, dunno):
APs are a measurement of how fast your merc is. If you are able to run faster than me, you could run e.g. 100m in 10 sec. while i'd only achieve 80 m in the same 10 sec. Hence you'll get 100 AP to represent 10 seconds and you can spent them to run 100m while I get just 80 AP to represent the same 10 seconds and can run only 80m. So for you 10 AP = 1 sec. For me 8 AP = 1 sec.
Firing a gun consists (among other things) of the time the bullet needs to fly to the target. This time is independent of the merc firing the gun, so your faster movement can not speed up the bullet. The bullets will always need, let's say, 1 second to fly.
Hence I will have to wait 1 sec before I can take another action, so I "waste" 8 APs for this. You will also have to wait 1 sec thus wasting 10 AP for it.
That's why giving extra APs to everybody means spending more APs on firing a gun.
(This is also explained in detail - and probably better than my try - in the JA2 manual)
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
Re: Absurdly small code changes[message #321634]
|
Sun, 16 June 2013 17:03
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
I see no further need to remove essential game information to make the game more hardcore. Play Ironman on insane with standard funds if you want a challenge.
In other news, the <highExplosive>-tag of AMMOTYPES was used inconsistently. It is a boolean tag... that sometimes is used as an item index, and sometimes as an index over explosives... Well, no more of that. It is now an item index, an used only for that. This means that if you, say, define your HE ammo to have
<highExplosive>131</highExplosive>
<explosionSize>5</explosionSize>
, your rocket rifles can now fire rockets that cause stun grenade explosions. This shouldn't break any existing explosives. It if somehow does for you, please inform me. This fix was committed in r6124.
[Updated on: Sat, 06 February 2016 00:58] Report message to a moderator
|
|
|
|
Re: Absurdly small code changes[message #321635]
|
Sun, 16 June 2013 17:13
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
FlugenteIn other news, the -tag of AMMOTYPES was used inconsistently. It is a boolean tag... that sometimes is used as an item index, and sometimes as an index over explosives... Well, no more of that. It is now an item index, an used only for that. This means that if you, say, define your HE ammo to have
, your rocket rifles can now fire rockets that cause stun grenade explosions. This shouldn't break any existing explosives. It if somehow does for you, please inform me. This fix was committed in r6124.
Already ahead of you, HE rocket rifle rounds have been high explosives for a few years in my projects... and linked to an explosives.XML index. Going to need to update those to Items.XML indexes now (which means no more worrying about shifting the indexes whenever an exploding item is spliced in).
Problem is the XML Editor has yet to catch up with these changes...
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Absurdly small code changes[message #323989]
|
Wed, 14 August 2013 19:52
|
|
Deleted. |
|
Messages:2656
Registered:December 2012 Location: Russian Federation |
|
|
One absurdly small code change would make Barry Unger happy - adding a hotkey for getting another tripwire from inventory, as shift+alt+k does for knife.
Or make "endless" tripwire drum that will not disappear after "planting".
[Updated on: Wed, 14 August 2013 20:53] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
Re: Absurdly small code changes[message #324129]
|
Sun, 18 August 2013 21:35
|
|
merc05 |
|
Messages:90
Registered:January 2013 |
|
|
Hmm... a dumb question then. Is this correct?
void IgniteExplosion( UINT8 ubOwner, INT16 sX, INT16 sY, INT16 sZ, INT32 sGridNo, UINT16 usItem, INT8 bLevel, UINT8 ubDirection )
{
if ( Item[usItem].glgrenade == TRUE )
ubDirection = GetDirectionFromGridNo( MercPtrs[ubOwner]->sTargetGridNo, MercPtrs[ubOwner] );
InternalIgniteExplosion( ubOwner, sX, sY, sZ, sGridNo, usItem, TRUE, bLevel, ubDirection );
}
Seems to work.
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
Re: Absurdly small code changes[message #324136]
|
Mon, 19 August 2013 00:20
|
|
merc05 |
|
Messages:90
Registered:January 2013 |
|
|
Ok, I've found it in physics.cpp void HandleArmedObjectImpact
Quote:
IgniteExplosion( pObject->ubOwner, (INT16)pObject->Position.x, (INT16)pObject->Position.y, sZ, pObject->sGridNo, pObject->Obj.usItem, GET_OBJECT_LEVEL( pObject->Position.z - CONVERT_PIXELS_TO_HEIGHTUNITS( gpWorldLevelData[ pObject->sGridNo ].sHeight ) )[color:#FF0000], GetDirectionFromGridNo( MercPtrs[pObject->ubOwner]->sTargetGridNo, MercPtrs[pObject->ubOwner] )[/color] );
That's what I added now. Alas, there is no SOLDIERTYPE in HandleArmedObjectImpact so again I needed to use ubOwner instead.
There are 2 calls for IgniteExplosion() in HandleArmedObjectImpact (one for grenade, one for bomb), both didn't specify ubDirection at all. There seem to be some calls for IgniteExplosion() in the code that don't do that.
Hope this is right this time :bluesuspect: .
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
|