Home » MODDING HQ 1.13 » v1.13 General Development Talk » HAM 3.6 Alpha - RELEASED
Re: HAM 3.6 Alpha - RELEASED[message #233186] Mon, 14 September 2009 13:21 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Quote:
If the job for a merc was blinking (like maybe just finished being patient) and you assign them to a facility, it keeps blinking.


Can you test whether the blinking continues for at least several hours? Also, is the character showing signs of actually benefiting from the facility work?

Quote:
Practicing at a facility gives no benefit to learning the skill.


Interesting. I'll have to check that out. However, this is probably a result of using percentages instead of flat bonuses. If the character was not going to get a lot of progress from practicing outside a facility, then using the facility may not help at all. That's a flaw in JA2's design.

Quote:
Before you make this go live you need to make a readme, add a help screen to the game, add info to your wiki, or do something to let players know what each facility task is meant to do.


I'm hoping to add some sort of tooltip at some point, although this may be very difficult to do automatically and may require modders to write their own tooltips for display. Until then, your only option is to examine the FacilityTypes.XML file to see what each facility does.

Quote:
far as I can tell the sam site job is just a great way to loose money and degrade your mercs, not much fun really.


Man a SAM Site to reduce Skyrider's flight costs by 100$ per manner. You'll need to spend at least an hour doing this before the cost reduction kicks in. Once the helicopter has completed its journey, you can remove your men from the facility.

Quote:
the health hits are evil


I'm aware of this. All of the facility risks are way too likely. You can adjust risk values yourself in FacilityTypes.XML, and eventually HAM will come with updated XMLs that reduce the risks to acceptable levels. Please note that you can also edit the JA2_Options.INI setting "FACILITY_EVENT_RARITY" upwards, to reduce the chance of this occuring. Of course, it also reduces the chance of GOOD events occuring.

Quote:
Also the readme for installing and running ham needs to be updated to include info for those who use the ini editor.


HAM comes packaged with a new INI Editor config file. Copy that into your main JA2 folder, and INI Editor will then show you all the details. You can also read instructions for INI settings on the HAM Wiki.

Quote:
Perhaps make each facility hurt a different trait


Some already do. Health loss is the most common one, and as you stated, it is simply too common. And as explained above, it is easily moddable.

Quote:
The penalty hits don't always get displayed via a popup


That's odd, they should always be displayed. Due to program limitations, however, only one pop-up can appear on screen at any time, so if during a single hour several characters are hurt, you'll only be notified about one of them. This is something I can't change, but the message log will show all penalties.

Quote:
one time i left a facility that paid me to work there and lost all the money I had been paid.


Interesting. You're saying that it was removed from your account? Was the money flowing in correctly before this occurred?

Quote:

After an "accident" the merc who was involved stays at the facility but no longer gets any benefits from doing so.


Hmmm... perhaps he/she has lost a required attribute from that accident. Please be more specific.

Quote:
The facilities make the game progress much slower because instead of fighting and winning my mercs are working fulltime jobs it seems. enrico is getting very mad at my lack of progress.


Facilities are meant to encourage recruiting more mercs to use them, and are also optional. So you should not halt your war progress to utilize them. Also, it is possible to turn off the constant loss of loyalty from Enrico's rants, I don't remember which setting does that though. It's in JA2_Options.INI.

Quote:
As I'm playing Smeagol's Wildfire mod (items+maps), I tweaked a few of the locations (particularly the ACA buildings) and introduced the port in Chitzena. Also added a weaker version of the Munitions Factory to both Cambria and Drassen (Wildfire includes an extra sector, C14, as part of Drassen), which has lower benefits than the Munitions factory, lower skill requirements, but has the same penalties.


There is a thread in the "1.13 XML Modding" forum for publishing facilities you've created. These will be of great use once I set up a HAM+WF data pack. Keep up the good work.

Quote:
I've reduced the chances of any permanent stat change to a third of what they were originally in the facility type xml file


Please let me know if you find these settings reasonable. I am very much interested in locating the correct balance for risk chances.

Quote:
would it be possible to have the chances of both positive and negative stat and skill effects to be adjusted by the same proportion as the appropriate SUBPOINTS_TO_IMPROVE


I would rather not interlink them, as that would only serve to confuse people editing the INI file. I believe that settings need to be as independent from one another as possible.

Quote:
Some of the facility stat/skill requirements strike me as being high - particularly the practice strength features of the airport and harbour, along with some of the wisdom requirements - 85, 90 strikes me as cutting out too many of the mercs from the assignments, and that 70, 75 would be a better high end limit for most assignments (barring those few assignments that really should require the best of the best, where maybe 2 or 3 mercs in total can undertake the assignment).


Unfortunately, there are too many mercs who start out with very good stats. I agree as I have previously that prerequisites are somewhat out of place, but until I make a better system for risk management, requirements are a good way to keep mercs from causing too much damage to others/themselves.

Quote:
Finally, one thing in the facility types xml file, Facility 17, the Lab, appears to have an error - TRAINER_EXPLOSIVES appears twice, with no STUDENT_EXPLOSIVES?


Thanks, that's what I get for copy-pasting.

Quote:
Like Dingle, I've had shipments disappear on me in Drassen - messing around tonight, managed to get 2 out of 3 shipments arrive after forcing an attack on the airfield, but tried it again with 2 attacks and all three shipments arrived.


That is probably unrelated to HAM. There have been some changes to the shipping code in the past few months, and some bugs are still hiding there.

Quote:
The mercs section of the laptop is reporting all sorts of weird assignments for each of them - apparently half my crew is dead


Noted. It probably has no effect on the game, just a cosmetic change I missed. I'll see to that.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #233239] Tue, 15 September 2009 05:50 Go to previous messageGo to next message
Hairysteed is currently offline Hairysteed

 
Messages:193
Registered:December 2007
Location: Finland
Headrock
Man a SAM Site to reduce Skyrider's flight costs by 100$ per manner. You'll need to spend at least an hour doing this before the cost reduction kicks in. Once the helicopter has completed its journey, you can remove your men from the facility.

Too much micromanagement!

Report message to a moderator

Staff Sergeant
Re: HAM 3.6 Alpha - RELEASED[message #233254] Tue, 15 September 2009 15:46 Go to previous messageGo to next message
Kaihuligan is currently offline Kaihuligan
Messages:4
Registered:September 2009
Location: New Zealand
Headrock,

I've had a bit more of a play around with the facilities and have some more comments and queries...

First up, Ambient effects - is the chance tested per merc or a flat chance of it triggering no matter how many mercs are in the sector (I'm assuming per merc, but there's that whole thing about assumptions:grin:)?

Quote:
Quote:
I've reduced the chances of any permanent stat change to a third of what they were originally in the facility type xml file


Please let me know if you find these settings reasonable. I am very much interested in locating the correct balance for risk chances.


I had a look at the spreadsheet you posted earlier in the thread, my grasp of stats and probability is pretty (read very) rusty nowadays, but I'm not sure you've looked at the probability right - pretty sure it's not linear (e.g. 6%/hour therefore 16 hrs max between occurrance) and that at best you can be x% confident that after y hours that it will have occurred at least once - so for the 6%/hour, you can be 75% confident that after 22 hours it will have triggered at least once, while 95% that after 48 hours it will have. I've a spreadsheet with the formulae that calculate this if you'd like to have a look.

Any chance of seeing the formulae that handle the base effect/range and risk reduction/gain maximisation? I'd like to try putting the full thing through some calcs as at the moment I'm working on pretty rough assumptions - if you take the 6%/95% above, and a merc that only gets 1 point/hour for practicing a stat (with the standard 50 to improve it), he is going to spend roughly an equal amount of time practicing the stat as to using the facility if he wants to sustain his stat (and that's with me making a horribly lazy assumption that he only ever loses 1 point during those 48 hours:grin:).

Quote:
There is a thread in the "1.13 XML Modding" forum for publishing facilities you've created. These will be of great use once I set up a HAM+WF data pack.


Have tried creating a couple of additional facilities, but is getting late here so will put the xml for them up on that thread tomorrow. One's a satillite recon facility (uses the reveal all enemy locations + enemy count outside of the towns) that got me to thinking; you've got stat and skill requirements, but how about traits or personalities? This facility would be ideal for a requires Electronics tag, at least to me.

Quote:
Quote:
would it be possible to have the chances of both positive and negative stat and skill effects to be adjusted by the same proportion as the appropriate SUBPOINTS_TO_IMPROVE


I would rather not interlink them, as that would only serve to confuse people editing the INI file. I believe that settings need to be as independent from one another as possible.


Fair enough, but is it a problem if it's one ini line with true/false that defaults to false, that tells the code to go look the subpoints ini lines when true? If you don't mess about with the subpoints lines it doesn't matter, if you do, then at least you have the choice of keeping the chances in line with the rate of gain. Failing that, split FACILITY_EVENT_RARITY into two? One for stats and skills, the other for the rest?

Cheers,

Kai.

Report message to a moderator

Civilian
Re: HAM 3.6 Alpha - RELEASED[message #233259] Tue, 15 September 2009 17:26 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Quote:
First up, Ambient effects - is the chance tested per merc or a flat chance of it triggering no matter how many mercs are in the sector (I'm assuming per merc, but there's that whole thing about assumptions)?


It's a chance per merc per hour. Every merc in the sector has a chance, and statistically speaking ALL mercs in the sector could be affected at once, or none, or some, you get my drift.

Quote:
I had a look at the spreadsheet you posted earlier in the thread, my grasp of stats and probability is pretty (read very) rusty nowadays, but I'm not sure you've looked at the probability right - pretty sure it's not linear (e.g. 6%/hour therefore 16 hrs max between occurrance) and that at best you can be x% confident that after y hours that it will have occurred at least once - so for the 6%/hour, you can be 75% confident that after 22 hours it will have triggered at least once, while 95% that after 48 hours it will have. I've a spreadsheet with the formulae that calculate this if you'd like to have a look.


Interesting. My grasp of statistics however says that if a 6-sided die is rolled 6 times, you have a 100% statistical chance of getting a 6 at least once... even if it's not guaranteed in reality. I built the chart on that premise. If you have a more mathematically accurate chart, feel free to post it.

Quote:
Any chance of seeing the formulae that handle the base effect/range and risk reduction/gain maximisation? I'd like to try putting the full thing through some calcs as at the moment I'm working on pretty rough assumptions - if you take the 6%/95% above, and a merc that only gets 1 point/hour for practicing a stat (with the standard 50 to improve it), he is going to spend roughly an equal amount of time practicing the stat as to using the facility if he wants to sustain his stat (and that's with me making a horribly lazy assumption that he only ever loses 1 point during those 48 hours).


I'm afraid I don't understand this question. Which formula exactly do you want to see?

Quote:
that got me to thinking; you've got stat and skill requirements, but how about traits or personalities?


Not yet available, but it is planned for future versions. However, I am more inclined to remove ability -requirements- and instead let modders decide which abilities/traits influence each individual risk. It may make the XML more complex, but allows modders to determine for themselves the stats required to get better risk results...

Quote:
Fair enough, but is it a problem if it's one ini line with true/false that defaults to false, that tells the code to go look the subpoints ini lines when true? If you don't mess about with the subpoints lines it doesn't matter, if you do, then at least you have the choice of keeping the chances in line with the rate of gain. Failing that, split FACILITY_EVENT_RARITY into two? One for stats and skills, the other for the rest?


INI settings are not generally meant as shortcuts to avoid XML work. I do have a few of these, but they are pretty major (like increasing/decreasing weapon B/5AP values). Adding another setting for what you're describing would be superfluous, when you can (rather) easily edit the facilitytypes.XML to accomodate your new subpoints requirements.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #233271] Tue, 15 September 2009 22:46 Go to previous messageGo to next message
BirdFlu is currently offline BirdFlu

 
Messages:438
Registered:September 2007
Location: Lampukistan
Headrock
Quote:
I had a look at the spreadsheet you posted earlier in the thread, my grasp of stats and probability is pretty (read very) rusty nowadays, but I'm not sure you've looked at the probability right - pretty sure it's not linear (e.g. 6%/hour therefore 16 hrs max between occurrance) and that at best you can be x% confident that after y hours that it will have occurred at least once - so for the 6%/hour, you can be 75% confident that after 22 hours it will have triggered at least once, while 95% that after 48 hours it will have. I've a spreadsheet with the formulae that calculate this if you'd like to have a look.


Interesting. My grasp of statistics however says that if a 6-sided die is rolled 6 times, you have a 100% statistical chance of getting a 6 at least once... even if it's not guaranteed in reality. I built the chart on that premise. If you have a more mathematically accurate chart, feel free to post it.


Well, the formula to compute the probability of an event to happen at least once in N times is this
Quote:
1 - (1-p)^n,

p : probability of an event [0,1]
n : number of tests [1,infinity)

So, an event with a base probability of 0.05 (5%) would occur at least once (or twice or 24 times) in 24 hours with a chance of (1 - (1-0.05)^24) = 0.708 (70.8%).

The formula to compute an event that occurs exactly once in N times is this
Quote:

n*p*(1-p)^(n-1)

The chance for an event with the base probability of 0.05 to occur exactly once in 24 hours is (24 * 0.05 * (1-0.05)^(24-1) ) = 0.369 (36.9%)

Here is a screenshot
http://img17.imageshack.us/img17/5228/probabilities.png

Report message to a moderator

Master Sergeant
Re: HAM 3.6 Alpha - RELEASED[message #233299] Wed, 16 September 2009 09:26 Go to previous messageGo to next message
hal900x is currently offline hal900x

 
Messages:64
Registered:August 2009
Cool. I like to think my questions contributed to some of the militia alterations =p

So, it's not possible IRL to store an EMPTY backpack inside a combat pack?

Report message to a moderator

Corporal
Re: HAM 3.6 Alpha - RELEASED[message #233301] Wed, 16 September 2009 09:53 Go to previous messageGo to next message
Starwalker is currently offline Starwalker

 
Messages:759
Registered:October 2005
Location: Hannover, Germany
Hal900x
So, it's not possible IRL to store an EMPTY backpack inside a combat pack?

I think it is IRL, and with NIV it is possible in 1.13 as well. But what does this have to do with HAM?

Report message to a moderator

First Sergeant

Re: HAM 3.6 Alpha - RELEASED[message #233316] Wed, 16 September 2009 15:15 Go to previous messageGo to next message
Kaihuligan is currently offline Kaihuligan
Messages:4
Registered:September 2009
Location: New Zealand
Quote:

Well, the formula to compute the probability of an event to happen at least once in N times is this

Quote:

1 - (1-p)^n,

p : probability of an event [0,1]
n : number of tests [1,infinity)


So, an event with a base probability of 0.05 (5%) would occur at least once (or twice or 24 times) in 24 hours with a chance of (1 - (1-0.05)^24) = 0.708 (70.8%).


What Birdflu posted was the formula that I was using - just rearranged it to calculate n instead, to see how many hours you'd expect a given proportion of playthroughs to trigger the event 1+ times - for the 5%/hour after 13.5 hours you'd expect 50% of them to have triggered it, while after 44.9 hours 90% would have - at this point 10% of the playthroughs are still lucky/unlucky enough to have not triggered the event at all.

Quote:

I'm afraid I don't understand this question. Which formula exactly do you want to see?


Sorry, obviously wasn't very clear as to the formula I was after (lack of caffeine and the late hour on my part I guess:grin:). The formula that I was after is the one (or more) that and tie into - particularly how the skills then adjust this value. Basically this bit from the HAM wiki -

Quote:

FacilityTypes.XML (HAM 3.6)

Using Skills to Reduce Risk and Maximize Gain

If the character has high skills, he/she may be able to minimize damage or maximize gain whenever the risk is triggered. Conversely, a character with low skills is more likely to suffer severe damage, or gain less benefits.

The skills you need are based on the risk involved. For the most part, wisdom and experience level will help here, but other skills can also come in handy.


I'm trying to get to a point where I can look a risk (say for health) and be able to say if someone uses the facility for 30 hours, then typically they will lose 2 point of health, and then compare that to the time needed to restore the lost health - then tweak the hourly % or and to get a desired ratio between the hours using the facility and hours taken to restore the damage. Unfortunately it's difficult to do within the game via a playthrough - particularly when young master Gasket manages to find every sharp object in the workshop on a very regular basis:crazy:. I swear he's the guy that would get hit by lightning, not twice, but three times.

Report message to a moderator

Civilian
Re: HAM 3.6 Alpha - RELEASED[message #233319] Wed, 16 September 2009 16:38 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Here's the formula you requested. Please note the following stipulations:

If bBaseEffect < 0 then
   ubMaxResult = (bBaseEffect + ubRange) or -1, whichever is LOWER.
   ubMinResult = bBaseEffect - ubRange

Else if bBaseEffect > 0 then
   ubMaxResult = bBaseEffect + ubRange,
   ubMinResult = (bBaseEffect - ubRange) or 1, whichever is HIGHER.

Else
   bMaxResult = bBaseEffect + ubRange,
   bMinResult = bBaseEffect - ubRange


These minimum and maximum values are absolute. The result cannot be outside these established values.

At this point the program calculates a "combined skills" value, which factors in various skills and other variables into a single number between 0 and 100. The specific factors vary depending on the risk you are running. There's a full list of these factors on the same Wiki page you were quoting from.

if Combined_Stats = 100, then
   Result = bMaxResult

Else if Combined_Stats = 0, then
   Result = bMinResult


In the above instances, we skip further calculations. Either our subject is perfect in all required skills, or has no skills. The 0 option is virtually impossible, as it cannot normally be achieved due to the importance of Experience Level for every risk type (and experience level can never be less than 1).

Combined_Stats is reduced by the value of the INI setting "FACILITY_DANGER_RATE".


The value of the INI setting is anywhere between 0 and 100. The higher the setting, the more our combined stats factor is reduced from its original value. If the danger is set to 0, the combined stats value is not changed at all.

If bBaseEffect > 0 then
   ubChance = ubChance + ((Combined_Stats * ubChance) / 100)

If bBaseEffect < 0 then
   ubChance = ubChance - ((Combined_Stats * ubChance) / 100)


Here you can see how the combined stats affect your chance to trigger the risk.

The idea here is that superior characters (Combined Stats > 0) can increase the chance of triggering a "beneficial" risk (positive base effect) and decrease the chance of triggering a "malevolent" risk (negative base effect). Conversely, characters with insufficient statistics (Combined Stats < 0) are more likely to trigger bad risks while less likely to trigger good risks.

Please note that if the "Danger Rate" constant is 0, then combined stats are always positive and will therefore always skew the ubchance in a "favourable" manner. If the danger rate is 100, then the ubchance is always skewed badly for the character. The default danger value is 50.

If the base effect was 0 ("can go either way"), the chance of triggering it is not affected.

RandomNum = A random number between 0 and the value of the INI setting "FACILITY_EVENT_RARITY"
If RandomNum > ubChance, then
   Risk fails to trigger


Self explanatory, I hope. Note that the default event rarity is 1000.

bBaseEffect = bBaseEffect + ((Combined_Stats * (ubRange+1)) /100)
bBaseEffect is then limited (min/max) to the bMaxResult and bMinResult variables we've determined earlier


This bit increases or decreases the base effect, again based on the combined stats variable. It can only push the base effect as far as it could go, within the established limits.

ubRange = ABSOLUTE of (Combined_Stats * (ubRange+1)) / 100


Here we also modify the range based on the Combined_Stats variable. In practice, the more your bBaseEffect has shifted from its original position, the less randomality there will be to the result. If bBaseEffect has shifted all the way to one of the possible result extremes, then there is no randomality to the result whatsoever - the character will receive that exterme result. If the base effect has not shifted from its original position, then the range of possible results is the largest possible, so the result may randomly be at either extreme, at dead center, or anywhere else within that range.

Random_Num = Anywhere between 0 and ((ubRange*2)+1)
Result = bBaseEffect + (Random_Num - ubRange)
Finally, make sure the result is still within the acceptable Min/Max.


The final result is randomized, although as explained above, if the base effect has moved from its original position, the range of possible results is proportionally smaller, making the result less randomal.

This may be easier to understand graphically, but I don't have the time to create a demonstration of this.

If you have any questions, feel free to ask.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #233328] Wed, 16 September 2009 21:20 Go to previous messageGo to next message
GreenKustom is currently offline GreenKustom

 
Messages:21
Registered:July 2009
Location: Hyvink
As not an expert with XML's and stuff I put this simply: Is it normal to get health loss on sectors for working even when your mercs are inactive? It seems that sometimes if you use a facility, the penalties may come later. It was a hell of a problem in Grumm as I counted that from my 21 mercs (17 inactive) lost total of 56 health points during a day. A pain in the ass really

Report message to a moderator

Private 1st Class
Re: HAM 3.6 Alpha - RELEASED[message #233333] Wed, 16 September 2009 23:19 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
@ GreenKustom:

In HAM, some sectors have a facility that can cause health deterioration to anyone around it. Think of strong pollution, like the kind you'd find at a factory (Sector H2). It affects anyone, even if they are inactive, so long as they are in the same sector. Oftentimes, working at that facility can be even more dangerous.

However, the problem right now is that there are unbalanced values in the XMLs, which generally means that the risk of health loss is being triggered way too often, causing unacceptable health loss. At the moment, your best bet to counter this issue is to lower the INI setting called "FACILITY_DANGER_RATE" to a very low value (even 0 is good). Your other option is to edit the XMLs, which as you said may not really be your specialty.

However you (and everyone else reading this) should note that HAM 3.6 is in Alpha testing. This means that you should be prepared to encounter issues like this. If you do not wish to take that risk, I suggest you download the much-more-stable HAM 3.5, which is available at the HAM Wiki under "Download and Installation". Just a reminder.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #233337] Wed, 16 September 2009 23:51 Go to previous messageGo to next message
Dummvogel is currently offline Dummvogel

 
Messages:5
Registered:February 2007
Location: Stade or Wolfenb

Permanent Stat losses should be removed permanently from HAM. I for one would never use this feature if that is involved.

Report message to a moderator

Private
Re: HAM 3.6 Alpha - RELEASED[message #233350] Thu, 17 September 2009 02:41 Go to previous messageGo to next message
czar1985 is currently offline czar1985

 
Messages:5
Registered:September 2009
@ Dummovogel and GreenKustom any facility feature is realy easy to delete from xml.
Special to you facilities with removed stat losses:
http://odsiebie.com/pokaz/5566079---53d2.html

Headrock I think that HAM 3.6 is great. Features which I like very much:
- Progress Bars
- Militia Upkeep Costs
- Separate Mobile Militia Assignment

Facilities needs to balance but they have greatest potential.
I read about your idea with smal village as bulding. This will make game more real.
An interesting development of this idea would be to reduce the income base of the mine.
Added biger % bonus to facility "mine" and delete negatives.
Good headminer (merc) will increase income and town loyalty. Poor headminner will decline to decline town loyalty over time and in conjunction income.

If start mine icome will be 60% of normal then mine facilty should give ~70% bonus to income.
0,6*1,7=1,02 this will simulate administration on conquered territories.


I think there is bug with A.C.A. I don't need to staff to see enemies in nearby sectors to militia and in wildness I see their number.

In the end my own facility which is placed in the A10 Smile

Quote:

21
Rebel Base
Base
6

REST
6
105
105

[Updated on: Thu, 17 September 2009 02:43] by Moderator

Report message to a moderator

Private
Re: HAM 3.6 Alpha - RELEASED[message #233358] Thu, 17 September 2009 09:46 Go to previous messageGo to next message
hal900x is currently offline hal900x

 
Messages:64
Registered:August 2009
Starwalker
Hal900x
So, it's not possible IRL to store an EMPTY backpack inside a combat pack?

I think it is IRL, and with NIV it is possible in 1.13 as well. But what does this have to do with HAM?


Headrock
# Backpack Exploit Fix

* Much to the chagrin of some people ;\) it is no longer possible to carry a backpack in your hands (or, for that matter, anywhere in your inventory) to avoid a movement cost penalty.

Report message to a moderator

Corporal
Re: HAM 3.6 Alpha - RELEASED[message #233360] Thu, 17 September 2009 10:49 Go to previous messageGo to next message
Starwalker is currently offline Starwalker

 
Messages:759
Registered:October 2005
Location: Hannover, Germany
The system we chose for NIV is like this: each LBE-Item has its own size, to facilitate its easy packing into other LBE-Items (for transport purposes). But LBE-Items do also have a 'filled size', meaning that they grow bigger when filled up, and thus should not fit into the places they fit before.
This system works gradual, so if there's five sizes (inclusive) between empty and full, then the item in question would grow about one size if filled to one quarter. It also takes into account the size of the items packed into the LBE-Item.
Backpacks, with their large number of slots (and versatility of slots) grow in size in comparatively smaller steps, and thus can fit into a combat pack even if filled somewhat, sometimes even if /full with smaller items/ (as the maximum filled size may not have been reached).

It's a limitation of the system, we can only circumvent it if we set the filled size to be considered already if there's a /single/ item inside the LBE-Item (all-or-nothing approach).

But disallowing a backpack from being carried in one's hands seems unrealistic to me.

And that an /empty/ backpack would fit into a combat pack was designed that way, to avoid the movement penalty when just /transporting/ the backpack.

Perhaps ChrisL needs to have a look at it again...

[Updated on: Thu, 17 September 2009 11:00] by Moderator

Report message to a moderator

First Sergeant

Re: HAM 3.6 Alpha - RELEASED[message #233370] Thu, 17 September 2009 12:38 Go to previous messageGo to next message
GreenKustom is currently offline GreenKustom

 
Messages:21
Registered:July 2009
Location: Hyvink
Thank you for the quick answer.
I played around with the INI files for a minute and found good value for the stat losses.

Also I know this is an Alpha (Beta's and Alpha's are always the most exciting) and we come to here for the stuff that needs to be fixed, so we can make the "Final release" perfect. Thanks again

Report message to a moderator

Private 1st Class
Re: HAM 3.6 Alpha - RELEASED[message #233374] Thu, 17 September 2009 13:18 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Quote:
But disallowing a backpack from being carried in one's hands seems unrealistic to me.


I didn't disallow carrying it in your hands, I simply made sure the movement penalty applies even when it is carried in the hands.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #233377] Thu, 17 September 2009 13:35 Go to previous messageGo to next message
Czert is currently offline Czert

 
Messages:105
Registered:August 2007
[quote=Headrock]
Quote:
the health hits are evil


I'm aware of this. All of the facility risks are way too likely. You can adjust risk values yourself in FacilityTypes.XML, and eventually HAM will come with updated XMLs that reduce the risks to acceptable levels. Please note that you can also edit the JA2_Options.INI setting "FACILITY_EVENT_RARITY" upwards, to reduce the chance of this occuring. Of course, it also reduces the chance of GOOD events occuring.

[/quote=Headrock]

Is here wy to split chances for good events and bad events ? Currently I only get bad, bad, bad event/chances but no good.

[Updated on: Thu, 17 September 2009 13:36] by Moderator

Report message to a moderator

Sergeant
Re: HAM 3.6 Alpha - RELEASED[message #233384] Thu, 17 September 2009 14:25 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Yes, edit FacilityTypes.XML.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #233390] Thu, 17 September 2009 15:38 Go to previous messageGo to next message
Starwalker is currently offline Starwalker

 
Messages:759
Registered:October 2005
Location: Hannover, Germany
Headrock
Quote:
But disallowing a backpack from being carried in one's hands seems unrealistic to me.


I didn't disallow carrying it in your hands, I simply made sure the movement penalty applies even when it is carried in the hands.

Aaah, I see, although Quote:
it is no longer possible to carry a backpack in your hands
sounds much like it is no longer possible at all.

Report message to a moderator

First Sergeant

Re: HAM 3.6 Alpha - RELEASED[message #233393] Thu, 17 September 2009 16:03 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Yeah because you've taken it out of context... But I guess I should rephrase it anyway.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #233449] Fri, 18 September 2009 02:07 Go to previous messageGo to next message
hal900x is currently offline hal900x

 
Messages:64
Registered:August 2009
All I'm saying is that an empty backpack, folded up and stored inside a combat pack, should not incur a movement penalty. I don't know if it actually will or not, since I'm not using 3.6 yet.

Report message to a moderator

Corporal
Re: HAM 3.6 Alpha - RELEASED[message #233450] Fri, 18 September 2009 02:31 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
I'm not entirely sure myself. However, if I understand what I did correctly, then it should only be looking for that backpack in major slots, and not within other LBEs. If my fix does cause movement penalties for empty backpacks stored inside other objects, then it should be revised.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #233456] Fri, 18 September 2009 07:05 Go to previous messageGo to next message
dinglehopper is currently offline dinglehopper

 
Messages:134
Registered:January 2008
The blinking job does not last long usually. The first event to happen always turns it non blinking, also adding a merc to any job that did not have a blinking task indicator will stop all mercs from blinking. It does however appear that the merc is getting no benefit/risk while the task is blinking.

The only getting one popup an hour is really bad, and i feal you will get many complaints about it when people start to notice they are missing stats they didn't know were lowered. My suggestions are to either group all the people who lost stats into one string and pop that message up so they can see everyone who lost in that hour. Or you could make it so people who loose stats go into a first in first out queue and then every hour the top name is picked from the queue checked to see if they are still in the situation that caused the loss, if so they are the lucky looser of the hour, if not the next name gets picked. That way you have only one person per hour and therfore need only one popup.

New bug, I have had probably 30 events happen, but all of them were negative. At some point around halfway I went and changed the ini modifier to 1 thinking that was close enough to 0 i should see some positive events. instead since then every event has been the "something really bad happened but fortunately it was not so bad" variety and the merk looses a couple of health (not permanently). Still no positives. I will say my mercs because I am testing and so starting over frequently with different setups have always been low level. So I am thinking perhaps level plays to much role. I even made a merc that was 95 in every stat and skill, and still at level 2 he got the bad but not so bad event with the ini set at 1. Either I am incredibly unlucky or something is wrong, or both.

Sorry if this seems like i am a foreigner and has lots of weird misspellings and lack of punctuation/capitalization. As was the case last time i am writing from a laptop with an unlit keyboard while lying in bed and trying not to wake the wife. A trick and a half.

DH

Report message to a moderator

Sergeant
Re: HAM 3.6 Alpha - RELEASED[message #233462] Fri, 18 September 2009 11:04 Go to previous messageGo to next message
Starwalker is currently offline Starwalker

 
Messages:759
Registered:October 2005
Location: Hannover, Germany
Headrock
Yeah because you've taken it out of context... But I guess I should rephrase it anyway.


Well,
Quote:
Much to the chagrin of some people it is no longer possible to carry a backpack in your hands (or, for that matter, anywhere in your inventory) to avoid a movement cost penalty.

does not make clear that you can still carry the backpack in your hands. I had cut out that part because it is the meaning the reader will most probably take from the sentence.
For you it was clear what your sentence meant...

What you meant was: The movement penalty will always apply, no matter where in the inventory the backpack is.
But that is not what your sentence is actually saying, the meaning is not clear.

Report message to a moderator

First Sergeant

Re: HAM 3.6 Alpha - RELEASED[message #233523] Sat, 19 September 2009 14:16 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
Hi there,

I'm really really impressed. Awesome work, Headrock.

I've begun a new game with HAM 3.6 alpha, so far I have encountered these bugs:

I staffed the A.C.A. Building in Drassen Airport at 11:00. Had to move everybody to counter an attack at Drassen Mine at 12.52. Now I can't staff the A.C.A. Building again (same error as described before by others in this thread). Only solution was to edit facilitiytypes.xml so staffing the a.c.a. doesn't cost money. But that's not really a solution...

Savegame Link : http://rapidshare.com/files/282154319/QuickSave.sav.html

It is not really a bug, but: Even though you stated otherwise, it is possible to get other colours for vests and pants - I did so after save-corrupting UniformColours.xml. The Army wore neongreen pants and deepblue vests. Punk Alert Smile

Have fun.

Report message to a moderator

Captain

Re: HAM 3.6 Alpha - RELEASED[message #233525] Sat, 19 September 2009 14:24 Go to previous messageGo to next message
Kaihuligan is currently offline Kaihuligan
Messages:4
Registered:September 2009
Location: New Zealand
Headrock, thanks for the details of the formula. A couple of questions though.

For the Combined Stats, I assume that's the 0-100 adjusted by the Facility Danger Rate in all the parts of the formula you listed with the exception of the very first check?

Quote:
Random_Num = Anywhere between 0 and ((ubRange*2)+1)
Result = bBaseEffect + (Random_Num - ubRange)
Finally, make sure the result is still within the acceptable Min/Max.

The final result is randomized, although as explained above, if the base effect has moved from its original position, the range of possible results is proportionally smaller, making the result less randomal.


If the result somehow ends up outside the original min/max, it is set to either be the min or max as appropriate, rather than the result generated again (and possibly again) until it falls inside the acceptable range?

Quote:
ubRange = ABSOLUTE of (Combined_Stats * (ubRange+1)) / 100

Here we also modify the range based on the Combined_Stats variable. In practice, the more your bBaseEffect has shifted from its original position, the less randomality there will be to the result. If bBaseEffect has shifted all the way to one of the possible result extremes, then there is no randomality to the result whatsoever - the character will receive that exterme result. If the base effect has not shifted from its original position, then the range of possible results is the largest possible, so the result may randomly be at either extreme, at dead center, or anywhere else within that range.

Either I'm misreading this formula, or it's not doing what you're describing. Aside from the outlying cases of 0 and 100 that you mention to start with, when Combined Stats is 0 you end up with the smallest possible range, with the highest range appearing at 100. The following would invert this so that you get the max range when Combined Stats is 0:

ubRange = (1-ABSOLUTE(Combined Stats))/100 * (ubRange+1)


This still has an issue in that with the standard Facility Danger Rate of 50 the range is only ever reduced to half the normal range, and you end up getting a big step from 1 down to 0 and from 99 up to 100 - as an example:

with uBaseEffect = -20, ubRange = 15, Facility Danger Rate = 50
-50 Combined Stats, Result = -35
-49 Combined Stats, Result Range = -35 to -19
49 Combined Stats, Result Range = -20 to -5
50 Combined Stats, Result = -5


Again, cheers. I've a better handle on how it works now, and now understand why poor old Gasket was taking a hiding in health:grin:.

Kai.

Report message to a moderator

Civilian
Re: HAM 3.6 Alpha - RELEASED[message #233550] Sun, 20 September 2009 06:57 Go to previous messageGo to next message
TheShodan

 
Messages:23
Registered:May 2007
Question for the future of the mod, how about attaching facility-like functions to vehicles, i.e. an RV or a commander vehicle? Basically just a mobile facility. I'm pretty sure there is a far easier way to do it which I'm thinking ing my head right now, but I can't really explain it. I guess copy the code that lets facilities exist, but instead of attaching it to a location attach it to an entity such as a vehicle.

Report message to a moderator

Private 1st Class
Re: HAM 3.6 Alpha - RELEASED[message #233727] Wed, 23 September 2009 16:40 Go to previous messageGo to next message
GreenKustom is currently offline GreenKustom

 
Messages:21
Registered:July 2009
Location: Hyvink
Also the Departures list needs some fixing. Barry faces everywhere o_0

Report message to a moderator

Private 1st Class
Re: HAM 3.6 Alpha - RELEASED[message #233949] Sun, 27 September 2009 14:34 Go to previous messageGo to next message
Sandro is currently offline Sandro

 
Messages:420
Registered:November 2008
Location: Mars
Headrock:
I would like to ask, if there is a chance to either obtain a source code of profex feature or make it to be included in original SVN branch? Or just HAM 3.6 SC?
I am making STOMP traits optional and this would really be valuable to me.

EDIT: Also I have a question, what means the letters before variables names? Like "b"AutofireBulletsPer5APModifier? I noticed you changed some of them in your HAM 3.5. I always wonder what those mean.

[Updated on: Mon, 28 September 2009 00:41] by Moderator

Report message to a moderator

Master Sergeant

Re: HAM 3.6 Alpha - RELEASED[message #234184] Fri, 02 October 2009 06:22 Go to previous messageGo to next message
LootFragg is currently offline LootFragg

 
Messages:349
Registered:August 2009
Location: Berlin, Germany
Okay. Uhm. Yah. Hi.

Feature requests, I suppose.

First of all, Headrock, you devil, you godfather of the HAM project in all its holiness: Unite with the Great Sandro to create t3h uberl33t m0d oi. But I won't further molest you with stuff like this if I can avoid it.

More importantly:

[Updated on: Fri, 02 October 2009 10:27] by Moderator

Report message to a moderator

Master Sergeant
Re: HAM 3.6 Alpha - RELEASED[message #234284] Sat, 03 October 2009 15:45 Go to previous messageGo to next message
elenhil is currently offline elenhil

 
Messages:64
Registered:June 2008
I've just thought of something that made me enjoy JA1 so thoroughly and what I missed it JA2. Perhaps it will strike your fancy and some day you might do something along that line.

I'm talking about sectors. Regular sectors, you know, not towns or mines or else. It was part of the original JA gameplay that you had to fight for every sector on the island. It was kinda fun. It is no longer so it JA2, and you will loose pretty much none of the fun if you travel the roads and take "inhabited" sectors only. There are some hidden weapon stashes out there in the wilderness, of course, but nothing enticing enough to visit all the sectors. Perhaps something could be done to induce the player to scout the wilderness gameplaywise?

Now, Hidden Enemy Strategic Movement introduced in 3.5 may actually turn to be a step towards that direction. Scout the wilderness or face unexpected guests. But there can surely be more that just that! Apart from necessity, there should also be prizes - and resistance to overcome - to induce the player to traverse the country.

Currently there is no reason for enemy patrols to defend a wilderness sector (and generally no reason for the player to seize it). Maybe we could come up with some reason for that? Stashing weapons in every sector is kinda dull. Making sector exploration one's main progress calculation factor is nothing of interest, too. What about a dynamic system of territory (or at least some wilderness sectors) control which would make a difference between going straight through the cities and mines towards the Palace to simply kill the Queen (made substantially more difficult because of that new factor) and really liberating the country?

Imagine first putting those farm sectors to use. I see glimpses of that in your Facilities features. Now, controlling those farms can be made to be of some value for your campaign. Like feeding the militia, for starters (given that you mercs seem to live on raw cash)! No farms - severe militia number caps. Now, see how those farms are no longer just sectors you may lose or regain without making any strategic difference! Imagine that there is a certain level of strategic value (like maximum number of militia you may support) that is reset when a sector is taken by enemies (and subsequently retaken) - like it was a punitive squad that has raided the farm damaging the equipment (or worse), and it will now take some time (and possibly money) for you to regain that level (kind of rebuilding the infrastructure). Lost farm = some of the militia disbanded (forced to start feeding themselves - and possibly rebuilding that very farm of theirs).

Now, with features like that enemies would have a reason to wrestle with you for the control of certain sectors besides cities and SAM sites. There will be necessity, strategic prizes and resistance to overcome to make it fun and worthwhile. I suppose it is not hard to imagine going beyond farms only. Up to a certain point where almost every sector outside the cities and SAM sites will become valuable for your cause and worth to take and defend, and the whole concept of frontlines and strategic perimeters appearing. We only have to come up with viable ideas what these new strategic bonuses/resources should look like (max militia levels, nearby cities' loyalty, what else?)

Imagine a strategic situation where you control a part of Arulco - which, of course, does not mean having a squad in each of the sectors - and then suddenly realize that an enemy quad had evaded your scout network (as your forces are obviously stretched thin), invaded your territory and is now wreaking chaos some couple of sectors deep inside your territory where you thought it was already safe. Your forces are elsewhere where you thought they were better needed, you must send a quick reaction force to deal with the breakthrough before your strategic resources are seriously undermined. The thrill! The strategic challenge! The new dimension of gameplay! One might almost say that this type of gameplay versus the old one is something like US in Iraq versus US-in-Iraq-as-they-thought-it-would-be. Now to overthrow the Queen you will have to do more than just take the cities and kill her.

What do you say to that? Let's start with the farms=militia cap first!

Report message to a moderator

Corporal
Re: HAM 3.6 Alpha - RELEASED[message #234286] Sat, 03 October 2009 17:46 Go to previous messageGo to next message
Requiem is currently offline Requiem

 
Messages:93
Registered:February 2007
elenhil
Imagine first putting those farm sectors to use. I see glimpses of that in your Facilities features. Now, controlling those farms can be made to be of some value for your campaign. Like feeding the militia, for starters (given that you mercs seem to live on raw cash)! No farms - severe militia number caps.
When I saw the HAM 3.6 ini setting 'Militia Upkeep Costs' I started thinking along similar lines. Could a second currency and bank balance be added to the game? That currency of course being food, generated by farms and/or other appropriate facilities. Then could the militia upkeep costs be applied to all characters (paid from the food balance not bank account), in addition to any regular fees? Then farms could work both ways, not enough food you can't muster such a large force. But capture farms/storehouses from enemy control, then the army starts having problems with desertion.

Money could also be converted into food by buying MRE's in bulk which you could then 'pay' into the food balance.

[Updated on: Sat, 03 October 2009 17:48] by Moderator

Report message to a moderator

Corporal 1st Class
Re: HAM 3.6 Alpha - RELEASED[message #234306] Sat, 03 October 2009 23:20 Go to previous messageGo to next message
LootFragg is currently offline LootFragg

 
Messages:349
Registered:August 2009
Location: Berlin, Germany
WOW! elenhill, you devil. Nice idea.

The idea of maintaining militia is a great idea. Right now, it costs money. Think of the idea of militia. You need guns and training, but apart from that, they're pretty much just citizens knowing how to defend themselves from Deidranna's retaliation. And how to fend off those oppression squads raiding them from time to time. That means, they don't work for money. The way it is now, you have an army, simple as that, they're just called militia. But you train them, pay them and they work for you. Militia forces usually don't really work for military purposes only. They harvest crops, repair roofs, clean clothing or play guitar, but from time to time they practice shooting and military stuff to be able to resist attacking forces trying to gain control over the land at least to a certain extent.

Basically, that's a whole new approach to it, so elenhill, good job.

Another principle that I really like is the sudden and unforeseen attack on any farmhouse / village / whatever that you have to fend off. It resembles X-Com and terror attacks on cities, where you were forced to react before the nations' loyalty towards your organisation faded away. It's not a quest, it's a task. This way, enemy forces could be spotted early without having primary forces (militia) around, but the population itself gives you hints on where they have seen soldiers, maybe based on their loyalty towards you. Combined with a territorial loyalty spread, you would most of the time not know when an enemy squad has moved into your visited area, but the closer they get to cities or areas of your influence in general, the more chance there is for you to know they're near.

New facility: Propaganda center. Call it newspaper press or candy distribution headquarters, but it'll increase your influence in visited sectors or keep it from falling quickly, because the populace knows you're still alive and you'll come around and help, eventually. Charismatic mercs with high leadership and probably Sandro's Squad Leader trait have a generally higher influence on its success, wisdom and experience also play a role.

T_Bolt, your idea is splendid as well. Any further currency shouldn't be displayed, I think, but still be essential. Imagine a message displayed when trying to stack more militia: "It's getting hard getting people to join the local militia. Try liberating some more sectors to convince the population." Something like that. This way, existing militia can be counted against ressources and loyalty available, because you don't leave your job to go to arms if you don't know someone else takes care of your stuff, whatever you do. So it shouldn't be defined via food production, but this should have a definite effect.
You could then also lower the importance of mines by changing the militia hiring system, so they're no longer paid soldiers, but civilians brought to arms, who basically need lots of training, are mainly fighting for their faith in their country being freed from Deidranna instead of your daily payments (I know the concept of upkeep costs also includes the maintenance of arms, but why should you pay them money they can't really spend?) and they could therefore lose their will to fight if you don't care for their families (ignore farm raids and violence against civilians for the sake of training your stats in that safe airport of yours) and disband partially, according to how much they still believe in your victory.

I wouldn't, however, weaken the army too severely by cutting off ressources. It's logical, yes, and it makes you want to gain control over the land first before attacking any larger city, so it makes the game quite interesting, but if you exaggerate this effect or make it realistic, you could lose some fun due to lack of fights. While it's of course the right way of mobilizing a country, showing the people how they can take care of themselves, without really needing to do all of the work on your own, this is an essential part of the gameplay and most of the players don't care for the Arulcans, they want to kill redshirts. Me, for example.

Anyway, the idea is brillant, that's what I think. It puts some focus on civilians, whom I use to ignore. In that context, more work could be dedicated to adding more villages, farms, lonely huts, especially when combined with the large maps project, so 4 houses is a small village instead of an important sector (like it is now). Additional NPCs who are not that important, could serve for loyalty and smaller quest purposes. This resembles Afghanistan, where we go from village to village to convince the elders we're the good guys. Oh my god, we're playing war here. In that context:elenhill
something like US in Iraq versus US-in-Iraq-as-they-thought-it-would-be
Hehe, yeah. "Let the bodies hit the floor."

The concept has lots of potential. It's a major change with a strong impact on gameplay. Needless to say, it should be optional and easy to adjust (IMPORTANCE_OF_CIVILIAN_LOYALTY = 80), but it could serve as the basis for warfare mods. Headrock! Feature request! ^^

elenhill
The thrill! The strategic challenge! The new dimension of gameplay!
Hahaha! Keep it low, it's just a nice idea. Let's convince the almighty Headrock of its value by slaughtering some lambs and reciting satanic formulas.

That Fragg of yours

Report message to a moderator

Master Sergeant
Re: HAM 3.6 Alpha - RELEASED[message #234312] Sun, 04 October 2009 01:07 Go to previous messageGo to next message
Requiem is currently offline Requiem

 
Messages:93
Registered:February 2007
I think there should be some sort of ledger for the food currency, at least there should be some information available on food production from each farm. Good logisticians should be aware of their supply lines. Each farm should run the risk of drought or disease as well, just like a mine can run out. There should also be a penalty if you go around punching cows, dairy production should go down.

Desertion doesn't have to weaken the army, in terms of having less opponents to kill, though it could affect patrol frequency. I was thinking more of capture a farm get a free squad of veteran militia next time you train militia. The veterans being army deserters who have changed sides.

Report message to a moderator

Corporal 1st Class
Re: HAM 3.6 Alpha - RELEASED[message #234325] Sun, 04 October 2009 03:47 Go to previous messageGo to next message
LootFragg is currently offline LootFragg

 
Messages:349
Registered:August 2009
Location: Berlin, Germany
Eeh... I think we should open a new thread and dedicate it to this topic. We've got different opinions here, since I think the player should not need to take much care about the economy and balance the income and output and... randomizing farm output is realistic, but it's a step further and interferes with the actual gameplay, since farming is a matter of months and I myself would not want to take care of nutrition, my mercs don't need it either (and that's good) and I'm in that country to kill a certain someone, after all. The concept points in a strategy game direction and it's a matter of taste and more mod content.

Desertion means free militia. Well, I wouldn't make them veterans, because these are the last to leave the army, they're best paid after all. Also, if you think of increasing militia caps by exercised control and militia being not money dependent, you get the same effect, it would only increase the numbers.

Anyway, let's not raid this thread, Headrock didn't even get to say a thing.

Fragglitou

[Updated on: Sun, 04 October 2009 04:09] by Moderator

Report message to a moderator

Master Sergeant
Re: HAM 3.6 Alpha - RELEASED[message #234326] Sun, 04 October 2009 04:02 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Don't worry, I read my threads. I think the idea has lots of merit, there's been some discussion in the past about very similar issues, such as having a limit on the number of civilians who can be drafted from each city, also based on loyalty, etcetera. I like the idea of having some way to limit the number of militia you can have, and farms are certainly a good instrument in making that happen. It's quite a project though - there's going to need to be lots of new interfaces for something like that - so I see it as a long-term goal. The discussion is still valid though, and you guys definitely have good ideas about it. I think it should be moved to its own thread, so it can evolve as an idea.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #234342] Sun, 04 October 2009 12:16 Go to previous messageGo to next message
LootFragg is currently offline LootFragg

 
Messages:349
Registered:August 2009
Location: Berlin, Germany
Headrock, Bug Report.

This time, Hans really means it. There's something very wrong with your suppression system and it turns Hans hostile, in the way of really hostile, but only temporarily. I'm playing on 3.6a.

I'm searching San Mona for the last remaining enemy. There obviously only is one left, because of the quick civilian turns. Madame Leyla was not treated as an enemy. That's cool, so your script works. Billy got served with a Deagle faceshot, he deserved it. Anyway, the game went into turn mode when I went down the street across Hans' video store entry. I first didn't notice it was him, I thought it was somewhere else, but I got closer to the problem when I heard a noise coming from his store. I had Wolf cover the entrance and that's when Hans went mad. He suppressed me. I then took my more important mercs aside and only left Wolf there, trying out and relying on what was once said about him only doing this once. He did it twice. Wolf now gets emergency care and I'll test out how many times Hans will repeat this behaviour. He's not treatet as an enemy, after all, only when he attacks me or spots me.

Ah, interesting bug. Hans didn't repeat this. I shot him with a salvo to the head. After some shots, the view changed to strategical, I was informed about a fight in A1, where I had no mercs in, unexplored. I accepted. Mickey flickered up in the upper left corner of the screen, obviously with the wrong pictures loaded to cover the eyes and mouth, a green "NOT DONE" text on his portrait, telling me something. The game then ended in a deadlock.

If you want to, I can send you a savegame, but I doubt it. You already know that bug, at least up to Hans firing at you. This might be something you would want to change, as civilians not firing at you randomly makes the game much easier, since you wouldn't have to exercise retaliation genocides in order to prevent anybody from ever shooting you in the back again.

...
A different thing, though. Why don't civilians in San Mona drop loot? Special NPCs do, they're scripted. I have drop_all enabled, militia as well. Fighting against someone with ~100 HPs, a spectra vest, kevlar helmet and pants and an assault rifle, against whom I could hardly even win and only had a chance by exploiting the suppression system and spamming him with bullets, closing in and keeping the trigger pressed until he finally died from boredom, because my bullets just tickled him, I would expect his equipment to be dropped like a regular enemy's equip. They don't drop anything. Named NPCs only.
Oh, by the way, don't tell me I shouldn't use the green or blue ammo on armored guys. I used the best of ball and AP ammo I could get at that time. Even 5.56mm AP did not really damage those brutes. It took me about 10-20 hits of ball ammo each to kill them. Hans, however, landed two hits on Wolf and nearly mangled him. So it might be that they're just better equipped, but then I want that gear, must be one helluva gear. Could you please have a look and at least tell me whether or not this / these issues can be solved without much effort?

Up until now, except maybe for the stuff mentioned in the earlier post, the game went fine.

Report message to a moderator

Master Sergeant
Re: HAM 3.6 Alpha - RELEASED[message #234348] Sun, 04 October 2009 12:59 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
There's something wrong with the way the factions react to you after you attack kingpin or get Maria. I don't believe it had anything to do with the suppression system or HAM, I seem to recall this happening long before HAM was created. The annoying part is that this bug can probably be found through testing, but would require fighting kingpin's men over and over again...

The weird thing is what you describe happened with Mickey, I've never heard about that.

What savegames do you have?

Quote:
A different thing, though. Why don't civilians in San Mona drop loot?


Item drops are calculated when a character is created. For NPCs, the exact item drops are decided in PROF.DAT, for enemies it is randomal. 1.13's Drop_All and drop customization were created to affect enemies, and HAM added this to militia. I'm afraid that adding it to unnamed hostile civilians is much more difficult than either of these. Perhaps one day it will be possible. I'd like to see that happen, for sure.

Report message to a moderator

Sergeant Major

Re: HAM 3.6 Alpha - RELEASED[message #234349] Sun, 04 October 2009 13:08 Go to previous messageGo to previous message
Logisteric

 
Messages:3199
Registered:December 2008
Location: B
that mickey thing is an old one - it happened very often with some of spave-viking's exes it sometimes says creptus-attack - a1, centSAM and estoni (just once) - mostly a1, though

as for hans - the only explanation is a stray bullet that hit him

civillians/nonames do not drop stuff, but you may steel their gear - you'll swim in spectra-vests and commandos

Report message to a moderator

Captain
Previous Topic: 100AP Project - open Beta
Next Topic: A* pathing, only for non-NPCs?
Goto Forum:
  


Current Time: Fri Mar 29 07:00:00 GMT+2 2024

Total time taken to generate the page: 0.02682 seconds