Home » MODDING HQ 1.13 » v1.13 General Development Talk » HAM 3.6 Alpha - RELEASED
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #238536]
|
Mon, 23 November 2009 18:23  
|
|
 duckbillclinton |
 |
Messages:9
Registered:March 2008
Location: USA |
|
|
@Headrock,
I had similar issues like others with NPC refuse to move, and I was only able to solve those by blowing holes on wall or xml hack Gen IV NV goggles to thermal optics so I could see through walls to talk to Hans. Recruiting Hamous caused nasty CTD with confirmation of sending error report to MS. Hope you have time to look into these. Thanks, DBC
[Updated on: Mon, 23 November 2009 18:26] by Moderator Report message to a moderator
|
Private
|
|
|
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #238971]
|
Sun, 29 November 2009 14:46
|
|
| duckbillclinton |
|
Messages:9
Registered:March 2008
Location: USA |
|
|
DBC@Headrock,
I had similar issues like others with NPC refuse to move, and I was only able to solve those by blowing holes on wall or xml hack Gen IV NV goggles to thermal optics so I could see through walls to talk to Hans. Recruiting Hamous caused nasty CTD with confirmation of sending error report to MS. Hope you have time to look into these. Thanks, DBC
@Headrock again,
I found the cause of recruiting Hamous CTD, it has something to do with DBB mod. After fixing the XMLs, this issue went away. Not sure if now days people still want my DBB XML fix or not... :placard:
Also one very interesting thing I found, before the fix Hans and other NPCs will step aside properly the first time I talk to them, but re-visit will cause stuck up. After my fix, however, is that the NPCs like Hans will immediately refuse to move. So I wonder if DBB mod has some broken data causing this... Can anyone test it out without installing DBB mod?
:professor:
DBC
Report message to a moderator
|
Private
|
|
|
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #238989]
|
Sun, 29 November 2009 19:38
|
|
| Headrock |
 |
Messages:1757
Registered:March 2006
Location: Jerusalem |
|
|
Quote:I am near 100% sure the default SVN 1.13 does not have NPC stuck issue this easily. Up till 1.5 weeks ago, I have been only playing 1.13 + DBB for 2-3 hours during weekends and never had this issue.
Hmmmm. My problem is that I can't figure out what might be causing the error. Thanks though.
Quote:BTW, any chance the strength to weight ratio can take 0.01 as parameter? I am such a pack rat with DBB...
At the moment, IIRC, the minimum value is 0.1. A merc with 50 STR would therefore be able to carry 500 KG, which is a LOT.
A value of 0.01 would mean that 50 strength can carry 5000 KG... Do you really need that much weight capacity?
Quote:For a wild guess, I think the root cause might be related to merc related XMLs, as fixing DBB's data can make Hans behave differently. There might be some memory leakage related to merc data.
Well, I would imagine that most players don't use PROFEX, which is the only system that has anything to do with the profiles. Perhaps there is some data overflow somewhere, but omg I can't even begin to imagine where it might be. The worst thing is that I can't track the error properly. I guess this may be beyond me.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239134]
|
Wed, 02 December 2009 02:36
|
|
| Headrock |
|
Messages:1757
Registered:March 2006
Location: Jerusalem |
|
|
UPDATE (yeah, I bet you haven't heard that one in a while)
Actually it's just an update for HAM 3.5. I was sure that I'd added the INI Editor configuration XMLs to the download a long time ago, and only now thanks to Sincleanser I realized my mistake. This has baffled people for a long time now, especially since I kept claiming that everything should be in the ZIP file. Apparently that was a mistake on my part and I apologize.
Anyhow, the zip now contains INIEditorJA2Options.XML and INIEditorAPBPConstants.XML which should allow the editor to set ALL HAM 3.5 settings properly. In fact, with these XMLs it should be easier to set up HAM 3.5 without having to mess with the INI files, as it can generate the required files itself. Of course, that means you have to set everything manually in the editor before playing, and its default values are set to JA2 Default, not HAM default, so keep that in mind.
If you intend to use these XMLs, on your first run of the INI editor please make sure to check the values of the following settings:
JA2 Options INI (HAM Settings section)
LEADERSHIP_AFFECTS_MOBILE_MILITIA_QUALITY
EXPLOSIVE_SUPPRESSION_EFFECTIVENESS
GOGGLE_SWAP_AFFECTS_ALL_MERCS_IN_SECTOR
HELICOPTER_BASE_COST_PER_GREEN_TILE
HELICOPTER_BASE_COST_PER_RED_TILE
DEFAULT_ARRIVAL_SECTOR_X
DEFAULT_ARRIVAL_SECTOR_Y
RANGE_EFFECT_ON_MAX_TRACER_CTH_BONUS
APBP Constants INI
AP_SUPPRESSION_SHOCK_DIVISOR
Again, the editor sets these to JA2 defaults on its first run, unless you already manually added the proper lines in your INI files. So just make sure.
For more information about the various HAM settings, hop over to http://ja2v113ham.wikia.com.
Sorry for the inconvenience.
Oh and please let me know how it goes.
Report message to a moderator
|
|
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239299]
|
Fri, 04 December 2009 09:12
|
|
| colorfuldays |
|
Messages:5
Registered:December 2009 |
|
|
Hello!
First of all, I want to thank you and all the other modders for putting this much effort into making such a great game even better!
On HAM 3.6a: There is one problem regarding dynamic mobile militia that I stumbled across while playing with HAM_3.6a.
The first time I noticed this was while using WildFire maps.
So just to make sure the problem persists with standard maps, I reinstalled Ja2 Gold, the latest SCI (JA2 1.13 3287 exe SVN@1203 Full.exe) and HAM_3.6a with the exact same configuration as it is found in the archive.
The actual problem: With the exception of the area around Omerta, Drassen and upper Alma, all trained mobiles are frozen in place and don't roam at all. Following mercs works perfectly fine, however.
If a trained stack spawns around any other city than Drassen or upper Alma, they are stuck on their spawnpoint at the outskirts of that city, adding nothing but a strong (albeit expensive) extra layer of defense.
I tried editing the DynamicRestrictions.XML, setting the requirement for each sector to city 2 (Drassen). But still, they didn't advance beyond the areas mentioned above.
Here is a screenshot of the sectors they are able to roam through: http://img252.imageshack.us/img252/472/mobilesaccessiblesector.jpg
The Drassen Sam was accessible to the mobiles as soon as I captured it, too.
Staffing the A.C.A. building in Drassen also showed the same restrictions as seen in the screenshot ().
All this happened using the following settings:
RESTRICT_ROAMING = TRUE
ALLOW_DYNAMIC_RESTRICTED_ROAMING = TRUE
ALLOW_RESTRICTED_MILITIA_THROUGH_VISITED_SECTORS = FALSE
After opening the save with the HAM_3.5.exe, the dynamic mobiles started roaming just fine. Saving, and again starting with HAM_3.6a.exe resulted in them freezing in place precisely the way they did before.
---
I also tried setting it to:
RESTRICT_ROAMING = TRUE
ALLOW_DYNAMIC_RESTRICTED_ROAMING = FALSE
ALLOW_RESTRICTED_MILITIA_THROUGH_VISITED_SECTORS = FALSE
This resulted in them never roaming at all. Not even around the Drassen area. They were still following mercs, though.
and:
RESTRICT_ROAMING = FALSE
ALLOW_DYNAMIC_RESTRICTED_ROAMING = FALSE
ALLOW_RESTRICTED_MILITIA_THROUGH_VISITED_SECTORS = FALSE
This worked just fine. They roamed all over the place! Straight towards the other end of the map. ;]
I am really curious whether I screwed something up on the installation process...or if maybe I am the only person playing with mobiles enabled..hehe
cheers
Report message to a moderator
|
Private
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239326]
|
Fri, 04 December 2009 17:08
|
|
| Loucipher |
 |
Messages:157
Registered:October 2009 |
|
|
In order for the militia to roam properly, one of the two latter settings must also be set to true.
Basically:
- if you set RESTRICT_ROAMING to FALSE, the militia will run rampant all around Arulco (their roaming is not restricted). The game ignores the two latter settings.
- if you set RESTRICT_ROAMING to TRUE, the game looks which one of the latter settings is also TRUE, and will use the one that's enabled. If both of them are FALSE, though, the game cannot read the restrictions from the files, and assumes all sectors are restricted - this results in no roaming at all.
Headrock, please correct me if I'm wrong, but that's how I understand these settings.
Report message to a moderator
|
Staff Sergeant
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239328]
|
Fri, 04 December 2009 17:46
|
|
| Headrock |
|
Messages:1757
Registered:March 2006
Location: Jerusalem |
|
|
That's correct. However I'm having trouble understanding what the problem really is.
On the one hand, the restrictions you (colorfuldays) were using initially should not allow militia to roam near Alma at all. In fact, since you only have Drassen under control, the militia should roam to Omerta, the SAM site, and no southwards than sector F12. That's the idea behind the HAM restrictions - the militia move to defend the roads and nearby strategically-important areas that aren't within reach of enemy cities. To allow roaming around Alma, you would need to conquer Alma.
So in fact, you have MORE militia roaming than should be allowed. On a wild guess I'd say one of the two things below happened:
A) You set ALLOW_RESTRICTED_MILITIA_THROUGH_VISITED_SECTORS = TRUE at some point while testing, and the militia roamed into those Alma outskirts sectors.
B) You led those militia there and they somehow failed to return to the Drassen area.
Or maybe another option that is more complicated. It would help if you could describe how the militia are moving in the Alma outskirts sectors.
However, the real conundrum is why did things not change when you edited DynamicRestrictions.XML. By setting all requirements to "2", all sectors in the list should've been enabled for roaming as long as you control the city of Drassen. Could you post your current XML?
Report message to a moderator
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239342]
|
Fri, 04 December 2009 21:27
|
|
| colorfuldays |
|
Messages:5
Registered:December 2009 |
|
|
Hamrock A) You set ALLOW_RESTRICTED_MILITIA_THROUGH_VISITED_SECTORS = TRUE at some point while testing, and the militia roamed into those Alma outskirts sectors.
B) You led those militia there and they somehow failed to return to the Drassen area.
Neither of this is true. I only visited the sectors so they would stand out a little bit more on the screenshot. But in the end it was probably a bad idea to do that. My bad, sorry.. 
Quote:On the one hand, the restrictions you (colorfuldays) were using initially should not allow militia to roam near Alma at all.
They don't. The screenshot was taken after! I set the requirement for every sector to city 2. Sorry for the confusion.
But even after setting every requirement to city 2, they never roam any farther than the sectors they are currently occupying on the screenshot.
Here is the XML I used: http://www.speedyshare.com/files/19620480/DynamicRestrictions.xml
---
This happens at Chitzena when using the orgininal DynamicRestrictions.XML found in the archive:
http://img46.imageshack.us/img46/9554/mobilesstuckchitzena.jpg
Clearly, C3 should be visitable by the mobiles, as C3 + 12 would suggest.
However, they never leave the sector they spawn in at all. This happens for every city except the Omerta, Drassen and upper Alma area.
cheers
[Updated on: Fri, 04 December 2009 21:38] by Moderator Report message to a moderator
|
Private
|
|
|
|
|
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239352]
|
Fri, 04 December 2009 23:48
|
|
| KEN C |
 |
Messages:244
Registered:May 2007
Location: Aberdeen Washington USA |
|
|
Headrock, now that you have Ham3.6 out is there any way you would consider removing the Ham from SVN 1.13 and releasing it as a stand alone mod?
Report message to a moderator
|
Sergeant 1st Class
|
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239363]
|
Sat, 05 December 2009 04:44
|
|
| KEN C |
|
Messages:244
Registered:May 2007
Location: Aberdeen Washington USA |
|
|
?? yourself.
my question is would you consider removing the ham you have installed into SVN1.13 last spring?
Report message to a moderator
|
Sergeant 1st Class
|
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239377]
|
Sat, 05 December 2009 09:20
|
|
| colorfuldays |
|
Messages:5
Registered:December 2009 |
|
|
Hello!
on the first page of this thread, I read about a bug regarding the payment of "outstanding debts" after using a facility.
Choosing "Yes" resulted in nothing, while choosing "No" would result in a CTD.
If you were already able to recreate this bug, then feel free to ignore this post
On the first page, it was assumed the result of sudden combat interaction.
I tried to recreate it this way for some time, too. But like you, I was not able to do so and everything worked just fine.
Anyway, I messed around a little bit and this is what I noticed/did:
From what I can gather, the facility costs add up each hour. And as soon as the accumulated facilitycosts for the day surpass the current balance, the bugged pop-up starts to appear.
At what time of the day this happens is irrelevant.
If this happens, further assignment to any facility is no longer possible. The currently assigned mercs, however, stay assigned until midnight.
The popup persists even if you raise your current balance above the accumulated facilitycosts...there is no way to fix this until midnight.
This is probably what happened on page one. The accumulated costs surpassed the current balance and after the battle, further assignment was not possible until the next day.
At midnight it's time to pay the costs. If you were able to raise your current balance higher than the accumulated costs, you are fine and should be able to reassign your mercs to the facility.
If you were not, the locals are "not pleased". The only way to fix this is to get enough funds and wait until next midnight. The debts are then automatically subtracted from your current balance.
Now the pop-up disappears and everything works fine.
Maybe the pop-up isn't working because it's set to get substracted at the end of the day...but that's a wild guess, really..
A very easy fix is probably to simply substract the facilitycosts from the current balance on an hourly basis.
I have no idea if that's an easy thing to implement, though
It is very easy to test all this by adding a beach resort to A10 (Omerta) and putting some mercs to rest in the resort.
I hope this was helpful and comprehendible this time  .
cheers
[Updated on: Sat, 05 December 2009 09:30] by Moderator Report message to a moderator
|
Private
|
|
|
|
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239500]
|
Mon, 07 December 2009 01:14
|
|
| colorfuldays |
|
Messages:5
Registered:December 2009 |
|
|
Hey Headrock,
sorry, I have to correct my last posting about the bugged pop-up.
I thought it would only appear if the accumulated costs surpass the current balance.
But that's not true at all. I guess my balance was just really low. And after I got caught up into this little trap, everything seemed to make soo much sense. Sorry!
Anyway! The pop-up is much easier to recreate...
I tested this 5 times and it worked every single one of them. I tried this by adding either a shooting range or a beach resort to A10 (Omerta).
Here is what I did:
1] I added a beach resort to A10.
2] I hired any amount of mercs. I tried 3 and 1. For this try, I used Bull.
3] Without any fighting, I went straight out of A9 to A10.
4] Now, at 7:05AM, I assigned any amount of mercs to the facility. How many I assigned made no difference. I assigned Bull.. (Current Balance: 30,384$ vs. Daily Expenses: 1,800$)
5] After simulating until 8:00AM the bugged pop-up started to appear, no matter what. Assigning before 8:00AM was still possible, though. Which makes sense..
After I paid the expenses at midnight, everything was back to normal. New assignment was again possible.
This is from another try. Might be of interest, too:
At 7:55AM, I assigned Bull back to Squad-1 and immediately reassigned him to rest in the beach resort again.
I did this every hour (8:55AM, 9:56AM, 10:57AM) until 11:55AM. And despite Bull being assigned for over an hour multiple times, I didn't have to pay any expenses and the pop-up didn't show up.
The problem: At 9:00AM I still had to suffer a loyalty loss through the region because of Bulls actions at the beach resort.  This doesn't seem very fair.
Looks to me like there isn't a bug about when or how the pop-up appears. It appears if the facility was "used" for at least an hour and the problem simply lies in the pop-up itself... <_<
---
That aside, I only noticed three other minor things:
1] After filling both Chitzena sectors with green militia, I assigned MERC1 to train regular militia. It was then possible to assign MERC2 to train mobiles without the payment pop-up showing up. I was able to train a stack mobiles for free.
Trying to assign MERC2 to train regulars with MERC1 now results in a pop-up asking me for payment of a further 750$. Whether I do this directly from Mobile Militia > Militia or over Squad-1 > Militia doesn't make any difference.
Apparently this bug does not occur if I save & load the game after filling the city with regular militia! After loading, I have to pay for both the regulars & mobiles.
2] A similar thing happens when I am broke. I tell MERC1 to train mobiles. Then the pop-up shows up, telling me that I have insufficient funds to train mobiles.
But instead of being reassigned to a squad, the mobile training starts anyway.
This does not happen with the training of regular militia.
---
The only other bug I found has already been mentioned in this thread. All militias go AWOL despite me having some funds available.
With all that out of the way, I must say I absolutely love the idea behind militia upkeep. Now, it's no longer possible to mindlessly extend contracts and spend money like it was before.
The one time I did and ran out of money before the day ended, I desperately raided the mines, hoped for tony to be "in back", lost with Flo in the fighting competition (lol) and prayed not to get ambushed by bloodcats at San Mona mine only to find out that I can't open Kingpin's chests anyway...
An hour later my entire force was gone... The experience of desperately needing "just another 10000$" was pretty exciting .
Thank you for all your hard work! *thumbs up*
[Updated on: Mon, 07 December 2009 03:42] by Moderator Report message to a moderator
|
Private
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239798]
|
Thu, 10 December 2009 22:54
|
|
| Luppolo |
|
Messages:150
Registered:July 2009 |
|
|
savegames are randomly corrupted (ERROR loading game), even from several new games without any apparent logic
[Updated on: Thu, 10 December 2009 23:01] by Moderator Report message to a moderator
|
Staff Sergeant
|
|
|
|
| Re: HAM 3.6 Alpha - RELEASED[message #239899]
|
Sat, 12 December 2009 13:22
|
|
| RandomOracle |
|
Messages:19
Registered:October 2009 |
|
|
Headrock
Thereafter, as in you could come back to hands repeatedly and he would always move? In other words, loading a savegame into 1.13 fixes the problem permanently for that saved-game?
It doesn't fix the problem permanently for 3.6, I have to load the game in 3.5 each time I get this problem.
Headrock
Also, are you guys killing Kingpin before this happens? Rescuing Maria first?
No killing Kingpin or rescuing Maria. For what it's worth, this problem happens most consistently with Darren for me, as in he doesn't move and give me my winnings.
Btw, I think it was mentioned before but it bears repeating: this problem isn't limited to just Hans, Darren, and other NPCs. Your mercs also have a tendency to stop in the middle of movement orders.
[Updated on: Sat, 12 December 2009 13:41] by Moderator Report message to a moderator
|
Private
|
|
|
|
| Pages (12): [ 9 ] |
  |
Goto Forum:
Current Time: Mon Jun 15 06:37:45 GMT+3 2026
Total time taken to generate the page: 0.35657 seconds
|
Blog
Search
Help
Members
Register
Login
Home
