Home » MODDING HQ 1.13 » Flugente's Magika Workshop » Absurdly small code changes  () 1 Vote
Re: Absurdly small code changes[message #320767] Sat, 25 May 2013 13:44 Go to previous messageGo to next message
Lexx

 
Messages:62
Registered:June 2009
Location: Germany
lockie
Looneys , the lot of you !
Who wants to play with a partially or colour blind sighted merc ?
Absolute nonsense , get a grip guys :crazy:
That's taking realism waaay too far ......


I thought this stuff is already in the game in an abstract way.

Like, if I cannot really walk and have a wooden leg, then I do not have the "pirate"-trait, but a very low agility value. If I only have one eye, then my marksman value is low, etc. It comes down to pretty much the same in the end.
Re: Absurdly small code changes[message #320768] Sat, 25 May 2013 13:48 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3804
Registered:July 2009
No it doesn't. Since there are no caps on the skills, you can train your one legged, half blind pirate to be a dancer with godlike accuracy.


Re: Absurdly small code changes[message #320773] Sat, 25 May 2013 14:13 Go to previous messageGo to next message
Lexx

 
Messages:62
Registered:June 2009
Location: Germany
Yeah, but maybe he is that good then. Wink And if he is starting with like 20 agility and 20 marksman skill, it would take quite some time to reach high levels. As one-eyed, he could be as cool as Snake Plissken then.

[Updated on: Sat, 25 May 2013 14:15] by Moderator

Re: Absurdly small code changes[message #320774] Sat, 25 May 2013 14:17 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3804
Registered:July 2009
Assuming otherwise equal aptitude, potential and amount of training - No, some guy with a pegleg and lack of stereoscopic vision will not be as a good as a regular guy.


Re: Absurdly small code changes[message #320775] Sat, 25 May 2013 14:23 Go to previous messageGo to next message
Lexx

 
Messages:62
Registered:June 2009
Location: Germany
Well, same applies to Gus then. He is old and can't move that good anymore, but with a little time you get him into the exact same shape as the next best merc. Adding a "old fart"-trait now to limit this with a skill-cap or somesuch would feel a little over the top, wouldn't it? After all, it's still a game we are talking about.
Re: Absurdly small code changes[message #320776] Sat, 25 May 2013 14:25 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3804
Registered:July 2009
Hey, we weren't done yet figuring out all the little disabilities we need ...


Re: Absurdly small code changes[message #320787] Sat, 25 May 2013 16:32 Go to previous messageGo to next message
Sam Hotte

 
Messages:2011
Registered:March 2009
Location: Middle of Germany
Parkan
Is 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)
Re: Absurdly small code changes[message #320844] Sat, 25 May 2013 23:34 Go to previous messageGo to next message
Parkan

 
Messages:451
Registered:April 2010
Location: Russia,Sevastopol

I didn't know about that.Thank you for explaining this.
Re: Absurdly small code changes[message #320961] Mon, 27 May 2013 01:36 Go to previous messageGo to next message
Parkan

 
Messages:451
Registered:April 2010
Location: Russia,Sevastopol

I have a question:We have now ability to show\hide health\energy bars from merc head above.Just curious-is it possible to remove such bars from mercs portraits(so player can see merc status if move mouse to merc portrait(or position where bars was before)?
Re: Absurdly small code changes[message #320962] Mon, 27 May 2013 01:40 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
Yes. It would look very odd, as the space of the bars would still be used, but one can hide the red/blue/green bars. Though I don't see a practical reason for this - after all, one still needs some sort of information about your mercs, otherwise they'll collapse/bleed out with almost no feedback.


Re: Absurdly small code changes[message #320963] Mon, 27 May 2013 02:07 Go to previous messageGo to next message
Parkan

 
Messages:451
Registered:April 2010
Location: Russia,Sevastopol

Flugente
Though I don't see a practical reason for this

Adding a little hardcore to game maybe? =)Just remove bars but all info about health\energy made appear as usual =)

Plus,if it possible to remove such bars from Autoresolve battles too?

[Updated on: Mon, 27 May 2013 13:41] by Moderator

Re: Absurdly small code changes[message #321634] Sun, 16 June 2013 17:03 Go to previous messageGo to next message
Flugente

 
Messages:3461
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]



Re: Absurdly small code changes[message #321635] Sun, 16 June 2013 17:13 Go to previous messageGo to next message
Wil473

 
Messages:2861
Registered:September 2004
Location: Canada
Flugente
In 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
131
5
, 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...


Re: Absurdly small code changes[message #321636] Sun, 16 June 2013 17:16 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
Thats weird... the explosion code does not always treat that correctly, so I'd assume that would have caused some bugs there.


Re: Absurdly small code changes[message #321637] Sun, 16 June 2013 17:25 Go to previous messageGo to next message
Wil473

 
Messages:2861
Registered:September 2004
Location: Canada
The exploding ammo feature has been available and working reasonably well for a couple years now, though only a small number of us are aware it exists. Smeagol only found it last year (or was it two years ago).

Looks like I'll have to do another release of AFS and DL-1.13 along side the next UC-1.13 full release next week.


Re: Absurdly small code changes[message #321638] Sun, 16 June 2013 17:28 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
But at some point, the game tried to get the correct animation from the tag by using it as an index over the explosive items. That could get odd results if there aren't enough explosive items.


Re: Absurdly small code changes[message #321640] Sun, 16 June 2013 18:05 Go to previous messageGo to next message
Wil473

 
Messages:2861
Registered:September 2004
Location: Canada
Flugente
But at some point, the game tried to get the correct animation from the tag by using it as an index over the explosive items. That could get odd results if there aren't enough explosive items.


I thought the Animation was in the Explosives.XML definition?

As far as I understand it, the explosive ammo mechanism substitutes an in-game explosion effect on the tile where normally bullet impact effects occur. Now to confuse things a bit, the "normal" bullet impact effects may include an explosion animation, though the damage effects are still those for a gun.

That said, I welcome the use of Items.XML indexes for this as it avoids the problem of having to recheck/redo the AmmoType XML every time a new explosive item is added to the game, changing the order of the Explosives.XML indexes.

EDIT: with the changes, does this now mean that a grenade item is now launched when explosive ammo is fired?

[Updated on: Sun, 16 June 2013 18:07] by Moderator



Re: Absurdly small code changes[message #321641] Sun, 16 June 2013 18:16 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
Previously, the specific code line was
ExpParams.ubTypeID = (INT8)Explosive[AmmoTypes[ammotype].highExplosive].ubAnimationID;
This means that we used the item index set in AmmoTypes to access an explosive - which was weird, as in other instances we use that number to denote which item is exploding in the first place.

Now it is
ExpParams.ubTypeID = (INT8)Explosive[Item[AmmoTypes[ammotype].highExplosive].ubClassIndex].ubAnimationID;	
, so we now use the class index of an item. So if you want a new sort of explosion effect on a bullet, you can define an explosive item that has the parameters you want, and link that via ammotypes, instead of moving xml arrays.

I changed locations where the tag was used. It does not change any handling of GLs etc.. The change simply occurs when fired ammo is told to explode.


Re: Absurdly small code changes[message #321642] Sun, 16 June 2013 18:44 Go to previous messageGo to next message
Wil473

 
Messages:2861
Registered:September 2004
Location: Canada
Flugente

131
5


Why is = 5?

Under the old system the valid vales would be:
0 = no explosion
1 = original JA2 Explosive ammo, small explosion animation/damage via normal gun effects
2 = "Real Exploding Ammo" which causes an in-game explosion on the tile defined by = Explosives.XML index


EDIT: something I remembered, before "real exploding ammo" Madd Mugsy put in a system for the original JA2 Explosive Ammo to use bigger explosion animations, adding medium and large size animations, though the animation selected had no effect on damage effects. Madd Mugsy's explosive ammo feature was dropped eventually in favour of the system I noted above.

[Updated on: Sun, 16 June 2013 18:50] by Moderator



Re: Absurdly small code changes[message #321643] Sun, 16 June 2013 19:00 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
I just needed a value > 1 to test, no reason at all Smile


Re: Absurdly small code changes[message #321982] Tue, 25 June 2013 17:50 Go to previous messageGo to next message
Parkan

 
Messages:451
Registered:April 2010
Location: Russia,Sevastopol

Hello all again =).I have few suggestion for new features:
1.It is possible to made cheat codes not turn off every time after reload game(so made like Ctrl+GABBI made cheats works all time,if player enter CTRL+gabbi again-cheat codes goes off)
2.It is possible to add new cheat codes?(Like mercs God mode,unlimited energy?,etc)
3.Is it possible to extranalised penalty of wearing backpacks during turnbased mode?(so player will decide how much Ap penalty he will have if his mercs wear backpack)
4.Any luck in extrenalisation of AP Firing cost modifier from weapons?(like gun damage,range,etc in ja2_option.ini)
Re: Absurdly small code changes[message #322144] Fri, 28 June 2013 01:45 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
1. Possibly yes.
2. Yes. I don't see any need though.
3. Yes.
4. No. firing cost is used in too many places. It is very much possible, but just very tedious. I have no more interest in doing this.


Re: Absurdly small code changes[message #322149] Fri, 28 June 2013 08:15 Go to previous messageGo to next message
RoWa21

 
Messages:2030
Registered:October 2005
Location: Austria
@1: how would you disable cheat codes on a running game if they are applied automatically after loading a game??


Re: Absurdly small code changes[message #322152] Fri, 28 June 2013 11:13 Go to previous messageGo to next message
Parkan

 
Messages:451
Registered:April 2010
Location: Russia,Sevastopol

RoWa21
@1: how would you disable cheat codes on a running game if they are applied automatically after loading a game??


Enter again CTRL+GABBI for disable them or something another cheat(for example ctrl+09876,because there is no cheats in game that used numbers,so we can use them

Flugente

2. Yes. I don't see any need though.


For game testing needs and etc.As for me i want to play unstable builds from start to the end with intresting features,but sometimes it became boring to play all time again and again from start.I don't want to quick finish of game with GABBI and CTRL+O i want to play like a normal game but with some advantage.Besides,cheats codes maded for fun game.So sorry for asking twice-but is it possible to add new cheats to game(God mode for mercs,unlimited energy?etc)?

[Updated on: Fri, 28 June 2013 12:33] by Moderator

Re: Absurdly small code changes[message #322155] Fri, 28 June 2013 13:35 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
@RoWa: by turning off cheat codes with a yet-to-be-coded turn off cheats command :placard: . I'm answering the possibility here, not wether its reasonable Smile

If you want to test features, use a debugger. That allows cheating and testing everything on an epic scale, with much more precision and speed than cheats could ever accomplish.


Re: Absurdly small code changes[message #322164] Fri, 28 June 2013 17:54 Go to previous messageGo to next message
Parkan

 
Messages:451
Registered:April 2010
Location: Russia,Sevastopol

What is a debugger and how use it?
Re: Absurdly small code changes[message #322165] Fri, 28 June 2013 19:30 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
http://www.codeproject.com/Articles/79508/Mastering-Debugging-in-Visual-Studio-2010-A-Beginn

Also, google is your friend.


Re: Absurdly small code changes[message #322171] Fri, 28 June 2013 22:09 Go to previous messageGo to next message
Parkan

 
Messages:451
Registered:April 2010
Location: Russia,Sevastopol

omg...to very hard for me.
Re: Absurdly small code changes[message #323494] Tue, 30 July 2013 22:58 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
As of r6262 and GameDir r1716, the new item tag in Items.xml forbids AI from picking an item at night if set to 1 and at day if set to 2.

Previously items were sometimes forbidden according to their bonus, but not always, not for attachments, and not accounting for dual boni.


Re: Absurdly small code changes[message #323806] Fri, 09 August 2013 00:32 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
Also here, as this is no longer purely IoV-relevant:

:newstuff:

Thanks to DepressivesBrot and zwwooooo, all remaining features of IoV that 1.13 did not have are now in the trunk as of r6279 and r1722:

added and adjusted the following features by zwwooooo to help restoring IoV to a pure item mod:
- externalized the brightness vision range modifiers to allow for different ratios of day/night vision range
- added as a complement to
- added the possibility for LBE vests to function as plate carriers

As a result, IoV is now fully compatible to our exes. They don't have to worry about updating their exes, and we have some new features to play with :shake:

For those interested: does what it says. Adding a 80 tag to a gun/attachment will increase its base range by 80%. The -modifiers come afterwards.


Re: Absurdly small code changes[message #323989] Wed, 14 August 2013 19:52 Go to previous messageGo to next message
sevenfm

 
Messages:1890
Registered:December 2012
Location: Soviet Russia
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



Re: Absurdly small code changes[message #323993] Thu, 15 August 2013 06:50 Go to previous messageGo to next message
Bambusar

 
Messages:64
Registered:July 2012
We should consider making new thread with all the new (and old) keyboard shortcuts. There is alot of new stuff.
Or insated of new thread we could just add new stuff to that wiki article that come first on google:
http://ja2v113.pbworks.com/w/page/4218351/ja2_and_1_13_hot_keys

All that Tab-left click, Ctrl-Tab-left click... from new move inventory and equip militia features.

Ctrl-. for new ingame menu.

Shift-Alt-K and other shortcuts connected to tripwires and stuff connected to sandbags and barb wire.

Probably lots of other shortcuts I cant remember.




Re: Absurdly small code changes[message #324004] Thu, 15 August 2013 14:10 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3804
Registered:July 2009
Yes! Make another orphaned thread. Or look into the docs folder.


Re: Absurdly small code changes[message #324113] Sun, 18 August 2013 16:24 Go to previous messageGo to next message
merc05

 
Messages:78
Registered:January 2013
I was inventing some new weapons and did this small change to the code. It is useful if you ever want to use a directional frag explosive launched from a grenade launcher - makes sure the frags go the right way Very Happy.

Explosion Control.cpp
// if explosive is directional, calculation of frags is different
if ( Item[usItem].directional == TRUE )
{
	// Flugente: if item is a directional explosive, determine in what direction the frags should fly
	INT16 degree = (45 + ubDirection * 45) % 360;											// modulo 360 to prevent nonsense from nonsensical input
	INT16 horizontalarc = Explosive[Item[usItem].ubClassIndex].ubHorizontalDegree % 360;	// modulo 360 to prevent nonsense from nonsensical input
	INT16 halfhorizontalarc = (INT16)(horizontalarc / 2);
	INT16 sLowHorizontalD = (360 + degree - halfhorizontalarc) % 360;	
	INT16 dRandomDegreeH = (sLowHorizontalD + Random(horizontalarc) ) % 360;

to
// if explosive is directional, calculation of frags is different
if ( Item[usItem].directional == TRUE )
{
	if ( Item[usItem].glgrenade == TRUE )
		ubDirection = GetDirectionFromGridNo( pThrower->sTargetGridNo, pThrower );
	// Flugente: if item is a directional explosive, determine in what direction the frags should fly
	INT16 degree = (45 + ubDirection * 45) % 360;											// modulo 360 to prevent nonsense from nonsensical input
	INT16 horizontalarc = Explosive[Item[usItem].ubClassIndex].ubHorizontalDegree % 360;	// modulo 360 to prevent nonsense from nonsensical input
	INT16 halfhorizontalarc = (INT16)(horizontalarc / 2);
	INT16 sLowHorizontalD = (360 + degree - halfhorizontalarc) % 360;	
	INT16 dRandomDegreeH = (sLowHorizontalD + Random(horizontalarc) ) % 360;
Re: Absurdly small code changes[message #324123] Sun, 18 August 2013 20:15 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
Ehm... not sure about the specific code instance, but ubDirection is already used for the direction. Why not use that? And if its not used, wouldn't it be more reasonable to fill it correctly in IgniteExplosion()? That function has DIRECTION_IRRELEVANT as a default parameter... so I suggest using GetDirectionFromGridNo( pThrower->sTargetGridNo, pThrower ) for IgniteExplosion().


Re: Absurdly small code changes[message #324129] Sun, 18 August 2013 21:35 Go to previous messageGo to next message
merc05

 
Messages:78
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.
Re: Absurdly small code changes[message #324131] Sun, 18 August 2013 21:47 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
Not necessarily. There can be cases where there is no owner (in that case ubOwner is NOBODY). At that point MercPtrs[ubOwner]->sTargetGridNo will cause a CTD.

In other cases it will work, but the direction will be bad. If we plant a claymore, we are its owner - but the direction we are looking into when it explodes is not necessarily the one we planted it in.

It can also happen (mines) that the owner is travelling, in which case his GridNo is NOWHERE. Also bad.

Best check on what code location the explosion of your grenades is ignited, and then fix the direction there.


Re: Absurdly small code changes[message #324136] Mon, 19 August 2013 00:20 Go to previous messageGo to next message
merc05

 
Messages:78
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: .
Re: Absurdly small code changes[message #324138] Mon, 19 August 2013 00:49 Go to previous messageGo to next message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
Well, as long as the owner exists in the sector that should be fine. I am not sure, but I think the direction part was first introduced by Headrock, which explains why most calls don't use it, as it is irrelevant without frags.


Re: Absurdly small code changes[message #324167] Mon, 19 August 2013 22:06 Go to previous messageGo to previous message
Flugente

 
Messages:3461
Registered:April 2009
Location: Germany
Not a change (yet?): repairing items is not possible underground. Simply because we don't allow it underground... but I can find no explanation for this in the code, and recall being able to repair underground a long long time ago.

This is forbidden since 1299, which is so ancient that can't get a log on the reason... hey old people :professor: , is there any good reason for this? Codewise, changing this is trivial, but I'd like to know the reason for this.


Previous Topic: New (unofficial) merc: Mercy (Overwatch)
Next Topic: New Feature: Radio Operator
Goto Forum:
  


Current Time: Mon Jul 22 13:25:24 EEST 2019

Total time taken to generate the page: 0.03102 seconds