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:2588
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:175
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:2588
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:1926
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 (r1141) | Unofficial modpack | Win8+ fix | Experimental project | 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:1926
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 (r1141) | Unofficial modpack | Win8+ fix | Experimental project | 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:1926
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 (r1141) | Unofficial modpack | Win8+ fix | Experimental project | 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:2588
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:1926
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 (r1141) | Unofficial modpack | Win8+ fix | Experimental project | 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:2588
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:1926
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 (r1141) | Unofficial modpack | Win8+ fix | Experimental project | 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:175
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:2588
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:1926
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 (r1141) | Unofficial modpack | Win8+ fix | Experimental project | 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 messageGo to next message
sevenfm

 
Messages:1926
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 (r1141) | Unofficial modpack | Win8+ fix | Experimental project | Youtube

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


Re: Code Snippets[message #357817 is a reply to message #356150] Fri, 09 August 2019 20:11 Go to previous messageGo to next message
sevenfm

 
Messages:1926
Registered:December 2012
Location: Soviet Russia
Looking at HourlyUpdate.lua
-- Bar/night club
if ( cHour >= 15 or cHour < 2) then
	
	SetFactTrue( Facts.FACT_CLUB_OPEN )
	SetFactFalse( Facts.FACT_PAST_CLUB_CLOSING_AND_PLAYER_WARNED )

	-- Reset boxes fought
	for i = 0,2 do
		-- Set false
		gfBoxerFought(i,false)
	end

	-- If # of boxing matches the player has won is a multiple of
	-- 3, and the boxers haven't rested, then make them rest
		
	if ( gfBoxersResting == true ) then
			
		-- Done resting now!
		gfBoxersResting = false
		gubBoxersRests = gubBoxersRests + 1
			
		p = gubBoxingMatchesWon / 3
			
	elseif ( p > gubBoxersRests ) then
		-- Time for the boxers to rest!
		gfBoxersResting = true
	end

else
	SetFactFalse( Facts.FACT_CLUB_OPEN )
end

I don't think it will work. This script gets access to gfBoxersResting and gubBoxersRests by registering them in Luaglobal.cpp
lua_pushboolean(L, gfBoxersResting);
lua_setglobal(L, "gfBoxersResting");
	
lua_pushinteger(L, gubBoxersRests);
lua_setglobal(L, "gubBoxersRests");
But as far as I understand, it only allows read access to C++ variables, so the code
gfBoxersResting = false
gubBoxersRests = gubBoxersRests + 1
doesn't change anything actually.
I think we need new functions l_SetgfBoxersResting and l_SetgubBoxersRests and use them in lua like:
SetgfBoxersResting(false)
SetgubBoxersRests(gubBoxersRests + 1)
Also, comparing the code with original C++ hardcoded hourly update, it looks very strange, for example, in original code we only execute it twice, at 15 and 2 hour, not every hour between 15 and 2.
Currently, even if lua script would work, it would change gfBoxersResting = true to false immediately next hour after the player have won the third battle, instead of waiting for the next day's 15 hour.
And I don't understand why use local p variable?

Currently, my HourlyUpdate.lua looks like:
Toggle Spoiler
and seems to work well.

Also, in l_ResetBoxers() function which is called every time player loads sector, gfBoxerFought[] is reset:
// set boxer ids back to NOBODY, so they can be reinitialised
static int l_ResetBoxers( lua_State *L )
{
	for ( UINT8 i = 0; i < NUM_BOXERS; ++i )
	{
		gubBoxerID[i] = NOBODY;
		gfBoxerFought[i] = FALSE;
	}

	return 0;
}
which is incorrect in my view, because gfBoxerFought[] should be reset in lua script every day at 15 hours, not every time player enters sector.

Also, after you have fought 3 times, manager will not talk with you, but if you wait until after midnight but before 2 hours, something is reset in his script and he will talk to you, allowing you to fight. Something in his script is reset every day at 24:00, but I dont't know where to find it.

What do you boxing/lua experts think?

[Updated on: Fri, 09 August 2019 22:26]




7609+fix | 7609+AI (r1141) | Unofficial modpack | Win8+ fix | Experimental project | Youtube

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


Re: Code Snippets[message #357832 is a reply to message #357817] Sun, 11 August 2019 11:37 Go to previous messageGo to next message
silversurfer

 
Messages:2588
Registered:May 2009
I'm no expert on boxing or lua but here are my 2 cents:

The reason why HourlyUpdate.lua was changed to check every hour between 15 and 2 was probably because some of the checks need to be done every hour. Ok, we do not need to reset the FACTs every hour. We also do not need to reset gfBoxerFought.
However, we should set gfBoxersResting to true when we have done 3 fights, no matter if it is 17 or 23 or whatever on the clock.

So the bar code should look like this:
Toggle Spoiler

I think you are right that ResetBoxers() should be removed from strategicmap.lua and instead be used in HourlyUpdate.lua and we may need new functions to set gfBoxersResting and gubBoxersRests.



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 #357842 is a reply to message #357832] Mon, 12 August 2019 04:48 Go to previous messageGo to next message
sevenfm

 
Messages:1926
Registered:December 2012
Location: Soviet Russia
silversurfer wrote on Sun, 11 August 2019 13:37
However, we should set gfBoxersResting to true when we have done 3 fights, no matter if it is 17 or 23 or whatever on the clock.
I think the original idea was that if player wins 3 fights, next day at 15 hours gfBoxersResting is set to true, as a result, player cannot fight this day, next day at 15 hours gfBoxersResting is set to false and player can fight again.
If we set gfBoxersResting immediately after the player have won 3 fights, next day at 15 hours it will be set to false and player can fight again, making the resting system useless as player now can fight 3 times every day and not waiting for one day between fights as it was in vanilla.

Quote:
I think you are right that ResetBoxers() should be removed from strategicmap.lua and instead be used in HourlyUpdate.lua and we may need new functions to set gfBoxersResting and gubBoxersRests.
I think that ResetBoxers() should stay wehere it is now, because as I understand it it is called when new sector is loaded, and it's function since vanilla was to clean boxers IDs so the game can assign new ids for newly loaded sector. BoxersFought should be cleared at 15 hours every day as it was in vanilla, when the club opens, at least it's how I understand it at the moment.

With my changes, boxing seems to work better than before, but one problem still exists - Darren's dialogue status seems to be reinitialized only at 00:00, that means even if boxers are not resting and all 3 are available, you cannot have "another fight" until 00:00, that makes opening club at 15 hours meaningless. Unfortunately, I don't know where to look for Darren's dialogue and script to make it reset "another fight" option to 15 hours.

[Updated on: Mon, 12 August 2019 04:58]




7609+fix | 7609+AI (r1141) | Unofficial modpack | Win8+ fix | Experimental project | Youtube

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


Re: Code Snippets[message #357847 is a reply to message #357842] Mon, 12 August 2019 15:34 Go to previous messageGo to next message
silversurfer

 
Messages:2588
Registered:May 2009
Ok, if that additional delay of one day is intended we should set gfBoxersResting = true the next day as you do with your current script.

gfBoxerFought is cleared by function ResetBoxers() so if you leave that in strategicmap.lua it will be cleared every time sector D5 is loaded. If you don't want that you should remove "gfBoxerFought[i] = FALSE;" from function ResetBoxers() in LuaInitNPCs.cpp.

Regarding Darren's dialogue you should look at his NPC scripts. It's Data-1.13\NpcData\87.npc. In record 26 there is a condition check for fact 230 "FACT_NO_CLUB_FIGHTING_ALLOWED". When this is true he will respond with audio record 30 telling you that the boxers still need some rest. There is also a record 7 that has the same fact condition with a similar audio record 33.

If you set fact "FACT_NO_CLUB_FIGHTING_ALLOWED" to false when you allow boxing again at 15 o'clock in HourlyUpdate.lua this should unblock his dialogue. Just don't forget to set "FACT_NO_CLUB_FIGHTING_ALLOWED" to true when you send the boxers to rest.



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 #357850 is a reply to message #357847] Mon, 12 August 2019 22:26 Go to previous messageGo to next message
sevenfm

 
Messages:1926
Registered:December 2012
Location: Soviet Russia
@silversurfer
There is 087.NPC file in Wildfire 6.07 svn, is it different from original script? Maybe it already has some fixes implemented. Or it can be safely removed?



7609+fix | 7609+AI (r1141) | Unofficial modpack | Win8+ fix | Experimental project | Youtube

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


Re: Code Snippets[message #357853 is a reply to message #357850] Tue, 13 August 2019 00:14 Go to previous messageGo to next message
silversurfer

 
Messages:2588
Registered:May 2009
I'm not sure. The WF script has modified records 21 to 24 with additional conditions set. I wouldn't remove the file.



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 #357861 is a reply to message #357853] Tue, 13 August 2019 14:35 Go to previous messageGo to next message
sevenfm

 
Messages:1926
Registered:December 2012
Location: Soviet Russia
Something I don't understand in Lua, for example if I use test script:
-- Bar/night club
if ( cHour == 15 ) then
	SetScreenMsg(FontColour.FONT_MCOLOR_DKWHITE, "Boxing club opened")
	SetFactTrue( Facts.FACT_CLUB_OPEN )
	SetFactFalse( Facts.FACT_PAST_CLUB_CLOSING_AND_PLAYER_WARNED )
elseif ( cHour == 2 ) then
	SetScreenMsg(FontColour.FONT_MCOLOR_DKWHITE, "Boxing club closed")
	SetFactFalse( Facts.FACT_CLUB_OPEN )
end
The message "Boxing club opened" will appear at 16:00 and "Boxing club closed" will appear at 3:00.
At the same time, Darren appears in club at correct time 15:00 and disappears at 2:00.

cHour is defined in LuaGlobal.cpp as uiHourLua
lua_pushinteger(L, uiHourLua);
lua_setglobal(L, "cHour");
and uiHourLua is defined in Game Closck.cpp as:
guiHour = ( guiGameClock - ( guiDay * NUM_SEC_IN_DAY ) ) / NUM_SEC_IN_HOUR;
uiHourLua = guiHour;
So it should work correctly, but it doesn't.
If I add
cHour = GetWorldHour()
to the start of HourlyQuestUpdate() in HourlyUpdate.lua, the script suddenly starts to work correctly and opens club at 15:00

[Updated on: Tue, 13 August 2019 14:47]




7609+fix | 7609+AI (r1141) | Unofficial modpack | Win8+ fix | Experimental project | Youtube

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


Re: Code Snippets[message #357862 is a reply to message #357861] Tue, 13 August 2019 18:00 Go to previous messageGo to next message
silversurfer

 
Messages:2588
Registered:May 2009
Having cHour = GetWorldHour() at the start of HourlyUpdate.lua doesn't hurt so I think you should leave it there as a safety measure.

Have you tried modifying FACT_NO_CLUB_FIGHTING_ALLOWED when you modify the resting status of the boxers? My hope is that it updates Darren immediately instead of 24:00 o'clock.



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 #357863 is a reply to message #357862] Tue, 13 August 2019 21:09 Go to previous messageGo to next message
sevenfm

 
Messages:1926
Registered:December 2012
Location: Soviet Russia
Also it seems that
if ( gubBoxingMatchesWon / 3 > gubBoxersRests ) then
doesn't work because the resulting value is probably float in lua, unlike c++, so I changed it to
if ( math.floor(gubBoxingMatchesWon / 3) > gubBoxersRests ) then
and it seems to work correctly now.
Maybe it was the reason of p variable introduction? But it has no type, I doubt it auto converts value into int.

silversurfer wrote on Tue, 13 August 2019 20:00
Have you tried modifying FACT_NO_CLUB_FIGHTING_ALLOWED when you modify the resting status of the boxers? My hope is that it updates Darren immediately instead of 24:00 o'clock.
As I understand it, FACT_NO_CLUB_FIGHTING_ALLOWED is defined dynamically each time NPC script asks for it:
quests.cpp
case FACT_NO_CLUB_FIGHTING_ALLOWED:
	SOLDIERTYPE * pKingpin;
	pKingpin = FindSoldierByProfileID( KINGPIN, FALSE );
	if ( pKingpin )
		gubFact[usFact] = ( gubQuest[ QUEST_KINGPIN_MONEY ] == QUESTINPROGRESS || gfBoxersResting || ( !BoxersAvailable() && PythSpacesAway(pKingpin->sGridNo, gModSettings.iKingpinRingTile) > 2 ) );
	else
		gubFact[usFact] = TRUE;
	break;
The problem here is that we need BoxersAvailable() check, or Darren will allow boxing matches sometimes with unavailable boxers due to the way his script works, but if we just leave this check, he will not give money after fight, because conditions 21, 22, 23 check FACT_NO_CLUB_FIGHTING_ALLOWED (for no reason in my opinion, because if they are called that means that fight already happened, so no need for additional check).
Currently PythSpacesAway(pKingpin->sGridNo, gModSettings.iKingpinRingTile) > 2 condition is used to allow finishing fight and giving money when all boxers are beaten/killed, but it's not reliable, because there can be cases when Kingpin stands near ring but there are no boxers available, then player can wait until midnight, Darren's script will refresh and allow him to fight, resulting in a bug.

[Updated on: Tue, 13 August 2019 21:13]




7609+fix | 7609+AI (r1141) | Unofficial modpack | Win8+ fix | Experimental project | Youtube

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


Re: Code Snippets[message #357951 is a reply to message #357863] Fri, 23 August 2019 13:57 Go to previous messageGo to next message
sevenfm

 
Messages:1926
Registered:December 2012
Location: Soviet Russia
Something I don't understand.
Weapons.cpp, CalcChanceHTH()
// CALCULATE ATTACKER'S CLOSE COMBAT RATING (1-100)
if (ubMode == HTH_MODE_STEAL)
{
	///////////////////////////////////////////////////////////////////////////////////////
	// SANDRO - Enhanced Close Combat System - different calculation for stealing
	if (gGameExternalOptions.fEnhancedCloseCombatSystem)
	{
		// We need to be agile and dexterous
		iAttRating = ( 2 * EffectiveDexterity( pAttacker, FALSE ) + // coordination, accuracy  *
				 2 * EffectiveAgility( pAttacker, FALSE ) +    // speed & reflexes
			     pAttacker->stats.bStrength +    // physical strength 
				 pDefender->bExtraStrength +    // additional strength from power armour
				 (10 * EffectiveExpLevel( pAttacker ) ) );  // experience, knowledge
	}
...
We add attacker's strength but defender's extra strength? How defender's strengh can help to steal weapon?
At the same time, when we calculate defender's rating, we only use his strength:
// CALCULATE DEFENDER'S CLOSE COMBAT RATING (0-100)
if (ubMode == HTH_MODE_STEAL)
{
	// SANDRO - Enhanced Close Combat System - stealing defence based on dexterity and strength
	if (gGameExternalOptions.fEnhancedCloseCombatSystem)
	{
		iDefRating = ( EffectiveAgility( pDefender, FALSE )) +   // speed & reflexes
		   2 * EffectiveDexterity( pDefender, FALSE ) +  // coordination, accuracy
		   2 * pDefender->stats.bStrength +    // physical strength 
		   2 * pDefender->bExtraStrength +    // additional strength from power armour
		   (10 * EffectiveExpLevel( pDefender ) );  // experience, knowledge
	}
...



7609+fix | 7609+AI (r1141) | Unofficial modpack | Win8+ fix | Experimental project | Youtube

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


Re: Code Snippets[message #357953 is a reply to message #357951] Fri, 23 August 2019 14:58 Go to previous message
silversurfer

 
Messages:2588
Registered:May 2009
That sounds like a bug to me. It should be "pAttacker->bExtraStrength" instead of "pDefender->bExtraStrength". After all we want to know how strong the attacker is.

The different weight of the attributes seems ok to me. The attacker needs more agility to use the element of surprise and the defender focuses more on strength to keep his weapon.



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

Previous Topic: New Attachment System Beta
Goto Forum:
  


Current Time: Sat Aug 24 21:08:56 EEST 2019

Total time taken to generate the page: 0.02806 seconds