The new project is finally released. It is not perfect yet, and has known issues, but it is a hugely improved project worthy of continuing to grow, refine and fix. This thread will be the home of support related issues including testing, as well as bouncing or suggesting ideas as it moves forward.
New HUB controller class and global singular tick that all cores operate from.
All war core (not player assist) tickrate properties have gone obsolete.
[ HUB ]
HUB.TickRate=4444 // Controls the rate at which all war cores operate from the HUB controller.
The HUB will tick at this rate regardless of any core status. Everything is in sync and everything knows if everything else is ready or not.
The cores themselves will always operate as fast as they can based on the rig itself, so the value here has a nominal setting.
Cores release slices to other cores after they finish a heavy operation so the entire system gets a chance to attempt an operation.
This is now possible due to the recent changes I made and can take advantage of the huge performance increase due to the new strategy I put in place.
[ Performance ]
I've implemented something I've been chewing for awhile and fundamentally changed some implementations based on my thinking.
This yielded a GIGANTIC improvement in general performance and optimization.
It should now be much, much improved speed / less impact across the board, as long as the processor is at-least a dual-core.
As always the more cores the better.
Due to my new implementation it now depends far more on the true raw horsepower of the rig.
This significantly reduces "hitching / bursting" at the expense of previously blasting numbers into the world at break-neck speeds regardless if the engine is actually ready or not.
This new implementation is also designed to produce more stuff relative to the player generally, faster and more consistently when things are actually available and suitable.
Certain properties have also been tweaked to go along with this for a more complete experience.
Some properties are no longer used and will eventually go obsolete / get-deleted.
[ Clean-up ]
Dramatically improved the speed of cleaning up when the cores go offline, especially car crews.
[ In-game Editor ]
All actice cores will now automatically be turned off when the editor is triggered.
[ Thugs ]
Due to the raw numbers required for the car crews (up to 4 per vehicle) the priorities/default numbers are now inverted.
That is to say, previously the crews were given more priority over street thugs.
That is no longer the case. Street thugs now rule the day with crews coming in behind.
This provides a MUCH more active, consistent, constant environment because of raw numbers available and horsepower.
The war presets will now do a math floor of either none, /2 or /3 for crews against street thugs based on which was selected.
Mayhem is now pushed to the lowest priority in relation to any other core activity.
[ Recruits ]
Recruits are now released to the game instead of killed outright so the game can more quickly reuse them as it sees fit.
Recruits that bail to make room for new recruits might get punished by former mates for leaving.
[ Fixed Bugs ]
Recruits should now correctly warp into and show with the player when the player is inside buildings and spawns vehicles with auto-warp enabled.
Fixed group related problem I noticed in the recruit collection.
(Hopefully) fixed a bug that was causing recruit statues to eventually appear or general recruitment failure.
Fixed numerous minor bugs / glitches.
[ Known Bugs ]
Occasional world statues, especially garbagemen at night.
Car windows might still be inconsistently removed.
There might be a leak in Mayhem somewhere.
Firemen, Paramedics and Cops are now excluded from recruitment, crews and street thugs. Cops can still be caught up in Mayhem.
Hookers are now excluded from Recruits.
[ Police ]
Now with the ability to recruit for backup as well as (and more importantly) no longer having cops in crews, the default setting no longer has wanted levels cleared on tick.
This applies only to the PlayerAssist.ClearWantedLevelOnTick and does not affect PlayerAssist.MaxWantedLevel.
The original default of True was in place because having cops in crews means you would CONSTANTLY get huge wanted levels by killing them.
Having cops (as well as firemen and medics) now excluded from all core scooping except Mayhem makes it less likely to get such huge levels so fast, though moderate levels are normal, and fun :)
It can always be turned back on as you see fit.
Note toggling the cores will still clear the wanted level regardless of this setting.
This is intentional for "clean slate" in either case.
[ Recruits ]
If PlayerAssist.RecruitsMax is set > 7 it will now always get reset to 7 when loaded in the game regardless.
Made some enhancements to the recruitment code. They should be more likely now to make it to the vehicle, less likely to shoot at new recruits after being recruited and more likely to join the player when switching or entering new vehicles generally.
Additional restrictions already applied in other cores are now also applied on recruits to be considered acceptable.
Recruits will now mostly only attack other peds they deem a direct threat to the player or them.
PlayerAssist.RecruitsMatchSeats=True // If True, when new recruits are signaled, existing counts will be adjusted to the current vehicle passenger seat count if applicable.
Since it is useless to have more recruits than passenger seats generally speaking I thought this would be a fun idea to try and I like the result.
When True, and new recruits are signaled, the current recruit cache is tested against current vehicle passenger seats. If it's > then it will get purged until there is room for
the new recruit up to the seat count. So this means if you have 5 say on foot and snatch a bike and signal for a new recruit, the new recruit will wind up being the only
one left alive as they join you on the bike and the rest will suffer death as normal. So then you dump the bike and get a 4dr ride. You can signal 2 more recruits to fill
up the car etc etc. This keeps the crew in line with what you can actually use based on the ride you're in at the time so there isn't wasted processing power on recruits trying
to chase you down because they couldn't fit in the vehicle.
This will only apply when you are in a vehicle and signal a recruit. Being on foot when you signal will always use up to RecruitsMax.
[ Car Selector ]
This has been enhanced to now include any living recruits.
Recruits are whittled down to the number of available passenger seats and then warped on in just like the player so everyone is ready to rock'n roll immediately.
Had to implement a synced bi-directional cross script call for this one but it was interesting and gave me an excuse to finally do it :)
CarSpawner.UseHelmets=True // If True, and Warp is True and the spawned vehicle is a Boke, the Player and any Recruits warped to the bike will get helmets.
There appears to be a bug in SHDN where the ForceHelmet function doesn't actually work.
After roaming the raw ScriptHook API I implemented a new API method which "gives" the ped a helmet and then calls SHDN Ped.ForceHelmet. This solved the problem.
[ Car Repair ]
Now that AW provides recruiting the raw API used to remove the front windows now also removes rear windows for the same reason.
[ In-Game Editor ]
Made the selection colors for the lists much easier to see.
[ TickRates ]
Adjusted some rates up a bit as originally intended now that long term extreme testing phase is finally wrapping up.
They were extra aggressive to make it more likely to encounter problems faster, especially sync issues.
[ Performance ]
Enhanced performance a bit more with another quick pass.
[ Internal SyncAbort ]
Implemented internal sync abort so all scripts can instantly know they should dump their current operation for cleaning up.
This applies to heavy hitting or iteration based code where my global sync pool forces the scripts to perform busy checks.
With this in place it is now possible to have a faster clean-up when AW gets toggled off without causing additional problems.
The Car Crews will always take the longest to clean up due to the nature of it. Messages will say to wait for clean up to complete.
Always wait for clean-up complete messages when toggling off before doing anything else.
This does not apply to Player Assist core. It is exceedingly fast in its operation generally.
Added an additional sync structure so the entire system now knows when all enabled cores have cleaned up and able to now show an accurate, final "Everything is cleaned-up" message when it goes offline.
This applies to the war cores not player assist.
[ Fixed Bugs ]
Fixed a sync bug introduced with the recent addition of player recruits.
Fixed a bug in an API call.
Fixed a few messages that were not controlled by debug property.
Fixed a bug in TogSync where it didn't have the recent in-game hotkey ability applied yet.
Finished the 1st draft of an in-game configuration editor.
You should always turn OFF all the cores before bringing up the editor and making changes. Although I have in fact tested it without doing that, it is less likley to cause issues if the cores are turned off 1st.
Also note there is stll no data validation so entering invalid data will cause problems as always.
And finally the controls provided by SHDN are very limited and do not provide -many- features common to the types of controls they simulate.
This is understandable because HazardX would have had to hand code these anyway since they are likely technically using Direct3D.
I have overridden and inherited many underlying controls and coded up missing functionality however I do not have access to the true underlying objects so I can only go so far atm.
Things I've enhanced includes making it possible to scroll list boxex with keyboard arow keys, have the scroll bars track, object linking etc etc.
The editor will get expanded eventually to include some way of using war presets. There isn't a combo box equivalent so the likely replacement will be a listbox instead.
Realized the dev keys I've added for troubleshooting are simply wasting key binds users may have in something else.
So now the binds simply won't even happen unless it's on my rig. These are in place to assist me and now prevent having to keep removing the things before releasing versions.
[ Common Properties ]
Fixed bug where some underlying common properties weren't fully applied to inherited objects.
[ Crew Passengers ]
Oops. Forgot to remove a flag check which prevented full car crews. Cars should now be full again when reserves are actually available for them.
Since it is unknown when if ever SHDN will see another release that fixes critical known issues, I have enhanced my API class further.
It now includes a number of direct calls that entirely bypass SHDN versions and the result is very good.
These include but are not limited too real-time entity validation checks that are not cached like the SHDN versions and report the real status of the object when it's needed, any time.
These also include warp related and other operations.
The end result is a more stable Ambient Wars operation because it gets critical real-time results from the game instead of depending on SHDN results that are cached and very often cause failures, when it wouldn't have too, because of the cached nature.
Having cached results as SHDN does may be good for less complex mods, however it is proven unsuitable for Ambient Wars because of what it does, how much it does, and how often it does it.
Luckily I am still able to use the majority of the excellent .NET wrapped features of SHDN and greatly enjoy using it.
As other problems are uncovered identified as being caused by cached results, new API calls will be created to replace them. This will provide a better Ambient Wars deployment strategy that doesn't rely on SHDN being updated to fix the problems.
[ Independent Toggles ]
The Player Assist core is now entirely seperate from the war cores.
F9 now toggles the Player Assist.
F10 now toggles the war cores.
This allows using Player Assist while on missions where the war cores can not be consistently used without problems.
[ Dynamic Configuration ]
A core must have been turned on at-least once in a game session for the following to apply.
Loader code has been enhanced and now reloads all property blocks from the configuration file when the core is toggled on again.
This allows changes to be made to the config file and see those changes reflected simply by toggling on the relevant core again.
This is early stage code so some properties should not be changed for use like this and instead use the normal ReloadScripts commands.
Examples of properties that may cause odd behavior if changed and reloaded using this feature until code to deal with it is created include Enabled and Hotkey bindings etc.
[ Reserve Corp ]
A new system has been built and serves as a recruiting, configuration, maintenance and release system for Car Crews and Street Thugs.
This eliminates the "dragger" issue and help further reduce but not eliminate the long term statue phenom. If the war cores are left running for extended periods without repeatedly toggled on and off then statues are less likely to show, take longer to show and are generally reduced in numbers.
[ Rage Mode ]
A new mini rage system has been created and allows changing general behavior applicable as described below. This is in the AllThugs property section.
RageMode 1: Policy - It's still moving. Shoot it again. The city is in total war with no loyalty of any kind. This is the normal, default mode.
RageMode 2: Policy - Cop Killers. All Thugs will mostly focus their rage on the police whenever and whereever they encounter them, and mostly ignore anything else.
RageMode 3: Policy - Brothers in Blood. All Thugs will mostly focus their rage on any living thing except other Criminals.
Medics and Firemen are now automatically excluded from any rage include mode 1.
Felt bad about seeing those guys get hit. Plus, it's more fun seeing the ones they just helped get shot in the head in a drive-by as they are standing up again :)
If this is set to any value other than those listed above an exception will be repeatedly thrown with a message to go fix it.
[ Thug Models ]
The file is still required for now, but the models are no longer used. This is because the new reserve system and the inability of any known method to update a game-created ped entity with a different model after it already exists.
[ Mayhem Disabled ]
The Mayhem core is internally disabled until it is updaed to use the new systems and enhancements being applied to the thug cores.
[ Weapon Chances ]
The Weapon chance code has been updated and is now operating as originally intended.
All weapon chance properties are now pre-sorted with the lowest numbers (highest chances) tested first, then next highest numbers etc.
The global randomizer is now also re-seeded providing maximum random chance selection behavior.
Car crews will always (in addition to) get a suitable weapon they can use out a window regardless of the chances to have other weapons too.
[ Spawnable Cars List ]
The list has been updated and now includes previously disabled models.
Thanks to Motorsport71 for spending time and snatching the names from the ide file for the ones that are named differently in the handling file.
[ Performance ]
Performance has been slightly enhanced further with a new entity system that can in many cases bypass the need to gather further entitites until its current known supply is exhausted.
This results in occasional bursts instead of continuous heavy hits which is perfer based on my own testing.
[ Debug ]
A few more debug related properties exist.
[ Fixed ]
The Mayhem core should no longer count the headers and spaces in the spawnable cars list in the totals count.
[ Troubleshooting ]
Updated the file with a note about turning off clip capture that help some folks.
Emergency release due to trying to assist with a rare issue only some may experience.
[ Debug ]
A new Debug property class has been created to try and provide work arounds for 1 or more issues some people experience. It may grow over time.
Debug.UseTaskSequences=True // If False, the use of a task sequence object will be replaced with an alternate direct single task call instead.
[ Police ]
A new Police property class has been created and its first role controls the creation and clearing of standard LCPD.
Police.ClearLCPD=True // If True, then ClearLCPDRadius around the Player will be cleared. This is NOT elegant but it works.
Police.ClearLCPDRadius=400 // If ClearLCPD=True, this radius around the Player will be cleared of all standard police.
[ Weapon Chances ]
Ok the weapon arming code with weapon chances is back in operation so have at it. See notes in editor on AK47 for general info.
The default chances have been reduced to 1 in 5 for most except the most dangerous and those are about 1 in 15 to 1 in 20 now.
[ Car Crews Reborn ]
I've re-written substantial portions -again- and implemented a substantial new reserve corp system, so custom thug models are back and so are packed vehicles, except this time their drivers could be anything from old men to librarians. This is not perfected see note in Bugs section.
The MinCarCrewPollRadius is back to 50 and is now used in conjunction with OnScreen checks. This helps minimize pop-in for SOD factor while allowing them to spawn -very- close (much closer than 50) when they are NOT on screen as much as possible.
[ Blood Sport ]
As requested by knightofni on the boards, there are now options to get melee weapons only, or fists in the city. I will look into also adding an option to remove all police in the next build as I think that would help your intent, and it could be very useful for other things in the future too.
AllThugs.NothingButFists=False // If True, nothing controlled by AW will have weapons at all. This overrides all other weapon props.
AllThugs.NothingButMelee=False // If True, nothing controlled by AW will have non melee weapons. This overrides all other weapon props except NothingButFists.
[ Weapon Chances Still Old ]
Just to re-note I still have not looked into the weapon selection code but I might finally get a chance too in the next build we'll see. So until then changing chances may have no affect as noted in the editor.
[ Mayhem ]
API class enhanced to add more types of damage to cars involved.
[ Misc ]
Made various changes to try and address occasional script aborts seen by Motor and possibly others. These do not include fundamental SHDN issues that need addressed in the long run, althuogh some try to work around SHDN in related cases.
Reimplemented AmmoMin and AmmoMax usage in the arming code. The arming code still needs a serious look and overhaul as noted above and in the editor.
Some properties marked as unused or obsolete.
[ Bugs ]
The new thug reserves corp is slowly losing their numbers over time. The net effect is a slowly diminishing supply of available crew members as the war rages over very long periods.
There may be an occasional [ EXCEPTION ] with a null object during initial startup. This is a trapped .NET issue and not an abort so if you see this you can use F9 to restart the system without a game restart. I will track this down when I can. I believe it's related to init of the reserve corp but not certain yet.
Updated: I may have resolved this issue. Report it if you see it at startup.
[ Fixed ]
Fixed a leak in street thugs that occasionally surfaced when toggling AW state.
AW is undergoing its first performance analysis pass for areas where performance can be optimized or made more effecient.
New properties, code and other factors will be created, changed or deleted applicable to the goal.
CarCrew.MaxCarCrewPollRadiusOptimized=50 // Now controls the final pass and can increase performance. If to few cars are being returned increase this to increase the amount.
CarCrew.PedScooperMaxRadius reduced to 80.
StreetThug.MaxStreetThugSpawnDistanceOptimized=50 // Now controls the final pass and can increase performance.
Performance.UseOnScreenChecks=True // If True, certain operations will use this instead of distance based calculations.
There is a caution associated with this. See config editor.
[ Ambient Wars Object Policy ]
Due to the recent changes where existing objects the game itself has created are being used instead of AW explicitly creating them, a project wide change will take affect in conjunction with it.
Previously AW would automatically delete objects under its control in many situations, mostly related to garbage collection. This behavior will be changed to simply release them back to the game.
The reasoning is simple. The game is not expecting these objects to be arbitrarily deleted outside its normal logic in general, because they are objects fully under its garbage collector and recycler.
I believe the game may have trouble in the long run (just a hunch for now) with these objects suddenly vanishing from its pool, where it can not account for it in its GC or recycle stages. So to
stem any possible issue this may cause (if I am correct) I am going to implement this change and see what happens.
[ Car Crews ]
MinCarCrewPollRadius is now being used in conjunction with MaxCarCrewPollRadius returning a random number between the 2. This provides a better randomized experience or variance in their locations.
[ Street Thugs ]
Idle Street Thugs can now steal cars instead of always just continuing to go insane.
StreetThug.MaxChanceStealsCars=4 // The max chance (higher is less likely) an idle Street Thug decides to steal a nearby car.
StreetThug.MinStreetThugSpawnDistance reduced from 15 to 5.
AllThugs.MaxChanceWantedByPolice=5 // Max chance (higher is less likely) any thug in any core is immediately wanted by the cops. See notes.
[ Car Spawner ]
Because the Player Assist core is now fully operational, the Car Spawner will no longer make any changes to the player at all including wanted level, health, etc as it previously did.
The former behavior was intended as a temporary measure until the Player Assist core came online.
[ Misc ]
Removed the x64 version link of the 2010 C++ redist from the TS file, as the core ScripHook is only 32 and the x64 won't resolve the issue where some people need the latest. Only the x86 will.
[ SHDN Exists() ]
Because SHDN.Exists is a cached result updated only once per frame, AW has new code to bypass this and directly call the core ScriptHook object check methods in real time. This is optional.
[ Performance ]
Performance.ThreadWait increased to 500.
Performance.ThreadWaitFine=200 // Will be used in situations where a heavy operation failed and throttle until the next occurs.
Performance.UseNativeObjectChecks=True // If True, AW will directly call native functions to determine if an object still exists instead of depending on SHDN.Exists versions.
This is a new feature intended to bypass the cached SHDN.Exiss result in favor of a direct ScriptHook object null ptr check in real time.
[ Bugs ]
The car selector might cause an unexpected reset or change in certain properties including the enabled status of all cores.
The GetCarsLoadedUp method that uses WarpIntoCar can not be stabilized and has been disabled entirely for now.
[ Fixed ]
Exceptions were not being logged.
Finally saw the private build tag was still in the logs. It's been removed.
Updated header to reflect the 2010 version of the project.
[ Properties ]
Deleted an obsolete property.
Moved property ThugModelsFile from CarCrews to AllThugs base so it can be inherit by Street Thugs too. This is in prep for later when / if a way to change an existing entity model is found due to the recent changes in the way Car Crews are created.
Increased CarCrews.EngineQualityMin from 60 to 250 so they start with a better low end car if this is the random low selected.
Decreased StreetThug.MinStreetThugSpawnDistance from 55 to 15
Decreased StreetThug.MaxChanceStreetThugCreated frpm 3 to 2
Decreased StreetThug.MaxStreetThugSpawnDistance to 100
Decreased StreetThug.MaxStreetThugRetentionDistance to 130
Increased a number of tickrates as some recent changes hopefully require less execution cycles.
[ Auto Remove Windows ]
I (and probably you too) got sick of constantly having to re-break the windows for shooting after car is auto repaired. That is no longer a problem. I added a new call to my API wrapper that knocks this issue right out.
PlayerAssist.RemoveWindowsOnRepair=True // If True, and the car was repaired during tick, then the left front and right front windows will be removed.
[ Config Editor ]
Added a new automation menu that can bulk enable / disable cores and blips including exclusions. Very handy / fast for testing or quick changing these particular settings. It may get extended.
- War Presets
Added a new War Presets combo setting a number of properties in bulk for quick change of the most relavent properties.
Note some of these, especially Rebellion and Armageddon are/can-be extremely taxing on a system.
The number of properties changed in bulk will grow over time. Use the spitter above the bottom log panel to see propeties being changed by selections.
The default as shipped will always be Ambient.
[ Performance ]
A new Performance property class now exists and will be used over time where or when I think of, discover or uncover things that can be used to explicitly boost performance generally.
The entire project still needs a serious performance-focused analysis pass but this new class is a quick way to increase performance a little as follows:
Performance.UseLowPriorityThreads=True // If True, all AW script threads are set to Low Priority.
Performance.UseBackgroundThreads=True // Intended for use in conjunction with UseLowPriorityThreads.
Performance.UseThreadWait=True // If True, each heavy operation in all applicable AW threads will wait after.
Performance.ThreadWait=333 // A millisecond time all applicable AW threads will wait if UseThreadWait = True.
Made some more changes to get back a bit more performance in certain areas.
[ Ped Scooper ]
The new code has been made configurable so a choice can be made to allow or disallow how it operates with respect to scooping for crews. See additional comments in the config editor.
CarCrew.PedScooperFlexible=False // If True, the ped scooper will snatch them for crews even if they are in a vehicle somewhere, otherwise they will be skipped.
CarCrew.PedScooperMaxRadius=120 // It will be allowed to reach up to this range looking for candidates.
CarCrew.PedScooperMaxCache=30 // The max allowed to scoop and cache. The cache is used to help performance preventing a billion repeated calls.
* There is a performance warning associated with these. See config editor.
CarCrew.PreferMoreSeats=True // Not implemented yet. Intended to try and increase the probability of heavier crews.
[ Bugs ]
- It's occasionally possible for a street thug to be in the air. Cause unknown and will be investigated.
[ Fixed ]
- Fixed a bug where a Rogue crew member had a blip created even if CreateBlips was False.
Due to the ever present, as-yet unsolvable long term play statue syndrome related to creating car crew peds from thin air and eventual statue form, the car crew code has been dramatically altered and now uses civs already existing in the world, specifically already in vehicles. This is an attempt at discovering if this change eliminates long term statue problems. From current experience, Street Thugs do no exhibit this problem, and because they are existing entities within the game, is the reason car crews will now also use existing entities so we'll see.
An obvious side effect of this change is the use of thugmodels is temporarily disabled until I find a method of directly updating an existing Ped model to another model. If you know a native method sig or otherwise know how to do this shoot me a message on it at the forums and I'll implement it so thug models can return faster.
This new technique has all but eliminated the dreaded statue issue based on my testing, so I will keep this new strategy and go forward with releasing this version now, as it has a number of other extensive changes as well.
- Crews that have an immediate car failure (internal open chance) now have a 50/50 chance of being violent to the player regardless of MaxChanceHatesPlayer.
- Crews that wind up outside their vehicle and trip the Rogue chance or are Idle now have a 50/50 chance of being violent to the player regardless of MaxChanceHatesPlayer.
- The code monitoring a crew in an apparent stuck car is now more tolerant in giving them time to get it moving again and is also now more vriant in how much time that is for randomness.
- Since the changes to crews moves away from creating entities the game has problems with and instead using those it has already created, I've now created an additional set of functions that help fill a vehicle up when it at-least gets one that already has a driver as required. This further reduces the solo Leader phenom and also helps get full loads in 4dr again much better.
[ New Properties ]
CarCrew.MaxChanceOldTires=4 // Max chance (higher is less likely) 1 or more tires on a crew car have seen so much extreme driving they are about to blow out.
CarCrew.MaxChanceSoloLeader=6 // Max chance (higher is less likely) an evaluated car is allowed to have a solo Leader out on his own looking for a crew instead of having one already.
Note this should naturally occur more often at night, as there are fewer cars with more than 1 occupant generally.
It is eventually anticipated that I will add a new set of logic so a solo Leader will be solo less often by using existing entities. This is part of reducing statue formation by not creating new ones on the fly as before.
[ Street Thugs ]
The min and max times for custom tasks has been reduced.
[ Blips ]
In an attempt to increase performance as well as potential stability or statue-form, Blips are now created and destroyed immediately. They are no longer retained for garbage collection later.
Ny testing has shown the game has a more limited resource pool than was previously thought, and due to the way I now create and destroy blips immediatey, where in many cases the delete fails because the game supposedly nulled it, in reality the game TOOK it and therefore changed its mem ptr, because later you can start to see the game recycle peds and cars randomly into the game world and see a purple blip ped walking along a sidewalk, or a green blip car driving along. So this was important and I will keep the new strategy and no longer retain blips for extended periods (for updating colors) as it appears to cause the game real problems over time.
[ Performance Specific ]
UseThreadWaits is now True by default and should provide a boost in performance by self throttling heavy hitting operations that can iterate more than once per TickRate.
[ Bugs ]
There may be times when car crew drivers are more retarded / less reactive than they should be. I'll look into this some time next week when I get a chance after getting back to my contract site out of state.
Fixed a bug where a much smaller dev test setting was still being used in place of MaxCarCrewPollRadius.
Fixed a bug where a suitability check on a car was after instead of before a mutually exclusive check and resulted in an inop car.
Fixed a bug related to snatching street thugs.
From the Readme file (partial):
Ambient Wars Revival 2010 v220.127.116.11 - It's a war out there ...
I will say a short summary of the key components but can not possibly describe everything and will not attempt to.
The city used to be full of bland, stupidly boring drivers that do nothing but clog the roads and tail each other like lemmings. I guess that describes plenty of real life drivers and roads too. A new breed of folks have moved into Liberty City now, and they intend on ripping the city apart in any way they can.
Car Crews are Thugs. They have a Leader and their goal is essentially to take over their territory. But this will never happen, because no crew has loyalty with any other. So the result is a constant battle for turf all over the city. And speaking of loyalty, that is in short supply too. If the Leader fails to continue allowing its members to rampage as they require, there is a high probability (configurable as are a billion things) they will turn Rogue and punish those around them for screwing up their objectives.
The Civilians of Liberty City have taken note of, and are not immune to, the effects of these crews. Many have themselves turned to violence as a means to accomplish their objectives if they have one. It's also brought out the simply-insane that just want to take part and themselves enjoy turning the city to ash.
Due to the constant, endless war that now rages, the previously dependable vehicles of the city now suffer tremendous shortages of parts and good maintenance practices. The result is an ever increasing list of common mechanical failures. These range from simply blowing out tires all the way to a car having a lot of simultanious failures from the lights to the hatches to the motor and tanks. The nastiest are stuck throttles if the other failures are present, as these essentially become out of control missles headed in out of control directions. It could be a building, another vehicle or worse it's headed for. Regardless of what that is, unless it's ummune to fire it's going to burn, and in many cases it's going to explode. Badly.
Another side effect of these failures directly affects Civs themselves and not just related to vehicle maintenance either. The weapons they carry are seriously becoming degraded and are dangerous to the owners too, not just their targets.
Due to the nature of everything described above, the default abilities and resources available to us as players is now totally insufficient. The Player Assist component addresses a huge amount of configurable options so we can make it be exactly how we want it to be. The default settings that ship with AW have a little regeneration turned on for health, armor and ammo, as well as vehicle regeneration so we can keep the action going if we choose to drive without having to constantly change cars. But that's also easily done too with the Advanced Car Selector.
Advanced Car Selector:
While helping me debug and test both the orginal project during experimentation, and especially in the new project, Motorsport71 (more on him in Special Thanks) mentioned in pssing "maybe a car spawner would be cool?".
Yes, yes it would. After creating the initial version, I wound up growing it into a fairly hefty system unto itself and it's now capable of being used to instantly select vehicles from an origanized customizable list, including base and feture colors, and bring it into the world with the engine running, the player in the driver seat and boom. Just spawn and drive or fly away.
From the Requirements file:
Ambient Wars Revival 2010 v18.104.22.168 - Requirements
PC GTAIV version 22.214.171.124 or later. Previous versions may work, but they are not tested or supported by me.
Ambient Wars Revival v2.x or later.
GTAIV ScriptHook 0.5.1.0 or later.
GTAIV .Net Script Hook v126.96.36.199+ BETA or later.
XLiveLess 0.999b7 ASI Loader or other functioning ASI loader.
Microsoft .NET 4.0 Framework or compatible.
You can find ScriptHookDotNet and links to everything else except Ambient Wars at the following support site:
You may use any functioning ASI loader you want. I use XLiveLess because it is 1 file (Xlive.dll) and it works. It can prevent saving in the normal way using beds so you may want a different loader. I use CONTROL+S provided by Ambient Wars to save whenever and whereever I want (except while driving...) so I could care less about bed saves not working. Auto saves work as normal regardless.
1 - Copy or unpack ScriptHook.dll, ScriptHookDotNet.asi and xlive.dll (or other ASI loader) into the root of GTAIV.
2 - Create a scripts folder off the root of GTAIV
3 - Copy or unpack the contents of AmbientWars into the scripts folder.
4 - Load the game using LaunchGTAIV.exe (if using XLiveLess) or the game directly if using other loaders that support direct EXE launch.
5 - Enter the world and confirm ScriptHook is working by pressing the tilde key. If the command console opens then you have done it correctly and ScriptHook is running so press again to close the console.
5b- Optional: type ReloadScripts into the console and confirm ScriptHook reloads 3 scripts from AmbientWars. This 100% confirms ScriptHook is working in the game and can also be used after changing AmbientWars.ini file settings to have it reload your changes without needing to restart the game. If this is your intent then toggle AW off (F9 is default to toggle on/off), make changes, ReloadScripts, toggle back on, test changes.
6 - Press the Ambient Wars hotkey (F9 is default). If you see your health and armor flash and grow then AW has turned ON. If you see your health go to full and the armor flash between 50 and 100 then AW has toggled OFF.
7 - Let the carnage begin!
If you have problems or can not open the console in the game world read the AW.TroubleShooting.2010.Txt file for possible causes.
Close the game and remove the files you added.
From the troubleshooting file:
Q: Common Problem: You can't open the ScriptHookDotNet command console while in the game world and Ambient Wars doesn't appear to work:
A: That is not Ambient Wars failing. See the following.
If you can't open the SHDN command console while in the game world, then Ambient Wars likely isn't working either.
That's not Ambient Wars failing. That is ScriptHook/SHDN related:
If you've installed everything as specified in my ReadMe and pressing the Tilde Key in game (in the game world loaded, not the main menu) doesn't open the ScriptHookDotNet command console, that is ScriptHookDotNet failing to load, and it's probably because the core ScriptHook (C++) file needs one of the following redist updates.
Q: Common Problem: You have a functioning ScriptHook and when you turn on Ambient Wars you see an error related to access denied of files.
A: You are probably under UAC control and Windows is preventing access to required files. Run As Administrator = Problem Gone.
Q: GTAIV with Ambient Wars seems to crash / CTD often and random, especially when a lot is going on including huge explosions and a lot of action.
A: Disable ALL GPU and CPU overlocking and see how it does. Don't concern yourself with it running like shit. Concern yourself with a reduction in crashing.
If it reduces or eliminates the frequency it is crashing, then you have a hardware or heat problem you need to address to get a stable gaming experience.
08-15-2010 10:32 AM
Just a question: Will this function in EFLC (Episodes from Liberty City), or do we need to stick with vanilla GTAIV?
08-15-2010 10:40 AM
I've only been working on it with Iron for the original GTAIV 188.8.131.52, i believe that is the only supported format. I don't have EFLC so i haven't tried it.
***UPDATE*** See later posts, Ironhide got confirmation it does run on EFLC
08-15-2010 11:07 AM
Actually, this should totally work with EFLC because the core ScriptHook and SHDN layers support EFLC, and Ambient Wars simply uses whatever is provided by those layers. It is not game pack specific, unless those packs remove any vehicles, character models or core game functions used by Ambient Wars which iI highly doubt.
08-15-2010 07:06 PM
I can confirm this working on EFLC as well.
Very nice job, total chaos without any crashes !
Ironhide, I've sent you a PM on GTAForums
08-15-2010 07:31 PM
Excellent news this is the first confirmation of EFLC operation. Very much appreciate it!
A number of changes are already in place in the next version and about to be tested heavily with Motor before it goes live.
Sjaak327 check messages. Let me know immediately as requested if you find it possible. Messages here or there are fine though I am more likely to see PM's here (much) more often due to the home support thread being here.
08-16-2010 02:33 PM
I have a problem with your mod, it doesn't spawn many street thugs. and haven't seen any Mayhem peds and car crews . I turned the blips fuction on because I thought; there weren't many thugs(only 2 never seen anymore than that), or mayhem peds, and i don't get any of those colors that the blips fuction does and the reason i can say it doesn't work is because the different colors there i tried provoking them by shooting/driving into them and they just drove of like they would normally do, which i think is wierd. I've made some changes to the settings, thought it would give me some more of them, but no it didn't :/. I really would like this mod to work because the city is boring like ****.
Edit: I just killed my first Car Crew which consisted off 2 peds....
08-16-2010 02:44 PM
I did find one problem, I am not sure if it is related to either AW or the .net scripthook, but if either runs, and I alt-tab out of the game, I have to kill the process, as I can never get back into the game.
08-16-2010 05:13 PM
v184.108.40.206+ of AW no longer creates crews from scratch. It uses what the game has in the world. This is experimental to address the eventual statue-form problem that will otherwise occur. Turn up traffic density to max and see if there are more.
Set MaxChanceStreetThugCreated=1, reduce MinStreetThugSpawnDistance to 10 and MaxStreetThugSpawnDistance to 100, set MaxStreetThugPerTick to equal MaxStreetThugCanExist and see if more street thugs spawn. All of this depends on your machine. If you have things low, with low density and low resources, and generally low entity counts in the world because the game is trying to keep your performance up, you will not be able to force a different outcome without having the game being able to create more entities for use.
I find the game is usually only consistently alt-tab friendly if I first bring up the map with esc. When doing that I can tab with no problems, which I do constantly because of development. However if I tab out without hitting esc first to bring up the map 9 out of 10 times I can't tab back in, and this has always been the case (for me anyway) even with just the base game and no mods running of any kind.
08-16-2010 05:48 PM
i just left my machine run AW for 11 hours straight while at work. got home... NO STATUES!!!!!!! AW did slow down all processes though. For example, thugs were barily spawning, not much mayhem was going on, and CarCrews was selecting Peds and vehicles but not implementing them. I've noted before that AW tends to slow it's havok down over time, but my machine was running smooth with no hickups and again... NO STATUES!!!!!!!
08-16-2010 07:56 PM
There are definitely still quirks and glitches that need to be hammered out over time, and I need to stop adding new stuff soon and go into a performance analysis mode so I can refine and boost performance, but that damn statue business was a giant pain. A down side of the new approach is no custom thug models until a way is found to dynamically change the model of an existing entity. Another down side is the code now directly depends on existing entities, so machines with low resources or low settings have less available entities to draw from, which is directly proportional to how many things AW can "create" obviously. In the original approach I could create whatever I needed regardless, but the game as we've seen has a huge problem in dealing with that over time.
And I think I know why. The game is constantly recycling peds and cars as part of keeping itself within a 2gig footprint. And as you'll remember from one of my posts what we're doing is injecting content into the game on rogue threads the game is not aware of in the normal sense. It processes the thread because it's in the thread pool but it is clueless as to the nature of what it's doing or creating outside the control of it's normal collection system. So none of what is created in this manner falls within the games normal garbage collection and recycle except the fact it would be seeing higher numbers than it can account for, because it didn't create them, so over a long period of time it is probably litterally breaking its garbage collection. The stuff gets orphaned and stranded because the game isn't treating them the same as within its own collection system since it's not aware of or accounted for in that manner.
Switching to using what the game itself provides eliminates that problem at the cost of entity model customization. To get a stable long term war I'll definitely pay that price if no way is found to dynamically change models.
08-16-2010 08:12 PM
i was just playing for about 50 minutes when i got a car crews error in the script. Now i did adjust the poll radius MaxCarCrewLeaderTargetPollRadius up from 25 to 40 so that i got more vehicles filled with crews instead of having only two ( a lot of vehicles only harbor two members). But the error isn't what got me... it was the side affect. I turned off ambient wars and the remaining CarCrews weren't swept up by garbage collection, which has happened before. When i toggelled it back on the script was still "broken", which was expected. But when i hit the ~ then reloaded the scripts everything fired up normal...except the old Crews were still running around the world unchecked and not picked up by garbage collection even after a script reset. It sounds to me like the CarCrews got away from AW and ran for it!
I am going to reduce the radius back and lower the CarCrew numbers. The problem might be the GTA i'm running, i'm running my modded file, still v220.127.116.11. The script error came during a chase where car crews were driving two downloaded modded cars and i was in another. The size of the downloaded vehicles is anywhere from 2x to 4x the original vehicle file size. I have 34 replaced vehicles, extra blood, and the loading screen bypassed in this modded game. These models all have been thoroughly tested and do not have any texture errors, and i ran it for a half an hour before that before i made config changes to the poll radius and so on without any trouble. I then made it another 50 minutes. And almost all of the chases have been in modded vehicles.
I will actually just go back to my "unmolested" file and run it as the config is set from the download again. That would be the safest way to determine true car crew stability under factory software conditions. I'll post back with my findings.
08-16-2010 09:21 PM
We covered this many, many times previously.
When the script thread is aborted, which is the error you are describing, AW is not in control any more. It's been aborted. There is no mystery. When the script thread is aborted, AW isn't running any more and has no control over anything that was on the thread that was aborted. AW itself went away with the abort. The only way to clean up when a script thread is aborted is to restart the game.
08-17-2010 03:37 AM
I have all my settings on high, and there are lots and lots off peds all over the city so they shouldn't be a problem, and I have the settings you described, now im gonna check it ot and see if there is some improvement :)
08-17-2010 06:59 AM
War Presets Option
Originally Posted by takanuva200
I have all my settings on high, and there are lots and lots off peds all over the city...)
Excellent then you should be able to get some crazy numbers if you mess with the settings. I also forgot to mention I have reimplemented the Ped Density Boost property which can substantially increase the number of peds in the city by huge factors.
You situation made be think of something I hadn't yet. What I will do and include in the next release is create a War Presets type option in the editor. The defaults that ship with AW are specifically to be a middle of the road, background ambient war numbers and not a full out Armageddon. This is the default for 2 reasons. ( 1 ) so it is actually just ambient and not in your face every step you take no matter what and ( 2 ) it takes a LOT of horsepower to crank the numbers up and not utterly crush the CPU(s) depending on the type, core numbers and speed.
So here is what I'm thinking as far as a presets option:
1 Unrest - Low settings. 1 crew, 1 street thug, 2 mayhem.
2 Ambient - Moderate settings. 3 crew, 3 street thug, 3 mayhem.
3 Chaos - Elevated settings: 5 crew, 6 street thug, 4 mayhem.
4 Wars - High settings: 8 crew, 8 street thug, 5 mayhem.
5 Rebellion - Very high settings: 12 crew, 12 street thug, 6 mayhem.
6 Armageddon - Extreme settings: 16 crew, 16 street thug, 7 mayhem.
So it could be a combo box with these, you just pick one, save it and go. I will eventually need to make it so AW does a total re-read of all it's settings when toggling on off. Right now I think it does the bulk of them in the ctor which means only a ReloadScripts console command will cause a full re-load of settings changed while the game is running. Of course AW should always be toggled off before doing a ReloadScripts because if you don't and AW is running whatever it had control over will be lost and kept in the city which is bad because it will then have mission req peds and cars in memory and you do not want that in save games.