Wasteland People Bitching About Jamming

[GarfunkeL]

I fought some red scorpions, the last guy had 1 (one!) HP left, my sniper had 95% chance but the fucking rifle got jammed and the bastard threw a pipe bomb which killed 3 of my men. True story, bros.

And you will be telling that story to your grandchildren in the decades to come.

 

[Konjad]

The weapons don't jam more often than the game tells you, which OP proves.

The weapons have higher jamming rate than I guess they would have IRL as someone already mentioned.

Except only if we count weapons in great condition and considering the game hinting at the player that even the powerful groups like desert rangers just scavenge them it makes sense the weapons are jamming more often than IRL because the equipment in the game is supposed to be old and worn in general. (Notice that the new technology - energy weapons - doesn't jam)

 

[toro]

Weapons still jams a little too many times, but it seems it is just bad luck.

5% chance to jam ≙ statiscally, 1 out of 20 shots will cause your gun to jam

So we mod our gunz with this baby here:

1% chance to jam ≙ statiscally, 1 out of 100 shots will cause your gun to jam

Spoiler

You don't know what you are talking about.

The code posted from Immortal is just doing a jam-chance-check each time you use the weapon independent of the previous shoots.

This is naive implementation and basically if the RNG generator is fucked (stays in some limited range) then you can have infinite JAMs. The algorithm allows this.

Basically I don't see anything wrong with the code but we don't have all the code in that picture: please post the content of current.GetBonus("chanceToJam") function.

Until then my assumption is that Unity's RNG generator might be fucked meaning that it generates more numbers closed to 0 (could be a special case just for some type of processors).

Other than this, the code is unoptimized: the addition of chanceToJam each fucking time is retarded. I wonder why?

 

[Mangoose]

Non realistic jamming probability is only an issue if the rest of the game is realistic. Is this a realistic game? Do a realistic percentage (a la the majority lol) of shots miss? Does it take a realistic number of shots to kill an enemy?

Etc. Etc.

If you're playing a simulator like ARMA then there is a point to having realistic jamming probabilities. Otherwise, it's a matter of game balance/playability.

(That's not to say jamming percentage is not an issue in WL2. Just that the subject needs to be approached a different way than "realism.")

 

[Norfleet]

This is naive implementation and basically if the RNG generator is fucked (stays in some limited range) then you can have infinite JAMs. The algorithm allows this.

Really, I doubt that. Even if you used perfect quantum randomness and the code worked perfectly, given the kind of numbers involved, it would happen constantly anyway.

 

[Vault Dweller]

It's like we be playin' and then we be jammin'.

 

[gromit]

You don't know what you are talking about.
(...)
Basically I don't see anything wrong with the code but we don't have all the code in that picture: please post the content of current.GetBonus("chanceToJam") function.
(...)
Other than this, the code is unoptimized: the addition of chanceToJam each fucking time is retarded. I wonder why?

Are you kidding me? You can't ask and say such things if you're going to start your post like that.

The getBonus function is just returning the chanceToJam value of each weapon mod so it can add those negatives to the weapon's base chance before it is returned. It's getting a known number, and adding it to an unknown, what is your difficulty here?

Terrible optimization? That shit can fetch one integer and add it to another up to THREE TIMES per someone shooting a gun. Hello framerate killer!

A high cost indeed for not trampling all over information you're going to use again, and avoiding stupid upstream bugs, and just generally encouraging consistency, encapsulation and flexibility.

 

[Raghar]

Does someone have a source code to actual RNG implementation in Unity?

Also normally competent game developers are copying random generator to theirs library to avoid changes in updating theirs framework. Less than high end RNG that has been tested upon, is better alternative to something that can change in background.

 

[Immortal]

Does someone have a source code to actual RNG implementation in Unity?

Also normally competent game developers are copying random generator to theirs library to avoid changes in updating theirs framework. Less than high end RNG that has been tested upon, is better alternative to something that can change in background.

Did you even read the thread..

 

[Raghar]

I fought some red scorpions, the last guy had 1 (one!) HP left, my sniper had 95% chance but the fucking rifle got jammed and the bastard threw a pipe bomb which killed 3 of my men. True story, bros.

You should hire that guy into your team.

 

[Raghar]

Does someone have a source code to actual RNG implementation in Unity?

Also normally competent game developers are copying random generator to theirs library to avoid changes in updating theirs framework. Less than high end RNG that has been tested upon, is better alternative to something that can change in background.

Did you even read the thread..

Yes I did. I didn't see any source code of Unity's RNG. Also I'm pretty sure they didn't move Unity's RNG into theirs own library to ensure proper statistical behavior.

 

[Immortal]

Does someone have a source code to actual RNG implementation in Unity?

Also normally competent game developers are copying random generator to theirs library to avoid changes in updating theirs framework. Less than high end RNG that has been tested upon, is better alternative to something that can change in background.

Did you even read the thread..

Yes I did. I didn't see any source code of Unity's RNG. Also I'm pretty sure they didn't move Unity's RNG into theirs own library to ensure proper statistical behavior.

I posted the algorithm used in Unity's Random implementation and the code is open source.

 

[Raghar]

You posted source code of MT.

BTW where is Unity3D searchable repository?

 

[Immortal]

You posted source code of MT.

BTW where is Unity3D searchable repository?

 

[toro]

You don't know what you are talking about.
(...)
Basically I don't see anything wrong with the code but we don't have all the code in that picture: please post the content of current.GetBonus("chanceToJam") function.
(...)
Other than this, the code is unoptimized: the addition of chanceToJam each fucking time is retarded. I wonder why?

Are you kidding me? You can't ask and say such things if you're going to start your post like that.

The getBonus function is just returning the chanceToJam value of each weapon mod so it can add those negatives to the weapon's base chance before it is returned. It's getting a known number, and adding it to an unknown, what is your difficulty here?

Terrible optimization? That shit can fetch one integer and add it to another up to THREE TIMES per someone shooting a gun. Hello framerate killer!

A high cost indeed for not trampling all over information you're going to use again, and avoiding stupid upstream bugs, and just generally encouraging consistency, encapsulation and flexibility.

Do you see the source code for getBonus() function? No. Is it so far fetched to think that they have some Luck formula involved or some other shit?

That little part of tiny code is unoptimized. That is obvious. I didn't say that the entire source code is like that but of course you are too fucking retarded to think for a second.

"A high cost indeed for not trampling all over information you're going to use again, and avoiding stupid upstream bugs, and just generally encouraging consistency, encapsulation and flexibility." - you forgot to mention Agile in order to check all the buzzwords.

Would you kindly fuck off?

 

[Immortal]

Is it so far fetched to think that they have some Luck formula involved or some other shit?

No.. But I already said that it wasn't there..

public virtual float GetBonus(string statName)
{
 float num = 0f;
 ItemTemplate_Mod itemTemplate_Mod = this.template as ItemTemplate_Mod;
 if (itemTemplate_Mod != null)
 {
 float stat = itemTemplate_Mod.GetStat(statName);
 num += stat;
 }
 return num;
}

That little part of tiny code is unoptimized.

No it's not.. The method is linear (O(n))

 

[Revolucas]

Other than this, the code is unoptimized: the addition of chanceToJam each fucking time is retarded. I wonder why?

It's kind of funny how cocky you act but you proved you have no idea what you are talking about with this statement. I'm surprised you are allowed to run around here with a mouth like that.

 

[gromit]

consistency, encapsulation and flexibility.

buzzwords

For real? Ok then. Anyone with a genuine interest in this stuff:

Is it so far fetched to think that they have some Luck formula involved or some other shit?

That depends on the "so" in "so far fetched." But it would be naive and harmful, for many reasons.

The heart of OOP is encapsulation keeping things intuitive, logical, and distinct, and not going at it like a phantom-shitter with a penchant for booby-traps.

Each object is responsible for its own information and actions.

Crossover should should take place at at a level / within an object which is

1. high enough that it can or does contain or reference all the sources
2. low enough that it can be used in all the necessary scenarios and contexts
3. somewhere between those as to reflect "real world" relationships and actions

People w/ Luck use Weapons. Weapons can Jam when used. Jams involve the Weapon. Weapons can have Mods. Mods use getBonus() to provide Mod info. Doing otherwise creates many issues, for no reason.

• Mod info adjusted by other things, is no longer info about the Mod. Info you need, to show in the inventory, and for when you must recalculate.
• Jam code at the Mod-level increases a Mod's complexity. But Mods don't Jam. They're just numbers relevant to Weapon use.
• Splitting a calculation up and scattering it, obscures it. The Jam system is no longer controlled where it "happens." The definition of a Mod now contains critical logic, specific to Jams, People, and Luck.
  
• Apply Luck per input, and it must be done for all potential inputs. The above problems are exacerbated.

One piece of logic, split in two, invoked three places, running four times, to do one thing.... for a total of infinite headache potential, zero mathematical difference, one inevitable murder-suicide, and several (very ignorable) performance hits.

Minor downsides. But ones created for no reason, while deftly avoiding most of the upsides of OOP.

That little part of tiny code is unoptimized. That is obvious.

Before changing working code to be more "optimized" it helps to ask:

1. Would it impact performance in a meaningful way?
2. Would it avoid introducing unwanted complexity?
   
3. Would it be a clean, acceptable trade, without hidden cost?

1. No. Once or twice per turn -- "hundreds" to "hundreds of thousands" of frames -- we read four non-decimal numbers from an object in memory, and take their sum. You could almost keep up on pen and paper.
2. No. The computed value must be specifically recalculated each time it could change. Timeless RPG bug: equipment effects that refuse to apply or remove if things don't go "just right."
3. No. Storing the sum, for each weapon on the field, consumes memory across all frames. Logic to calculate and store as-needed, could cause more impact than it avoids.

In this case, going past Step 1 is a waste of time. Even getting TO Step 1 is a waste of time. There is X happening each frame to figure out what you're pointing at, where X is way greater than adding four numbers together when you click.

I didn't say that the entire source code is like that but of course you are too fucking retarded to think for a second.

I didn't say I thought you said that, so you should have thought for a second before thinking, you, you -- you great big meanie.

I said I thought you say some awfully bold shit, about other people not knowing what they're talking about, for that talking, about what you're not knowing.

 

[Black]

Even if the weapons jammed way "too" often, I had no problem with it. One, it happened to enemies too, a fucking blessing when it happened to the AG Center Boss.
Second, that's one of the differences between energy weapons and conventional boom sticks. Energy weapons are next-gen and streamlined so they don't jam at all. Old weapons are old and no amount of maintenance will turn them into straight outta factory. Added to my immershun.

 

[Immortal]

consistency, encapsulation and flexibility.

buzzwords

For real? Ok then. Anyone with a genuine interest in this stuff:

Is it so far fetched to think that they have some Luck formula involved or some other shit?

That depends on the "so" in "so far fetched." But it would be naive and harmful, for many reasons.

The heart of OOP is encapsulation keeping things intuitive, logical, and distinct, and not going at it like a phantom-shitter with a penchant for booby-traps.

Each object is responsible for its own information and actions.

Crossover should should take place at at a level / within an object which is

1. high enough that it can or does contain or reference all the sources
2. low enough that it can be used in all the necessary scenarios and contexts
3. somewhere between those as to reflect "real world" relationships and actions

People w/ Luck use Weapons. Weapons can Jam when used. Jams involve the Weapon. Weapons can have Mods. Mods use getBonus() to provide Mod info. Doing otherwise creates many issues, for no reason.

• Mod info adjusted by other things, is no longer info about the Mod. Info you need, to show in the inventory, and for when you must recalculate.
• Jam code at the Mod-level increases a Mod's complexity. But Mods don't Jam. They're just numbers relevant to Weapon use.
• Splitting a calculation up and scattering it, obscures it. The Jam system is no longer controlled where it "happens." The definition of a Mod now contains critical logic, specific to Jams, People, and Luck.
  
• Apply Luck per input, and it must be done for all potential inputs. The above problems are exacerbated.

One piece of logic, split in two, invoked three places, running four times, to do one thing.... for a total of infinite headache potential, zero mathematical difference, one inevitable murder-suicide, and several (very ignorable) performance hits.

Minor downsides. But ones created for no reason, while deftly avoiding most of the upsides of OOP.

That little part of tiny code is unoptimized. That is obvious.

Before changing working code to be more "optimized" it helps to ask:

1. Would it impact performance in a meaningful way?
2. Would it avoid introducing unwanted complexity?
   
3. Would it be a clean, acceptable trade, without hidden cost?

1. No. Once or twice per turn -- "hundreds" to "hundreds of thousands" of frames -- we read four non-decimal numbers from an object in memory, and take their sum. You could almost keep up on pen and paper.
2. No. The computed value must be specifically recalculated each time it could change. Timeless RPG bug: equipment effects that refuse to apply or remove if things don't go "just right."
3. No. Storing the sum, for each weapon on the field, consumes memory across all frames. Logic to calculate and store as-needed, could cause more impact than it avoids.

In this case, going past Step 1 is a waste of time. Even getting TO Step 1 is a waste of time. There is X happening each frame to figure out what you're pointing at, where X is way greater than adding four numbers together when you click.

I didn't say that the entire source code is like that but of course you are too fucking retarded to think for a second.

I didn't say I thought you said that, so you should have thought for a second before thinking, you, you -- you great big meanie.

I said I thought you say some awfully bold shit, about other people not knowing what they're talking about, for that talking, about what you're not knowing.

Today's Buzzwords are:
'Encapsulation' 'Decoupling' and 'Inheritance'..

The fact he said the only buzz word you are missing is Agile.. leads me to believe he actually isn't a software developer or knows wtf he is talking about.. These aren't buzz words.. I can't have a conversation at my job without talking about this stuff on a regular basis..

Buzz words are generally things that don't have a meaning but sound like they do (and are catchy or easy to say).. The words toro claim are buzz words take abstract and complex ideas on code design and condense them into one word so we can have conversation about them in under 5 hours.

 

[Awor Szurkrarz]

Wait, this game has a chance for weapon to jam that is measured in percents? It's a crazy level of unreliability, no wonder that people get jams multiple times in a row.
Are the weapons in game in very bad shape or something like that?

 

[Spockrock]

there's this paper on the reliability of four weapon platforms, based on info from combat veterans: M16, M4, M249 and M9. InXile should read it to understand that even the most prone to jamming weapons don't have percentages that high. although, they have cleaning kits in the armed forces. not sure if desert rangers get those

 

[Immortal]

there's this paper on the reliability of four weapon platforms, based on info from combat veterans: M16, M4, M249 and M9. InXile should read it to understand that even the most prone to jamming weapons don't have percentages that high. although, they have cleaning kits in the armed forces. not sure if desert rangers get those

Is this really important for a video game? They wanted to introduce a mechanic that effects ranged weapons in order to balance them without just taking down the damage or increase the AP price.

It just adds depth to the game.. The realism argument is never a good one.. If you feel the mechanic just plane sucks that's a more defensible position then "Well my dad is a gun expert and he says..."

 

[Spockrock]

that's my argument: it doesn't add anything to combat.

I saw enemies have their weapon jam a whooping 2 times in 50+ hours of playing. although, it's not representative since it's only my experience, but to me this mechanic seems useless in its current implementation.

combat in W2 is so basic -- missing a lot of crucial elements of ranged combat (quick shots vs. carefully aimed shots and how it affects accuracy, character's stance - this is implemented to a degree, but still not where it needs to be etc.) -- that having jamming over those more important elements feels like an afterthought

 

[Immortal]

that's my argument: it doesn't add anything to combat.

I saw enemies have their weapon jam a whooping 2 times in 50+ hours of playing. although, it's not representative since it's only my experience, but to me this mechanic seems useless in its current implementation.

combat in W2 is so basic -- missing a lot of crucial elements of ranged combat (quick shots vs. carefully aimed shots and how it affects accuracy, character's stance - this is implemented to a degree, but still not where it needs to be etc.) -- that having jamming over those more important elements feels like an afterthought

So if you could have a mod that adds more to combat and balances the game out.. what would it be? It's easier to shit all over something then to improve it.

 

[Spockrock]

answered in two other threads: (1), (2)