Home » MODDING HQ 1.13 » v1.13 Coding Talk » Code Snippets  () 1 Vote
Re: Code Snippets[message #355664 is a reply to message #355659] Sun, 04 November 2018 23:14 Go to previous messageGo to next message
silversurfer

 
Messages:2500
Registered:May 2009
Unfortunately the next release date for the latest SCI and exe will be at the beginning of December. Because of that I uploaded the new 8635 exe to my personal folder on SVN. You can download it here.

MD5 checksum: 6ba2368f301b92aa5ecfa63c72af684c



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

Re: Code Snippets[message #355680 is a reply to message #355664] Mon, 05 November 2018 22:50 Go to previous messageGo to next message
ZedJA2

 
Messages:162
Registered:January 2018
What I downloaded comes as a 0 byte JA2_8635.exe file and as a JA@_8635.exe.part file of 8646 KB. Do I have to process this somehow? When I go ahead and have 7-Zip unpack the archive, it then has a rsrc, data, and other folder. Am I supposed to then start the JA2_8635.exe file in the same folder or is this some sort of thing I need to compile or use SVN software on?
Re: Code Snippets[message #355681 is a reply to message #355680] Mon, 05 November 2018 22:54 Go to previous messageGo to next message
silversurfer

 
Messages:2500
Registered:May 2009
The file is over 8MB in size. Your download wasn't finished correctly.



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

Re: Code Snippets[message #355923 is a reply to message #355681] Wed, 21 November 2018 16:21 Go to previous messageGo to next message
sevenfm

 
Messages:1823
Registered:December 2012
Location: Soviet Russia
Overhead.cpp, CheckStatusNearbyFriendlies()
UINT8 ubLevelDifference = 0;
...
ubLevelDifference = (pLeader->stats.bExpLevel - pSoldier->stats.bExpLevel );
...

What will happen if pLeader->stats.bExpLevel < pSoldier->stats.bExpLevel?

Later the code checks:
if ( ubLevelDifference >= 0 )

which makes no sense at all because UINT8 cannot be negative.
Something is definitely wrong here.

[Updated on: Wed, 21 November 2018 16:33]




7609+fix | 7609+AI (r946) | 7609 unofficial modpack | Win8+ fix | Experimental project | Vengeance:Reloaded | Youtube

"It's already "dog-eat-dog", friend. Not sure what worse a bunch of zombies could do."


Re: Code Snippets[message #355928 is a reply to message #355923] Wed, 21 November 2018 20:58 Go to previous messageGo to next message
sevenfm

 
Messages:1823
Registered:December 2012
Location: Soviet Russia
Soldier Profile.cpp, DoesMercHaveABuddyOnTheTeam()

UINT8	bBuddyID;
//If its not a valid 'buddy'
if( bBuddyID < 0 )
	continue;

I don't think it will work well. Maybe check for 255 instead?
if( bBuddyID == 255 )
	continue;



7609+fix | 7609+AI (r946) | 7609 unofficial modpack | Win8+ fix | Experimental project | Vengeance:Reloaded | Youtube

"It's already "dog-eat-dog", friend. Not sure what worse a bunch of zombies could do."


Re: Code Snippets[message #355997 is a reply to message #355928] Mon, 26 November 2018 20:45 Go to previous messageGo to next message
sevenfm

 
Messages:1823
Registered:December 2012
Location: Soviet Russia
AIUtils.cpp

GetClosestFlaggedSoldierID()
GetClosestWoundedSoldierID()
GetClosestMedicSoldierID()

// this is not for tanks
if ( ARMED_VEHICLE( pFriend ) )
	return FALSE;


should be
// this is not for tanks
if ( ARMED_VEHICLE( pFriend ) )
	continue;


Funny bug, makes the game think there are prisoners of war/medics/wounded soldiers if there is tank in sector, as it returns FALSE (0) which points to the first ID in player team.



7609+fix | 7609+AI (r946) | 7609 unofficial modpack | Win8+ fix | Experimental project | Vengeance:Reloaded | Youtube

"It's already "dog-eat-dog", friend. Not sure what worse a bunch of zombies could do."


Re: Code Snippets[message #356084 is a reply to message #355997] Sun, 02 December 2018 16:59 Go to previous messageGo to next message
silversurfer

 
Messages:2500
Registered:May 2009
Thanks for spotting those bugs. Fixed in r8643.



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

Re: Code Snippets[message #356091 is a reply to message #355649] Mon, 03 December 2018 17:11 Go to previous messageGo to next message
sevenfm

 
Messages:1823
Registered:December 2012
Location: Soviet Russia
silversurfer wrote on Sun, 04 November 2018 22:52
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.

Just a minor issue - if you order merc to jump using [j] key, he will always stand up no matter what his original stance was (though the game at least correctly deducts AP points for standing). Could be dangerous in some situations.

Also maybe you know what prevents prone merc from plotting path over fence? In theory, he could crawl to it, jump over, and then continue crawling. It would be good for AI to allow crawling movement over fences, currently it limits usefulness of this movement mode for AI as it cannot plot path over fences.

[Updated on: Mon, 03 December 2018 17:25]




7609+fix | 7609+AI (r946) | 7609 unofficial modpack | Win8+ fix | Experimental project | Vengeance:Reloaded | Youtube

"It's already "dog-eat-dog", friend. Not sure what worse a bunch of zombies could do."


Re: Code Snippets[message #356093 is a reply to message #356091] Mon, 03 December 2018 17:55 Go to previous messageGo to next message
silversurfer

 
Messages:2500
Registered:May 2009
Plotting for a prone merc works for me but I noticed that he doesn't properly jump the fence if he is some tiles away at the start. He will crawl to the fence and then I get a spinning clock. This resolves itself after some seconds but the merc stays prone in front of the fence. If I press "c" to crouch he will automatically jump the fence and continue his path in squatting mode. Maybe the game has a problem with the stance that the merc would need to take after fence jumping because he can't go prone in that scenario. Maybe that was the reason for the automatic switch to standing stance?

[Updated on: Mon, 03 December 2018 17: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

Re: Code Snippets[message #356102 is a reply to message #356093] Wed, 05 December 2018 06:18 Go to previous messageGo to next message
sevenfm

 
Messages:1823
Registered:December 2012
Location: Soviet Russia
LOS.cpp, LineOfSightTest()

Penalty from smoke effect in tile
if ( pMapElement->ubExtFlags[0] & (MAPELEMENT_EXT_SMOKE | MAPELEMENT_EXT_TEARGAS | MAPELEMENT_EXT_MUSTARDGAS | MAPELEMENT_EXT_BURNABLEGAS | MAPELEMENT_EXT_DEBRIS_SMOKE) )
{
	if ( (pMapElement->ubExtFlags[0] & (MAPELEMENT_EXT_SMOKE | MAPELEMENT_EXT_DEBRIS_SMOKE) ) && !fSmell )
	{
		bSmoke++;

		if ( bSmoke >= 3 )
		{
			iAdjSightLimit = 0;
		}
	}
	else
	{
		// reduce by 2 tiles per tile of tear gas or mustard gas
		iAdjSightLimit -= 2 * CELL_X_SIZE;
	}

	if ( iAdjSightLimit <= 0 )
	{
		// can't see, period!
		return( 0 );
	}
}


It checks for smoke effect on ground level, as a result, smoke on ground level will affect LOS check on roof, and smoke on roof will not work at all.



7609+fix | 7609+AI (r946) | 7609 unofficial modpack | Win8+ fix | Experimental project | Vengeance:Reloaded | Youtube

"It's already "dog-eat-dog", friend. Not sure what worse a bunch of zombies could do."


Re: Code Snippets[message #356103 is a reply to message #356093] Wed, 05 December 2018 09:15 Go to previous messageGo to next message
ZedJA2

 
Messages:162
Registered:January 2018
That actually makes a lot of sense. There are numerous places where you cannot go prone, but think you can, and usually these are near objects of some kind, like trees or fences.

Perhaps then, the better fix (but more involved) would be to allow the character to go to the Standing stance, but not cost anything to choose whatever ending stance they use once having jumped over the obstacle.

I mean, in real life, you would just choose what amount of leg power you want to use as you drop from the jump, and then just either stand, or reduce leg strength and fall with gravity into a crouch, or then drop fully, again mostly reducing leg strength to counter gravity and fall forward. Arguably, the soldier could do almost all of these in about the same amount of time, and with similar amounts of effort to achieve any post-jump stance, so using APs to choose stance after the obstacle is rather nonsensical. You use energy to clear the obstacle, not so much to hit the dirt or remain standing. Your final stance could be anything you chose after jumping, the AP cost would practically be the same, as would the time involved (if well practiced and used to hitting the dirt/hard ground).

So, if this is just a mechanic, the standing up first, to make sure you fit in the terrain available, because then it checks to see if it can go prone, but it cannot since not enough "room" to go prone in the terrain -- that's really the solution.

The problem is that standing after jumping may burn extra APs, and or doing prone after standing per the game's MECHANICS. Perhaps we just have to make sure what all stances after jumping back to ground, cost the same. Well also with climbing to the roof. You constantly waste APs because you are first forced into a crouched stance when you climb to the top and arrive on the roof, when in reality, when you pull yourself over the ledge, you will go with your momentum and finish at the stance you decide (barring injury). There is energy burnt there for taller stances when climbing though. But not when jumping downwards after you clear an obstacle or when jumping down to the ground. So I do believe you are right, SilverSurfer, that it is just an odd way to check for terrain clearance to fit a prone character in that direction. That's the other part of it as well, you don't get to choose what direction you face when you clear the fence -- which forces you to fit in certain terrain but not others depending on the room available when perhaps a mere turn of 90 degrees would avoid the change in stance.

[Updated on: Wed, 05 December 2018 09:17]

Re: Code Snippets[message #356132 is a reply to message #356103] Sun, 09 December 2018 11:51 Go to previous messageGo to next message
silversurfer

 
Messages:2500
Registered:May 2009
I did some tests today with the spinning clock while trying to cross a fence in prone stance. The spinning clock happens only in turn based mode. In realtime mode the character only stops at the fence but there is no spinning clock. Looks like it doesn't have anything to do with the fixes in r8635. I started r8626 and the problem exists there as well. It doesn't seem related to a stance check for the tile behind the fence. The game doesn't even get to the function that checks for valid stances. So far I haven't found the location that causes the spinning clock. If someone else wants to take a look at this I would appreciate 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

Re: Code Snippets[message #356142 is a reply to message #356132] Mon, 10 December 2018 23:19 Go to previous messageGo to next message
sevenfm

 
Messages:1823
Registered:December 2012
Location: Soviet Russia
XML_Merge.cpp
struct
{
	PARSE_STAGE	curElement;

	CHAR8		szCharData[MAX_CHAR_DATA_LENGTH+1];

	UINT16			curMerge[6];
	UINT32			maxArraySize;
	UINT32			curIndex;
	UINT32			currentDepth;
	UINT32			maxReadDepth;
}
typedef mergeParseData;

later curMerge[6] is initialised
memset(&pData->curMerge,0,sizeof(UINT16[4]));

something like
memset(&pData->curMerge,0,sizeof(pData->curMerge);

should work better.

[Updated on: Mon, 10 December 2018 23:19]




7609+fix | 7609+AI (r946) | 7609 unofficial modpack | Win8+ fix | Experimental project | Vengeance:Reloaded | Youtube

"It's already "dog-eat-dog", friend. Not sure what worse a bunch of zombies could do."


Re: Code Snippets[message #356150 is a reply to message #356142] Wed, 12 December 2018 06:10 Go to previous message
sevenfm

 
Messages:1823
Registered:December 2012
Location: Soviet Russia
Items.cpp, AttachObjectNAS()

case COMBINE_POINTS:
...
// add part of this one and then we're done
attachmentAmount = (UINT16)(*pAttachment)[0]->data.objectStatus;
attachmentAmount -= (ubLimit - (UINT16)(*this)[subObject]->data.objectStatus);
(*pAttachment)[0]->data.objectStatus = attachmentAmount;
if ((*pAttachment)[0]->data.ubShotsLeft == 0) {
	pAttachment->RemoveObjectsFromStack(1);
}
(*this)[subObject]->data.ubShotsLeft = ubLimit;
break;

Why the code checks for shots left instead of objectStatus? This merge doesn't change shots left, only item status.
In my view, this code should look like:
if ((*pAttachment)[0]->data.objectStatus == 0) {
	pAttachment->RemoveObjectsFromStack(1);
}
(*this)[subObject]->data.objectStatus = ubLimit;
break;

Can anyone explain it please?

Another strange code in Weapons.cpp, UseThrown()
HandleSoldierThrowItem(pSoldier, pSoldier->sTargetGridNo);
pSoldier->inv[HANDPOS].RemoveObjectsFromStack(1);
...
// anv: knife throw attack noise
UINT16 usUBItem = pSoldier->GetUsedWeaponNumber( &pSoldier->inv[ pSoldier->ubAttackingHand ] );
UINT8 ubVolume = Weapon[ usUBItem ].ubAttackVolume;
MakeNoise( pSoldier->ubID, pSoldier->sGridNo, pSoldier->pathing.bLevel, pSoldier->bOverTerrainType, ubVolume, NOISE_UNKNOWN );

return( TRUE );

First we destroy the object in hands (thrown grenade), then check if weapon in hand has attack volume.

[Updated on: Wed, 12 December 2018 06:11]




7609+fix | 7609+AI (r946) | 7609 unofficial modpack | Win8+ fix | Experimental project | Vengeance:Reloaded | Youtube

"It's already "dog-eat-dog", friend. Not sure what worse a bunch of zombies could do."


Previous Topic: New Attachment System Beta
Goto Forum:
  


Current Time: Wed Feb 20 17:53:57 EET 2019

Total time taken to generate the page: 0.02646 seconds