Home » MODDING HQ 1.13 » Flugente's Magika Workshop » Absurdly small code changes  () 1 Vote
Re: Absurdly small code changes[message #356653 is a reply to message #356590] Mon, 11 February 2019 00:02 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
I've added a few new things this month. And the thing isn't even over.



  • r8658: If a gun has a magazine size < 5, the 'out of ammo' soundfile is only displayed with a chance of CHANCE_SAY_ANNOYING_PHRASE (JA2_Options.ini). This should make using guns with tiny magazine sizes less annoying.
  • 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.
  • r8660: A new additional dialogue event allows adding voice lines whenever zombies rise, as seen at the end of the video.
  • GameDir r2466: Molotov cocktails now have an added light effect. This was already present in most mods, not sure why it wasn't in stock.
  • r8662/GameDir r2467: A paramedic/doctor can fill a bloodbag from a willing, fully-healed, not-knowingly-diseased, non-drugged teammate. These can then be used to boost surgery - in stock the health regained is increased by another 15%. A full bag is used every time you decide to use this option. Which makes things easier for me and is how it is in life.
    Because you people would otherwise prey on the civilians like a tabloid preys on dick pics, this only works on your teammates. It also does not work on corpses. Blood donation people are serious about freshness. True fact: they don't appreciate it when you come to the donation station with a clean jam jar full of blood you already took, even if you made sure to wash it hot (with dish liquid and all!).
    Anyway, if the person donating the blood has diseases, this will be spread to the patient (though only for disease #0 for now due to coding reasons).
  • GameDir r2468: I don't know what the people who ages ago filled the starting gear kits where smoking, but given that quite a few doctors have no first aid kits/medkits to speak of... it wasn't that good. Though note that the previous addition of makeshift bandages also eases this problem a bit... Anyway, added first aid kits and empty blood bags to several kits.
  • r8664/GameDir r2470: Armour and its attachments can have a fire resistance value, which lowers (or increases!) fire damage received. For demonstration purposes I set it to 100% for full EOD armor, which allows Sara to play Targaryen. This won't work with stock values, where I added a 50% resistance to full EOD suits.

[Updated on: Mon, 11 February 2019 00: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.


Re: Absurdly small code changes[message #356715 is a reply to message #356653] Sat, 16 February 2019 01:10 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
Not entirely what I was aiming for this evening, but at least somewhat useful, as of r8666, stun effect explosions briefly remove gas effects from any tile they affect.

https://i.imgur.com/CIDDlln.png

As the smoke code is... not as accommodating as I had hoped, all smoke deleted will come back the next time it updates, which is every turn. A more 'realistic' smoke effect spreading would require more recoding of that part than I am currently motivated to do.

Still, this does allows us to, say, extinguish fire long enough for mercs to traverse the blast zone, possible to even drag someone else 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.


Re: Absurdly small code changes[message #356736 is a reply to message #356715] Sun, 17 February 2019 01:32 Go to previous messageGo to next message
Flugente

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

    https://i.imgur.com/c7uwpml.png




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.


Re: Absurdly small code changes[message #356750 is a reply to message #356736] Sun, 17 February 2019 21:53 Go to previous messageGo to next message
Flugente

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


Re: Absurdly small code changes[message #356758 is a reply to message #356750] Mon, 18 February 2019 17:55 Go to previous messageGo to next message
sevenfm

 
Messages:2317
Registered:December 2012
Location: Russian Federation
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.



7609+AI (r1695) | Unofficial modpack | Win8+ fix | Experimental project | Youtube | Trunk (r8908) | 1.13 Starter Docs

Кто в Москве не бывал, красоты не видал.


Re: Absurdly small code changes[message #356761 is a reply to message #356758] Mon, 18 February 2019 22:21 Go to previous messageGo to next message
Flugente

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


Re: Absurdly small code changes[message #356937 is a reply to message #356653] Sun, 10 March 2019 18:55 Go to previous messageGo to next message
sevenfm

 
Messages:2317
Registered:December 2012
Location: Russian Federation
Flugente wrote on Mon, 11 February 2019 03:02
[*] 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?



7609+AI (r1695) | Unofficial modpack | Win8+ fix | Experimental project | Youtube | Trunk (r8908) | 1.13 Starter Docs

Кто в Москве не бывал, красоты не видал.


Re: Absurdly small code changes[message #357220 is a reply to message #356937] Mon, 15 April 2019 07:46 Go to previous messageGo to next message
ZedJA2

 
Messages:205
Registered:January 2018
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.

[Updated on: Mon, 15 April 2019 08:35]

Re: Absurdly small code changes[message #357221 is a reply to message #357220] Mon, 15 April 2019 08:03 Go to previous messageGo to next message
ZedJA2

 
Messages:205
Registered:January 2018
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.

[Updated on: Mon, 15 April 2019 08:06]

Re: Absurdly small code changes[message #357230 is a reply to message #357220] Tue, 16 April 2019 01:46 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
ZedJA2 wrote on Mon, 15 April 2019 04:46
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.


Re: Absurdly small code changes[message #357231 is a reply to message #357221] Tue, 16 April 2019 01:50 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
ZedJA2 wrote on Mon, 15 April 2019 05:03
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.


Re: Absurdly small code changes[message #357237 is a reply to message #357231] Tue, 16 April 2019 07:08 Go to previous messageGo to next message
ZedJA2

 
Messages:205
Registered:January 2018
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.

[Updated on: Tue, 16 April 2019 07:27]

Re: Absurdly small code changes[message #357293 is a reply to message #357237] Mon, 22 April 2019 14:19 Go to previous messageGo to next message
silversurfer

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



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 #357341 is a reply to message #357293] Sun, 05 May 2019 18:41 Go to previous messageGo to next message
Kitty

 
Messages:225
Registered:October 2017
Location: Germany
@ silversurfer:

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.

thanks



I need more details. (Didi Hallervorden)

Latest JA2 v1.13 (SCI-maeyanie) Compiling Guide 7609 (eng) MapEditor+UB 8904
Re: Absurdly small code changes[message #357349 is a reply to message #341859] Mon, 06 May 2019 11:32 Go to previous messageGo to next message
sevenfm

 
Messages:2317
Registered:December 2012
Location: Russian Federation
Flugente wrote on Sat, 25 July 2015 02:46
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.

[Updated on: Mon, 06 May 2019 21:44]




7609+AI (r1695) | Unofficial modpack | Win8+ fix | Experimental project | Youtube | Trunk (r8908) | 1.13 Starter Docs

Кто в Москве не бывал, красоты не видал.


Re: Absurdly small code changes[message #358189 is a reply to message #357349] Thu, 03 October 2019 20:31 Go to previous messageGo to next message
ZedJA2

 
Messages:205
Registered:January 2018
-- 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.

[Updated on: Thu, 03 October 2019 20:33]

Re: Absurdly small code changes[message #358200 is a reply to message #358189] Sat, 05 October 2019 17:43 Go to previous messageGo to next message
GiantBasher

 
Messages:41
Registered:July 2017
Same sentiment - many thanks for these quality of life changes. Any more in the pipeline? We've missed you Flugente. Don't stay away too long!
Re: Absurdly small code changes[message #358411 is a reply to message #358200] Fri, 01 November 2019 01:39 Go to previous messageGo to next message
Flugente

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

https://i.imgur.com/9tsykQ9.png
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. greedy

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


Re: Absurdly small code changes[message #358569 is a reply to message #358411] Wed, 27 November 2019 23:45 Go to previous messageGo to next message
Flugente

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

https://i.imgur.com/yipP45f.png

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.


Re: Absurdly small code changes[message #358857 is a reply to message #358569] Fri, 24 January 2020 09:06 Go to previous messageGo to next message
LatZee

 
Messages:145
Registered:December 2015
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 cheeky 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 cheeky

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.

https://i.imgur.com/qDnruZZ.jpg

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

https://imgur.com/dAnHWMc.jpg

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 cheeky 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.
Re: Absurdly small code changes[message #358858 is a reply to message #358857] Fri, 24 January 2020 09:16 Go to previous messageGo to next message
sevenfm

 
Messages:2317
Registered:December 2012
Location: Russian Federation
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.



7609+AI (r1695) | Unofficial modpack | Win8+ fix | Experimental project | Youtube | Trunk (r8908) | 1.13 Starter Docs

Кто в Москве не бывал, красоты не видал.


Re: Absurdly small code changes[message #358861 is a reply to message #358858] Fri, 24 January 2020 14:21 Go to previous messageGo to next message
silversurfer

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



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 #358862 is a reply to message #358861] Fri, 24 January 2020 15:46 Go to previous messageGo to next message
LatZee

 
Messages:145
Registered:December 2015
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 cheeky
Re: Absurdly small code changes[message #358863 is a reply to message #358862] Fri, 24 January 2020 15:55 Go to previous messageGo to next message
silversurfer

 
Messages:2758
Registered:May 2009
Ok, so at least my analysis was correct. big grin
I guess we need updated JSDs that match better, if that is possible at all.



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 #358864 is a reply to message #358862] Fri, 24 January 2020 16:04 Go to previous messageGo to next message
sevenfm

 
Messages:2317
Registered:December 2012
Location: Russian Federation
@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.



7609+AI (r1695) | Unofficial modpack | Win8+ fix | Experimental project | Youtube | Trunk (r8908) | 1.13 Starter Docs

Кто в Москве не бывал, красоты не видал.


Re: Absurdly small code changes[message #358865 is a reply to message #358864] Fri, 24 January 2020 16:35 Go to previous messageGo to next message
LatZee

 
Messages:145
Registered:December 2015
sevenfm wrote on Fri, 24 January 2020 15:04
@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 cheeky 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)...
Re: Absurdly small code changes[message #358866 is a reply to message #358865] Fri, 24 January 2020 16:52 Go to previous messageGo to next message
silversurfer

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



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 #358867 is a reply to message #358866] Fri, 24 January 2020 18:20 Go to previous messageGo to next message
LatZee

 
Messages:145
Registered:December 2015
Sure, why not big grin
Re: Absurdly small code changes[message #358884 is a reply to message #358867] Sun, 26 January 2020 11:05 Go to previous messageGo to next message
ZedJA2

 
Messages:205
Registered:January 2018
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.

[Updated on: Sun, 26 January 2020 11:13]

Re: Absurdly small code changes[message #358887 is a reply to message #358884] Sun, 26 January 2020 15:08 Go to previous messageGo to next message
silversurfer

 
Messages:2758
Registered:May 2009
@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. big grin



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 #358888 is a reply to message #358887] Sun, 26 January 2020 17:20 Go to previous messageGo to next message
edmortimer

 
Messages:1352
Registered:January 2015
Location: Home Free
Nice work, Silversurfer!






Re: Absurdly small code changes[message #358892 is a reply to message #358888] Mon, 27 January 2020 16:39 Go to previous messageGo to next message
LatZee

 
Messages:145
Registered:December 2015
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
https://i.imgur.com/xNb1YcG.jpg

South
https://i.imgur.com/KCm75Pj.jpg

West
https://i.imgur.com/H6cu4iH.jpg

East
https://i.imgur.com/2Qw3p0d.jpg

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).
Re: Absurdly small code changes[message #358898 is a reply to message #358884] Thu, 30 January 2020 04:19 Go to previous messageGo to next message
Gopas

 
Messages:278
Registered:June 2016
Location: Norway
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.



Nipson anomimata mi monan opsin
Re: Absurdly small code changes[message #359074 is a reply to message #358898] Sat, 22 February 2020 19:13 Go to previous messageGo to next message
sevenfm

 
Messages:2317
Registered:December 2012
Location: Russian Federation
Looks like new M_STAND.JSD makes hitting enemy swimming in deep water impossible.



7609+AI (r1695) | Unofficial modpack | Win8+ fix | Experimental project | Youtube | Trunk (r8908) | 1.13 Starter Docs

Кто в Москве не бывал, красоты не видал.


Re: Absurdly small code changes[message #359075 is a reply to message #359074] Sun, 23 February 2020 00:55 Go to previous messageGo to next message
silversurfer

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



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 #360380 is a reply to message #359075] Tue, 16 June 2020 02:15 Go to previous messageGo to next message
Flugente

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

SP4T_TENTACLE_MODIFIER		= 1.0
; ------- THROWING KNIFES -------
SP4T_THROWKNIFE_MODIFIER	= 1.0
; ------- THROW GRENADES --------
SP10T_THROWGRENADE_MODIFIER     = 1.0



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.


Re: Absurdly small code changes[message #360400 is a reply to message #360380] Thu, 18 June 2020 01:22 Go to previous messageGo to next message
Flugente

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


Re: Absurdly small code changes[message #360407 is a reply to message #360400] Fri, 19 June 2020 00:25 Go to previous messageGo to next message
Flugente

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

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.


Re: Absurdly small code changes[message #360457 is a reply to message #360407] Fri, 26 June 2020 23:41 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
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 cool

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.

https://i.imgur.com/hmVFvwS.png

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.


Re: Absurdly small code changes[message #360475 is a reply to message #360457] Mon, 29 June 2020 23:00 Go to previous messageGo to previous message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
Thanks to sun_alf, the way queen replenishes it's forces is now a bit more interesting as of r8830 & GameDir r2555.

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.


Previous Topic: New feature: Administration assignment
Next Topic: New feature: enemy helicopters
Goto Forum:
  


Current Time: Fri Oct 23 02:12:04 EEST 2020

Total time taken to generate the page: 0.03174 seconds