Home » MODDING HQ 1.13 » Flugente's Magika Workshop » New feature: individual militia
|
Re: New feature: individual militia[message #351085 is a reply to message #351013]
|
Thu, 21 September 2017 21:40
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
Hmm. As you've discovered, there was a mix up between soldier class and militia level. I'm not sure why, because at some point I was aware of that exact issue and used conversion functions. Weird.
Anyway, fixed in r8477. This also fixes any ranks when loading an older savegames, of course.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
Re: New feature: individual militia[message #351198 is a reply to message #351153]
|
Thu, 05 October 2017 23:01
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
I've fixed the appearance of that error message in r8493. But the militia profiles in Drassen already exist when one loads the savegame (it says they were trained in Drassen on Day 1, 16:00). I'm not sure where they come from though. As we completely wipe our individual militia every time we load a savegame, I don't think this could be some sort of saving/loading issue. Do you have another savegame from, like, a different campaing where these guys existed?
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
Re: New feature: individual militia[message #352295 is a reply to message #346803]
|
Mon, 05 February 2018 08:35
|
|
Elvis_A |
|
Messages:282
Registered:December 2012 Location: exUSSR |
|
|
silversurfer wrote on Sat, 03 September 2016 11:14I'd say that we should keep the names that aren't wrong (don't exist or are written incorrectly). For the sake of variety we should have as many names as we can and I don't mind if some are a short form of an other name. Most people probably don't know that anyway (including me) especially since certain names have been adopted to other countries in their short form as a regular name. If I'd call the Katja's I know "Ekaterina" they'd probably give me a strange look. ;-)
Some players probably remember the time where we still had only a handful of names for enemy/militia profiles and on every encounter we got some "Lachlan "Sir" Botticchio" or another which made me turn the feature off. So instead of removing names which aren't wrong I'd propose to correct the ones that have been written incorrectly and add your new names to increase the number of names.
Enneagon wrote on Sat, 03 September 2016 13:47silversurfer wrote on Sat, 03 September 2016 11:14So instead of removing names which aren't wrong I'd propose to correct the ones that have been written incorrectly and add your new names to increase the number of names.
I also don't think we should worry about obsolete names, short forms or any exact etnical conformity at all as long there no screaming typos.
Flugente wrote on Fri, 06 May 2016 17:32PMC mercenary are russian-like. While the description I made for Kerberus potentially allows any nationality, I feel that having them immediately stand out from the locals would be good. Additionally, this lets me show off how men and women can also have different surnames.
As I understand the only goal here is to create 3 recognisably different naming lists. "Hispanic", "Russian" and "German" therefore are just very broad labels.
"Latin" and "Slavic" would probably be more appropriate labels.
Or even revert to functional labels as "local", "hired", "army" or some such.
But well, tangential discussion about labels is in itself quite... stupid (for lack of better word).
Boojum wrote on Sat, 03 September 2016 19:48Quote:Some players probably remember the time where we still had only a handful of names for enemy/militia profiles and on every encounter we got some "Lachlan "Sir" Botticchio" or another which made me turn the feature off.
"Sir", "tty" and so on? Yes, I remember this time too (I play 1.13 since 2011).
Quote:Especially since certain names have been adopted to other countries in their short form as a regular name.
I didn't know how wide is it. You are right. "My name is Petya Ivanov" sounds weird to me, but if this is in use in any country, why not.
If so, how about adding more short forms for more accordance (by now, some names have their alternative forms, and some haven't, which is a bit selectively)?
Quote:I also don't think we should worry about obsolete names, short forms or any exact etnical conformity at all as long there no screaming typos.
Oh... If no one will complain, you are right. But these old "Osip", "Lukyan" and so on sound just like Ealdgyth (en.wikipedia.org/wiki/Ealdgyth) or Aescwine.
Sorry for necroposting here, I missed the discussion.
I intentionally left old names, well because they are sometimes used. The name "Osip" actually was used in XX century. You might heard the famous russian poet Osip Mandelstam https://en.wikipedia.org/wiki/Osip_Mandelstam
I actually explained hypocorisms and as Silversurfer said I left them intentionally so non-Russian community could recognize these names.
Elvis_A wrote on Wed, 06 July 2016 21:16most of the fore/surnames are good to use. Some of the names are not Russian however they are Slavik:
<male_forename>Borislav</male_forename>
<male_forename>Lubomir</male_forename>
etc.
Other (sur)names are non Slavik for example:
male_surname>Engelgardt</male_surname> Jewish/German
following names are the same(Hypocorisms):
<male_forename>Grigory</male_forename>
<male_forename>Grischa</male_forename>short form of Grigory (like Rob/Bob - Robert)
<male_forename>Petya</male_forename> short name for Pyotr
<male_forename>Pyotr</male_forename>
<female_forename>Maria</female_forename>
<female_forename>Masha</female_forename> short form of Maria
<female_forename>Nastja</female_forename> short form of Anastasiya
<female_forename>Natalia</female_forename>
<female_forename>Natasha</female_forename> Short form of Natalia
<female_forename>Tanya</female_forename> short form of Tatiana
<female_forename>Tatiana</female_forename>
Russia is multinational country, so it is ok to have mentioned names above since you can often see those (Georgian, Azeri, Slovenian, etc sur/names),
BUT i would remove names below:
<male_forename>Abid</male_forename> never heard
<male_forename>Abily</male_forename> same as above
<male_forename>Aburom</male_forename> //-//
<male_forename>Avda</male_forename>
<male_forename>Avim</male_forename>
<male_forename>Avit</male_forename>
<male_forename>Avksily</male_forename>
<male_forename>Darko</male_forename> i would change it to Danko, which may be used both as name and surname
<male_forename>Inal</male_forename>
<male_forename>Avtonom</male_forename>
<male_surname>Rodriguez</male_surname> I will definitely remove 3 of these
<male_surname>Rodriguez</male_surname>
<male_surname>Rodriguez</male_surname>
<female_forename>Abijah</female_forename>
<female_forename>Leda</female_forename>
<female_forename>Zenalda</female_forename> replace with Zinaida
<female_forename>Zora</female_forename>
<female_surname>Osborn</female_surname> Ozzie? ;)
<female_forename>Rachel</female_forename>
There few typos left though, if somebody interested:
<male_forename>Amrovsy</male_forename>
replace with
<male_forename>Amvrosy</male_forename>
<female_forename>Ansastasia</female_forename>
replace with
<female_forename>Anastasia</female_forename>
<male_forename>Zoinoviy</male_forename>
replace with
<male_forename>Zinoviy</male_forename>
I can add more commonly used Russian names - just let me know if they are needed.
Small Bug
If the list is empty, Sector Names and Militia names get stacked on top of each other
[Updated on: Mon, 05 February 2018 08:46] Report message to a moderator
|
Master Sergeant
|
|
|
Re: New feature: individual militia[message #352617 is a reply to message #352295]
|
Sun, 04 March 2018 23:16
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
As of r8537 & GameDir r2409, we can do more things with individual militia. First things first, all militia-related assignments are now in their own sub-menu:
- The first option does what militia training does: train new militia (or promote existing ones if no more room or volunteers).
- The second option is new: drill militia trains existing green or regular militia until they are promoted, but does not train new ones. We basically increase their internal promotion points (made up from kills and assists in battle). Once we reach INDIVIDUAL_MILITIA_PROMOTIONPOINTS_TO_REGULAR or INDIVIDUAL_MILITIA_PROMOTIONPOINTS_TO_ELITE, we promote the militia (if we play with militia resources, we put the promotion on hold until we have enough resources. This is as effective as promotions via training new militia is:
- a normal militia training session requires 10000 points (when training, you see a merc's training points / 10 /maximum training points / 10 on their face).
- a training session would allow promoting NUM_MILITIA_TRAINED_PER_SESSION militia
- a green militia requires INDIVIDUAL_MILITIA_PROMOTIONPOINTS_TO_REGULAR to promote
- it thus follows that one point of militia experience is worth 10000 / (NUM_MILITIA_TRAINED_PER_SESSION * INDIVIDUAL_MILITIA_PROMOTIONPOINTS_TO_REGULAR) training points, so we apply that to our training points
Similar, it follows that
- a normal training session costs $ MILITIA_BASE_TRAINING_COST * MILITIA_COST_MULTIPLIER_REGULAR
- it promotes NUM_MILITIA_TRAINED_PER_SESSION militia with INDIVIDUAL_MILITIA_PROMOTIONPOINTS_TO_REGULAR points each
- thus a point costs $ MILITIA_BASE_TRAINING_COST * MILITIA_COST_MULTIPLIER_REGULAR / (NUM_MILITIA_TRAINED_PER_SESSION * INDIVIDUAL_MILITIA_PROMOTIONPOINTS_TO_REGULAR)
, so we always deduct that money. Can't have one assignment be free while the other costs something, no?
Experience is awarded in similar manner for training provided (trainig empty air does not award experience).
One important part: This works in any sector, regardless of whether training new militia is possible there, as long as militia that can be trained are present.
This only works with individual militia.
- The third option is new: doctor militia allows restoring militia HP similar to how the regular doctor assingment works. This obviously requires INDIVIDUAL_MILITIA_MANAGE_HEALTH to be TRUE.
As you may or may not be aware, individual militia data doesn't directly store militia health points (that would be useless, as militia stats depend on class, game progress and sector). We store their health ratio instead. They already heal INDIVIDUAL_MILITIA_HOURLYHEALTHPERCENTAGEGAIN % each hour, now you can speed that up by doctoring.
Of course, given the huge number of militia and their... tactics, that would be a lot of wounds to treat... a daunting task for your doctors. For that reason, you can increase the effectivity of a doctor on that task: INDIVIDUAL_MILITIA_DOCTORHEALMODIFIER determines how many percent one doctoring point heals (for example, stock Spider has 362 points, each normally heals 1/100 of a merc's HP). I set it to 0.2 in stock. To achieve near parity with merc healing (and likely keep all the doctors on the roster busy )use 0.01. Values from 0.01 to 1.0. That value is already applied to a merc's image on that assignment - in the above picture, Spider can heal 72.4% of a militia's HP.
This also works in any sector as long as militia in somewhat ruffled condition are present.
I hope that this will be quite helpful in making individual militia more useful. One could, say, pack a platoon of FNGs, a few trainers and medics to represent military advisors and LTs, and go to battle with that.
This is savegame compatible.
[Updated on: Sun, 04 March 2018 23:21]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
Individual Militia Bug Fix (DEV - 8551)[message #353051 is a reply to message #345324]
|
Wed, 11 April 2018 07:53
|
|
RunAwayScientist |
|
Messages:84
Registered:September 2001 |
|
|
DEV BUILD - 8551
Hello everyone & Flugente,
I've tracked down the issue with mobile militia entering loaded sectors and will be submitting this to the BugFixes thread in addition to here. It took about 30 minutes of working through the MoveIndividualMilitia functions but it appears to be a missing MoveIndividualMilitiaProfiles(); func call in a if/elseif/else chain, that's all.
Corrected code below:
[[ Strategic Movement.cpp ]] { BUGGED CODE } :
Toggle Spoiler
// Flugente: if a militia group has reached its final destination, add them to the current sector
if ( pGroup && pGroup->usGroupTeam == MILITIA_TEAM )
{
// if they arrive in the sector we have currently loaded, let them join from the edge
// this will always remove them from the group - if you want them to continue moving, issue a new order
if ( pGroup->ubSectorX == gWorldSectorX && pGroup->ubSectorY == gWorldSectorY && pGroup->ubSectorZ == gbWorldSectorZ )
{
MilitiaGroupEntersCurrentSector( pGroup->ubGroupID, pGroup->ubSectorX, pGroup->ubSectorY );
if ( !fBattlePending && GroupAtFinalDestination( pGroup ) )
{
// once militia have arrived, move them from the group to the sector
DissolveMilitiaGroup( pGroup->ubGroupID );
}
}
[[ Strategic Movement.cpp ]] { CORRECTED CODE } :
Toggle Spoiler
// Flugente: if a militia group has reached its final destination, add them to the current sector
if ( pGroup && pGroup->usGroupTeam == MILITIA_TEAM )
{
// if they arrive in the sector we have currently loaded, let them join from the edge
// this will always remove them from the group - if you want them to continue moving, issue a new order
// RunAwayScientist fix on 4/10/2018: The below condition needs to have the other functions applied (MoveMilitiaEquipment, MoveMilitiaProfiles, reset)
// because the other if-else sections do NOT trigger if milita move into currently loaded sector.
// This should be done before dissolving the group.
// Currently only MoveMilitiaProfiles is needed, equipment is moved without being called from another func.
if ( pGroup->ubSectorX == gWorldSectorX && pGroup->ubSectorY == gWorldSectorY && pGroup->ubSectorZ == gbWorldSectorZ )
{
ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"CONDITION CHECKING LOADED SECTOR ACTIVATED" );
MilitiaGroupEntersCurrentSector( pGroup->ubGroupID, pGroup->ubSectorX, pGroup->ubSectorY );
// Flugente: move along individual militia data
MoveIndividualMilitiaProfiles( SECTOR( pGroup->ubPrevX, pGroup->ubPrevY ), SECTOR( pGroup->ubSectorX, pGroup->ubSectorY ), pGroup->pEnemyGroup->ubNumAdmins, pGroup->pEnemyGroup->ubNumTroops, pGroup->pEnemyGroup->ubNumElites );
if ( !fBattlePending && GroupAtFinalDestination( pGroup ) )
{
// once militia have arrived, move them from the group to the sector
DissolveMilitiaGroup( pGroup->ubGroupID );
// for safety, reset if necessary
ResetMilitia( );
}
}
(( This is optional, but I commented out the redunant 'Catch-All' feature that creates new militia profiles if none are detected in the sector. This caused more problems than it solved, and most people start new games or have updated their old game already. I highly recommend disabling the redunant 'Catch-All'.
There's a second 'Catch-All' in the FOR loop, which has only a 'return;', which may cause problems if it's ever triggered. That has also been commented out. ))
[[ Militia Individual.cpp ]] { BUGGED CODE } :
Toggle Spoiler
// search for a individual militia that is alive and not currently in use in this sector, and return its id
// if none is found, create new and return that one
UINT32 GetIdOfUnusedIndividualMilitia( UINT8 aSoldierClass, UINT8 aSector )
{
if ( !gGameExternalOptions.fIndividualMilitia )
return 0;
UINT8 militialevel = SoldierClassToMilitiaRank( aSoldierClass );
std::vector<MILITIA>::iterator itend = gIndividualMilitiaVector.end();
for ( std::vector<MILITIA>::iterator it = gIndividualMilitiaVector.begin( ); it != itend; ++it )
{
if ( !((*it).flagmask & (MILITIAFLAG_DEAD | MILITIAFLAG_FIRED | MILITIAFLAG_DESERTION )) && (*it).sector == aSector && (*it).militiarank == militialevel )
{
// fitting data found - now we have to make sure this one isn't already in use
BOOLEAN found = FALSE;
SOLDIERTYPE* pSoldier;
INT32 cnt = gTacticalStatus.Team[MILITIA_TEAM].bFirstID;
INT32 lastid = gTacticalStatus.Team[MILITIA_TEAM].bLastID;
for (pSoldier = MercPtrs[cnt]; cnt < lastid; ++cnt, ++pSoldier)
{
if (pSoldier && pSoldier->bActive && (*it).id == pSoldier->usIndividualMilitiaID && IsLegalMilitiaId(pSoldier->usIndividualMilitiaID) )
{
found = TRUE;
break;
}
}
if ( !found && IndividualMilitiaInUse_AutoResolve((*it).id))
{
found = TRUE;
}
if (!found)
{
return (*it).id;
}
}
}
// if this feature is on and we get to this point, then there aren't enough individual militia. This is odd, the player should be informed
// if ( gGameExternalOptions.fIndividualMilitia )
ScreenMsg( FONT_MCOLOR_RED, MSG_INTERFACE, L"Possible error: Not enough individual militia found in GetIdOfUnusedindividualMilitia" );
// nobody found. That shouldn't really happen, as we are supposed to create data whenever new militia is created. Create new data and use that
return CreateNewIndividualMilitia( militialevel, MO_ARULCO, aSector );
}
--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^
void MoveIndividualMilitiaProfiles( UINT8 aSourceSector, UINT8 aTargetSector, UINT8 usGreens, UINT8 usRegulars, UINT8 usElites )
{
std::vector<MILITIA>::iterator itend = gIndividualMilitiaVector.end( );
for ( std::vector<MILITIA>::iterator it = gIndividualMilitiaVector.begin( ); it != itend; ++it )
{
if ( !usGreens && !usRegulars && !usElites )
return;
if ( !((*it).flagmask & (MILITIAFLAG_DEAD | MILITIAFLAG_FIRED | MILITIAFLAG_DESERTION )) && (*it).sector == aSourceSector )
{
if ( usGreens && ( *it ).militiarank == GREEN_MILITIA)
{
(*it).sector = aTargetSector;
--usGreens;
}
else if ( usRegulars && (*it).militiarank == REGULAR_MILITIA)
{
(*it).sector = aTargetSector;
--usRegulars;
}
else if ( usElites && (*it).militiarank == ELITE_MILITIA)
{
(*it).sector = aTargetSector;
--usElites;
}
}
}
// if this feature is on and we get to this point, then there aren't enough individual militia. This is odd, the player should be informed
if ( (usGreens + usRegulars + usElites) && gGameExternalOptions.fIndividualMilitia )
ScreenMsg( FONT_MCOLOR_RED, MSG_INTERFACE, L"Possible error: Not enough individual militia found in MoveIndividualMilitiaProfiles" );
}
}
[[ Militia Individual.cpp ]] { CORRECTED CODE } :
Toggle Spoiler
// search for a individual militia that is alive and not currently in use in this sector, and return its id
// if none is found, create new and return that one
UINT32 GetIdOfUnusedIndividualMilitia( UINT8 aSoldierClass, UINT8 aSector )
{
if ( !gGameExternalOptions.fIndividualMilitia )
return 0;
UINT8 militialevel = SoldierClassToMilitiaRank( aSoldierClass );
std::vector<MILITIA>::iterator itend = gIndividualMilitiaVector.end();
for ( std::vector<MILITIA>::iterator it = gIndividualMilitiaVector.begin( ); it != itend; ++it )
{
if ( !((*it).flagmask & (MILITIAFLAG_DEAD | MILITIAFLAG_FIRED | MILITIAFLAG_DESERTION )) && (*it).sector == aSector && (*it).militiarank == militialevel )
{
// fitting data found - now we have to make sure this one isn't already in use
BOOLEAN found = FALSE;
SOLDIERTYPE* pSoldier;
INT32 cnt = gTacticalStatus.Team[MILITIA_TEAM].bFirstID;
INT32 lastid = gTacticalStatus.Team[MILITIA_TEAM].bLastID;
for (pSoldier = MercPtrs[cnt]; cnt < lastid; ++cnt, ++pSoldier)
{
if (pSoldier && pSoldier->bActive && (*it).id == pSoldier->usIndividualMilitiaID && IsLegalMilitiaId(pSoldier->usIndividualMilitiaID) )
{
found = TRUE;
break;
}
}
if ( !found && IndividualMilitiaInUse_AutoResolve((*it).id))
{
found = TRUE;
}
if (!found)
{
return (*it).id;
}
}
}
// if this feature is on and we get to this point, then there aren't enough individual militia. This is odd, the player should be informed
// if ( gGameExternalOptions.fIndividualMilitia )
ScreenMsg( FONT_MCOLOR_RED, MSG_INTERFACE, L"Possible error: Not enough individual militia found in GetIdOfUnusedindividualMilitia" );
// RunAwayScientist fix on 4/11/2018 - Creating new profiles when there's a bug duplicates orphaned militia that cannot be disbanded. We either need a clean-up method or the player can just move his militia back to the sector where they were orphaned to fix.
// nobody found. That shouldn't really happen, as we are supposed to create data whenever new militia is created. Create new data and use that
// return CreateNewIndividualMilitia( militialevel, MO_ARULCO, aSector );
}
--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^
void MoveIndividualMilitiaProfiles( UINT8 aSourceSector, UINT8 aTargetSector, UINT8 usGreens, UINT8 usRegulars, UINT8 usElites )
{
std::vector<MILITIA>::iterator itend = gIndividualMilitiaVector.end( );
for ( std::vector<MILITIA>::iterator it = gIndividualMilitiaVector.begin( ); it != itend; ++it )
{
// RunAwayScientist on 4/11/2018 - Redundant, the FOR loop should already catch end of vector. This may also cause a premature termination of the loop if 0's are fed to this function.
// if ( !usGreens && !usRegulars && !usElites )
// return;
if ( !((*it).flagmask & (MILITIAFLAG_DEAD | MILITIAFLAG_FIRED | MILITIAFLAG_DESERTION )) && (*it).sector == aSourceSector )
{
if ( usGreens && ( *it ).militiarank == GREEN_MILITIA)
{
(*it).sector = aTargetSector;
--usGreens;
}
else if ( usRegulars && (*it).militiarank == REGULAR_MILITIA)
{
(*it).sector = aTargetSector;
--usRegulars;
}
else if ( usElites && (*it).militiarank == ELITE_MILITIA)
{
(*it).sector = aTargetSector;
--usElites;
}
}
}
// if this feature is on and we get to this point, then there aren't enough individual militia. This is odd, the player should be informed
if ( (usGreens + usRegulars + usElites) && gGameExternalOptions.fIndividualMilitia )
ScreenMsg( FONT_MCOLOR_RED, MSG_INTERFACE, L"Possible error: Not enough individual militia found in MoveIndividualMilitiaProfiles" );
}
Thank you Flug or whoever who corrected the scope issues relating to recruiting militia. This combined with the above bug fixes should effectively fix 90% of mobile milita issues.
Disbanding militia seems to work just fine. So far.
@GiantBasher: Your issue was related to the bug above. As some point you moved militia into a sector you had loaded and it duplicated the profiles and orphaned others. The only fix is to load a point BEFORE it happened or restart your game or hex your save file and remove them. You can also set 'Individual Militia' to FALSE in your JA2_Options.ini and then turn it back to TRUE, but they will still be there most likely.
There's some optional changes I'd like to recommend as well, such as disabling the 'Milita could not find gun to use, uses harsh language instead!' chat spam that happens whenever unarmed militia are moving around the map. This occurs in every sector movement, resulting in 180 messages for a stack of 60 unarmed militia over three sectors (for example).
[[ Militia Individual.cpp ]] { ORIGINAL CODE } :
Toggle Spoiler
ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"Militia found no gun to equip, uses harsh langugage instead!" );
}
}
// we didn't find any gun at all. Now what?
else
{
si[SI_GUN].done = TRUE;
ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"Militia found no gun to equip, uses harsh langugage instead!" );
}
[[ Militia Individual.cpp ]] { CHANGED CODE } :
Toggle Spoiler
// RunAwayScientist on 4/11/2018 - Disabled no gun messages.
// ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"Militia found no gun to equip, uses harsh langugage instead!" );
}
}
// we didn't find any gun at all. Now what?
else
{
si[SI_GUN].done = TRUE;
// ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"Militia found no gun to equip, uses harsh langugage instead!" );
}
One more problem remains: There is one more bug to fix and it's related to militia in a group traveling into the same sector in which mercs arrived and the sector is occupied by enemies. If this occurs, the militia DO NOT equip any inventory they had with them and will be unarmed for combat when they arrive at the sector edge. I assume this is also a very easy fix, anyone who knows what function call or method directly affects this please check it out or submit to trunk. I'd love you long time.
.
Report message to a moderator
|
|
|
|
|
Re: New feature: individual militia[message #353094 is a reply to message #353052]
|
Thu, 12 April 2018 21:44
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
@LatZee: I'm not entirely sure how Kerberus gets cheaper. What?
@RunAwayScientist: First of, thanks for taking the time to look into issues. I hope I can check it out at the weekend latest.
Now, it seems your GetIdOfUnusedIndividualMilitia(...) does not return an ID if the profile does not exist. Does that compile? Second, if we do not have a profile, we need to create one, otherwise militia would be without it. So...
The idea in MoveIndividualMilitiaProfiles(...) was to speed up the loop (we could have hundreds or thousands of profiles and don't want to always loop over all of them). I originally planned to have a separate vectors for each sector, but that seemed excessive.
As to the warnings... the idea is to warn the player if something goes wrong (classic sirtech code solves that problem by simply crashing the game with Assert(0);, which is excessive). I mean, if militia somehow have no guns, that is... bad. Hmmm. I'd rather have those warnings at least in debug mode.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
Re: New feature: individual militia[message #353106 is a reply to message #353094]
|
Fri, 13 April 2018 02:50
|
|
LatZee |
|
Messages:187
Registered:December 2015 |
|
|
Flugente wrote on Thu, 12 April 2018 20:44@LatZee: I'm not entirely sure how Kerberus gets cheaper. What?
Well, to demonstrate, latest SCI, fresh install, started a game with INDIVIDUAL_MILITIA set to FALSE, hired Raider, ALT-O to Drassen, train a batch of militia to trigger Kerberus email, and the prices are:
Save, exit game, toggle INDIVIDUAL_MILITIA to TRUE, no other changes, start game, reload that same save, and prices are now:
If I had to guess how, I'd guess that hire price somehow gets mixed up with upkeep when the individual militia is on but as I said, it is really a microissue, to use the Calvin Barkmore vocabulary so probably not very important, just reporting it for completeness sake
Report message to a moderator
|
Staff Sergeant
|
|
|
Re: New feature: individual militia[message #353107 is a reply to message #353094]
|
Fri, 13 April 2018 02:56
|
|
RunAwayScientist |
|
Messages:84
Registered:September 2001 |
|
|
>does not return an ID if the profile does not exist. Does that compile?
Yes. It compiles and runs correctly. This is not good practice, I know, so perhaps you'd prefer a return null or 0? This function does not apparently require a return and terminates normally if no returned ID is provided. Your code is very robust.
> Second, if we do not have a profile, we need to create one, otherwise militia would be without it. So...
Nope, this is not required. What ends up happening is that if there is a problem or bug, it *will* create a new militia. This new militia ID orphans the old militia ID. This is how we get duplicated militia with orphan militia IDs that cannot be removed from savegames or dismissed. They are 'ghost' or 'phantom' IDs sitting in a vector. The game counts their salaries and results in a doubling of daily expenses. They *can* be dismissed manually, but this is annoying for the end user. They also /cannot/ be dismissed after their linked actual militia dies or disbands, resulting in stuck 'phantom' militia IDs in the save file that cannot be removed no matter what you do.
> As to the warnings...
Yes, I agree. This is good practice. However, a new variable should be used to measure the current computer clock time so that only *1* single debug message should be displayed every 30 minutes, or use in-game time for every day. This would cut back on the spam and still be a useful reminder to the player that they have unarmed militia.
For my games: I commonly smuggle in Kerberus militia into ports and docks and move them completely unarmed to reinforce current combat locations where I can give them equipment. This is how I encountered this issue.
@LatZee: If I understand the Kerberus code correctly, purchase prices are directly related to the settings in MilitiaIndividual.xml ; have you tried modifying those values and then going back to it? After I changed those values, I noticed that the purchase price for my Kerbs went up. I believe it's a hardcoded percentage or multiplier, but this can definitely be modified in the code or through the .xml to match the default prices.
I will pay.... a fair price.
[Updated on: Fri, 13 April 2018 03:05] Report message to a moderator
|
|
|
|
|
Re: New feature: individual militia[message #353133 is a reply to message #353107]
|
Sat, 14 April 2018 17:32
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
RunAwayScientist wrote on Thu, 12 April 2018 23:56>does not return an ID if the profile does not exist. Does that compile?
Yes. It compiles and runs correctly. This is not good practice, I know, so perhaps you'd prefer a return null or 0? This function does not apparently require a return and terminates normally if no returned ID is provided. Your code is very robust.
This is bad. If we create an existing militia soldier by, say, loading tactical, we use
Soldier.usIndividualMilitiaID = GetIdOfUnusedIndividualMilitia( pCreateStruct->ubSoldierClass, SECTOR( pCreateStruct->sSectorX, pCreateStruct->sSectorY ) );
So if we do not find a profile, this militia now has usIndividualMilitiaID 0 which means no ID. This means that this guy has no profile, thus no data will be stored etc.. As a result the feature now only works partially. I get that creating additional profiles is bad, but not creating ones for those missing them is at least equally bad.
RunAwayScientist wrote on Thu, 12 April 2018 23:56
> Second, if we do not have a profile, we need to create one, otherwise militia would be without it. So...
Nope, this is not required. What ends up happening is that if there is a problem or bug, it *will* create a new militia. This new militia ID orphans the old militia ID. This is how we get duplicated militia with orphan militia IDs that cannot be removed from savegames or dismissed. They are 'ghost' or 'phantom' IDs sitting in a vector. The game counts their salaries and results in a doubling of daily expenses. They *can* be dismissed manually, but this is annoying for the end user. They also /cannot/ be dismissed after their linked actual militia dies or disbands, resulting in stuck 'phantom' militia IDs in the save file that cannot be removed no matter what you do.
I guess the easiest (while not satisfactory) solution would be to write a function that loops over all sectors, counts militia, compares that to the 'alive' profiles existing for that sector, and creates new ones where required or culls excessive ones (newest first). Not satisfactory at that doesn't cure the root of the problem, which is new profiles not always being created properly for whatever reason.
RunAwayScientist wrote on Thu, 12 April 2018 23:56
> As to the warnings...
Yes, I agree. This is good practice. However, a new variable should be used to measure the current computer clock time so that only *1* single debug message should be displayed every 30 minutes, or use in-game time for every day. This would cut back on the spam and still be a useful reminder to the player that they have unarmed militia.
For my games: I commonly smuggle in Kerberus militia into ports and docks and move them completely unarmed to reinforce current combat locations where I can give them equipment. This is how I encountered this issue.
Eh. You kinda want that warning instantly. Knowing that something went wrong in the battle I've just started is good. Knowing that something went wrong at some point today is not useful. I'll think of something.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
Re: New feature: individual militia[message #353177 is a reply to message #353133]
|
Mon, 16 April 2018 18:49
|
|
RunAwayScientist |
|
Messages:84
Registered:September 2001 |
|
|
Flugente wrote on Sat, 14 April 2018 14:32So if we do not find a profile, this militia now has usIndividualMilitiaID 0 which means no ID. This means that this guy has no profile, thus no data will be stored etc.. As a result the feature now only works partially.
Yes, this is correct only for people who are updating their existing savegame from dev build <=r8202 where their existing militia must be given profiles, or from when they switch the feature on. (You know this, I'm just clarifying to anyone reading)
It's a safer alternative to leaving it on. If all root causes cannot be addressed, this might be a half-measure solution. Otherwise, yes, this is not an ideal workaround.
Quote:Not satisfactory at that doesn't cure the root of the problem
I'm crossing my fingers, but I believe with the missing moveMilitiaProfiles call added in the if/elseif/else chain, this will cure all errors and writing a 'Clean-Up' method will not be required.
Is there any way we can check for a duplicate ID or reference during profile creation?
Or check for profiles in a sector where there are no corresponding militia? (This will catch orphaned IDs, since orphaned IDs do not have their sector X, Y coords changed)
Report message to a moderator
|
|
|
|
Re: New feature: individual militia[message #353231 is a reply to message #353177]
|
Thu, 19 April 2018 22:27
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
I'v committed some things in r8558.
The argument in Strategic Movement.cpp was wrong though (we have to move the profiles first). ResetMilitia() would be rather bad in this case though, as this function causes militia to drop all guns and creates them anew, in new positions, and then arms them. We absolutely don't want that in case they arrive in combat (and it looks a lot better if they arrive on the sector border, the reset would cause them to be all over the sector).
MoveIndividualMilitiaProfiles(...) is a bit more effective now, and the relevant warnings only show up once in that file. Not the harsh language thing though. That's kinda important methinks.
Currently the only way outside of the code to know what profiles exist is the website.
[Updated on: Thu, 19 April 2018 22:28]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Oct 12 10:35:51 GMT+3 2024
Total time taken to generate the page: 0.02596 seconds
|