r8667: The duration and size of smoke clouds is reduced depending on weather. Using gas attacks would be hindered by weather, no?
r8668: If DISABLE_EVOLUTION = FALSE, a merc's evolution is shown on their 'More Stats' page in the laptop. So now you can check the laptop instead of hunting the value in MercProfiles.xml.
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.
A small idea from Taro in Discord that might be good, might be bad, but is trivial enough to implement on a test basis:
As of r8669 & GameDir r2473, vision range is lowered by 25% while running due to a new JA2_Options.ini setting:
;------------------------------------------------------------------------------------------------------------------------------
; If set to 0, nothing happens.
; If set to 1, vision is lowered while running.
; If set to 2, this only applies to the player team.
;------------------------------------------------------------------------------------------------------------------------------
LOWER_VISION_WHILE_RUNNING = 2
This means that rapidly closing in on the enemy will more likely cause them to see you first - you can't win an interrupt duel if you can't see them after all (okay, you can, but that's rather hard).
As the AI doesn't always run, their odd idea of walking instead of running might actually benefit them here. Of course attacking against fixed positions is now even deadlier... that's why you can set the value to 2 to at least force yourself to use tactics.
As said, I'm not sure whether this is useful. If it turns out it isn't I can always remove this later on, for now, test this out.
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.
Vision range is one of the biggest problems of AI as it cannot use scopes effectively and player can always have better scopes than average AI soldier.
I even wanted to remove scope vision bonus completely from Ja2+AI for better game balance.
I don't think that limiting sight range for running soldiers can help to improve balance as running solder already has penalty for interrupt level.
One possibility for running penalty could be increasing tunnel vision effect.
There's also a question if sight range is always updated correctly when solder starts\stops to run, also with disabled switching to standing animation at destination tile limited vision can be confusing for some players.
As for AI refusing to run in combat situation, I think that integrating movement mode code from Ja2+AI into the trunk can help with it as in my project enemy soldiers nearly always run when alerted except when swatting or crawling is more effective for hiding. Walking is only allowed when cautious mode flag is set (walking around the corner) or soldier has weapon raised so he can not lose raise AP cost and scope sight bonus while walking.
Hmm. Tunnel vision would be an alternative I guess. Hmm.
I should probably mention that this is set to 0 by default.
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.
[*] r8659: Skinning a bloodcat yields a bloodcat pelt. The status of said fur depends on how messily you murdered the poor thing, and how skilled you are at flaying stuff.
Looking at the code, it seems that bloodcat pelt is randomly (30%) dropped from bloodcats, and can also be retrieved by decapitating, what was the idea for adding another way of getting bloodcat pelt?
EDIT IN: And now, once again, I don't know where I read this in this thread, I could have sworn it was in the last two pages, but can't find it, argh. Seems it is in Barrel Modifications on the previous page in this thread.
Not trying to ask for too much, but the Baikal and the Sawed Off Shotgun discussion did catch my eye.
Now, here's the problem. In real life, and for usefulness, the desired ability to decide or set how many barrels you fire should be adjustable in game, just like selecting single,burst, or autofire mode with machine pistols, smgs, or ARs. The reasoning is that without such in-game selectability, Hunters are made second class mercs. Or shotguns are made second-class.
Whether it is by the $ menu, or some other method, I don't care. But I should be able, at least when not in combat, to be able to select how many barrels I wish to unload per fire attempt. It should, as you say, cost about the same AP. But without some ease of selectability in-game, I'm stuck with either all barrels unleashed, or one barrel unleashed. Why should such a situational tactical choice be made almost strategic by having to set it up on an XML rather than by some keystroke in the game. I suggest this needs a keystroke in game to choose functionality. I realize this is very demanding, but I'm talking about balancing the use of weapons that aren't automatic. The move in this game to empowering the automatic and burst weapons is taking away all the fun in having semi-automatic or shotgun fun, all because they have no in-game functionality of choice.
Now I've had some wine, but I have to push back, again, against the constantly changing balance of these feature changes. Because if I don't, who the heck will? So bear with me, for a moment.
On Running taking away the ability to detect and interrupt ability -- you are beginning, I believe, to go too far.
Some weapons depend almost entirely on the ability to move in, using the movement bonus to not getting hit, to be effective. These charging specialists, train in doing all this. Meaning that they train to be able to detect and still run forward and acquire targets. In addition, they are likely connected to all the other shouts and radio chatter that their friendlies, who are spotting or not running forward, give them for enemy location and intel. Pretending that the only factor in all this is the ability of a moving player to see and shoot, is like pretending that tennis players can't hit a 100 mph ball fired into their court that they run down and still see it and hit it accurately back. Fact is, they can. Why? Because they train at it everyday. Hell, I could do it, and I'm no pro, just a pretty damn good player in my prime years ago. It was almost impossible for a 110 mph serve to get past me without me getting it back in court -- and again, I was no pro. Oh, and just to get the point across, I did it from less than 2 yards off the service line, not anywhere near the baseline. It was THAT EASY FOR ME. But I wasn't even a pro.
I realize you are trying to simulate your vision of realism. But your vision of realism, is not all that realistic. Hockey players can slap back at high speed hockey pucks fired faster at them than even tennis players. Goalies can stop such shot even thru a mask blocking their vision and teammates in the way. Let's get real. The time in a phase, does not require a full speed run. Those are APs, and if I have APs left to fire a weapon, it means I can run so fast, that I can charge upon you and then hit the brakes and fire into your body so well, that I can still take you down, because I have those APs, and I have that experience with the tactic I am using. Stop trying to force tactics. I know you think you aren't doing this, but you are. The whole game is starting to lean towards autofire everything, or explosives. Now, sheesh, I already know that autofire everything, with a fully cushioned weapon, and autofire rocket launchers, ought to take down everything in the known universe. Except, you don't simulate the huge kickback and necessary cyborg arms to do all that. But you let if fly nonetheless. Meanwhile single fire everything is now pwowned. Let's get real. The mechanics of the game allowed it. They did it for a reason. If you really are going to change that, then tunnel vision may be an adequate simulation, though wrong as heck, since most runners, swivel their heads like donuts in combat, unless the terrain is uneven. Remember, the chargerinos are virtual trackstars under war stress, that's what those stats represent. But meanwhile we already have unrealistic launching of run n gun RPG firing mercs -- which isn't realistic at all. Balancing requires more than taking every stat literally, it requires an understanding of the limitations of the game and what was once being simulated to the letter of the rules that is now.
So let me appeal to your logical integrity. If simulating this charging mechanic to lose vision takes away the whole charge and shoot aspect, did you perhaps overstate what was already understood in the ability of someone to run, then gain balance, and still fire after such a run -- instead of thinking as you did, that they aren't quite that fast, and are simply unable to recover in time to fire a balanced shot as they charge in? The mechanic/tactical option was there before, now you hamper it? Based on what exactly, some misunderstanding myopia of what was meant, or the plain truth? Think it over.
At the very least, make sure this is a toggleable option, because I think you are reading between the lines when you do this.
EDIT IN: And now, once again, I don't know where I read this in this thread, I could have sworn it was in the last two pages, but can't find it, argh. Seems it is in Barrel Modifications on the previous page in this thread.
Not trying to ask for too much, but the Baikal and the Sawed Off Shotgun discussion did catch my eye.
Now, here's the problem. In real life, and for usefulness, the desired ability to decide or set how many barrels you fire should be adjustable in game, just like selecting single,burst, or autofire mode with machine pistols, smgs, or ARs. The reasoning is that without such in-game selectability, Hunters are made second class mercs. Or shotguns are made second-class.
Whether it is by the $ menu, or some other method, I don't care. But I should be able, at least when not in combat, to be able to select how many barrels I wish to unload per fire attempt. It should, as you say, cost about the same AP. But without some ease of selectability in-game, I'm stuck with either all barrels unleashed, or one barrel unleashed. Why should such a situational tactical choice be made almost strategic by having to set it up on an XML rather than by some keystroke in the game. I suggest this needs a keystroke in game to choose functionality. I realize this is very demanding, but I'm talking about balancing the use of weapons that aren't automatic. The move in this game to empowering the automatic and burst weapons is taking away all the fun in having semi-automatic or shotgun fun, all because they have no in-game functionality of choice.
Eh? One sets what possible configurations a gun can use in the xml (if none is set, 1 barrel is used). Ingame one toggles through barrel configurations while toggling firemodes with the 'b' key. I mean... I don't exactly see how that can get any easier?
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.
Now I've had some wine, but I have to push back, again, against the constantly changing balance of these feature changes. Because if I don't, who the heck will? So bear with me, for a moment.
On Running taking away the ability to detect and interrupt ability -- you are beginning, I believe, to go too far.
Some weapons depend almost entirely on the ability to move in, using the movement bonus to not getting hit, to be effective. These charging specialists, train in doing all this. Meaning that they train to be able to detect and still run forward and acquire targets. In addition, they are likely connected to all the other shouts and radio chatter that their friendlies, who are spotting or not running forward, give them for enemy location and intel. Pretending that the only factor in all this is the ability of a moving player to see and shoot, is like pretending that tennis players can't hit a 100 mph ball fired into their court that they run down and still see it and hit it accurately back. Fact is, they can. Why? Because they train at it everyday. Hell, I could do it, and I'm no pro, just a pretty damn good player in my prime years ago. It was almost impossible for a 110 mph serve to get past me without me getting it back in court -- and again, I was no pro. Oh, and just to get the point across, I did it from less than 2 yards off the service line, not anywhere near the baseline. It was THAT EASY FOR ME. But I wasn't even a pro.
I realize you are trying to simulate your vision of realism. But your vision of realism, is not all that realistic. Hockey players can slap back at high speed hockey pucks fired faster at them than even tennis players. Goalies can stop such shot even thru a mask blocking their vision and teammates in the way. Let's get real. The time in a phase, does not require a full speed run. Those are APs, and if I have APs left to fire a weapon, it means I can run so fast, that I can charge upon you and then hit the brakes and fire into your body so well, that I can still take you down, because I have those APs, and I have that experience with the tactic I am using. Stop trying to force tactics. I know you think you aren't doing this, but you are. The whole game is starting to lean towards autofire everything, or explosives. Now, sheesh, I already know that autofire everything, with a fully cushioned weapon, and autofire rocket launchers, ought to take down everything in the known universe. Except, you don't simulate the huge kickback and necessary cyborg arms to do all that. But you let if fly nonetheless. Meanwhile single fire everything is now pwowned. Let's get real. The mechanics of the game allowed it. They did it for a reason. If you really are going to change that, then tunnel vision may be an adequate simulation, though wrong as heck, since most runners, swivel their heads like donuts in combat, unless the terrain is uneven. Remember, the chargerinos are virtual trackstars under war stress, that's what those stats represent. But meanwhile we already have unrealistic launching of run n gun RPG firing mercs -- which isn't realistic at all. Balancing requires more than taking every stat literally, it requires an understanding of the limitations of the game and what was once being simulated to the letter of the rules that is now.
So let me appeal to your logical integrity. If simulating this charging mechanic to lose vision takes away the whole charge and shoot aspect, did you perhaps overstate what was already understood in the ability of someone to run, then gain balance, and still fire after such a run -- instead of thinking as you did, that they aren't quite that fast, and are simply unable to recover in time to fire a balanced shot as they charge in? The mechanic/tactical option was there before, now you hamper it? Based on what exactly, some misunderstanding myopia of what was meant, or the plain truth? Think it over.
At the very least, make sure this is a toggleable option, because I think you are reading between the lines when you do this.
Sigh. I assume you mean LOWER_VISION_WHILE_RUNNING? That thing is set to be off by default, as mentioned earlier (though not in the initial post I admit). I am somewhat unsure why the sheer existence of options is a bad.
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.
Ok, I was obviously confused by what you had described earlier. I also, expressly said I was for options, I just wanted them in-game.
Here is the area of confusion for me. You said we needed to set how many barrels is default to fire in the INI. That suggested that you could not do it in the game. Then you say in the replies that B toggles the number of barrels to fire, with Shotguns with Two Barrels, for example. Um, then why do we need the INI file. I thought that you were saying that we could not switch with B how many barrels would fire at one time. Obviously, if that can be done in-game, I don't even have to worry about the INI or other file outside of the game. I just set it up via hitting B as many times as necessary (none, once, whatever), and I'm good to go.
Maybe you meant that the INI would set the new default as 1 or 2 barrels. Maybe otherwise B always goes back to default after a game session. Ok. But I thought you were saying that B did not handle number of Barrels fired in a Sawed-Off Shotgun or a Baikal. Your reply suggests I misunderstood that. I'll just say, I bet a lot of other people who never tried B for Shotguns also thought you implied it could not be done in-game.
Thanks for the reply. I'll test it out in game. I'm not against options, I'm always for them, I even said it in my post. So we both misread things. My apologies.
-----
On the Lowered Vision, etc. I'm all for options. I realized it is OFF by default. I just think the effect is a bit much. Character is running, so doesn't it already have a Stamina hit. Doesn't the movement code already make the character less accurate after all that. Hasn't the running character already used up most of its AP, so that it can't Aim much? Why then hit it with another Nerf? That was all I was getting at.
I could imagine a Standing Still feature that harms the person who doesn't run as well.
All of these stances or modes of movement already have pluses and minuses. Perhaps those numbers are already balanced with the belief that no further Feature with a Malus is going to added to one of the movement modes. Perhaps those old numbers would have to be tweaked if we add the Tunnel Vision or Lowered Vision, whichever implementation ends up final.
Again, that was all I was getting at. Just for consideration. My counter suggestion is assigned as dead in the water, I can live with that.
From revision 8675 GameDir 2475 the "Drop All" option in JA2_Options.ini works a little different than before. The old False/True combination was replaced by a number.
We now have 3 values for "Drop All":
0 means "Drop All" is off, JA2 default
1 means "Drop All" is on
2 means "Mild Drop All"
You already know how the first two work in the game. How does a value of "2" work? It's basically a combination of the two others. You get all items like "1" but those that you wouldn't have gotten with "0" are severely damaged now instead of vanishing completely. To me this is a good compromise to the two extremes we had before and solves several issues that some players had:
you get access to items that you'd love to have but since you have no luck they just wouldn't drop before
you get more ammo which is good for NCTH gameplay
severely damaged items are worth a lot less so (hopefully) no complaining about "too much money flying around" ;)
you get access to attachments that would have vanished together with the base item before
you have more reason to use NPCs or technicians that can repair items beyond the repair threshold
This requires a GameDir >= 2475 unless you want to replace the FALSE/TRUE by the proper number yourself in your game.
Just playtested the new drop-all and it works just fine, thanks. This way drop-all really is no longer as overpowered, cool.
I created a hostile civ-group and turned on civilians drop all. But since they are civilians they don't use the enemies drop all features at all, if I understand correctly.
I don't have the slightest clue how much work this is, so I appologize, if asking for something ridiculous, but is it possible to do the same thing for civilian drop-all?
Like I said, I like the new feature, so hopefully this doesn't sound unthankful. Just a thought how this might could be expanded, if possible at all.
In fortification-related news, two issues have been fixed in r7931:
[*] Sandbags could only be jumped if their height was < 2. But a structure with a .jsd-size of 1 barely offers protection, thus limiting the usefulness of sandbags. It was also no visual barrier, as pointed out here.
I've changed the code - now sandbags with a height of 2 can also be jumped over. This requires changed jsd files, which have been added to the stock GameDir in r2266.
The bug was introduced in r7931:
Changing max jumpable sandbag height to 2 allows mercs to jump over roof sandbags on some modified maps by pressing [j] when standing under the roof with sandbags.
Tested on Wildfire 6.07 maps with r8674.
Update: the problem seems to be fixed by checking for flat roof above gridno and lowering max height to 1 if roof found, this should allow compatibility with old maps.
-- Mild Drop All seems a good compromise option. SilverSurfer notes all the great reasons for this option. It provides a good time sink (for Repairing Technicians), some cost for Toolkits and Cleaning Kits, and does provide some good pluses also like finding some possibly hard-to-find attachments. A great brainstorm result from him. Is attractive to try on a harder custom difficulty now.
-- On Lower Vision While Running, the increasing Tunnel Vision for rapidly moving Mercs (or all actors possibly) suggested by Flugente to help address SevenFM's meaningful concerns sounds like a preferable approach. Supposedly some say that in real life this is what tends to happen with greater speed (such as in racing vehicles) as you focus more and more on the target or view ahead. The greater need for focus could cause this Tunnel Vision, and fits with similar explanations or terms for other tunnel vision in the game. Perhaps adjusted for experience and some skills, it might work fairly well, as an option.
Been trying many of the other added Absurdly Small Changes introduced in the last year and am enjoying them a good amount. Thanks for all those.
When one hires a merc from A.I.M/M.E.R.C, gear can be bought. However that gear then cannot be bought again during a later hiring process. This does seem somewhat odd, after all it's not in the posession of the merc in question, it's merely one set of gear fitting the merc. So as of r8704 & GameDir r2482, if the option in JA2_Options.ini is TRUE (default FALSE)
;------------------------------------------------------------------------------------------------------------------------------
; On the A.I.M/M.E.R.C websites, a merc's gear kits are always available during the hiring process, even if they've been bought
; before.
;------------------------------------------------------------------------------------------------------------------------------
GEARKITS_ALWAYS_AVAILABLE = FALSE
then gear kits can be bought every time you hire a merc, regardless of whether you already did so the last time you hired them.
Gary, still in transit, obviously with a gun from his gear kit equipped. Said kit is still shown on his webpage.
In case this optional, per-default-inactive optional inexplicably enrages you... there is no good reason to hire and fire a merc repeatedly in the first place. Second, 'exploiting' this requires hiring a merc for a day with gear, having them arrive in Arulco, firing them immediately, waiting until they return home, waiting until they agree to be hired again (there is a time period during which they will refuse to do so) and then repeating the process.
If you are that bad that you need to consider this 'exploit', you might as well simply cheat.
[Updated on: Fri, 01 November 2019 01:44]
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.
Because I'm somehow still adding new mercs from games and want to use as many sound files as possible, I've added the possibility of melee battlesounds for our mercs in r8708. As the names imply, the PUNCH files are played whenever the merc punches, the KNIFE sounds are used whenever they use a blade weapon. They go to the usual folder, BattleSNDS.
As I previously expanded the number of Battlesounds a merc can have to more than you'd ever need, this is your chance the dump the dozens of aggressive moans extracting a video game character inevitably yields.
[Updated on: Wed, 27 November 2019 23: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.
I'd like to go back for a moment to one mini-feature that is not really new any more at this point, and that is the ALLOW_TARGET_HEADANDLEG_IFPRONE one.
First, I've been using it 100% on since it came out, and absolutely love it. Primarily because it forced me to worry much more about friendly fire, positioning, lines of fire and all that, therefore making me much better in the process. Still, I've always had a feeling that it makes things kinda weird in NCTH, but I thought that it's probably not as extreme as it seemed to me, and learned to live with it.
Recently though, I was creeping through Omerta at night on WF maps with a group of relatively bunched up 6 mercs, when we got completely blindsided by a redshirt who flanked us by running on the roof (never saw them doing that, so didn't cover that side with one of night ops guys). He fired a short-ish 8 or 9 bullet burst at us and hit 5 of the mercs, all 5 headshots, at which point my head also exploded, while yelling bullshit And while that incident was certainly extremely unlucky, it made me finally try to test the fact that it always seemed to me that this feature really does make everyone run around with hugely oversized heads
So I've decided to make a small (by no means comprehensive) test of it. Two of the greatest military heroes of our times volunteered for it, so we've had Ivan and Biff cheat their way to Drassen, order some equipment needed for the test from Bobby Ray and then we had Biff lay down prone on the ground, while wearing some really buffed up armor. About 25 tiles away Ivan also plopped his ass to the ground (both prone, facing each other directly), and used his AEK-973 (we're certainly not going to use some dirty capitalist rifle, and AEKs are, I think, the only russian rifles with 3 round burst) to shoot Biff. We used 300 rounds, in 3 round bursts, to minimize any auto fire randomness from the test. Test was done 2 times, with ALLOW_TARGET_HEADANDLEG_IFPRONE being set to FALSE first, and then to TRUE.
So let's go to the results.
"Standard" set shows that Ivan hit Biff 62 times out of 300 tries, dealing a total of 239 damage through his beefed up armor. So that should be some kind of baseline result. Let's see the other one.
First, the test with ALLOW_TARGET_HEADANDLEG_IFPRONE set to TRUE shows some scuffed up stats. Ivan allegedly hit only 6 times. I assume that is due to the fact that I aimed all 300 shots at the torso, and probably only hit torso 6 times. Biff stats show that he has in fact been hit 94 times. So in 94 shots that hit him, only 6 were considered hits, meaning that they hit the torso. 88 shots were eaten by his stupid big head So his head takes up about 90% of hits. Also 94 hits compared to 62, so his gigantic head makes him take about 50% more hits, all together resulting in 586 damage taken, more than double compared to "baseline".
This kind of performance has couple of really bad consequences. One, it makes prone stance more dangerous, due to 90% of hits being caught by the head. That's not how things should work, you should probably want to go prone. Heads are catching more shit in all stances, I feel, but in prone, almost every hit taken from the front will be to the head. So it's almost prudent to never go prone. But the most annoying thing is that it makes "Mexican New Year" style of warfare way too good. I find that random, blind, unaimed, suppresive fire is hitting way too often (random shit getting caught by inflated heads, mostly).
So, maybe at some point this feature deserves a bit more tweaking. Or at least, I think that it should never go in the announced (but obviously not enforced, at least so far) direction of either going core or going away. Leaving it optional is probably ok, even in this state.
There should be probably some randomness added, like if merc is hit from the front side while prone, only 30% of the hits are considered head hits. Also not counting hits in this case is strange and looks like a bug.
The "counting hits" part is debatable. When I'm told to hit the target mark that is painted on a target dummy's torso and I hit him in the head instead, I could say that I scored a hit but the drill instructor probably wouldn't agree. ;) We accidentally hit "something" but not what we were aiming for so for the game it doesn't count as a hit.
I guess the problem with hits to the head is how a hit is processed when the target is prone. This happens in LOS.cpp function BulletHitMerc(). The function tries to figure the difference between the hit location and the target center (coordinate 0,0 in the JSD is the center tile). The current JSD files are not perfect for that. You see, when a target is crouched or standing he occupies only one tile and the head occupies only the center spot in a 5x5 matrix that represents the tile. This is just perfect but when the target is prone it depends on the body orientation where the "head pixel(s)" are. Take a look at "ANIMS\STRUCTDATA\M_PRONE.JSD" and you'll see what I mean.
Directions go from 0 (North) to 7 (Northwest) in clockwise direction. Looking at the JSD file it seems that:
0 North - has a torso with legs in one tile and a giant head that is spread across two tiles
1 Northeast - has a torso with legs in one tile and a giant head in another tile
2 East - just like North
3 Southeast - has a torso in one tile, legs in another tile, no head
4 South - has a torso in one tile, legs spread across two tiles, no head
5 Southwest - just like Southeast
6 West - has a torso in one tile, legs in another tile and a giant head
7 Northwest - just like Northeast
I wonder if you can even hit a prone character in the head who is facing Southeast, South or Southwest because the JSD has no "head tile" and the calculated hit location will probably always be closer to the torso tile center than that of the supposed head tile center.
Well the theory seems to check out, I repeated the test with guys being in north - south orientation, with Biff facing south, and there is practically no difference between the results with or without it activated, there was no headshots at all it seemed, everything went to chest/shoulder. So the tactical choice is obviously to always attack from the north, got it
@LatZee you may want to try prone JSD from NightOps mod, it was designed to remove restrictions to lie prone near obstacles, but maybe it will also work better for headshots, I don't know.
@LatZee you may want to try prone JSD from NightOps mod, it was designed to remove restrictions to lie prone near obstacles, but maybe it will also work better for headshots, I don't know.
Doesn't seem to help, tried it out in first test position instead of standard JSD, it's still headshot, headshot, headshot, so while I didn't run it all the way to 300 shots, it seems to be going in the same direction, seen nothing but headshots after 2 mags.
Doesn't matter, it's fine just knowing that I'm not insane, there is some kind of issue and while waiting for some of you smart people to maybe come up with a solution one day, I'll just keep using methods to deal with it that I was already using (such as removing bonus headshot damage to make more common headshots a bit less of a problem and so on)...
LatZee, if I find the time to update the JSDs, will you test them for me? I updated the broken grass structures in WF maps long time ago so maybe I manage to update the body structure as well. It should at least provide some balanced chances to be hit in different body parts for all directions. If that means that I will provide more restrictions to lie prone near obstacles I will do so.
I'll just say this much. I told you all that I don't play with this allow targeting body parts when prone option on. I had my reasons. Glad you all are catching up to my own experiences with it. With it on you either don't get hit or find a very lethal result. It also does seem to depend on what your target's angle is to the direction of fire.
Anyway I get tired of defending some things I say because ... reactions. Hope you can get it revised after testing further. I find it can be abused for good and ill, thus I turned it off. Just like I don't fire my gun to attract enemies to a kill zone to my advantage, just because some say it is an advanced tactic. If I want to scam the A.I., I can think of other better disguised ways. Something is patently wrong with the game when you turn this feature allowing to target body parts when prone on. Also no one ever proved to me that one ought to be able to target body parts when people are prone in HIGH grass, rocky terrain,or the like, especially when one can imagine that they use standard protocols of bobbing up and down, at most, to check for targets. Prone doesn't mean prone on clear ground, it means prone in all sorts of terrain, for usually a few APs worth of a full turn. Why should I be able to target a body part, when I first have to hit the head anyway to get to the torso and legs to make the shot to the legs anyway.
Sometimes we are presuming too much by simplifying so. Already someone delayed interrupts to happen only after so many APs are done within interrupter's vision, which probably was a good call. So now you get to target when someone was only prone for a few APs worth of a full turn -- I dunno. Seems a reach. I might as well remain crouched then.
Which was the point, you are actually SAFER CROUCHED than PRONE when you toggle this option ON. That's the point. You might get hit about the same, but you take a whole lot less damage, and a whole lot less headshots when crouched rather than prone. You do seem to get hit a lot more by what were supposedly missed shots. Go ahead and place a couple of prone friendlies right behind each other, and taste the frustration. Where, before this revision, the game was designed to benefit prone status, then it became a matter of range plus prone status, then it became a turkey shoot when prone. You "hit the dirt!" for a reason, and it isn't to be an easier target.
Anyway, I'm just saying, I liked the idea, and I turned it off after 3 camapaigns started with it finding it balderdash. You are better off in the early stages standing up than prone. Once the enemy has enough experience, crouched is better survival stance (which is pretty hilarious). When it feels that way when it never felt that way before, that's a major change -- glad you are taking a second look at it.
@ZedJA2
The problem isn't the feature itself. You would get exactly the same amount of hits before it. The only difference is that all hits were counted as hits to the torso before. The body part targeting feature merely shows how bad the JSDs are.
@LatZee
I modified all stance JSDs, because even the standing and crouched JSDs had some "errors". In my opinion the new ones should reflect better what you see on the screen. It is now even possible to shoot someone between the legs and miss. Also it's not easier anymore to shoot someone who is facing N,E,S or W compared to the other directions.
You can download the archive from SVN -> here. Just unzip it into your JA2 folder.
The result of the new JSDs might be, that it is more difficult to hit a target at specific parts with NCTH, as if that wasn't difficult enough as some say... The problem is that the game doesn't use different structures for different weapons.
Example - soldier standing relaxed: the arms are hanging down on the side so he has a slim silhouette when viewed from the side.
Example - soldier standing with rifle: the right elbow is extended behind the back and left arm is out to the front which gives him a bigger silhouette when viewed from the side.
I can't implement this in just one JSD so I decided to use the slim silhouette. If someone actually codes weapon type dependent JSD usage I could create the corresponding JSDs.
I had a bit of trouble with the crouched stance. A standing character is 3 height units tall. In the JSD a tile is 5 pixels wide. The standing body definition is:
level 3 = head (1 pixel)
level 2 = torso (3 pixels)
level 1 = legs (3 pixels)
When crouched we only have 2 height units:
level 2 = old: torso, head (3 pixels) / new: head only (1 pixel)
level 1 = legs, torso (3 pixels)
I'm not sure if it will get too hard to hit a crouched character because of the reduction of the level 2 width so I provided two versions for testing, the wide one (torso and head) and the narrow one (head only). Just copy the file you want to test to M_CROUCH.JSD. I'd prefer the wide one myself because otherwise the torso will be too small, compared to the rest of the body, but that means the JSD has no real head and it will probably be easier to score head shots. If tests show that the narrow one is fine, we can use this one.
PS: Fun fact - in the crouched SE direction the character had a giant penis sticking out in the original JSDs.
Ok, so I have started slowly with the test, for beggining the prone position, in 4 basic directions (will fully do diagonal directions if at the end it seems needed, if everything seems fine, I'll just give them a quick test), in all cases at 26 tiled distance, so it should be comaparable. So as we now know how the stats bug/feature works, we can (ab)use to it track head/torso/whatever shots. So, for every orientation, I've done the test 4 times:
1) old JSD, no TARGET... thingy, so the good old baseline one
2) new JSD, no TARGET... thingy, probably a useless test, but just wanted to make sure nothing weird happens with the new JSD
3) new JSD, TARGET... thingy set to TRUE, all shots aimed at torso
4) new JSD, TARGET... thingy set to TRUE, all shots aimed at head
So, let's see the results:
North
South
West
East
So, those thing that were problematic seem to be more or less gone. There are no more dramatic changes based on direction. Both torso or head aimed shots seem to have nice variety, with generally torso being hit significantly more often than the head, but head being hit sometimes(and some leg shots in the mix), so no more binary either all headshots or no headshots. There are no significant difference in number of hits with the TARGET... thingy on or off, and while the damage is consistantly higher, it is higher by reasonable amount considering that certain percentage of shots now hit the head and get the headshot bonus damage. So, working as intended.
One thing that kind of catches the eye is how the eastern orientation consistently shows the lowest amount of hits, not related to either new JSD or TARGET... thingy. It is probably either just a stupid statistic artifact due to relatively low sample or thinking back to it, it's possible that I laid Biff down in some grass so that might be the cause... anyway at this point I'm treating it as more of a curiosity to maybe be revisited than a genuine issue.
So generally, looks like a great job, at lest with prone position. When I catch a bit more time, I'll do the same thing, with Biff in crouched position (with both JSDs).
Personally, i love that feature. Whoever doesn't like it can turn it off, just as i turned off Disease in some mod cause it was too much. The point is that others may like things that some of us we don't like, in which case, the best solution is to have a toggle choice.
M_STAND.JSD wasn't changed much, except you can now shoot between the legs and N, E, S, W directions are not thicker anymore than the other directions.
As of r8820 & GameDir r2549, we can modify the basic AP cost for throwing grenades in Item_Settings.ini by altering SP10T_THROWGRENADE_MODIFIER. It works similar to the other modifiers next to it.
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.
If, for whatever reason, one decided to play with a resolution that exceeds that of the monitor, it was possible to cause the tactical screen to overwrite random pieces of memory, because somehow there was no check on whether we were accessing a huge array with negative indexes. I could have sworn we had that years ago, but it seems I was wrong.
In any case, fixed in r8822, so playing with resolutions too high is now possible again (still dumb though).
[Updated on: Thu, 18 June 2020 01:22]
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 my ever growing collection of useless code bits, behold the newest entry:
In a style similar to Borderlands, every single damage source results in their own damage display. One notices that when using weapons with fragments (buckhot, grenades) or automatic weapons fire that hits someone multiple times.
It also displays if we didn't cause any damage, which isn't that useless, maybe.
It's also possible to colour the display, the idea being that one can determine the damage sources from the colour of the floating number. Of course that's not as useful in Jagged Alliance as in Borderlands, because we barely have any immunities, and most often it's obvious what the source is, anyway.
On the other hand, RaInBoWs!
Unless there is a good reason to add parts of this to the trunk, I'll delete this again.
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.
Reminiscent of this, as of r8829 & GameDir r2554, NPCs - that is, all humanoids at least - can now have more battlesounds. You know, those little soundbits whenever they are hit/dying/curse/laugh.
You proably don't know this, but in vanilla there are several sets of these sounds, so that an enemy always grunts in the same voice. Which is a neat detail. If only Sirtech hadn't borked that up...
There are 6 sets (0-5) for men, 3 sets (6-8) for women. Except 4,5 and 6 were never used. Obviously I'm unlocking those, so... in a way we're getting fresh Sirtech content, 21 years after game release
Anyway, sets 9-11 are now also a thing and can be used for women. Though at the moment it's just the normal ones reused.
Anyway, the main point of this is that once the game is told to play a sound, it looks how many fitting numbered sounds it can find, and uses them randomly.
Observe the format. The filename is always "NPC type""Sound set"_"Sound name""ascending number"."mp3, ogg or wav".
NPC type is "bad" for normal humans, "kid" for kids (who apparently have no gender) and "zombie" for zombies.
Sound set is 0-5 for men, 6-11 for women, 0-1 for kids (who have no gender), 0 for zombies (who have a gender but don't care).
Sound names are the same as for mercs, "dying", "laugh", "hit" and "curse".
Numbers go from 1 to 4.294.967.295. I am somewhat optimistic this will be enough.
Due to legacy reasons, the very first sound can also be without a number. So both BAD6_CURSE.WAV and BAD6_CURSE1.WAV are legal.
Due to compatibility reasons, I changed all dying sounds to the sound name "dying" instead of "die", and renamed the zombie sounds which brings this in line with the mercs battlesounds.
Due to legal reasons, I'm not adding any new sounds, only existing Sirtech ones.
[Updated on: Mon, 29 June 2020 22:55]
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 more information, look into that thread. With stock settings of DiffcultySettings.xml the replenishing behaviour is unchanged.
There are few interesting bits in there. Depending on ini settings once can throw a wrench into the queen's logistics by disabling Alma. And it offers an interesting possibility to force the queen into conscripting unwilling recruits by force, which could be exploited to raise unrest... neat.
All other settings are the same, except that QueenPoolIncrementPerDifficultyLevel is now QueenPoolBaseIncrementSizePerDifficultyLevel, and is no longer multiplied per difficulty level. Which is somewhat oddly named, but all of them are. Anyway, that value (the increase to the pool once it's empty with the old method) is no longer multiplied by the difficulty, which was a unfortunate thing to begin with.
Anway, when you use the new exe, also use the new GameDir data. As you always should!
[Updated on: Mon, 29 June 2020 23: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.
If you have a slow PC, or are you using a debug exe, you might have come across an annoying issue:
While plotting a path for a squad in the strategic view, there is a noticeable lag. This can range from 'barely noticable' to 'it lags so hard it does barely register me aborting the plot, so it might be necessary to Alt+F4 the process'.
The reason for this behaviour is that the game constantly redraws the plotted path, and constantly recalculates the ETA.
ETA depends on travel speed.
Travel speed depends on encumbrance and stats, thus we constantly recalculate the selected squad's inventory weight. For this we loop over each item and all of it's attachments...
Well, no more of that. As our squad and their inventory cannot be changed while we plot the path, and we cannot advance the time either, we do the above evaluation only once from now (r8832) on. This stops the lag, even on a debug exe the plot is now lag-free.
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.
One has two possible solutions to solving the Doreen quest: convincing her to leave peacefully, or killing her. The first solution yields double the loyalty bonus in Drassen.
Sirtech's intention was that if you kill her after already having solved the quest, you lose the loyalty gain you got for the peaceful solution. But due to not taking into account twon sentiment properly, the bonus was never fully removed. As a solution the optimal approach was to first convince her of the error of her ways, and then to kill her. Which, frankly, shouldn't be a thing. The population shouldn't cheer you most when you convince someone to do something for you and then immediately stab you in the back.
Fixed in r8835.
[Updated on: Sat, 04 July 2020 02:23]
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.
) 1 Vote
Blog
Search
Help
Members
Register
Login
Home
And while that incident was certainly extremely unlucky, it made me finally try to test the fact that it always seemed to me that this feature really does make everyone run around with hugely oversized heads 
