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
|
|
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 #355351 is a reply to message #353872]
|
Tue, 16 October 2018 15:04
|
|
silversurfer |
|
Messages:2793
Registered:May 2009 |
|
|
sevenfm wrote on Fri, 22 June 2018 19:00in 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%20MODReport message to a moderator
|
|
|
|
|
|
Re: Code Snippets[message #355511 is a reply to message #355510]
|
Mon, 29 October 2018 21:23
|
|
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
|
|
|
|
Re: Code Snippets[message #355512 is a reply to message #355511]
|
Mon, 29 October 2018 22:08
|
|
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
|
|
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
|
|
|
|
|
Re: Code Snippets[message #355515 is a reply to message #355514]
|
Mon, 29 October 2018 23:04
|
|
Deleted. |
|
Messages:2663
Registered:December 2012 Location: Russian Federation |
|
|
edmortimer wrote on Tue, 30 October 2018 02:00Does 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
|
|
|
|
|
Re: Code Snippets[message #355523 is a reply to message #355517]
|
Tue, 30 October 2018 07:22
|
|
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
|
|
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 SpoilerSince AI is designed as aggressive in vanilla game, this function is mostly used to aggressively advance to closest enemy, ignoring any cover, when at the start of the turn, and seek cover when having very low AP at the end of the turn. And obviously it never takes sight cover into consideration, because why should it bother with such minor detail?
[Updated on: Tue, 30 October 2018 16:35]
Left this community.Report message to a moderator
|
|
|
|
Re: Code Snippets[message #355528 is a reply to message #355525]
|
Tue, 30 October 2018 12:11
|
|
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
|
|
|
|
Re: Code Snippets[message #355532 is a reply to message #355528]
|
Tue, 30 October 2018 16:47
|
|
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[code]
else // noise maker still can't be seen
{
SetNewSituation( pSoldier ); // re-evaluate situation
// if noise type was unmistakably that of gunfire
if (((ubNoiseType == NOISE_GUNFIRE) || (ubNoiseType == NOISE_BULLET_IMPACT)) && (ubVolume >= 3))
{
// if status is only GREEN or YELLOW
if (pSoldier->aiData.bAlertStatus < STATUS_RED)
{
// then this soldier goes to status RED, has proof of enemy presence
pSoldier->aiData.bAlertStatus = STATUS_RED;
CheckForChangingOrders(pSoldier);
}
}
[/pre] [/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%20MODReport message to a moderator
|
|
|
|
|
|
Re: Code Snippets[message #355576 is a reply to message #355537]
|
Thu, 01 November 2018 23:30
|
|
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
|
|
|
|
Re: Code Snippets[message #355578 is a reply to message #355576]
|
Fri, 02 November 2018 00:01
|
|
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 #355583 is a reply to message #355579]
|
Fri, 02 November 2018 02:08
|
|
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 #355592 is a reply to message #355589]
|
Fri, 02 November 2018 11:57
|
|
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 #355609 is a reply to message #355602]
|
Fri, 02 November 2018 23:34
|
|
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 #355614 is a reply to message #355578]
|
Sat, 03 November 2018 14:11
|
|
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 #355623 is a reply to message #355620]
|
Sat, 03 November 2018 19:45
|
|
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
|
|
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
|
|
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 #355629 is a reply to message #355627]
|
Sat, 03 November 2018 23:00
|
|
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
|
|
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
|
|
|
|
|
Re: Code Snippets[message #355645 is a reply to message #355643]
|
Sun, 04 November 2018 19:12
|
|
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
|
|
|
|
|
Re: Code Snippets[message #355659 is a reply to message #355649]
|
Sun, 04 November 2018 21:35
|
|
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
|
|
|
Goto Forum:
Current Time: Fri Mar 29 07:21:28 GMT+2 2024
Total time taken to generate the page: 0.04582 seconds
|