Home » MODDING HQ 1.13 » v1.13 Coding Talk » Code Snippets
() 1 Vote
Re: Code Snippets[message #191140]
|
Fri, 18 July 2008 22:02
|
|
Khor1255 |
|
Messages:1817
Registered:August 2003 Location: Pleasantville, NJ |
|
|
The miracle shot thing needs to be fixed. Autofire is already accurate enough. If you plan to increase it's accuracy please do so in an adjustable manner.
In fact, it would be nice to have all accuracy modifyers adjustable. But better than adjustable is back to the way it was in vanilla Ja2.
EDIT
Did I say that? No, of course anything adjustable is much better than not adjustable. What I meant to say is that it would be nice to 'revert' to the way the game originally made the calculation then externalise any modifying factor. This way not only could those who have a different idea about the balance could make the game the way they want it but we could also have wide differences in weapons in a project that uses both the new modifyers and weapons that are closer to the vanilla calculation.
Any diversity we can add to weaponmods gives modders more tools to work with.
But yea, fix the 1 in 100 nonsense. Perhaps some negative modifyer would be cool that is adjustable. Perhaps factoring something in to the 1-100 'roll' is possible to prevent this random exploit.
[Updated on: Fri, 18 July 2008 22:21] by Moderator Report message to a moderator
|
Sergeant Major
|
|
|
Re: Code Snippets[message #191145]
|
Fri, 18 July 2008 22:25
|
|
KEN C |
|
Messages:244
Registered:May 2007 Location: Aberdeen Washington USA |
|
|
Headrock,
Please check out the "hail mary thread". SpaceViking has been investigating this and several other issues.
My concern is that changes can be externalized so as to be optional rather than mandatory.
I would also like to call to your attention the idea that last winter there was a general plea from many (several) of the most skilled modders and others to create a "milestone release" ie; JA2 1.13 V1.0 possibly having an annual update so that these talented people can start, develop, and complete mods. I do believe this one thing would advance the 1.13 mod base project tremendously as it would soon generate several new mods and therefore attract new interest. Can you help with that idea?
[Updated on: Fri, 18 July 2008 22:55] by Moderator Report message to a moderator
|
Sergeant 1st Class
|
|
|
|
Re: Code Snippets[message #191150]
|
Fri, 18 July 2008 22:54
|
|
Headrock |
|
Messages:1760
Registered:March 2006 Location: Jerusalem |
|
|
Externalizing this shouldn't be hard at all. In my code above you can see that I roll for 9 out of 10 (or 9 out of 9, I'm never sure about randomize functions...). So either or both values can be altered.
The formula essentially looks like this (after a small change, "<=" to "=" ):
if ( Random( A ) > B )
{
iChance = MINCHANCETOHIT;
}
else
{
iChance = MINCHANCETOHIT+1;
}
A and B can be externalized. If they're both set to the same number (preferably 1) then it functions as though nothing's been changed (1/100 bullets will hit, because the output of this clause would be MinChanceToHit+1, which equals 1 percent chance). The greater the A, the more likely it is to give a 0% CTH. Increase B alongside A to get more finely-tuned odds. Also, to make absolutely sure, we could also externalize Minchancetohit (And Maxchancetohit if we want!)
@ Khor:
It would be impossible to get anywhere near vanilla values, mainly because so much has been added already. The formula is VERY complex and includes data from several new sources. I don't even remember what vanilla was like in this resepct. But I do agree that the CTH formula is in line for a good revamp.
@ N000B:
I haven't been around so I don't know about milestone releases, nor am I responsible for such stuff. I just come up with ideas - it's up to the 1.13 team to decide whether and how those ideas could possibly fit into 1.13.
Report message to a moderator
|
|
|
|
|
|
Re: Code Snippets[message #191155]
|
Sat, 19 July 2008 00:06
|
|
KEN C |
|
Messages:244
Registered:May 2007 Location: Aberdeen Washington USA |
|
|
@Headrock, Sorry to step on your toes, but after reading your postings this morning I mistakenly assumed that you were part of the development team. But from your postings, I am very glad you are back as "good help is hard to find".
Report message to a moderator
|
Sergeant 1st Class
|
|
|
|
|
Re: Code Snippets[message #191172]
|
Sat, 19 July 2008 02:56
|
|
Headrock |
|
Messages:1760
Registered:March 2006 Location: Jerusalem |
|
|
Thanks. I don't know if I could be of much help though. If you recall, it took a massive effort for us to get the NIV project going - for about a year or so we were told that it was impossible and would take many indirectly-related changes to the code that were low on the priority list, and we didn't get any better answers or explanations at all - if you remember, the project eventually kicked off simply because someone (Bartek) suddenly discovered how easy it was to add new and useable pockets... And even when the project did kick start we had to rely on at-that-time newcomers to make most of the modifications.
But that's not to say I blamed the core team because this is still a volunteer project and because I agree that the top priority of 1.13 is to add moddability. What annoyed me back then was that moddability was at a peak at that time (as evidence, you're using the build that directly preceded the NIV project) so it made no sense to me at the time why coders were still busting their heads on more complex moddability projects when just a little help on the NIV would've brought that project to completion much earlier, freeing all of us to aid the moddability effort...
Frankly, had I known it would cause issues to moddability, I'd have leaned more towards making the NIV a standalone mod. In hindsight it would make much more sense to take all the improvements to 1.13 and turn them into a downloadable "collection" mod - that means mobile militia, autofire, heck even the 1000+ item list - leaving behind a vanilla JA2 that serves as a modding platform for everything else. Unfortunately, as the code looks today, that would take nearly as many years of work as it did to make 1.13 what it is today, so it's not feasible. The better solution would probably be to repair whatever is wrong with today's version, set that as a modding platform, and branch the project in two, as you said is being discussed now. I think that coders here would have no problem splitting the work between them, as some coders are inherently more interested in externalization, and others in adding new gameplay perks. And of course many would probably want to work on both projects. I agree that bug hunting is harder with two versions going parallel, but if it helps solve crises like this, it's worth the trouble.
Then again I'm not a coder, I'm just a designer. What I can do with code is basically find the places where a change needs to occur, though I seldom know how to change it properly. So I probably wouldn't be of much help with this. The stable platform needs, and has always had, the best coders in the team. I think your problem however comes from the fact that they have little time nowadays to give the code the attention it deserves. That's the problem with volunteer projects, but that's what we'll have to live with. I think the main issue would be to get people interested in working on the stable platform, but I can't help you there, because as I said - my brain works towards gameplay...
Report message to a moderator
|
|
|
|
Re: Code Snippets[message #191174]
|
Sat, 19 July 2008 03:02
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
HeadrockFrankly, had I known it would cause issues to moddability, I'd have leaned more towards making the NIV a standalone mod. In hindsight it would make much more sense to take all the improvements to 1.13 and turn them into a downloadable "collection" mod - that means mobile militia, autofire, heck even the 1000+ item list - leaving behind a vanilla JA2 that serves as a modding platform for everything else.
don't ever think that wasn't discussed like 753 times in the past years. Again and again.
nobody wanted to do it then, nobody would do it now, except for some smp alibi exercises at the border to ridiculousness. :wave:
that in a hindsight, a big bunch of people would agree didn't help me much years ago. Fools. just 2 years faster thinking. Planning ahead. Or simply reading what those that did wrote.
fools.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
Re: Code Snippets[message #208810]
|
Sat, 14 February 2009 15:54
|
|
2Points |
|
Messages:10
Registered:February 2009 |
|
|
Might as well give it a go and post something I've recently completed here. This snipped implements dynamic repair priorities based on item type, placement and durability. Idea behind it was that my repair dudes basically always started to repair minorly broken items in their own inventory instead of items on other mercs that might need repair much more urgently, wasting a lot of time until they finally got to the item in question. Most noticable when giving a broken weapon to a merc that doesn't have the ability to repair items - it takes ages until the repair merc finally gets to this item when there are a few other items to repair around.
So instead of looking through pockets in a linear fashion, all items that need repairing are collected and assigned priorites. The item with the highest priority will be repaired first.
Currently, the following repair order is used:
1. Jammed weapons
2. Equipped weapons
3. Equipped armor
4. Weapons in inventory
5. Armor in inventory
6. Other items
7. Bags
When two items share the same priority, the item with less durability will be favored.
A patch against the curent SVN trunk can be found here: http://files.sector-5.net/ja/dynamic-repair.patch
Test executable here: http://files.sector-5.net/ja/ja2_dynamic_repair_en.zip
Compiled with VS2008, so the executable might or might not have additional VS DLL dependencies.
[Updated on: Sat, 14 February 2009 21:44] by Moderator Report message to a moderator
|
Private
|
|
|
|
|
Sector inventory sorting[message #209173]
|
Sun, 22 February 2009 14:08
|
|
2Points |
|
Messages:10
Registered:February 2009 |
|
|
Inspired by this thread, a simple way to customize how a sector's inventory gets sorted. Probably most useful for `Drop all items'-games with tons of items after each battle.
The sort options aren't particularly extensive for now, since I've only added SHORTNAME, LONGNAME, CATRGORY, AMOUNT, QUALITY, RANGE, DAMAGE and ACCURACY. Implementing new options is pretty straight-forward though, simply inherit a new class from WorldItemComparator and overwrite its compareItemsInternal() method. Add a name for the option in GetComparatorForString() and you're done. (WorldItem Comparison.h/.cpp)
Also add this to your ja2_options.ini under Game options:
;******************************************************************************************************************************
; Customize sector inventory sort order.
; Possible sort criteria include: SHORTNAME, LONGNAME, CATRGORY, AMOUNT, QUALITY, RANGE, DAMAGE, ACCURACY
; Seperate values with comma. To specify sort order, prefix the criteria with either + for ascending order
; or - for descending order. If omitted, ascending order is used.
; Example for the `classic' sort order: CATEGORY,LONGNAME,-AMOUNT,-QUALITY
;******************************************************************************************************************************
SECTOR_INV_SORT_ORDER = CATEGORY,-RANGE,-DAMAGE,-ACCURACY,SHORTNAME,-AMOUNT,-QUALITY
Customize as you see fit.
Patch against SVN trunk is here: http://files.sector-5.net/ja/custom-sectorinv-sort.patch
Test executable: http://files.sector-5.net/ja/ja2_invsort_en.zip
Report message to a moderator
|
Private
|
|
|
|
Stock Multiplier[message #242964]
|
Mon, 01 February 2010 00:12
|
|
Faithless |
|
Messages:439
Registered:October 2009 Location: The safe end of the barre... |
|
|
I've made a little modification because I wasn't happy with the current bobby ray's selection setting.
I made it so that the BR selection setting no longer affects the item stock.
Instead I made another ini option that lets you multiply the BR stock by any number between 1 and 10 (1 being default of course :crazy: )
This mod may have implications for the MP part, because the stock might not be multiplied any more. Should be an easy fix but I don't know how MP works
I used SVN version 3111, if it matters. At the lowest 2 code fields I've added some surrounding code for easier reference. Code is working on my own compiled exe at least
So, lets get to the code:
Defining the new value
- GameSettings.h near line 285 (well not that it matters much where..)
//WarmSteel multiplier for BR stock
INT32 iBRStockMultiplier;
Reading from the ini file.
- GameSettings.cpp near line 944
//multiplier for BR stock - WarmSteel
gGameExternalOptions.iBRStockMultiplier = iniReader.ReadInteger("JA2 Gameplay Settings","BR_STOCK_MULTIPLIER",1, 1, 10);
Just replaced gGameOptions.ubBobbyRay with gGameExternalOptions.iBRStockMultiplier, this determines whether a restock is needed.
- BobbyR.cpp near line 718
//if the item isn't already on order
if( LaptopSaveInfo.BobbyRayInventory[ i ].ubQtyOnOrder == 0 || gGameOptions.ubBobbyRay == BR_AWESOME )
{
DebugMsg(TOPIC_JA2, DBG_LEVEL_3,String("DailyUpdateOfBobbyRaysNewInventory: item = %d, qty on hand = %d, half desired amount = %d",usItemIndex,LaptopSaveInfo.BobbyRayInventory[ i ].ubQtyOnHand,(StoreInventory[ usItemIndex ][ BOBBY_RAY_NEW ] * gGameExternalOptions.iBRStockMultiplier )/2));
//if the qty on hand is half the desired amount or fewer
if( LaptopSaveInfo.BobbyRayInventory[ i ].ubQtyOnHand <= (StoreInventory[ usItemIndex ][ BOBBY_RAY_NEW ] * gGameExternalOptions.iBRStockMultiplier )/2 )
{
Again just replaced gGameOptions.ubBobbyRay with gGameExternalOptions.iBRStockMultiplier.
This part now multiplies the amount of items restocked by BR by iBRStockMultiplier.
- BobbyR.cpp near line 830
// decide if he can get stock for this item (items are reordered an entire batch at a time)
if (ItemTransactionOccurs( -1, usItemIndex, DEALER_BUYING, ubBobbyRayNewUsed ))
{
if (ubBobbyRayNewUsed == BOBBY_RAY_NEW)
{
ubItemsOrdered = HowManyItemsToReorder(StoreInventory[ usItemIndex ][ ubBobbyRayNewUsed ] * gGameExternalOptions.iBRStockMultiplier, ubCurrentlyOnHand);
}
And the actual added ini option in the Gameplay Settings section (I put it near "TONY_USES_BR_SETTING")
;******************************************************************************************************************************
; The BR's new items stock is multiplied by this value. Values between 1 and 10
;******************************************************************************************************************************
BR_STOCK_MULTIPLIER = 4
So anyone willing to implement this ?
Edit: I just noticed a nice patch function on turtoiseSVN, I could just post the patch file? =)
[Updated on: Mon, 01 February 2010 01:45] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
Re: Code Snippets[message #258432]
|
Wed, 04 August 2010 23:16
|
|
silversurfer |
|
Messages:2793
Registered:May 2009 |
|
|
No more talking when spotting mines!
This one was requested so I decided to code it.
What does it do?
Until now when spotting a mine your merc says a quote. If you clear a mine field and have to listen to the same quote over and over again it can become quite boring. This is especially true for the large mine fields on WF maps. With this mod you can disable the quotes in Ja2_Options.ini.
What did I change?
new setting in Ja2_Options.ini:
[Tactical Interface Settings]
MINES_SPOTTED_NO_TALK = TRUE
If this is "TRUE" your merc won't says anything when spotting a mine. He will just place a blue flag if the setting "AUTOMATICALLY_FLAG_MINES_WHEN_SPOTTED = TRUE" otherwise you will be asked if you want to place a blue flag. If "MINES_SPOTTED_NO_TALK" is "FALSE" (the default value) the merc will say his quote like it was before.
GameSettings.h added line 821 and 822:
// silversurfer: don't play quote when merc spots a mine? TRUE = shut up! FALSE = tell me that you found a mine!
BOOLEAN fMineSpottedNoTalk;
GameSettings.cpp added line 763 and 764:
// silversurfer: don't play quote when mine spotted?
gGameExternalOptions.fMineSpottedNoTalk = iniReader.ReadBoolean("Tactical Interface Settings","MINES_SPOTTED_NO_TALK", FALSE);
Tactical\Overhead.cpp inserted at line 2202
// silversurfer: if TRUE the merc won't comment that he found a mine, otherwise old behaviour
if (gGameExternalOptions.fMineSpottedNoTalk )
MineSpottedDialogueCallBack ();
else
{
SetStopTimeQuoteCallback( MineSpottedDialogueCallBack );
TacticalCharacterDialogue( pSoldier, QUOTE_SUSPICIOUS_GROUND );
}
and again at line 2818
// silversurfer: if TRUE the merc won't comment that he found a mine, otherwise old behaviour
if (gGameExternalOptions.fMineSpottedNoTalk )
MineSpottedDialogueCallBack ();
else
{
SetStopTimeQuoteCallback( MineSpottedDialogueCallBack );
TacticalCharacterDialogue( pSoldier, QUOTE_SUSPICIOUS_GROUND );
}
INIEditorJA2Options.xml
If set to TRUE, when a character finds a mine they will not say anything and only put a blue flag there or ask if they should do so.
(depends on the setting of "AUTOMATICALLY_FLAG_MINES_WHEN_SPOTTED")
If set to FALSE, when a character finds a mine they will tell you with a comment (the "classic" behavior).
Setzen Sie diesen Wert auf TRUE, damit S
Report message to a moderator
|
|
|
|
|
Re: Code Snippets[message #273080]
|
Wed, 09 February 2011 18:20
|
|
JMich |
|
Messages:546
Registered:January 2011 Location: Greece |
|
|
Externalizing DIFF_FACTOR_PLAYER_PROGRESS, DIFF_FACTOR_PALACE_DISTANCE and DIFF_FACTOR_GAME_DIFFICULTY
Files Modified
- GameSettings.h
- GameSettings.cpp
- Soldier Create.cpp
- Ja2_Options.ini
Ja2_Options.ini
In the [Strategic Progress Settings] Section, we add;------------------------------------------------------------------------------------------------------------------------------
; Game difficulty weights
;
; Determine what factors influence the game's difficulty.
; Range: 0-100%
; Warning! The sum of all 3 variables must be 100, or the variables will be reset to defaults
;------------------------------------------------------------------------------------------------------------------------------
; Weight of Progress % Default 50%
DIFF_FACTOR_PLAYER_PROGRESS = 50
; Weight of Distance from Palace Default 30%
DIFF_FACTOR_PALACE_DISTANCE = 30
; Weight of Game Difficulty Default 20%
DIFF_FACTOR_GAME_DIFFICULTY = 20
GameSettings.h
After the section //WDS - Progress settings we add the following
// JMich - Difficulty Factor Settings
UINT32 ubDiffFactorPlayerProgress;
UINT32 ubDiffFactorPalaceDistance;
UINT32 ubDiffFactorGameDifficulty; This declares the 3 Difficulty Factors as external game options.
GameSettings.cpp
In the huge LoadGameExternalOptions() function, under "Strategic Progress Settings" //JMich - Difficulty Settings
gGameExternalOptions.ubDiffFactorPlayerProgress = iniReader.ReadInteger("Strategic Progress Settings","DIFF_FACTOR_PLAYER_PROGRESS", 50, 0, 100);
gGameExternalOptions.ubDiffFactorPalaceDistance = iniReader.ReadInteger("Strategic Progress Settings","DIFF_FACTOR_PALACE_DISTANCE", 30, 0, 100);
gGameExternalOptions.ubDiffFactorGameDifficulty = iniReader.ReadInteger("Strategic Progress Settings","DIFF_FACTOR_GAME_DIFFICULTY", 20, 0, 100);
// Any way to warn on this?
if (gGameExternalOptions.ubDiffFactorPlayerProgress +
gGameExternalOptions.ubDiffFactorPalaceDistance +
gGameExternalOptions.ubDiffFactorGameDifficulty != 100)
{
gGameExternalOptions.ubDiffFactorPlayerProgress = 50;
gGameExternalOptions.ubDiffFactorPalaceDistance = 30;
gGameExternalOptions.ubDiffFactorGameDifficulty = 20;
// Yes, there is!
std::stringstream errMessage;
errMessage << "The values of the three ''DIFF_FACTOR'' INI settings do not add up to 100! Using default values instead...";
iniErrorMessages.push(errMessage.str());
}
If I've done it correctly, this reads the 3 settings from the Ja2_Options.ini, with default values of 50, 30, 20 (original values), minimum value of 0 and maximum value of 100. If the 3 values don't add exactly to 100, then it replaces them with the default and mentions it.
Soldier Create.cpp
Most of the work was done here, code snippets and comments galore
// THESE 3 DIFFICULTY FACTORS MUST ALWAYS ADD UP TO 100% EXACTLY!!!
#define DIFF_FACTOR_PLAYER_PROGRESS 50
#define DIFF_FACTOR_PALACE_DISTANCE 30
#define DIFF_FACTOR_GAME_DIFFICULTY 20 is changed to// THESE 3 DIFFICULTY FACTORS MUST ALWAYS ADD UP TO 100% EXACTLY!!!
#define DIFF_FACTOR_PLAYER_PROGRESS gGameExternalOptions.ubDiffFactorPlayerProgress
#define DIFF_FACTOR_PALACE_DISTANCE gGameExternalOptions.ubDiffFactorPalaceDistance
#define DIFF_FACTOR_GAME_DIFFICULTY gGameExternalOptions.ubDiffFactorGameDifficulty
Function UINT8 GetLocationModifier( UINT8 ubSoldierClass ), after the "Switch(bTownID)" block we replace
// adjust for distance from Queen's palace (P3) (0 to +30)
ubLocationModifier = ( ( MAX_PALACE_DISTANCE - ubPalaceDistance ) * DIFF_FACTOR_PALACE_DISTANCE ) / MAX_PALACE_DISTANCE; with //JMich Modified Distance Factor
if (DIFF_FACTOR_PALACE_DISTANCE != 0)
{
// adjust for distance from Queen's palace (P3) (0 to DIFF_FACTOR_PALACE_DISTANCE)
ubLocationModifier = ( ( MAX_PALACE_DISTANCE - ubPalaceDistance ) * DIFF_FACTOR_PALACE_DISTANCE ) / MAX_PALACE_DISTANCE;
}
else
{
switch( gGameOptions.ubDifficultyLevel )
{
case DIF_LEVEL_EASY:
// all battles as far away as possible
ubLocationModifier = 0;
break;
case DIF_LEVEL_MEDIUM:
// all battles in middle distance
ubLocationModifier = 10;
break;
case DIF_LEVEL_HARD:
case DIF_LEVEL_INSANE:
// all battles in the palace
ubLocationModifier = 20;
break;
}
}
If we have a distance of 0, I've added a little difference to be used in CalcDifficultyModifier() function later on.
Function RandomizeRelativeLevel( INT8 *pbRelLevel, UINT8 ubSoldierClass ), after variables declaration, we replace // this returns 0 to DIFF_FACTOR_PALACE_DISTANCE (0 to +30)
ubLocationModifier = GetLocationModifier( ubSoldierClass );
// convert to 0 to 10 (divide by 3), the subtract 5 to get a range of -5 to +5
bRollModifier = ( INT8 ) ( ubLocationModifier / ( DIFF_FACTOR_PALACE_DISTANCE / 10 ) ) - 5; with //JMich Modified Distance Factor
if (DIFF_FACTOR_PALACE_DISTANCE==0)
{
switch( gGameOptions.ubDifficultyLevel )
{
case DIF_LEVEL_EASY:
// all battles as far away as possible
bRollModifier = -5;
break;
case DIF_LEVEL_MEDIUM:
// all battles in middle distance
bRollModifier = 0;
break;
case DIF_LEVEL_HARD:
case DIF_LEVEL_INSANE:
// all battles in the palace
bRollModifier = 5;
break;
}
}
else
{
// this returns 0 to DIFF_FACTOR_PALACE_DISTANCE
ubLocationModifier = GetLocationModifier( ubSoldierClass );
// convert to 0 to 10 (divide by DIFF_FACTOR_PALACE_DISTANCE/10), then subtract 5 to get a range of -5 to +5
bRollModifier = ( INT8 ) ( ubLocationModifier / ( DIFF_FACTOR_PALACE_DISTANCE / 10 ) ) - 5;
}
Again, if we don't have a distance factor to our calculation, adjust it according to difficulty level.
Finally, we change the function INT8 CalcDifficultyModifier( UINT8 ubSoldierClass ) as follows
INT8 CalcDifficultyModifier( UINT8 ubSoldierClass )
{
UINT8 ubDiffModifier = 0; //JMich converted to unsigned due to 127 cap of signed, added u to start of variable name
UINT8 ubProgress;
UINT8 ubProgressModifier;
INT8 USED_DIFF_FACTOR_GAME_DIFFICULTY = 20; //JMich unsure if DIFF_FACTOR_GAME_DIFFICULTY would be changed by if check below, decided to use temp variable
DebugMsg(TOPIC_JA2,DBG_LEVEL_3,String("CalcDifficultyModifier"));
if( gfEditMode )
{
// return an average rating for editor purposes
return( 50 );
}
// THESE 3 DIFFICULTY FACTORS MUST ALWAYS ADD UP TO 100% EXACTLY!!!
Assert( ( DIFF_FACTOR_PLAYER_PROGRESS + DIFF_FACTOR_PALACE_DISTANCE + DIFF_FACTOR_GAME_DIFFICULTY ) == 100 );
// adjust for game difficulty level
if (DIFF_FACTOR_GAME_DIFFICULTY >= 10) //JMich if GAME_DIFFICULTY too low, increase it
{
USED_DIFF_FACTOR_GAME_DIFFICULTY = DIFF_FACTOR_GAME_DIFFICULTY;
}
else
{
USED_DIFF_FACTOR_GAME_DIFFICULTY = 20;
}
switch( gGameOptions.ubDifficultyLevel ) //JMich This will give us a ubDiffModifier of 0 to 150 (INSANE at max Difficulty Level Factor for enemies)
{
case DIF_LEVEL_EASY:
// very strong militia, very weak enemies/cratures/bloodcats
if ( SOLDIER_CLASS_MILITIA( ubSoldierClass ) )
{
// +20
ubDiffModifier += USED_DIFF_FACTOR_GAME_DIFFICULTY;
}
break;
case DIF_LEVEL_MEDIUM:
// equally strong militia, enemies, creatures, bloodcats (+10)
ubDiffModifier += ( USED_DIFF_FACTOR_GAME_DIFFICULTY / 2 );
break;
case DIF_LEVEL_HARD:
// equally stronger militia/enemies/creatures/bloodcats (+20)
ubDiffModifier += USED_DIFF_FACTOR_GAME_DIFFICULTY;
break;
case DIF_LEVEL_INSANE:
// equally stronger enemies/creatures/bloodcats (+40)
if ( SOLDIER_CLASS_MILITIA( ubSoldierClass ) )
{
// militia only +20
ubDiffModifier += USED_DIFF_FACTOR_GAME_DIFFICULTY;
}
else
{
ubDiffModifier += (INT8)(USED_DIFF_FACTOR_GAME_DIFFICULTY * 1.5);
}
break;
}
// the progress returned ranges from 0 to 100
ubProgress = HighestPlayerProgressPercentage();
// bump it a bit once we've accomplished something (killed some enemies or taken an important sector)
if ( ubProgress > 0 )
{
// +5
ubDiffModifier += DIFF_MODIFIER_SOME_PROGRESS;
}
// adjust for progress level (0 to DIFF_FACTOR_PLAYER_PROGRESS ) //JMich Modifier of 0 to 100
ubProgressModifier = ( ubProgress * DIFF_FACTOR_PLAYER_PROGRESS ) / 100;
ubDiffModifier += ubProgressModifier;
// adjust for map location
ubDiffModifier += GetLocationModifier( ubSoldierClass ); //JMich Modifier of 0 to 100
// drop it down a bit if we still don't have any mine income
//JMich moved it to the end so we can have it unsigned, since if signed it caps at 127
if ( PredictIncomeFromPlayerMines(TRUE) == 0 )
{
// -5
if (ubDiffModifier > abs(DIFF_MODIFIER_NO_INCOME * -1)) //JMich Check if we can subtract from the difficulty, since unsigned 0 - 5 = 251
{
ubDiffModifier -= abs(DIFF_MODIFIER_NO_INCOME * -1); //JMich Subtracting a positive or adding a negative, if 0 mine income then difficulty decreases
}
else
{
ubDiffModifier = 0; //JMich If our current difficulty is lower than the modifier, set difficulty to 0
}
}
// should be no way to go over 100, although it's possible to go below 0 when just starting on easy
// JMich modified, checks added (hopefully)
// Assert( bDiffModifier <= 100 );
// limit the range of the combined factors to between 0 and 100
ubDiffModifier = __max( 0, ubDiffModifier );
ubDiffModifier = __min( 100, ubDiffModifier );
// DON'T change this function without carefully considering the impact on GenerateRandomEquipment(),
// CreateDetailedPlacementGivenBasicPlacementInfo(), and SoldierDifficultyLevel().
DebugMsg(TOPIC_JA2,DBG_LEVEL_3,String("CalcDifficultyModifier done"));
return(ubDiffModifier);
}
If I have done this change correctly, it means that we can have a mod where the EnemyItemChoice and EnemyGunChoice can depend on any combination of these 3 factors, like what BAG-Pro was supposed to be when it was first implemented (Progress 90%+, Location < 10%, Difficulty < 10%), or maybe even a mod with a few items, but independant of progress, for example a Wild West mod (grand total of 10? 15 weapons?) where the closer you are to P3, the greater the enemies choices will be.
There will also be a change to the enemies attributes if game difficulty is greater than Experienced, and they'll propably be a bit tougher, but I haven't really tried it that much.
P.S. Would it be possible to make these 3 variables to be in the EnemyItemChoices.xml so a mod maker can trully define his/her mod?
Report message to a moderator
|
First Sergeant
|
|
|
|
|
Re: Code Snippets[message #273193]
|
Thu, 10 February 2011 16:44
|
|
Buns |
|
Messages:655
Registered:September 2010 |
|
|
SpaceVikingCool! It sounds like we could use this to solve the "guys with G3A3s in Chitzena" issue. I don't think so: Now Chitzena has a rather low level, I guess 2 or 3. When you encounter someone with a G3 in Chitzena it means the G3 is made a valid weapon in level 2 or 3 (or this one was pre-placed).
With the new system that ties this to game progress you would still run into a guy with a G3 in Chitzena if that weapon is level 2, unless Chitzena realy is your first town. When Chitzena is your first town certainly the blackshirts that make the counter-attack will wield G3s, latest the first Trooper in the next town you attack have them.
[Updated on: Thu, 10 February 2011 16:45] by Moderator Report message to a moderator
|
First Sergeant
|
|
|
|
|
|
Re: Code Snippets[message #273231]
|
Thu, 10 February 2011 21:17
|
|
JMich |
|
Messages:546
Registered:January 2011 Location: Greece |
|
|
@SpaceViking
I run the numbers for Chitzena using the default (current) system (50% progress, 30% location, 20% difficulty), a 80/10/10 which is the most balanced location independant, and the harder than 100% 100/0/0 which is difficulty dependant.
After the number crunching, these are the final possible choices
Default = 0 to 5, or 2 to 7 for elites.
80/10/10 = 0 to 4, or 1 to 6 for elites.
100/0/0 expert = 4 to 8, or 6 to 10 for elites.
100/0/0 experienced = 2 to 7 or 4 to 9 for elites.
100/0/0 novice = 0 to 4 or 2 to 6 for elites.
Calculations by Headrock's How-to Part 11 (plus adding progress modifier), assuming a progress of 8 and no mine income.
HKG3A3 is at choice level 4, so while still possible for an 80/10/10 game, it should be about 1% chance (both random(10) rolls rolling 10s).
If you do play at 100/0/0 expert though, G3A3 at Chitzena will be the lowest part of the gun choices, because my proposed code assumes that all battles take place in the palace for expert level with a location modifier of 0.
Number crunching following in the spoiler (my rough draft in notepad)
NumbersChitzena distance modifier
(20-11)*(Location modifier)/20=
0.45*(Location modifier)=
13 default (30)
4 10
20 0 (expert)
10 0 (experienced)
0 0 (novice)
Equipment modifier
temp value
-1 + (0 to 9) = 0 to 8 (default and 10%)
5 + (0 to 9) = 5 to 9 (expert)
0 + (0 to 9) = 0 to 9 (experienced)
-5 + (0 to 9) = 0 to 4 (novice)
equipment modifier
0, 1, 2, 3 (default and 10%)
2, 3, 4 (expert)
0, 1, 2, 3, 4 (experienced)
0, 1, 2 (novice)
Difficulty modifier
20 default (20)
10 (10)
20 (expert)
10 (experienced)
0 (novice)
+5 for some progress, -5 for no mine income
Adding distance modifier
23 (default)
14 (10)
40 (expert)
30 (experienced)
20 (novice)
Adding Progress modifier (assume progress is
33 + 4 = 37 default (50)
15 + 6 = 20 (80)
40 + 8 = 48 (expert)
30 + 8 = 38 (experienced)
20 + 8 = 28 (novice)
Assuming slow progress is false
1 + (0 to 3) default
0 + (0 to 3) (80/10/10)
3 + (2 to 4) (100 expert)
2 + (1 to 4) (100 experienced)
1 + (0 to 2) (100 novice)
deviation of 1, and adding 2 more if elites
so, final range of weapon possibilities for chitzena
default means 0 to 5, or 2 to 7 for elites
80/10/10 means 0 to 4, or 1 to 6 for elites
100/0/0 expert means 4 to 8, or 6 to 10 for elites
100/0/0 experienced means 2 to 7, or 4 to 9 for elites
100/0/0 novice means 0 to 4, or 2 to 6 for elites
HKG3A3 is at 4
Report message to a moderator
|
First Sergeant
|
|
|
|
|
Re: Code Snippets[message #273332]
|
Fri, 11 February 2011 16:27
|
|
Buns |
|
Messages:655
Registered:September 2010 |
|
|
SpaceVikingSomewhere I read a quote from one of the original designers where they mentioned this very same problem. The game was actually *easier* on harder difficulty levels because you got better equipment sooner. Not only that: higher difficulty level means more fights with more and better enemies, means more leveling up for the player's characters. In fact, Novice can be quite tough in the late game when your level 3(!) IMP comes across the first blackshirts.
[Updated on: Fri, 11 February 2011 16:28] by Moderator Report message to a moderator
|
First Sergeant
|
|
|
|
|
|
Goto Forum:
Current Time: Fri May 03 03:57:36 GMT+3 2024
Total time taken to generate the page: 0.02423 seconds
|