Home » MODDING HQ 1.13 » v1.13 Coding Talk » Code Snippets  () 1 Vote
Re: Code Snippets[message #353902 is a reply to message #353874] Thu, 28 June 2018 14:18 Go to previous messageGo to next message
Talion

 
Messages:18
Registered:June 2018
Hi, i'm using wine version 3.0 and there is no problem with the mouse wheel. What version are you using? I know that distros based on debian (Ubuntu etc.) by default ship that ancient version 1.6.2 where the mouse wheel doesn't work for me either.

Report message to a moderator

Private
Re: Code Snippets[message #353906 is a reply to message #353902] Fri, 29 June 2018 07:39 Go to previous messageGo to next message
Taleman is currently offline Taleman

 
Messages:68
Registered:October 2010
Location: Finland
I'm using Debian GNU/Linux 9.4 Stretch. It has Wine version 1.8.7-2. But now I see stretch-backports has wine version 3.0-1. I'll try that.

Report message to a moderator

Corporal
icon7.gif  Re: Code Snippets[message #353907 is a reply to message #353906] Fri, 29 June 2018 07:49 Go to previous messageGo to next message
Taleman is currently offline Taleman

 
Messages:68
Registered:October 2010
Location: Finland
I'll have to setup a test machine, I don't dare mess up this computer with broken systemd. But thanks for the heads-up, now there is hope of a working mouse wheel. Good show, @Talion. You are my hero! happy

root@yosemitesam:/home/taleman# LANG=C apt-get install -t stretch-backports wine 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 udev : Breaks: systemd (< 233-4)
        Breaks: systemd:i386 (< 233-4)
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
root@yosemitesam:/home/taleman#

Report message to a moderator

Corporal
Re: Code Snippets[message #353908 is a reply to message #353874] Fri, 29 June 2018 13:56 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
Taleman wrote on Sat, 23 June 2018 20:45
Could any JA2 coder be encouraged to fix using mouse wheel under Wine? I have played only under wine for a few years already, and it works better than under windows. Only thing that does not work is mouse wheel.

Testing notepad.exe under wine shows that mouse wheel can be made to work.

Please post bug reports in appropriate thread:
http://thepit.ja-galaxy-forum.com/index.php?t=thread&frm_id=216&



Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355351 is a reply to message #353872] Tue, 16 October 2018 15:04 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
sevenfm wrote on Fri, 22 June 2018 19:00
in AIUtils.cpp:

UINT8 GetClosestFlaggedSoldierID( SOLDIERTYPE * pSoldier, INT16 aRange, UINT8 auTeam, UINT32 aFlag, BOOLEAN fCheckSight )
...
    // go through each soldier, looking for "friends" (soldiers on same team)
    for (uiLoop = gTacticalStatus.Team[ auTeam ].bFirstID; uiLoop < gTacticalStatus.Team[ auTeam ].bLastID; ++uiLoop)
    {
        pFriend = MercPtrs[ uiLoop ];
...

Why bLastID is not included in the loop?
Looking at other places in the code, bLastID is real last id of the team that should be used.
There are also some other places in the game code where bLastID is excluded from search.

Good catch. Fixed in r8629. There were quite a number of functions that ignored the last merc, including boxing, cleaning, repairs, dialogue, individual militia and opponent lists.



Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355507 is a reply to message #355351] Mon, 29 October 2018 20:13 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
In opplist.cpp, HearNoise()

if (ubVolume >= pSoldier->aiData.ubNoiseVolume)
{
	// yes it is, so remember this noise INSTEAD (old noise is forgotten)
	pSoldier->aiData.sNoiseGridno = sGridNo;
	pSoldier->bNoiseLevel = bLevel;

	// no matter how loud noise was, don't remember it for than 12 turns!
	if (ubVolume < MAX_MISC_NOISE_DURATION)
	{
		pSoldier->aiData.ubNoiseVolume = ubVolume;
	}
	else
	{
		pSoldier->aiData.ubNoiseVolume = MAX_MISC_NOISE_DURATION;
	}
		SetNewSituation( pSoldier );	// force a fresh AI decision to be made
}


ubVolume is current noise volume, MAX_MISC_NOISE_DURATION is 12.
See the problem?



Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355510 is a reply to message #355507] Mon, 29 October 2018 21:11 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Call me blind but I don't see it.


Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355511 is a reply to message #355510] Mon, 29 October 2018 21:23 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
@silversurfer
MAX_MISC_NOISE_DURATION is 12, noise volume for a gun shot is like 50-100 usually. When noise volume is stored in ubNoiseVolume, it's capped by 12, as a result, the soldier will not remember the loudest noise (which would make sense) but just any last noise that has volume of 12 or higher.

Example:
- soldier hears gun shot from KSVK with volume like 100 and remembers it's location
- soldier hears some unimportant noise, like bullet hitting the wall behind him, some random voice, distant steps from enemy running, crappy .38 pistol shot, random bullet hitting neutral civ etc, and since the typical noise will be louder than 12, it will replace the most important noise location with this new noise

And since soldier only remembers enemy location for 3 turns, after that he can only use stored noise location (for 12 turns), and since he stored some unimportant shit there instead of enemy sniper location, he will move to wrong spot and do stupid things like looking in the opposite direction of last heard enemy.

[Updated on: Mon, 29 October 2018 21:25]




Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355512 is a reply to message #355511] Mon, 29 October 2018 22:08 Go to previous messageGo to next message
ZedJA2

 
Messages:202
Registered:January 2018
I do see this much from what SevenFM is saying: It is odd in the first place that a Duration value is capping a volume value and replacing it. One would presume errors would result from it anyway. But as SevenFM describes it, since the cap is 12 and most key volumes to note and remember are above it, this means you tend to remember irrelevant stuff.

But from my point of view, the very fact that a Sound's Duration value is capping a Sound's Volume value in the code, is the real revelation of something is wrong here.

This is the second time SevenFM recently has caught some seemingly inconspicuous things in the code, I must say he has a very good eye for this (last time I think it was a bounding value using < instead of < and = together (which I don't know how to type from here as one symbol).

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #355513 is a reply to message #355512] Mon, 29 October 2018 22:23 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
@ZedJA2 I just spent maybe hundreds of hours watching and experimenting with AI, at some point I found they are doing some strange things related to noise and started investigating.
Limiting heard noise volume to 12 is not a problem - we don't want AI to remember noise forever, and 12 turns is just fine for that - most likely after that the threat will move or shoot again or something else will happen.

My solution to this problem in Ja2+AI was not to increase MAX_MISC_NOISE_DURATION but instead store not plain noise volume but a square root of it:
// sevenfm: scale ubVolume to remember noise
UINT8 ubVolumeScaled = (UINT8)sqrt((float)ubVolume);

and then later compare it with stored squarerooted value (possibly decremented by passed turns)
// CJC: set the noise gridno for the soldier, if appropriate - this is what is looked at by the AI!
if (ubVolumeScaled > pSoldier->aiData.ubNoiseVolume)
{
	// yes it is, so remember this noise INSTEAD (old noise is forgotten)
	pSoldier->aiData.sNoiseGridno = sGridNo;
	pSoldier->bNoiseLevel = bLevel;

	// no matter how loud noise was, don't remember it for than 12 turns!
	pSoldier->aiData.ubNoiseVolume = min(ubVolumeScaled, MAX_MISC_NOISE_DURATION);

	SetNewSituation( pSoldier );	// force a fresh AI decision to be made
}


Now we can have 12 steps of volume (from 1 to 144) so we can actually compare and distinguish noise but still use original 12 turn limit and don't touch noise code in other places.

[Updated on: Mon, 29 October 2018 22:48]




Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355514 is a reply to message #355513] Mon, 29 October 2018 23:00 Go to previous messageGo to next message
edmortimer is currently offline edmortimer

 
Messages:1533
Registered:January 2015
Location: Home Free
Does the AI still remember noises and sightings after combat ends but Mercs and enemies are still in sector? I mean, when the AI loses sight of the Player forces for two turns (I think it is) and combat turns stop and the AI returns to their default routine.

Report message to a moderator

Sergeant Major
Re: Code Snippets[message #355515 is a reply to message #355514] Mon, 29 October 2018 23:04 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
edmortimer wrote on Tue, 30 October 2018 02:00
Does the AI still remember noises and sightings after combat ends but Mercs and enemies are still in sector? I mean, when the AI loses sight of the Player forces for two turns (I think it is) and combat turns stop and the AI returns to their default routine.

In stock 1.13, AI will only remember known enemies (seen or heard) for 3 turns, and noise for 12 turns, after that it will return to green state and start patrolling etc.
In Ja2+AI, AI will remember last known enemy location (seen or heard) forever unless he will come close to it, see that it's empty and erase from memory, only in this case (or if all known enemies are killed, for example), it will return to green.



Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355517 is a reply to message #355515] Mon, 29 October 2018 23:34 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
To me it's strange that we store a duration value in a noise volume variable. That doesn't make sense at all but since it is used in so many places in the code it would be a nightmare to fix all of this. Your square root approach seems like a good workaround. I'm currently looking at the request to open doors from the side so I will also incorporate your change once I commit my code.


Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355523 is a reply to message #355517] Tue, 30 October 2018 07:22 Go to previous messageGo to next message
ZedJA2

 
Messages:202
Registered:January 2018
Well, what confuses me, even in your corrections SevenFM is this line (granted it has been 30 years since I've done any coding, back in the Structural days pre Object Oriented and only with Pascal in College back when):

// no matter how loud noise was, don't remember it for than 12 turns!
pSoldier->aiData.ubNoiseVolume = min(ubVolumeScaled, MAX_MISC_NOISE_DURATION);

Ok, now I have never looked at any of the JA2 code either.

But why is a NoiseVolume value having a Duration value slammed into it in the first place (here of course it may or may not be the one that goes in, I guess), we just take the smaller of ubVolumeScaled or MAXblahblahDuration. Or I'm reading that part wrong, since i'm not sure how this min (x,y) works as a function (I'm guessing it takes the smaller value and uses that from the two parameters.

But, I'm guessing later on or in other parts of the code, the noise and this duration are then being used to control how long something is remembered by the A.I. This seems at best a kludge. Why are not volume being compared simply to volume to then trigger a duration subroutine, since the sound passed the importance test (of being super loud, so big calibre). Beyond this, loudness is not the only character of an important sound that requires attention or remembering.

Forgive me, since I have no idea what this MAX_MISC_NOISE_DURATION was originally supposed to be controlling, that is what function it is limiting or being part of a test for. It just seems odd. It is definitely more odd to slam the value 12, and insert it into a volume parameter for no known reason. It is as if someone said, we just want to trigger something in another function, but we don't want to compare duration to duration, so we'll just slam a duration value into a volume value to signal that everything fades over time. Seems to me that an entire procedure or function or subroutine (whichever of the three options you want to call it) is missing that is supposed to actually replace this slamming a duration value into a volume value just to cause the right things to happen.

Anyway, since I've not studied the related functions I have no idea what else is going on with the Duration being tested in other functions, or volume, and that is probably why this kludge actually works. It certainly isn't a method you would want to teach someone to use in re-useable code, normally.

Then like SilverSurfer says, it is all over the code, so now we have to pray and hope that someone doesn't dig up this Duration variable, or rather the now volume value derived from Duration, and use it again for actual duration tests anywhere else, or we are really screwed. Mix n match stuff for purposes other than the variable or value was designed to be used -- very hack oriented, not clean at all. But who wants to go thru all the code to fix or check that and add a new function somewhere and then change all the variable names or values, lots of work, so understandable. Yowsers!

Is this code all written in C?

[Updated on: Tue, 30 October 2018 07:30]

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #355525 is a reply to message #355523] Tue, 30 October 2018 08:39 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
@ZedJA2
Ja2 1.13 code is based on vanilla Ja2 code which was written in 1999, and Ja2 code is based on Ja1 code which was written in 1994, so the current code base is a mix of c and c++ code written by literally hundreds of people with different skills and styles during last 30 years. It has some crazy parts which make no sense today but worked well in the days of Jagged Alliance 1 and i386. It also explains the weirdness of the AI code which was developed mostly for Ja1 to work on extremely slow (from today's standards) PCs.
For example, they could just think it's a good idea to save some memory by not using two variables instead of 1, because 640kb memory may be not enough to store information about every game object in every detail.

So when working with Ja2 code you can usually have two options: leave it as it is with maybe some minor tweaks not changing the original design, or rewrite the whole parts of it from scratch, possibly breaking something related in the process.

Just a funny example of Ja2 code: guess what FindBestNearbyCover AI function does most of the time?
Toggle Spoiler

[Updated on: Tue, 30 October 2018 16:35]




Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355528 is a reply to message #355525] Tue, 30 October 2018 12:11 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
From CTHConstants.ini
Quote:
; The shooting upwards modifier is then divided by the range to the target
; (in tiles). In other words, at a range of 2 tiles the modifier is
; HALVED. at a range of 10 tiles, the modifier is divided by 10. Etcetera.
; This means that the further the target is, the less relevant the upwards
; angle is.
BASE_SHOOTING_UPWARDS = -15.0

it's not exactly true.
Shooting upwards modifier is calculated in CalcNewChanceToHitBaseTargetBonus:
// Height difference is mitigated by range. A LONGER range reduces this penalty!
if (iRange > 0 && iHeightDifference > 0)
{
	FLOAT fTempPenalty = gGameCTHConstants.BASE_SHOOTING_UPWARDS * iHeightDifference;
	fTempPenalty /= iRange;

	fBaseModifier += fTempPenalty;
}

Where BASE_SHOOTING_UPWARDS is -15.0 by default and iHeightDifference is something like 3 when shooting from ground to roof.

And iRange is defined in CalcNewChanceToHitGun as
// calculate actual range (in units, 10 units = 1 tile)
iRange = GetRangeInCellCoordsFromGridNoDiff( pSoldier->sGridNo, sGridNo );

Which returns distance not in tiles but in units 10 times the tiles.

So actual penalty, for example when shooting at one tile above will be divided by 10 for 1 tile distance and by 100 for 10 tiles distance, making in completely insignificant.

In Ja2+AI, I use slightly different code:
// Height difference is mitigated by range. A LONGER range reduces this penalty!
if (iRange > 0 && iHeightDifference > 0)
{
	FLOAT fTempPenalty = gGameCTHConstants.BASE_SHOOTING_UPWARDS * iHeightDifference;

	//fTempPenalty /= iRange;

	// sevenfm: max penalty at zero range, half penalty at DAY_VISION_RANGE
	fTempPenalty = fTempPenalty / 3.0f;
	fTempPenalty = fTempPenalty * DAY_VISION_RANGE / (DAY_VISION_RANGE + iRange / CELL_X_SIZE);

	fBaseModifier += fTempPenalty;
}

Where DAY_VISION_RANGE is actual day vision range in tiles (used to scale various game values to work well with bigmaps).
So actual penalty will be max at 1 tile and halved at day vision range (and quarter at double day vision range which is usually max possible vision range with 100% bonus from sniper scope).
So we can have 15 penalty when shooting from ground to the roof at close range, and 7.5 penalty at day vision range which should be noticeable but not excessive.
I also don't understand, why shooting upwards has penalty, but shooting from roof to the ground has no bonus? Vanilla Ja2 has it and it was good as roofs were important tactically.

[Updated on: Tue, 30 October 2018 14:31]




Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355532 is a reply to message #355528] Tue, 30 October 2018 16:47 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
I implemented the noise workaround in r8630 but I'm not sure that your changes are enough. You said it yourself - gun shots are loud so why do we compare them to such low numbers like below?

Toggle Spoiler
[/align]

Shouldn't we use ubVolumeScaled for comparison instead of the old ubVolume? I mean in 99.9 percent of the cases a gun shot will be louder than 3, wouldn't it?


Regarding the "shooting upwards" code I don't like your changes because even at long ranges the penalty will be quite noticeable although it shouldn't be.

The default BASE_SIGHT_RANGE is 14 so DAY_VISION_RANGE is 28. Let's say that the target is 20 tiles away so with your formula we get a penalty of:

-15 * 3 / 3 * 28 / (28 + 20) = -8.75

The default 1.13 formula will calculate a penalty (edit: fixed in r8631) of:

-15 * 3 / 20 = -2.25

which seems more reasonable to me. At this range a height difference shouldn't have a noticeable impact.

[Updated on: Tue, 30 October 2018 16:56]




Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355536 is a reply to message #355532] Tue, 30 October 2018 18:24 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
@silversurfer
There's a similar problem with iRange in CalcNewChanceToHitAimTargetBonus:
// Height difference is mitigated by range. A LONGER range reduces this penalty!
if (iRange > 0 && iHeightDifference > 0)
{
	FLOAT fTempPenalty = gGameCTHConstants.AIM_SHOOTING_UPWARDS * iHeightDifference;
	fTempPenalty /= iRange;
	fAimModifier += fTempPenalty;
}


As for this code:
// if noise type was unmistakably that of gunfire
if (((ubNoiseType == NOISE_GUNFIRE) || (ubNoiseType == NOISE_BULLET_IMPACT)) && (ubVolume >= 3))

I don't understand why this condition (ubVolume >= 3) exists at all. If soldier hears gunshots, he should go to RED immediately, even if it's far away (noise is decreased over distance).
I think it can be left as it is or maybe even removed completely.



Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355537 is a reply to message #355536] Tue, 30 October 2018 20:43 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Thanks. I should have checked that myself... It's fixed in r8632.


Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355576 is a reply to message #355537] Thu, 01 November 2018 23:30 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
I don't think it will work as intended:
// SANDRO - STOMP traits - Athletics trait decreases movement cost
if ( gGameOptions.fNewTraitSystem && HAS_SKILL_TRAIT( s, ATHLETICS_NT ))
{
	ubAPCost = max(1, (INT16)((ubAPCost * (100 - gSkillTraitValues.ubATAPsMovementReduction) / 100) + 0.5));
}

Since there are parentheses, this expression is calculated first:
(ubAPCost * (100 - gSkillTraitValues.ubATAPsMovementReduction) / 100)

and since all constants and variables are integer, the result will be integer.
Now we add 0.5 to the integer value, result is float, then we cast it to integer back and have our original integer, what was the point of adding 0.5 then?
I think to work correctly it should like:
ubAPCost = max(1, (INT16)(((FLOAT)ubAPCost * (100.0f - (FLOAT)gSkillTraitValues.ubATAPsMovementReduction) / 100.0f) + 0.5f));

What do you think?

[Updated on: Thu, 01 November 2018 23:34]




Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355578 is a reply to message #355576] Fri, 02 November 2018 00:01 Go to previous messageGo to next message
ZedJA2

 
Messages:202
Registered:January 2018
@ SevenFM

I can confirm with townLTU that movement calculations are messed up when you can have the same cost running first north 4 tiles then east 4 tiles, as moving diagonally. TownLTU believes it is related to only those with Athletics trait.

I have not looked to see if your code made sense. I just wanted you to know that Movement calculations, in so far as straight diagonal movement shows no benefit often to moving in a zig-zag. Movement calculations DO NEED A TOTAL REVIEW, it might just be how ATHLETICS BONUS works.

-----

As to the shooting uphill situation, cover is really an angle function, that the floor gives. So yes, if farther out the protection from the angle (caused by the floor protecting some of the view to the body of the target) is reduced. It you are shooting at an 1 degree from horizontal to make the shot, I would suppose that you can see 89/90th of the target. If it is 10 degrees above horizontal, then you have probably 10/90 degrees of the total body masked by the floor as hard cover.

Of course, there could be a bonus for crouching or being prone, as the amount of body available goes down, as target visible. I don't directly see how a value like daylight vision range should impact this. It is more a question of height vs distance to target to calculate an angle ratio, and the stance of the merc on the roof. If you are one tile away, you chance to hit something on the roof is significantly reduced. If you are 20 tiles away it is significantly better, in terms of how little the roof's floor blocks of your vision to the target -- from there you will see most of the body in your aperture without blocking floor or roof.

The main advantages of shooting from a roof, are that safety, and it being less likely to be noticed or killed. Probably easier to brace weapons shooting downhill also. Not sure how you would provide a bonus for that.

---
On the UBVolume >= 3 test:

Does this have something to do with testing for silenced weapon sounds and allowing those to go unnoticed?

[Updated on: Fri, 02 November 2018 00:03]

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #355579 is a reply to message #355576] Fri, 02 November 2018 00:14 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Are you investigating the reported issue about diagonal movement with athletics that doesn't calculate the proper AP? I don't think that this is the culprit but still the formula isn't working properly. As you say, if we want the calculation done as FLOAT then we need to cast everything to FLOAT or we could simply ignore the post decimal position and always round down. In the latter case we don't need that 0.5 at all and we only need to cast the result to INT16.
Well, I'm for proper rounding so FLOAT it is.

If you find the reason for the diagonal issue please give a yell.

edit: I just did a simple test with Magic who has the athletics trait. He starts with 95 AP in standing stance.

Running 4 tiles diagonally cost 27 AP. 95 - 27 = 68 AP left.

Running 4 tiles west costs 15 AP. 95 - 15 = 80 AP left.
Running 4 tiles south costs 12 AP. 80 - 12 = 68 AP left. That's the same amount as the diagonal path. Doesn't make sense. big grin

[Updated on: Fri, 02 November 2018 00:30]




Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355583 is a reply to message #355579] Fri, 02 November 2018 02:08 Go to previous messageGo to next message
ZedJA2

 
Messages:202
Registered:January 2018
@ SilverSurfer

Yep, it's crazy wrong, isn't it?

Even with copies of my key old INI and XML files, I'm still revamping my files for the new SCI so it will take hours to set-up, then I'll look again at non athletes.

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #355589 is a reply to message #355583] Fri, 02 November 2018 10:23 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Actually it doesn't have anything to do with athletics. I just did the test again with Danny who doesn't have athletics trait. He started with 91 AP in standing stance.

Running 4 tiles diagonally costs 36 AP. 91 - 36 = 55 AP left.

Running 4 tiles west costs 20 AP. 91 - 20 = 71 AP left.
Running 4 tiles south costs 16 AP. 71 - 16 = 55 AP left.


edit: AP cost for a flat tile is 12. Running modifies by -8. That means to run from one tile to the next we need 4 AP. We also need 4 AP to start running. So let't take a look at the numbers again.

Running 4 tiles west costs 4 AP to start running + 4*4 AP to run = 20 AP. Correct.
Running 4 tiles south costs 4*4 AP to run (no start cost as we are running already) = 16 AP. Correct.

Running diagonally should cost 4 AP to start running + 4*4 AP to run * 1.4 (diagonal factor) = 4 + 22.4 = 26 AP. 36 AP cost is certainly too much...

edit2: What if we multiply 26 again with 1.4? Oops, that makes 36. It seems that somewhere the diagonal multiplier has been applied twice.

edit3: I know what the problem is. In function "TerrainActionPoints" the tile cost is multiplied by 1.4. Tile cost for flat ground is 12. 12 * 1.4 is 16. Only afterwards in function "PlotPath" we subtract the running modifier -8. This is wrong because:

wrong: 12 * 1.4 - 8 = 8
right: (12 - 8) * 1.4 = 5

The multiplier for diagonal movement has to be applied AFTER other modifiers or we make movement costs for diagonal movement twice as large as straight movement. If we also round properly it would be even better. ;-)

[Updated on: Fri, 02 November 2018 11:30]




Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355592 is a reply to message #355589] Fri, 02 November 2018 11:57 Go to previous messageGo to next message
ZedJA2

 
Messages:202
Registered:January 2018
@ SilverSurfer

Sounds like you have the problem figured out. The combination of changing to float for more accuracy before rounding, and also correcting the formulae so that multiplier for diagonal movement is applied in the right spot, should do the trick. Something to look forward to in the next upcoming SCI then.

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #355602 is a reply to message #355589] Fri, 02 November 2018 18:50 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
@silversurfer
It works like this since vanilla. In Ja2 1.12 running straight costs 1 AP/tile, running diagonally costs 2 AP/tile.

As for rounding calculations, searching the code for "+ 0.5" shows dozens of places with incorrect rounding.



Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355609 is a reply to message #355602] Fri, 02 November 2018 23:34 Go to previous messageGo to next message
ZedJA2

 
Messages:202
Registered:January 2018
Interesting, since the old JA2, really?

Well, here's perhaps a reason to correct it. When the engine calculates how many tiles you have run, does it use the number of tiles regardless of diagonal crossing or straight OR does it use the total APs used on movement?

If the first, then running diagonally runs THRU less tiles, so your lowered chance to hit via movement is LESS than someone moving straight and then cutting once in another perpendicular direction?!

If the second, then at least diagonal movement would have higher movement cost so less chance to be hit via movement penalty? But one would think that moving in a zig-zag several times ought to cause the most penalty to any shooter on the moving target? So that last is screwy as well. Movement AP costs should be calculated correctly so that total movement costs go into any movement penalty of the shooter on a moving target, since that way the runner who zigs and zags the most, will use more APs, and get a better bonus to evading the chance to be hit via movement. Then if you run three tiles to the east, turn 180 degrees around, run three tiles due west, turn around ... etc. ... you'd be just as hard to hit as doing it other ways.

Anyway, it's a case to be made.

Otherwise, maybe they presumed and approximated that all movement was equally evasive (soldiers just evade like heck all the time) anywhere in a huge radius around the start location, but then what is the point of having a grid at all and allowing interrupts. Seems it still begs for correction.

[Updated on: Fri, 02 November 2018 23:39]

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #355613 is a reply to message #355602] Sat, 03 November 2018 12:14 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
sevenfm wrote on Fri, 02 November 2018 17:50
@silversurfer
It works like this since vanilla. In Ja2 1.12 running straight costs 1 AP/tile, running diagonally costs 2 AP/tile.

If I read the comments in the code correctly then this has been changed back and forth over time. I think we should fix it because mathematically it doesn't make any sense. The shortest route between two points is a straight and not a triangle. We can't even explain the current behaviour with "balancing"...

sevenfm wrote on Fri, 02 November 2018 17:50

As for rounding calculations, searching the code for "+ 0.5" shows dozens of places with incorrect rounding.

I may fix those too if I'm in the mood. ;-)



Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355614 is a reply to message #355578] Sat, 03 November 2018 14:11 Go to previous messageGo to next message
townltu

 
Messages:384
Registered:December 2017
Location: here
ZedJA2 wrote on Fri, 02 November 2018 00:01
...
TownLTU believes it is related to only those with Athletics trait.
...
Just for the record, thats a misinterpretation of my message in admittedly bad english and simplified content which may have caused your assumption,
obviously the game does not simulate "real" geometric condition correctly for many of its calculations,
but since you apparently discovered the flaw with most obvious discrepancy,
(which goes paradox for diagonals when athletics and a movement bonus on tactical kicks in)
i did not even try to explain stuff in a wall of txt in weak english that cost me ton of time
and most likely cause more misunderstanding due to weak vocabulary/bad linguistic workarounds;)

However it appears that my assumption of factors applied at different stage was, as usual ;), not wrong.


"obviously the game does not simulate "real" geometric condition correctly for many of its calculations":
a) if my merc attacks an enemy with e.g. stun gun from directly adjacent tile,
the amount of reqired AP varies with direction of the attack,
i.e. it takes different AP ( +- 1) if the merc attacks the target from south, west north or east.
b) place your merc on a tile directly adjacent to solid terain like a tree, with the back to it.
Depending on direction, the merc may or may not go prone.




Besides @ZedJA2
Once upon a time We had to realize that some underling had dared to steal Our nick on a forum We intended to grant the grace of a registration,
and Our decision fell on the most obvious choice for trailblazing messages on VN's (rip) Wiz8 board.

I.e. effort to hold caps for my nick is a waste,
acronym of instakill message for Wiz8 2nd laid male character, aka m_laid20_056.mp3, contains only lower case letters :D

Report message to a moderator

Master Sergeant
Re: Code Snippets[message #355620 is a reply to message #355614] Sat, 03 November 2018 18:24 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Ok, in r8634 I fixed quite a number of incorrect rounding formulas and changed the calculation of AP and BP points for diagonal movement. BP calculation never took diagonal movement into account so we needed less BP than we should have. This was clearly a bug or a tradeoff for using too many AP. big grin
Now AP and BP are using 1.4 times the straight costs.


While I was testing I noticed something else that is strange. Jumping a fence costs Danny 24 AP. At least that is what the game UI says. BUT - he actually uses 30 AP if he was standing before jumping the fence. The 6 additional AP come from standing up after jumping. From my bad memory I remember that a merc would always stay crouched after jumping a fence.

If I remember wrong the calculation for the UI is wrong and the UI should display 30 AP instead.
If I remember correctly why does the merc stand up now? Was there a change that I missed?



Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355623 is a reply to message #355620] Sat, 03 November 2018 19:45 Go to previous messageGo to next message
townltu

 
Messages:384
Registered:December 2017
Location: here
Rather sure that a path always missed the AP for going into crouched stance after jumping over a fence, already in classic JA2,
and the gane will not perform the change in stance if the merc had spent the last APs with the jump,
which is the default behaviour of most paths that include a jump, due to the games way of plotting the path.
So your merc in the test may just have had enough AP to stand up,
or you plotted a path futher than the 1st tile behind the fence,
in which case the mercs will automatically stand up to continue movement in same stance as before,
but iirc change from running stance to walking stance after (s)he jumped over the fence.


Anyway i think the "go into crouched stance" step after crossing a fence is obsolete,
its not that jumping over an obstacle of 1+ m forces a medium str soldier w combat load to go into crouched stance on the other side.
(but encumbrance lvl and big number of big items should definitely rise AP cost;)
Also crouch after jump makes little sense in terms of "safe approach", in that case you should have taken cover behind the fence,
but its all about "advance!" once you jumped over it.


Btw "BP":
Not sure whether this was fixed in some release after 7609,
in AV 1.10 with stock exe and 7's exe(s) I noticed that mercs do not regain stamina if they end their turn in running stance,
only if you hit esc respectively if they change to "stand" by default (in which case enemies probably dont get cth penalty).
this lead to the paradoxon that Razor slowly lost stamina from runnung 1 tile back and forth
(aka "run in wait" to not pay the 3 AP for starting his movement)
In extreme example, one merc crosses whole map at full speed in x turns,
2nd merc crosses whole map at 2 tiles/turn, which irldoes not rise heartbeat by much,
but arrives totally exhausted because he ended every turn in running stance,
at a time when the 1st merc has regained 100% stamina a couple of turns ago.
This does not make sense in term of simulation or balance,
hasnt anybody complained yet or is it just hard to code?.

Report message to a moderator

Master Sergeant
Re: Code Snippets[message #355626 is a reply to message #355614] Sat, 03 November 2018 21:37 Go to previous messageGo to next message
ZedJA2

 
Messages:202
Registered:January 2018
@ townltu

I'm sorry if I offended you, it was completely the opposite of my intent. Since I thought it might be possible that your thoughts, which I obviously misunderstood and misstated summarily, were perhaps more accurate than my own, and since I like to give credit to anyone else I have discussed the matter with, or who might be exploring things independently, it is my custom to mention another thoughts or discoveries on the matter, perhaps in too brief a way, so that they may get some credit or so that another may follow-up with that person for further discussion.

It was the way I was taught to do things, when I studied science in school. So again, my apologies.

As to your nickname, again my error. I tend to like to put capitals in names, in part as a sign of respect, as I consider them living people therefore deserving of names that are capitalized, and also because those I note or talk to a lot I tend to remember their nicks differently or in that way. I do that same with SevenFM, EdMortimer, and SilverSurfer usually, even though I believe all their nicks are likewise all lower case.

I can discontinue it if this truly helps with knowing who said what.

By the way, I read all walls of text and am accused of such all the time. I find the insult rather specious, as the whole point of forum is writing/reading text, and detail is only meant, at best, to attempt to be accurate or share more info. I wish I was capable of being so accurate and brief, but usually I no longer can achieve that high standard. So, at least don't worry about me having to read a "wall of text", how else can I learn?

[Updated on: Sat, 03 November 2018 21:47]

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #355627 is a reply to message #355620] Sat, 03 November 2018 21:42 Go to previous messageGo to next message
ZedJA2

 
Messages:202
Registered:January 2018
@ SilverSurfer

AP trade-off, LOL, who would have guessed?

My memory was the same, in the older version of JA2 one used to remain crouched after landing from jumping a fence. Jumping and likewise jumping on/off or climbing buildings have always seemed to be a bit clunky in the way that is handled. It is also sort of funny that you often land a different direction than you started, probably because you are using your hand as a perch on the fence as you vault it, likewise climbing the top ledge of a building. Also when you climb down, you re-enter walking mode, even if you were in running mode before then on top of the roof.

Thanks for all the hard work looking into all this, the rounding issues, and changing this. For me at least, this will make a big deal, because I tend to try to be very efficient in my maneuvers, using diagonal movement as much as possible.

The A.I. will also be able to benefit from these calculations of diagonal movement? If so might be a faster more dangerous game than before, in terms of ability of both sides to maneuver.

[Updated on: Sat, 03 November 2018 21:44]

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #355628 is a reply to message #355627] Sat, 03 November 2018 22:14 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
There is certainly something wrong with jumping fences. There are basically 3 scenarios:

  • starting in standing stance:
    UI shows 24 AP cost. The merc ends in standing stance so it takes 24 AP for jumping + 6 AP to stand up afterwards. I could live with that and fix the calculation for the UI.
  • starting in crouched stance:
    UI shows 30 AP cost. The merc ends in crouched stance so it takes 6 AP to stand up and 24 AP for jumping. This is correct.
  • starting in prone stance:
    UI shows 24 AP cost. The merc ends in standing stance so it takes 6 AP to stand up + 24 AP to jump + 6 AP to stand up afterwards. Now that doesn't make any sense. Why would the merc stand up when he starts prone? If he can't go prone on the other side he should at least stay crouched. This scenario needs fixing UI display of AP cost and merc stance.
Oh my... Bang head more



Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355629 is a reply to message #355627] Sat, 03 November 2018 23:00 Go to previous messageGo to next message
townltu

 
Messages:384
Registered:December 2017
Location: here
@ZedJA2 Well i was not offended at all, at any point, so no need to apologize!

Regarding my nick, feel free to use capitals where and whenever you like. :)
I must even admit my guilt of intendedly misspelling names for the purpose of insult and devalution,
back in the days when flamewars raved @7kB/s through a young, wild and nearly ad free internet.

Report message to a moderator

Master Sergeant
Re: Code Snippets[message #355630 is a reply to message #355628] Sun, 04 November 2018 00:03 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
Found what looks like a 100AP bug in PathAI.cpp
// ATE: if running, charge extra point to srart again
if ( usMovementModeToUseForAPs== RUNNING )
{
	sExtraCostStand++;
}

Probably should be
// ATE: if running, charge extra point to start again
if (usMovementModeToUseForAPs == RUNNING)
{
	sExtraCostStand += GetAPsStartRun(pSold);
}


Also in Soldier Control.cpp
// Only if our previous is not running
if ( this->usAnimState != RUNNING )
{
	// CHRISL
	if ( (UsingNewInventorySystem( ) == true) && FindBackpackOnSoldier( this ) != ITEM_NOT_FOUND )
	{
		sAPCost = GetAPsStartRun( this ) + 2; // changed by SANDRO
		sBPCost += 2;
	}
	else
		sAPCost = GetAPsStartRun( this ); // changed by SANDRO
	DeductPoints( this, sAPCost, sBPCost, MOVEMENT_INTERRUPT );
}

Why the +2 is added to GetAPsStartRun( this )? I don't understand.

[Updated on: Sun, 04 November 2018 00:15]




Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355643 is a reply to message #355630] Sun, 04 November 2018 18:56 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
What a mess...

I got the game to calculate the correct amount of AP for jumping fences in all different stance variations. It shows the correct amount on the UI and deducts it from the merc's available action points. Stance changes now cost AP instead of being partly free as before.

Stance behaviour is now as follows:
  • start standing - end standing
  • start crouched - end crouched
  • start prone - end prone
This is working fine if we just jump over the fence to the tile behind it. It's also working fine if we continue our movement in standing or crouched stance.
One problem I can't seem to figure out is continued movement in prone stance. Danny gets up from prone, jumps over the fence, lands in crouched stance and then he stands up!, goes prone after that and continues to move in prone stance. Why does that dumbass stand up after jumping over the fence??? He is wasting 12 AP for that nonsense.

@Sevenfm
The +2 are probably a small penalty for wearing a backpack.



Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355645 is a reply to message #355643] Sun, 04 November 2018 19:12 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
What I found strange is that modifiers are applied to some AP costs that should be fixed (in theory), for example we add AP to crouch and then reduce it with athletics trait or possibly increase because of diagonal movement. So I decided to rearrange AP costs in the following order:
1. Terrain (+)
2. Movement mode (+)
3. Reverse movement (+)
4. Backpack (+)
5. Athletics (*)
6. Scuba fins (*)
7. Swimming background (*)
8. Stealth (+)
9. Diagonal movement (*)
10. Fixed costs (fence crouch, door open, not standing modifier)

Where (+) is addition, and (*) is multiplication. Stealth moved after athletics because we have a separate trait for that.
In my tests in 7609+AI everything seems to work fine, I have done many tests including various movement modes, moving straight and diagonally and jumping over fence.
For some reason jumping over fence in crawling movement doesn't work in 7609, the merc will try to crawl around fence instead.

There are 3 places in the code where these changes are made (path calculation and AP limit for AI calculation in PATHAI.cpp, AP cost in Points.cpp).
Without changes to AI path limit (gubNPCAPBudget), AI will not work properly (taking cover etc).

[Updated on: Sun, 04 November 2018 19:22]




Left this community.

Report message to a moderator

Lieutenant

Re: Code Snippets[message #355649 is a reply to message #355645] Sun, 04 November 2018 19:52 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
I figured it out. The standing up nonsense after jumping came from code that was commented, which I had to uncomment but it was bugged (probably the reason why it was commented...) so I also had to fix it. Now the merc properly takes the stance that he should no matter if he continues his path after jumping over a fence or not.

I don't think I will ever touch that part of the code again because we evade one mine only to step on the next...

Btw. someone thought that jumping over fences isn't an exhausting activity so we needed 0 BP to do it. I don't agree with this and we now charge the correct amount of BP.

Anyway, all of this seems to be fixed now in r8635. Don't be surprised to see higher AP costs for jumping over fences. Each stance change now costs the proper amount of AP unlike before.

[Updated on: Sun, 04 November 2018 19:52]




Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Code Snippets[message #355659 is a reply to message #355649] Sun, 04 November 2018 21:35 Go to previous messageGo to previous message
ZedJA2

 
Messages:202
Registered:January 2018
Wow, what a story! You guys are like living archaelogists of ancient mysterious code. Tutankhamen is probably right around the corner or at least an old mummy in the zombie code!

Alright, so it seems the best plan, per what you guys are doing, is to change to the correct stance that you want to end up in, before you go over the fence. Or just be upright (standing or running) and then vault it, and change stance to something safer (crouching or prone) after the vault over the fence, if required. That would be reasonable and make a lot of sense.

Boy, r8635 is going to be a huge change for the better!

If I want to add this to my current campaign (which is new and yep the New Weapons on the Enemies are in there, it sure was interesting to be taking on some SMGs in Omerta, still not done there yet), will it work on the old save for SCI 8633.

Where would I get this r8635, if it is possible, once it is ready?

Report message to a moderator

Sergeant 1st Class
Previous Topic: New Attachment System Beta
Goto Forum:
  


Current Time: Fri Mar 29 07:21:28 GMT+2 2024

Total time taken to generate the page: 0.04582 seconds