Came across this warning in Strategic Movement.cpp CalculateTravelTimeOfGroup(), looks important
// Flugente: start with the next waypoint we travel to, not the first one in the list
i = pGroup->ubNextWaypointID;
while ( i-- )
{
//Traverse through the waypoint list to the next waypoint ID
[b]if (pNode);[/b]
pNode = pNode->next;
}
The pNode = pNode->next; is executing regardless of the if statement due to the extra semicolon
Hmm. I copied that over from somewhere else, normal Sirtech code is to just crash the game if a pointer is NULL. Though in this case, a fix is easy. Good find!
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.
While scavenging the country and digging through the loot is a fun aspect of the game, parts of it can be very tedious. For example, if you use a weapon with 5 or so attachments and special ammo, and then come upon the same gun with a higher status, it is reasonable to replace the gun. This requires unloading, removing the attachments, swapping the guns, loading it and reattaching the attachments. This gets worse the more items there are, as after every battle you have to look at the loot to find out whether there's sth. better (you don't have to, but you know you want to).
I've added a little helper function for this in r7966:
The Improve gear option simply loops over all mercs present, checks whether there are any items in the sector (of the same item number), and, if an item with a higher status is found, swaps the two, along with ammo and attachments. You get a message for each swapped item.
This simply simulates the player performing these actions by hand. For this, both items must have the same item number, we accessible, not hidden to us and not be armed bombs.
If an item has inseparable attachments, we don't use it to swap, as the player wouldn't be able to do that by hand either.
Only status is relevant here, the repair threshold is not taken into account. As a consequence, a 80% M16 with a threshold of 100% will be swapped with a 81% M16 with a threshold of 81%.
Temperature and dirt are also not taken into account, this won't normally be a problem, as guns dropped by the enemy are rarely dirtier/hotter than a mec's guns, and food always spawns fresh.
This works for any item in your inventory.
This only works outside of combat.
Note that the items need to of the same item number. Determining what gun is superior to another gun is the source of looooooooooooooooooot of debate and threads and excels sheets and whatnot, so I won't go there.
Technically, we don't do a real swap for speed reasons - read the comment in void UpdateGear() to learn why you should only do this if you know what you're doing (I assume I do here).
Cleaning guns is now a single command - out side of combat, everybody cleans their guns, in combat only the currently selected merc.
[Updated on: Thu, 13 August 2015 13:08]
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.
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.
In r7981 & GameDir r2271 I've externalised two corpse-related values:
[Corpse Settings]
;******************************************************************************************************************************
; In this section you can specify settings for corpses
;******************************************************************************************************************************
; How many minutes it takes until a corpse begins to rot. Default 1440 (1 day), valid values from 720 (1/2 day) to 10080 (7 days)
CORPSE_DELAY_UNTIL_ROTTING = 1440
; How many minutes it takes until a corpse vanishes. Default 4320 (3 days), valid values from 1440 (1 day) to 20160 (14 days)
CORPSE_DELAY_UNTIL_DONE_ROTTING = 4320
This might be interesting if you play with zombies or disease.
Or if you like your sectors to be filled to the brim with charred, twisted human remains in various stages of decay, with a few burned out tanks as well. You twisted fruit.
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.
For once, no new code, just a very useful code section in case you ever want to alter map tilesets and want to know in what maps a tileset is used:
As you might know, the map editor has this very useful sector summary:
This is normally only updated if a map has been loaded or if you press the Update button. Still tedious, if you want to know data about all maps - but there is, however, a small code section that updates all maps in void LoadGlobalSummary() in Sector Summary.cpp:
...
if( gfMustForceUpdateAllMaps )
{
OutputDebugString( (LPCSTR)String( "A MAJOR MAP UPDATE EVENT HAS BEEN DETECTED FOR %d MAPS!!!!.
", gusNumberOfMapsToBeForceUpdated ) );
//ADB update it!
ApologizeOverrideAndForceUpdateEverything();
}
...
gfMustForceUpdateAllMaps is never set to true (perhaps someone somewhere sometime deleted a function here?), but if you do so via debugger, all map data gets updated, which is very convenient in case you, say, want to add a specific tile to as many maps as possible and want to find out which sets to alter (and/or which maps to look at for possible conflicts upon replacing stuff). *cough*Sandbags*cough*
Again, nothing new at all, but I just found this and am happy I don't have to code it.
[Updated on: Tue, 26 January 2016 22:06]
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.
As some people might know, normal enemy soldiers come in 3 varieties: troops, elites and admins. Admins are dickheads that ignore at you if you point out that your companies' development process might be comically unsafe one of the queen's forces: their are basically the police/thugs that enforce her will over the population with an iron fist. They are, however, less equipped for spec-ops warfare (as a result, they are the 'easiest' type of enemy).
A vanilla mechanic is that these admins are supposed to be replaced by troops over time - as the conflict escalates, it is logical that the queen improves these admins to regular troops. This is largely unchanged since vanilla, depends on player progress and a sector/patrol's priority, and there are 2 settings for that in DifficultySettings.xml, UpgradeAdminsToTroops and UpgradeGarrisonsAdminsToTroops.
However, what these settings do is to auto-force the conversion as soon as possible. At a progress as low as as 10!!!, all admins are always converted everywhere. This is absurdly low. This basically removes admins from all but the extremely earliest encounters. It may be vanilla, but I call it bullshit.
As of r8051 & GameDir r2291, I have changed this as follows:
UpgradeAdminsToTroops (0/1) controls whether admins in patrols can be upgraded by the AI.
UpgradeGarrisonsAdminsToTroops (0/1) controls whether admins in garrisons can be upgraded by the AI.
AlwaysUpGradeAdminsToTroopsProgress (0 to 100) is a progress level. Once the highest player progress reaches this, both conditions above are taken to be true.
As a result, setting both options to false while setting AlwaysUpGradeAdminsToTroopsProgress to a high value means you might actually encounter admins for more than the first few battles. Setting the options to true or setting the progress low will ensure you will only encounter them shortly.
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.
That's a good change. Admins were almost non-existent in the game so far.
I would even go farther and change the way the game assigns soldier levels. Depending on progress we usually get only a very small range of levels which leads to teams that are comprised of only level x +/- 1 so we could end up fighting a team of lieutenants and captains which is a bit strange in my opinion. Deidranna is constantly losing troops and she has to train new soldiers. They don't grow on trees with level 8. I would rather have more variety in levels throughout a team but I don't know how others would like such change.
That's less a problem with all of them being level 8 (after all, we're talking about late-mid to early-end game here, those guys need the level to not get stomped even harder) and more with the inherent stupidity of the rank scale we are using.
I might as well implement it. Of course the default behaviour would be what we know today. I guess I will add parameters to DifficultySettings.xml that allow to set a lower and upper limit so people can decide if they want to have a chance for balanced, weaker or harder opponents, militia etc.
While looking at the code I found some strange things.
1. Maximum character level is not consistent throughout the code. At some points it is 9, at others it is 10. I guess I should fix this to 10?
2. For all difficulty levels other than "Insane" there is a hardcoded soldier upper level limit of 6 (Easy), 7 (Experienced) or 8 (Expert). So anyone not playing on "Insane" is not allowed to fight higher level opponents? I plan to remove this limiter. Objections?
I can make it a setting in DifficultySettings.xml if people would like to keep the old behaviour.
In revision 8052 I fixed the inconsistent handling of max XP level. Max XP level is now 10 across the board. I also added the missing rank name for level 10 to EnemyRank.xml in GameDir 2292.
In addition to that I added some level variance to soldier creation like I planned to do. With this we do not have to fight a team full of only sergeants (or other rank depending on progress) anymore. There are two new parameters in DifficultySettings.xml in GameDir 2292:
LevelModifierLowLimit (0-5): This allows to randomly lower the soldiers XP level and attributes up to this amount. LevelModifierHighLimit (0-5): This allows to randomly increase the soldiers XP level and attributes up to this amount.
Examples:
Balanced modification: Low and high limit are 2 which means the XP level could be decreased or increased by up to 2 points so a soldier that would be level 4 in the old system could randomly roll an XP level between 2 an 6.
Difficulty decrease: Low limit is 3 and high limit is 0. A soldier that would be level 4 in the old system could randomly roll an XP level of 1 to 4.
Difficulty increase: Low limit is 0 and high limit is 3. A soldier that would be level 4 in the old system could randomly roll an XP level of 4 to 7.
Of course no soldier can fall below level 1 or beyond level 10.
Furthermore I added the following parameter to DifficultySettings.xml:
AllowUnrestrictedXPLevels (0/1): In the old system the game restricted higher XP levels for combatants. The upper limit was 6 (Novice), 7 (Experienced) and 8 (Expert). Only players that played on "Insane" could ever fight higher level enemies. This parameter allows to override this restriction so you can have high level enemies with your "Novice" configuration as well.
All these settings are optional. Their default values represent the old system. If you want to use them you will have to change them to something else than 0.
That sounds good. Any other bizarre code in that region? There's probably code untouched for over a decade down there, which can be interesting
Sandbag/concertina fortifications are not possible in all sectors. Where are they? I've added both to the GENERIC 2 (Dirtroads) tileset in GameDir r2293. Fortifications are now possible in the sectors marked with a green box (this does not account for alternate maps though), USE_XML_TILESETS = TRUE is required :
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.
That sounds good. Any other bizarre code in that region? There's probably code untouched for over a decade down there, which can be interesting
I didn't look too deep in the code but I noticed other things that were unknown to me. For example on Insane there is a minimum experience/stats level of 6 and random calculation for attributes allowed the attributes to go over 100. The latter was probably a result of the confusion about max level 9 or 10 and I fixed that as well.
Any chance to look at the item condition from dead enemies on insane level? It seems to be hardcoded to make all items enemies drop trash that badly needs repairs. It would be great if that value could be externalized as well.
Any chance to look at the item condition from dead enemies on insane level? It seems to be hardcoded to make all items enemies drop trash that badly needs repairs. It would be great if that value could be externalized as well.
That's not a bad idea. The reduction in item status is rather drastic on insane and we will not be able to use something until we spend a large amount of time for repairs.
The formula for that currently is:
new status = current status - (difficulty level - 1) * random(20)
Insane difficulty level is 4 which means that the current status could be lowered by 0 up to 57 points. If that would be externalized it should be made independent of difficulty level so I guess the new formula should look like:
new status = current status - random(externalized value)
Any chance to look at the item condition from dead enemies on insane level? It seems to be hardcoded to make all items enemies drop trash that badly needs repairs. It would be great if that value could be externalized as well.
There you go - revision 8056 with GameDir 2294 has the necessary parameter "LootStatusModifier" to set the possible randomized damage to dropped equipment. The default values in DifficultySettings.xml are 0 (Novice), 20 (Experienced), 40 (Expert) and 60 (Insane).
Because I was just in the neighbourhood, I've invested an hour or so into creating sth mildly useful in r8099: a basic cth display.
By pressing [Ctrl] + [c] and then selecting "CTH mode", the display will give you a very rough indication of cth.
All tiles in your current firing cone (what you can target without changing direction) are coloured:
red: cth > 0%
orange: cth > 25%
yellow: cth > 50%
green: cth > 75%
As demonstrated in the video, this takes into account
gun stats
attachments
merc stance
targetted location (head, torso, legs)
firing mode
aim level
offhand items
When you use a grenade, grenade launcher or bomb, the red area around the target/bomb cursor indicates the explosive radius. The orange area then represents the frag range (due to the random nature of frags, this does not guarantee a hit).
Note that there are a lot of cth calculations here, and this will slow down debug builds or bigmaps gameplay, even more so with NCTH. Note that in order to lower those, the calculations are only done in the firing cone, and only while inside the gun's range.
[Updated on: Wed, 09 March 2016 00:30]
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.
I fixed an error that is likely in since vanilla in r8115: negative values for ExplosionSoundID or AltExplosionSoundID in ExplosionData.xml can cause a game crash, even though negative values are intended. This now works properly. This means that if both values are -1, the explosion won't cause a sound - useful if you want, for example, a smoke effect without that annoying noise.
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.
r8120: You might not know this, but the AI is forbidden from having more than one mortar-equipped soldier at a time. At least it was - DifficulySettings.xml now has the <MaxMortarsPerTeam>-tag to change that. On insane, this is now 2. While this will increase the difficulty, as mortars are so dangerous, this also means the player might have more shells for to use...
r8124: Flak jackets have tripled protection against explosive damage. It seems extremely logical to me that they should also offer that against fragments (I believe this was the intention anyway), so now they do.
r8126: Armed vehicles (tanks and combat jeeps) now have their AI separated from the normal AI. For now this is just the normal AI with all unnecessary parts cut. I hope I didn't cut off something valuable, testing seems ok.
GameDir r2310: While silent explosions are now possible (see post above), this causes the xml editor to crash, as it cannot handle ExplosionSoundID of -1. For this reasons, I added an empty .wav (nothing.wav) that plays no sound.
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.
Messages:262
Registered:February 2009 Location: Finland
Pretty much all mil-spec body armors today are just as good (and often better) at protecting against shrapnel as a surplus Vietnam-era US Army flak jacket, which is what I assume the in-game Flak Jacket is supposed to be. That said, since we don't know what specific armors the Kevlar/Spectra/Twaron/Dyneema/whatever vests are supposed to represent, it's impossible to say exactly how well they would perform against fragmentation threats..
Point still stands. Flak jackets aren't especially good at catching fragments due to some magical property, fragments are so easy to catch that even flak can stop them. And EOD (the only other armor with that tag) is such a mountain of kevlar it'll stop nearly anything anyway.
r8126: Armed vehicles (tanks and combat jeeps) now have their AI separated from the normal AI. For now this is just the normal AI with all unnecessary parts cut. I hope I didn't cut off something valuable, testing seems ok.
Can you please upload "Build\ModularizedTacticalAI\include\LegacyArmedVehiclePlan.h"? The current code won't compile anymore because this new file is missing.
r8126: Armed vehicles (tanks and combat jeeps) now have their AI separated from the normal AI. For now this is just the normal AI with all unnecessary parts cut. I hope I didn't cut off something valuable, testing seems ok.
Can you please upload "Build\ModularizedTacticalAI\include\LegacyArmedVehiclePlan.h"? The current code won't compile anymore because this new file is missing.
Hmpf. Why do I always do that? Committed in r8129.
As to the flak jackets - while I get that all modern vests would have that property, not just the flak vest and EOD gear, this at least gives the flak vest at least some usefulness later on.
I'm a fan of items not being majorised by others. In that regard, I also plan to tweak the current stock armour values (perhaps even today or tomorrow) so that each armour type is good for a specific purpose (or, better said, specific objective function).
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.
Linker still fails.
edit: Nevermind. I just downloaded your update.
Flugente wrote on Sun, 27 March 2016 18:23
I'm a fan of items not being majorised by others. In that regard, I also plan to tweak the current stock armour values (perhaps even today or tomorrow) so that each armour type is good for a specific purpose (or, better said, specific objective function).
What exactly do you have in mind? Armor exists mainly to protect against bullets and fragments from explosions. The only differences I can think of is how strong they are, how well they cover the body, how durable they are and how much they hinder the wearer. All of these properties already exist. Do you want to modify these or implement something new?
For now, no new properties. It' just that some armour completely dominates other armour in each and every stat. For example, dyneema vest is better than Spectra, Twaron, Guardian vest in every way. This is bad gamewise, I feel. Hmm. I should probably post what I have in mind...
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.
Messages:262
Registered:February 2009 Location: Finland
If there's going to be a revamp of the armor items, I'd like to see them replaced with more realistic models. I could help with researching and selecting good candidates, if there's any interest for doing this. I know it would take a lot more work than simply rebalancing the existing values, and probably someone to make the images (unless IoV or some other mod has usable ones already), but the current imaginary armors are a bit of an eyesore considering that the vast majority of other gear is strictly based on real life stuff.
These are the , in my view, relevant current stock values for the base armour vests:
ID Name Weight Aim AP Stealth Flak? Protection Coverage
161 Flak Jacket 20 -1 0 0 True 20 75
164 Kevlar Vest 32 -2 0 0 False 25 70
167 Spectra Vest 32 -4 -3 0 False 29 85
189 Kevlar Leather 20 -1 0 0 False 20 85
196 Guardian Vest 32 -3 -3 0 False 28 70
283 Zylon Vest 30 -2 -1 0 False 25 85
284 Field Uniform 35 -2 0 0 False 25 85
295 SWAT Vest 33 -2 -1 0 False 28 90
803 Dyneema Vest 20 -3 0 0 False 29 85
806 EOD Vest 65 -10 -8 0 True 50 99
812 Twaron Vest 25 -3 -3 0 False 28 75
A few things I don't like:
Stealth mali are not used at all. It seems clear to me that any type of armour would make you significantly less stealthy compared to not wearing armour at all.
AP mali are used inconsistently. Kevlar, Field Uniform and Dyneema don't have a penalty even though comparable vests have
SWAT Vest owns Zylon Vest, Guardian Vest and Twaron Vest in all but tiny weight differences.
Dyneema vest owns Spectra Vest, Guardian Vest and Twaron Vest in all categories. Dyneema vs. Sepctra is especially bad - Dyneema has no AP penalty, better aim an weighs 1.3 kg less.
99% coverage in EOD seems bad to me. The thing already has loads of drawbacks, why do we even allow lucky shots here?
I propose the following rebalance:
ID Name Weight Aim AP Stealth Flak? Protection Coverage
161 Flak Jacket 30 -2 -2 -10 True 20 75
164 Kevlar Vest 30 -2 -2 -10 False 25 70
167 Spectra Vest 40 -6 -6 -20 False 31 84
189 Kevlar Leather 20 -1 0 0 False 17 90
196 Guardian Vest 36 -2 -5 -15 False 28 70
283 Zylon Vest 30 0 -3 -10 False 25 75
284 Field Uniform 30 0 -4 -10 False 25 80
295 SWAT Vest 38 -4 -4 0 False 26 90
803 Dyneema Vest 36 -6 -2 -20 False 28 84
806 EOD Vest 65 -10 -10 -25 True 50 100
812 Twaron Vest 35 -4 -4 -15 False 28 77
Stealth mali are now used, AP mali are used consistently. Apart from special cases, not wearing any armour now means consistently higher AP, better aim and better stealth. For some players, this might be even an alternative.
Flak Jacket stays in line with other items. While generally bad, it's the only item apart from EOD that has the flakjacket tag. For troops who mostly fear explosive damage (like, say, artillery), this would be a cheap, viable and surprisingly good alternative to other armour, now that this also helps against frags.
Kevlar Leather is light, maneuverable and covers you well, but does not reduce damage a lot.
EOD Vest now has 100% cover and the highest stealth penalty.
Idea is that Kevlar Vest -> Twaron Vest -> Spectra Vest - these armours are the 'base line' of armours. Each tier has higher coverage and protection, but also higher weight and penalties. The remaining armours are basically variations of these, better in some regards but worse in others.
Guardian Vest is a high-protective variant of Kevlar Vest, but this comes at a high AP tradeoff.
Zylon Vest might be used for mercs who need to maximize CTH - no to-hit malus, , slightly higher coverage, but higher AP malus.
Field Uniform is a subversion of Zylon Vest - even higher coverage, no to-hit malus, but higher AP malus.
SWAT Vest has the second-highest coverage, and no stealth malus, making it ideal for infiltration and against small-arms. It's downside is its comparably lower protection.
Dyneema Vest now has significantly lower protection than Spectra Vest, but also a very low AP penalty.
This seems a lot move balanced to me. And frankly, I'd like to change this in stock. Yes, yes, holy Sirtech values in many cases. But if we never change these, they'll always stay bad.
The C18/treated versions would then basically be variants of these, with fixed modifiers to each value, similar to as it is now (but more consistent). The other Medic/Field Ops/Stealth/Mechanic stuff I won't touch, it's dead weight anyway.
To be clear, I don't necessarily aim for max consistency of item <-> real world item here, but more for game balancing.
Anyway, opinions welcome.
[Updated on: Mon, 28 March 2016 00:48]
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.
I guess a bit more balancing is nice to have. It was a bit boring in the past where most players were probably aiming for a full set of Dyneema armor. With the updated values one has to make certain sacrifices and select the armor that best suits the role of a merc.
It's like with the guns that we have. All of them have certain pros and cons and there is no "best" gun.
I hope you are planning to update helmets and pants accordingly?
Also you will need to update the NCTH values. <AimBonus> only applies to OCTH.
Messages:1533
Registered:January 2015 Location: Home Free
I'm glad to see Stealth penalties associated with the armours -- I have already incorporated a version of that in AV. I don't think SWAT armour should get no penalty -- it is bulky and does hinder maneuverability, though not as much as other armours, but definitely more than no armour (say, -5 Stealth). I like your balancing for the most part, and definitely agree it's been a long time coming. As one who likes to play with as little armour as possible, it is certainly a welcome addition.
One area I would diverge a bit is that the weights of the armours do not increase in rl as you have them here. For game balance sake there is another factor to involve, price, which would ameliorate the lesser real world weight of the better armours. The better armours are very much more expensive than the lesser armours.
All in all, I think it is a welcome addition. I probably will incorporate much of it as-is in AV.
Messages:129
Registered:September 2014 Location: Berlin
Overall, I lke this a lot. While we are at it, could "Field uniform" be replaced with another name? An armour vest is at best a part of a field uniform...
Some niggling:
I think that the same factor (limited freedom of upper body movement) that negatively impacts your aim will also impact your APs, so I dislike the strong opposite spread of these two values for Guardian and Dyneema vests.
SWAT vest and Kevlar leather should get a small Stealth malus (-2 to -5) to fit the normal leather jacket (at Stealth 0) into the list.
While it's good that no longer are a few armours so clearly superior to so many others, in the new list not a single armour is definitely superior (by the numbers) to any other. In every comparison between any random pair of armours each contestant wins in at least one value. This is greaz when you want to keep all vests usefull at all progress levels, but seems problematic because of two reasons:
- some player satisfaction derives from the improvement of your equipment. When it depends on personal interpretation if any given armour is better than any other, item placement in maps and at BR becomes problematic.
- enemy equipment selection should become better at higher progress levels and for higher quality troops. Again, assigment is difficult if there is no clear "better"
Peace is a purely theoretical state of affairs whose existence we deduce because there have been intervals between wars.
J. Pournelle
While it's good that no longer are a few armours so clearly superior to so many others, in the new list not a single armour is definitely superior (by the numbers) to any other. In every comparison between any random pair of armours each contestant wins in at least one value. This is greaz when you want to keep all vests usefull at all progress levels, but seems problematic because of two reasons:
- some player satisfaction derives from the improvement of your equipment. When it depends on personal interpretation if any given armour is better than any other, item placement in maps and at BR becomes problematic.
- enemy equipment selection should become better at higher progress levels and for higher quality troops. Again, assigment is difficult if there is no clear "better"
In my opinion there is still improvement. I mean the most important parameter for assault troops is still armor value because it helps to stop bullets. For that we still have Guardian, Twaron, Dyneema and Spectra sets. Even with the new values I would still select Spectra or Dyneema for my front line troops. This also fits current item selection by progress where armor value is most important for direct assault. The enemy troops don't care if they get a stealth or AP penalty. Weight also isn't a factor for them. The only thing that will affect them is the aim penalty and that is only slightly changed.
@silversurfer: Yeah, the NCTH modifiers are done similar to the Aim bonus.
@edmortimer: I've adjusted stealth a bit. I've also changed weight a bit - it's now more of a mixture of current values and those that I'd ideally want, some weights go up, others go down. I've also adjusted prices a bit. both withing the current ranges, nothing drastically.
@CVB: Well, the Guardian vests concept is that it's simply a beefed up variant of the Kevlar vest (one can interpret the description that way), which results in more protection but also less mobility. The Dyneema's 'thing' is now extreme mobility, represented by AP. I know this seems a bit odd, but seems good balance-wise to me.
Swat and Kevlar Leather now have a small stealth penalty.
I don't plan to greatly alter coolness (if at all), so I don't see a BR problem. As for map placement - at least in vanilla maps 6 out of those 11 don't even exist.
The AI selects it's gear by looking at the gear table and drawing a random item from it. There was no evaluation of how good sth. is in the first place, so these changes shouldn't make this worse.
Anyway, updated data here, please let me know your thoughts:
Titanium plating had a coverage of 10, which is unreasonable since ceramic plates had 50. Additionally, both plates get a bit of AP and stealth penalty
Adjustes stealth penalties for Kevlar Leather and Swat Vest.
With stock values, C-18 versions had less protection but also a higher AP and aim penalty than Jelly versions. I know Jelly is extremely hard to get, but why not make these two compete? No C-18 adds a lot of protection for some drawbacks. Jelly doesn't add that much, but actually removes penalties. Thereby both should be useful.
Stealth and AP penalties aren't as harsh as for vests and leggings, but aim penalties fully kick in.
The steel helmets are still bad, but not as bad. They at least have the same coverage as a kevlar helmet, though less protection. Additionally, their aim penalty is relatively low. Still bad, but not as bad as before.
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.
Messages:129
Registered:September 2014 Location: Berlin
silversurfer wrote on Mon, 28 March 2016 11:10
I mean the most important parameter for assault troops is still armor value because it helps to stop bullets. For that we still have Guardian, Twaron, Dyneema and Spectra sets. Even with the new values I would still select Spectra or Dyneema for my front line troops. This also fits current item selection by progress where armor value is most important for direct assault.
Actually, I agree with you, in my opinion as well, there is improvement. The problem I see is that your or my opinion are not necessarily the same as anybody else's. For example, when we select Dyneema over Guardian (same weight, same protection) for our frontline troops, we implicitly and subjectively decide that an additional -4 aim penalty and worse stealth is more acceptable than an additional AP penalty of -3. Someone else might disagree.
If we stay with your selection of Guardian, Twaron, Dyneema and Spectra, my ideal solution would be a distribution where there is no clear winner among Guardian, Twaron and Dyneema, no clear winner among Dyneema, Twaron and Spectra, but Spectra unambiguously wins over Guardian. In my opinion, that would give us the best of both worlds. We have a broader selection of valid armours at any given moment, and still some clearly defined progress.
Quote:
The enemy troops don't care if they get a stealth or AP penalty. Weight also isn't a factor for them. The only thing that will affect them is the aim penalty and that is only slightly changed.
I didn't know that enemy troops were not subject to AP penalties. Then I withdraw my second point.
Peace is a purely theoretical state of affairs whose existence we deduce because there have been intervals between wars.
J. Pournelle
I mean the most important parameter for assault troops is still armor value because it helps to stop bullets. For that we still have Guardian, Twaron, Dyneema and Spectra sets. Even with the new values I would still select Spectra or Dyneema for my front line troops. This also fits current item selection by progress where armor value is most important for direct assault.
Actually, I agree with you, in my opinion as well, there is improvement. The problem I see is that your or my opinion are not necessarily the same as anybody else's. For example, when we select Dyneema over Guardian (same weight, same protection) for our frontline troops, we implicitly and subjectively decide that an additional -4 aim penalty and worse stealth is more acceptable than an additional AP penalty of -3. Someone else might disagree.
If we stay with your selection of Guardian, Twaron, Dyneema and Spectra, my ideal solution would be a distribution where there is no clear winner among Guardian, Twaron and Dyneema, no clear winner among Dyneema, Twaron and Spectra, but Spectra unambiguously wins over Guardian. In my opinion, that would give us the best of both worlds. We have a broader selection of valid armours at any given moment, and still some clearly defined progress.
Quote:
The enemy troops don't care if they get a stealth or AP penalty. Weight also isn't a factor for them. The only thing that will affect them is the aim penalty and that is only slightly changed.
I didn't know that enemy troops were not subject to AP penalties. Then I withdraw my second point.
Eh? Well, yes, we decide that then. That's our decision. Someone else might come to a different decision. I don't really understand why you want Spectra to unambiguously win over Guardian. The point is to change this so this does not happen anymore.
We now have a clearly defined progress with Kevlar -> Twaron -> Spectra. Protection and coverage gets better, penalties worse. The rest being variants or extreme outliers (EOD, Kevlar Leather). But no armour should be obsolete in every way (price is not a good counter for this - most armour comes from enemy drops anyway, so buying price is irrelevant).
I think you misunderstood silversurfer here. The AI is subject to all penalties. It just doesn't care. There is no decision process involved. Some factors, like weight, price and stealth though are irrelevant.
[Updated on: Mon, 28 March 2016 15:47]
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.
Messages:129
Registered:September 2014 Location: Berlin
Replying to two posts at once, was still writing when you posted your first answer today.
Flugente wrote on Mon, 28 March 2016 13:37
The AI selects it's gear by looking at the gear table and drawing a random item from it. There was no evaluation of how good sth. is in the first place, so these changes shouldn't make this worse.
Sorry, brainf*rt on my part. I thought that armour is subject to progress level like enemy gun choices. So the evaluation is only implicit by assignment of an item to admin/regular/elite tables.
Flugente wrote on Mon, 28 March 2016 14:44
Eh? Well, yes, we decide that then. That's our decision. Someone else might come to a different decision. I don't really understand why you want Spectra to unambiguously win over Guardian. The point is to change this so this does not happen anymore.
We now have a clearly defined progress with Kevlar -> Twaron -> Spectra. Protection and coverage gets better, penalties worse. The rest being variants or extreme outliers (EOD, Kevlar Leather). But no armour should be obsolete in every way (price is not a good counter for this - most armour comes from enemy drops anyway, so buying price is irrelevant).
I understand your point, I just don't share it completely. The original obsolescence pattern was bad, and I really like your proposal in principle. I just happen to think that switching from "a very few items supersede everything else" to "nothing is ever completely obsolete" is too much, and my proposal was aimed at "a few items supersede a few other items over time, while other items don't get obsolete".
I don't think that progress you mentioned (progress defined as getting better) is "clearly defined". When protection gets better and penalties worse, it's a judgment call if the penalties are really worth the gain. As you said, someone else may come to a different decision. For example, if you play an extremely careful and patient night-attack game and hardly ever get shot at, the penalties may outweigh the added protection. However by assigning (or leaving alone) coolness factors to items and assigning items to admin/regular/elite ItemChoices tables, that personal, subjective judgment call is now linked to objective game progress.
Quote:
I think you misunderstood silversurfer here. The AI is subject to all penalties. It just doesn't care. There is no decision process involved. Some factors, like weight, price and stealth though are irrelevant.
Thanks for the clarification.
Peace is a purely theoretical state of affairs whose existence we deduce because there have been intervals between wars.
J. Pournelle
) 1 Vote
Blog
Search
Help
Members
Register
Login
Home
