Home » MODDING HQ 1.13 » Flugente's Magika Workshop » Absurdly small code changes  () 1 Vote
Re: Absurdly small code changes[message #341994 is a reply to message #341896] Fri, 07 August 2015 00:40 Go to previous messageGo to next message
Franimus

 
Messages:43
Registered:June 2015
Location: USA
Flugente:

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
Re: Absurdly small code changes[message #342012 is a reply to message #341994] Fri, 07 August 2015 23:11 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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!



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #342055 is a reply to message #342012] Wed, 12 August 2015 02:02 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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:
http://i.imgur.com/Xzydpq3.png
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.

Code spoiler:
Toggle Spoiler


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]




Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #342056 is a reply to message #342055] Wed, 12 August 2015 02:09 Go to previous messageGo to next message
Slax

 
Messages:1439
Registered:July 2006
Location: People riding polar bears...
Flugente wrote on Wed, 12 August 2015 02:02
Cleaning guns is now a single command - out side of combat, everybody cleans their guns, in combat only the currently selected merc.

Do cleaning kits get shared between mercs or is that still manual? Anyway, much obliged.



1.13: Install JA2, unpack latest, play.
AIMNAS: Complete 1.13 installation, Download ZIP and unpack, play.

Re: Absurdly small code changes[message #342063 is a reply to message #342056] Wed, 12 August 2015 13:12 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
Everybody only cleans their own guns.



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #342127 is a reply to message #342063] Wed, 19 August 2015 23:06 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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.



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #343867 is a reply to message #342127] Tue, 26 January 2016 22:06 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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:
http://i.imgur.com/AE2BERD.png
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]




Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #343979 is a reply to message #343867] Sat, 06 February 2016 01:57 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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.



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #343980 is a reply to message #343979] Sat, 06 February 2016 02:29 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
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.



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

Re: Absurdly small code changes[message #343981 is a reply to message #343980] Sat, 06 February 2016 10:32 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3805
Registered:July 2009
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.



Chat with us!
#bearpit on IRC
Discord
Get your latest 1.13 Builds
(Pls don't use my forum PMs for general game queries)


Re: Absurdly small code changes[message #344001 is a reply to message #343981] Sat, 06 February 2016 19:22 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
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.



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

Re: Absurdly small code changes[message #344009 is a reply to message #344001] Sat, 06 February 2016 21:27 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
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.

[Updated on: Sat, 06 February 2016 21:28]




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

Re: Absurdly small code changes[message #344016 is a reply to message #344009] Sun, 07 February 2016 01:48 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
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.



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

Re: Absurdly small code changes[message #344020 is a reply to message #344016] Sun, 07 February 2016 03:44 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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 happy

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 :
http://i.imgur.com/e9KQjoc.png



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #344026 is a reply to message #344020] Sun, 07 February 2016 12:13 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
Flugente wrote on Sun, 07 February 2016 02:44
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 happy


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.



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

Re: Absurdly small code changes[message #344074 is a reply to message #344026] Wed, 10 February 2016 15:26 Go to previous messageGo to next message
Uriens

 
Messages:330
Registered:July 2006
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.
Re: Absurdly small code changes[message #344078 is a reply to message #344074] Wed, 10 February 2016 21:04 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
Uriens wrote on Wed, 10 February 2016 14:26
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)



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

Re: Absurdly small code changes[message #344120 is a reply to message #344074] Sat, 13 February 2016 17:13 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
Uriens wrote on Wed, 10 February 2016 14:26
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).



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

Re: Absurdly small code changes[message #344131 is a reply to message #344120] Sun, 14 February 2016 21:47 Go to previous messageGo to next message
Uriens

 
Messages:330
Registered:July 2006
Thank you very much. happy
Re: Absurdly small code changes[message #344441 is a reply to message #344131] Wed, 09 March 2016 00:23 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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]




Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #344652 is a reply to message #344441] Mon, 21 March 2016 21:58 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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.



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #344736 is a reply to message #344652] Sun, 27 March 2016 01:22 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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.



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #344740 is a reply to message #344736] Sun, 27 March 2016 02:55 Go to previous messageGo to next message
Hazapuza

 
Messages:264
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..
Re: Absurdly small code changes[message #344743 is a reply to message #344740] Sun, 27 March 2016 10:40 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3805
Registered:July 2009
True, it would probably have been better to just add a new ammotype for fragments with such shit armor penetration that even flak can stop them.



Chat with us!
#bearpit on IRC
Discord
Get your latest 1.13 Builds
(Pls don't use my forum PMs for general game queries)


Re: Absurdly small code changes[message #344745 is a reply to message #344743] Sun, 27 March 2016 11:33 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
If I don't misinterpret the changes "flak jacket" doesn't mean the item but the tag in Items.xml.

<FlakJacket>1</FlakJacket>

You can set this for any armor you want.



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

Re: Absurdly small code changes[message #344746 is a reply to message #344745] Sun, 27 March 2016 12:04 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3805
Registered:July 2009
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.



Chat with us!
#bearpit on IRC
Discord
Get your latest 1.13 Builds
(Pls don't use my forum PMs for general game queries)


Re: Absurdly small code changes[message #344747 is a reply to message #344736] Sun, 27 March 2016 12:05 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
Flugente wrote on Sun, 27 March 2016 00:22

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.



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

Re: Absurdly small code changes[message #344756 is a reply to message #344747] Sun, 27 March 2016 19:23 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
silversurfer wrote on Sun, 27 March 2016 09:05
Flugente wrote on Sun, 27 March 2016 00:22

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).



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #344759 is a reply to message #344756] Sun, 27 March 2016 22:26 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
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?

[Updated on: Sun, 27 March 2016 22:35]




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

Re: Absurdly small code changes[message #344761 is a reply to message #344759] Sun, 27 March 2016 23:46 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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...



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #344762 is a reply to message #344761] Mon, 28 March 2016 00:20 Go to previous messageGo to next message
Hazapuza

 
Messages:264
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.

[Updated on: Mon, 28 March 2016 00:20]

Re: Absurdly small code changes[message #344763 is a reply to message #344761] Mon, 28 March 2016 00:41 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
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]




Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #344765 is a reply to message #344763] Mon, 28 March 2016 02:49 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
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.



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

Re: Absurdly small code changes[message #344766 is a reply to message #344763] Mon, 28 March 2016 03:01 Go to previous messageGo to next message
edmortimer

 
Messages:1046
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.




Arulco Vacations Blog

Arulco Vacations Bears Pit Forum


Re: Absurdly small code changes[message #344767 is a reply to message #344763] Mon, 28 March 2016 04:00 Go to previous messageGo to next message
CVB

 
Messages:136
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
Re: Absurdly small code changes[message #344770 is a reply to message #344767] Mon, 28 March 2016 12:10 Go to previous messageGo to next message
silversurfer

 
Messages:2296
Registered:May 2009
CVB wrote on Mon, 28 March 2016 03:00

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.



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

Re: Absurdly small code changes[message #344772 is a reply to message #344770] Mon, 28 March 2016 14:37 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
@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:
Current stock armour vest values (base version)									
									
ID	Name	        Weight	Price	Aim	AP	Stealth	Flak?	Protection	Coverage
161	Flak Jacket	20	600	-1	0	0	True	20	        75
164	Kevlar Vest	32	1000	-2	0	0	False	25	        70
167	Spectra Vest	32	2000	-4	-3	0	False	29	        85
189	Kevlar  Leather	20	950	-1	0	0	False	20	        85
196	Guardian Vest	32	1400	-3	-3	0	False	28	        70
283	Zylon Vest	30	1300	-2	-1	0	False	25	        85
284	Field Uniform	35	1400	-2	0	0	False	25	        85
295	SWAT Vest	33	1100	-2	-1	0	False	28	        90
803	Dyneema Vest	20	2000	-3	0	0	False	29	        85
806	EOD Vest	65	4000	-10	-8	0	True	50	        99
812	Twaron Vest	25	1200	-3	-3	0	False	28	        75
									
183	Ceramic Plates	12	1000	-2	0	0	False	50	        50*
837	Titanium Plate	10	750	-1	0	0	False	35	        10*


*: plate coverage is not a modifier but is a value for the plate itself

Flugente's proposed rebalancing									
									
ID	Name	        Weight	Price	Aim	AP	Stealth	Flak?	Protection	Coverage
161	Flak Jacket	25	600	-2	-2	-10	True	20	        75
164	Kevlar Vest	31	1000	-2	-2	-10	False	25	        70
167	Spectra Vest	36	2000	-6	-6	-20	False	31	        84
189	Kevlar  Leather	20	800	-1	0	-5	False	17	        90
196	Guardian Vest	34	1200	-2	-5	-15	False	28	        70
283	Zylon Vest	30	1400	0	-3	-10	False	25	        75
284	Field Uniform	32	1500	0	-4	-10	False	25	        80
295	SWAT Vest	36	1800	-4	-4	-5	False	26	        90
803	Dyneema Vest	38	2000	-6	-2	-20	False	28	        84
806	EOD Vest	65	4000	-10	-10	-25	True	50	        100
812	Twaron Vest	30	1500	-4	-4	-15	False	28	        77									
									
183	Ceramic Plates	12	1000	-3	-1	-3	False	50	        50*
837	Titanium Plate	10	750	-1	-1	-3	False	35	        50*
									
	+C-18			        -1	-1	-3		4	
	+Royal Jelly			1	0	3		2	

  • 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.
Current stock armour pants values (base version)									
									
ID	Name	        Weight	Price	Aim	AP	Stealth	Flak?	Protection	Coverage
170	Kevlar Leggings	39	800	0	-3	0	False	23	        65
173	Spectra L.	39	1800	0	-6	0	False	27	        90
282	Zylon Combat P.	35	1000	0	-3	0	False	23	        90
294	SWAT Leggings	39	900	0	-3	0	False	26	        75
802	Dyneema L.	30	1800	0	-3	0	False	27	        95
805	EOD Leggings	48	2400	0	-12	0	True	45	        99
811	Twaron Leggings	30	1000	0	-3	0	False	26	        80
									
838	Leg Protectors	10	400	0	0	0	False	14	        25*

  • Dyneema leggings rule even more than Dyneema vests angry
Flugente's proposed rebalancing									
									
ID	Name	        Weight	Price	Aim	AP	Stealth	Flak?	Protection	Coverage
170	Kevlar Leggings	35	800	-1	-2	-10	False	23	        65
173	Spectra L.	39	1600	-3	-6	-20	False	29	        85
282	Zylon Combat P.	33	1000	0	-3	-10	False	23	        70
294	SWAT Leggings	39	1400	-2	-4	-5	False	24	        90
802	Dyneema L.	35	1600	-3	-2	-20	False	26	        85
805	EOD Leggings	48	2400	-5	-10	-30	True	45	        100
811	Twaron Leggings	33	1200	-2	-4	-15	False	26	        75
									
838	Leg Protectors	10	400	0	-1	0	False	14	        25*

  • The changes are pretty much in line with those from vests.
Current stock armour helmet values (base version)									
									
ID	Name	        Weight	Price	Aim	AP	Stealth	Flak?	Protection	Coverage
176	Steel Helmet	14	100	-1	0	0	False	14	        65
177	Kevlar Helmet	14	400	-1	0	0	False	23	        75
180	Spectra Helmet	14	900	-1	0	0	False	27	        75
293	SWAT Helmet	14	500	-1	0	0	False	26	        65
302	Camo Steel H.	14	200	-1	0	0	False	14	        65
801	Dyneema Helmet	10	900	-1	0	0	False	27	        70
804	EOD Helmet	35	1600	-4	0	0	True	45	        99
810	Twaron Helmet	10	600	-1	0	0	False	26	        70

  • Steel helmets are bad.
  • +5% camo doubles a Steel helmet's price.
  • If .4 kg weight are ok for you, Spectra wins. Otherwise, it still wins against most.
  • Somehow, the SWAT helmet is uncharacteristically bad at coverage.
  • You'd think that helmet's would hinder aiming more, and with some differentiation.

Flugente's proposed rebalancing
							
ID	Name	        Weight	Price	Aim	AP	Stealth	Flak?	Protection	Coverage
176	Steel Helmet	12	100	-1	-1	-10	False	18	        65
177	Kevlar Helmet	12	400	-2	-1	-7	False	23	        65
180	Spectra Helmet	14	800	-6	-3	-14	False	29	        75
293	SWAT Helmet	14	700	-4	-2	-3	False	24	        85
302	Camo Steel H.	12	120	-1	-1	-10	False	18	        65
801	Dyneema Helmet	11	800	-6	-1	-14	False	26	        75
804	EOD Helmet	35	1600	-10	-5	-20	True	45	        100
810	Twaron Helmet	12	600	-4	-2	-7	False	26	        70

  • 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.



Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #344773 is a reply to message #344770] Mon, 28 March 2016 15:33 Go to previous messageGo to next message
CVB

 
Messages:136
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
Re: Absurdly small code changes[message #344774 is a reply to message #344773] Mon, 28 March 2016 15:44 Go to previous messageGo to next message
Flugente

 
Messages:3307
Registered:April 2009
Location: Germany
CVB wrote on Mon, 28 March 2016 12:33
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.
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]




Saren threw his head back and screamed in impotent fury, before falling to his throne, head in his claws, trembling in horrified disbelief.

Then he heard a faint chime as Sovereign subscribed to her ECHO channel.

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.


Re: Absurdly small code changes[message #344776 is a reply to message #344774] Mon, 28 March 2016 16:48 Go to previous messageGo to previous message
CVB

 
Messages:136
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
Previous Topic: New feature: Intel
Goto Forum:
  


Current Time: Mon May 21 10:14:03 EEST 2018

Total time taken to generate the page: 0.02387 seconds