Home » MODDING HQ 1.13 » v1.13 Bug Reports » BUGZILLA report all bugs here!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: BUGZILLA report all bugs here![message #325213]
|
Mon, 16 September 2013 06:01  
|
|
 Moa |
 |
Messages:58
Registered:September 2013 |
|
|
To save you some time only the question below
**********************************
* Current situation
**********************************
Toggle Spoiler
(Food/Dirt/Temperature) decay get updated each time one enters sector or access map inventory by overwriting the uiTimeCurrentSectorWasLastLoaded.
Despite it has 'loaded' in the name, this variable is used to determine when the player was IN the sector (entered tactical) and gets updated everytime the map gets undloaded.
Used for updating rotting corpses, smoke effects, possibly even handling quests, everything that needs to know when the map (not just the items of a map) was last loaded. Might be totaly wrong but thats what the comment implies.
Showing sector inventory currently loaded and saved the items multiple times.
In addition to the repeadadly accessing the harddrive there are also multiple loops traversing several times the item list(s), sometimes just to get the size and often to adjust a single value or to copy to another array. Those redundant code can and should be replaced.
During timing tests I figured there are actually only two problematic functions: SectorInventoryCooldownFunctions() and BuildStashForSelectedSector().
To sum up the number of loops, file reads and writes:
(multi means the whole file is read/written,
single means a single word is read/written,
loop means there is a loop traversing all read items.)
best/worst case call count:
When entering sector (allways same sector as the loaded one):
-1x load items in a call of EnterSector() (single,multi)
-1x calc decay in HandleSectorCooldownFunctions() (loop)
-1x save items in SectorInventoryCooldownFunctions() (single,multi)
When accessing sector inventory (same sector/different sector then the loaded one):
-0x/1x load items in SectorInventoryCooldownFunctions() (single,multi)
-1x/2x calc decay in HandleSectorCooldownFunctions() (loop)
-1x/2x save items in SectorInventoryCooldownFunctions() (single,multi)
-0x/1x load items in GetSizeOfStashInSector() calculated by:
-accessing total number from file (single),
-calling GetNumberOfActiveWorldItemsFromTempFile() (single, multi and loop)
-loop all stacks and add the itemcount (loop)
-0x/1x load items in BuildStashForSelectedSector() to get total number of items (single)
-0x/1x load items in GetNumberOfActiveWorldItemsFromTempFile() to get number of existing items (single, multi, loop)
-0x/1x load items into local array (multi)
-1x/1x loop all itemstacks and add existing ones to global vector (loop)
-1x/1x loop all itemstacks and add unseen (filtered) ones to global array (loop)
As you see entering sector has one loop, but accessing sector inventory has multiple loops.
Therfore it is not possible to eliminate all redundant loops.
But we can make a huge boost in loading speed when reducing 11 reads, 4 writes and 6 loops down to -> 2 loops, 2 read (1x single,1x multi) and 2 write (1x single, 1x multi). That is more than 300% improvement.
If you wonder why I also count a single word read in a file as an issue: you have to add the access time to the file as well. In that time the CPU is able to do thousands and thousands of instructions (like checking all items in a sector and decay them as neccessary)
**********************************
* Options to fix the time bug
**********************************
Toggle Spoiler
Option 1:
Introduce another variable inside SECTORINFO used for the last time (game minutes) we have updated all items for that sector.
This approach brakes savegame compatibility.
Option 2:
Create a static array inside the decay handling function which holds the time at which all items in various sectors has been updated.
There is a problem here: one cant determine if a completly different savegame is loaded. To do make it work we need some global variable which tells us if our current save game is the one which matches our static times.
This also requires frequent recalculation of the static array after autosave, save and load.
Option 3:
Dont update uiTimeCurrentSectorWasLastLoaded when showing items in sector inventory.
Instead one must add the delta decay to the items before showing them and remove the delta decay (or trash the itemlists) when closing the sector inventory.
Let the final modification be handled when player is actually entering the sector.
Option 4:
Dont update item decay when showing the sector inventory.
The player will see outdated values in DB and tooltips and needs to enter a sector to get the correct values.
Option 5:
update decay as usual on enterSector and on showing the sector inventory by overwriting the uiTimeCurrentSectorWasLastLoaded.
This may brake some (potential) quest code, visual effects like smoke, rotting corpse ec.
They are actually broken allready, so we dont care!?
*************************************
* Options to fix the loading glitch
*************************************
Toggle Spoiler
Option 1:
relocate the decay handling function from SectorInventoryCooldownFunctions() to avoid multiple loadings of the same data:
For entering a sector this needs to be inside the EnterSector() function after we loaded the items or inside LoadWorld(), PrepareLoadedSector(),...
For accessing sector inventory a good place is right below the buildStashForSelectedSector() call in CreateDestroyMapInventoryPoolButtons() where the original call to SectorInventoryCooldownFunctions() was.
Because of Option 3 above we can use a hook where the stash actually gets build. Saving to tempfile can be omitted.
Merge all loading functions which have to get information from item temp file into a single function, at least those for building the sector stash.
Option 2:
Turn off Overheating, Food and Dirtsystem? - not a real option 
Extend the parameter list of various functions to return some known facts about read data (number of active items, total number,...). This however does not eliminate the loops which also are responsible for long loading times.
***********************************
* patches
***********************************
Toggle Spoiler
For a patch with savegame compatibility I used options 5/1. You can download the patch later here (using rev6401 as a base).
For a more robust patch options 1/1 will be used. Until that is finnished the first patch should allready contain a lot of improvement. Changing to another variable is not that hard. Possibly this can be added later to the trunk once we have another savegame incompatible update.
Note that this just handles the loading part - the saving (closing sector inventory) is a different kettle of fish.
The test save is the one from LootFragg in this thread but on another day (d10, 15:00)
after moving the HandleSectorCooldownFunctions() to enterSector and to CreateDestroyPoolButtons() in order to avoid 1 multi word load and 1 single word load the timings are:
timings (ms) before patch: after patch:
13977---to load save (into map view)----14040
10359---to show sector inventory D13----8034
6708----to close sector inventory-------6178
10140---to enter sector-----------------11372
Because of variance its probably around 1 second faster to show the stash.
During implementation of Option5 I figured that we can skip the save on showing stash (see Option3)
timings using 5/1 and using option 3/1:
14165---to load save (into map view)----14040
3267----to show sector inventory D13----1529
7379----to close sector inventory-------6178
10140---to enter sector-----------------11372
Unfortunatly this introduced a bug: viewing the inventory works fine, all items decay as suspected until one puts an item into the stash. The item decays compleatly after closing and reopening stash.
Is there some way to 'undecay' the item when droping into sector stash? 300% faster loading is ok, but 600% would be awesome
Moving the code from inside the loop of HandleSectorCooldownFunctions() to a seperate function, called internal_something(WORLDITEM* pwItem, INT32 minutes) which can take also negative minutes?
Does this work and do you know a good place for hook? is there another solution?
Report message to a moderator
|
Corporal
|
|
|
|
| Re: BUGZILLA report all bugs here![message #325244]
|
Mon, 16 September 2013 21:41
|
|
| Flugente |
 |
Messages:3507
Registered:April 2009
Location: Germany |
|
|
@Moa: Apart from loading times, what seems to be broken? I haven't observed broken quests/weird rotting corpses/odd smoke behaviour, is there something I'm missing? The only issue I'm aware is the added possibility to prohibt bloodcat assaults be prior opening of sector inventory, but so far, nobody seemingly found out about that^^
Note that we also load sector inventory for the 'MOVE ITEM' assignment, and for militia equipment. In both cases we don't need to see the stuff ingame, and aren't necessarily in sector (moving/reinforcing militia etc.)
MoaOption 1:
Introduce another variable inside SECTORINFO used for the last time (game minutes) we have updated all items for that sector.
This approach brakes savegame compatibility.
I actually prefer that one. When breaking, add a number of fillers, so we won't have to break again for a long time.
MoaOption 2:
Create a static array inside the decay handling function which holds the time at which all items in various sectors has been updated.
There is a problem here: one cant determine if a completly different savegame is loaded. To do make it work we need some global variable which tells us if our current save game is the one which matches our static times.
This also requires frequent recalculation of the static array after autosave, save and load. Bleh. That's just awful. How would you even do that in turnbased, where time is still?
MoaOption 3:
Dont update uiTimeCurrentSectorWasLastLoaded when showing items in sector inventory.
Instead one must add the delta decay to the items before showing them and remove the delta decay (or trash the itemlists) when closing the sector inventory.
Let the final modification be handled when player is actually entering the sector. Adding new variables to the OBJECTTYPE is bad and should imho be done only when everything else fails. This will bloat savegames and cause map incombatibilities.
MoaOption 4:
Dont update item decay when showing the sector inventory.
The player will see outdated values in DB and tooltips and needs to enter a sector to get the correct values. Let's call this the full-proof backup-plan.
MoaOption 5:
update decay as usual on enterSector and on showing the sector inventory by overwriting the uiTimeCurrentSectorWasLastLoaded.
This may brake some (potential) quest code, visual effects like smoke, rotting corpse ec.
They are actually broken allready, so we dont care!?
How are they broken?
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: BUGZILLA report all bugs here![message #325278]
|
Tue, 17 September 2013 15:02
|
|
| Kriplo |
 |
Messages:256
Registered:February 2008
Location: Zagreb - Croatia |
|
|
@Uriens
Some of shooting problems when turning from prone is fix from r6409, but notice problem when try autofire because somewhere after stance and turning change your settings is lost so he did just one autofire shoot, I will now look into that.
Also will check throwing stabbing and punching as notice AI not calculate precisely maybe our mercs neither.
From r6409 these fixings are applied into build:
Brief: //dnl ch70
- Some APs fixing for throwing knives and backpack, with doing some correction to my previous changes.
Details:
- Do some correction and missing parts to ch58 and ch69.
- Throwing knives will add you bonus for throwing knives to same target as was suppose from v1.12 but never works.
- Fix AI use gun calculation for throwing knives instead for throw.
- Fix incorrect showing and deducting APs when try to shoot from prone with backpack or throw from prone and crouch positions with turning in general.
- Fix cheating when sLastTarget is set just for raise gun in that direction, this was always done after you fire.
Brief: //dnl ch69
- Add alternative fix for CalcBestShot which should remove existing APs problems maybe even create AI deadlier then ever 
Details:
- Existing CalcBestShot simply became inadequate and buggier for so many add ons to game, so compiling with dnlCALCBESTSHOT is alternative option which calculate all turning, stance and raising gun cost for different stances and all available scopes, and after all hoping fix incorrect APs calculation as well, hitrate formula is adapt to 100AP system, also try to optimize a bit to get less AICalcChanceToHitGun calls and to use with different stance decisions.
- From ch58 aiming for burst and autofire was disabled as was causing invalid action handle due to incorrect APs calculation so from now aiming AI also use aiming before bursting.
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: BUGZILLA report all bugs here![message #325311]
|
Tue, 17 September 2013 21:06
|
|
| Kriplo |
|
Messages:256
Registered:February 2008
Location: Zagreb - Croatia |
|
|
Yes, this make things complicated.
Did reinforcement came when you turn off delay?
Because reinforcements would not came if no one call them (kill opposition silently) or in case that last of them is killed then they will be redirected if are in pending.
Below is current setting from gamesettings.cpp first number is default:
//dnl ch68 090913 Reinforcements minimum+random turn delay and minimum+random units enter for enemy and militia after they have been called
gGameExternalOptions.sMinDelayEnemyReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "MIN_DELAY_ENEMY_REINFORCEMENTS", 7, 0, 100);
gGameExternalOptions.sRndDelayEnemyReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "RND_DELAY_ENEMY_REINFORCEMENTS", 8, 0, 100);
gGameExternalOptions.sMinEnterEnemyReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "MIN_ENTER_ENEMY_REINFORCEMENTS", 6, 1, 64);
gGameExternalOptions.sRndEnterEnemyReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "RND_ENTER_ENEMY_REINFORCEMENTS", 6, 1, 64);
gGameExternalOptions.sMinDelayMilitiaReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "MIN_DELAY_MILITIA_REINFORCEMENTS", 10, 0, 100);
gGameExternalOptions.sRndDelayMilitiaReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "RND_DELAY_MILITIA_REINFORCEMENTS", 10, 0, 100);
gGameExternalOptions.sMinEnterMilitiaReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "MIN_ENTER_MILITIA_REINFORCEMENTS", 6, 1, 64);
gGameExternalOptions.sRndEnterMilitiaReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "RND_ENTER_MILITIA_REINFORCEMENTS", 4, 1, 64);
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
| Re: BUGZILLA report all bugs here![message #325319]
|
Tue, 17 September 2013 22:46
|
|
| Uriens |
|
Messages:345
Registered:July 2006 |
|
|
{7, 0, 100} I'm guessing that first number is default value, while the other 2 are min/max values allowed.
I have it set up like this:
MIN_DELAY_ENEMY_REINFORCEMENTS = 0
RND_DELAY_ENEMY_REINFORCEMENTS = 0
MIN_ENTER_ENEMY_REINFORCEMENTS = 64
RND_ENTER_ENEMY_REINFORCEMENTS = 64
MIN_DELAY_MILITIA_REINFORCEMENTS = 0
RND_DELAY_MILITIA_REINFORCEMENTS = 0
MIN_ENTER_MILITIA_REINFORCEMENTS = 64
RND_ENTER_MILITIA_REINFORCEMENTS = 64
When I used this value reinforcements came as they used to, as soon as they were called. It was counterattack event in Chitzena so about 96 enemies appeared and no stealth since it was day attack.
I'm guessing the problem is that default values are 7 turns min delay for enemy forces and 8 turns added random value to that so it can take up to 15 turns for enemy forces to appear. Similar for for militia where min is 10 and and adds random 10 value which can make them come after 20 turns.
If you set gGameExternalOptions.sMinDelayEnemyReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "MIN_DELAY_ENEMY_REINFORCEMENTS", 0, 0, 100
and
gGameExternalOptions.sMinDelayMilitiaReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "MIN_DELAY_MILITIA_REINFORCEMENTS", 0, 0, 100)
it should work as it used to in vanilla.
Btw, values of 7 or even 10 turns min delay are a bit excessive since by that time most of the fights are almost resolved. Kindda think it's best to have them set as they are in vanilla and have modders and players play with them.
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
|
|
| Re: BUGZILLA report all bugs here![message #325333]
|
Wed, 18 September 2013 10:00
|
|
| silversurfer |
 |
Messages:2791
Registered:May 2009 |
|
|
Flugente@silversurfer: I'm not familiar with JSDs... is that the view from above?
Yes. The picture shows a standing person cut into three parts - Level 1 (directly above ground = legs), Level 2 (torso) and Level 3 (head). These levels are also used to calculated height differences in CTH calculation (aiming upwards penalty).
When the person is crouched it only occupies level 1 and 2, when prone only level 1.
The different entries in one file show the different directions the object can be facing (NE, E, SE, S, SW, W, NW, N). That's why there are always 8 entries.
I have to agree with Kriplo that the prone structures are a bit wide sometimes and sometimes have a strange form but he also made them shorter and that is not correct. A merc doesn't shrink just because he is flat on the ground.
I will produce some new ones later today and let him decide if they better reflect the merc that we see in game.
Report message to a moderator
|
|
|
|
|
| Re: BUGZILLA report all bugs here![message #325339]
|
Wed, 18 September 2013 11:22
|
|
| Kriplo |
|
Messages:256
Registered:February 2008
Location: Zagreb - Croatia |
|
|
Excellent, EXECELENT !!!
This is not best topic, but stance JSD are huge bug, very annoying specially for prone, it's been long time ago from 1999 and we are still stuck with current crap.
We need to open debate and finally find replacement (remember Headrock also complains after NCTH released as primarily depend on them in compare of OCTH which use rolling dices and always hit [2,2] if rolled, other are accidental after angles adjustment for miss).
Let create several and vote for best suited which will go to trunk.
Here are links which decribe JSD, I use blackdragon's editor JSDEDIT v1.05
http://www.bears-pit.com/board/ubbthreads.php/topics/222117/JSD_file_structure_and_misc_in.html
http://www.ja-galaxy-forum.com/board/ubbthreads.php/topics/152657/1.html
Briefly, if remember correctly there are several JSD files, for sure knows cliffs and person stance are different files structure.
Ordinary structure splits one tile or cell in 5x5 array with 4 levels meaning in 3D we have 100 tiny structure hit locations. 1 tile is also cube with size (10x10x10), now height is bit complicated as defined by 256 units meaning 64 per level (see in los.h).
Mostly we like treat cell size in meters so our guy even if consist of one tile will be sized 2x2 meters and 2.5 meters tall 
So with such limitation is not easy to create best suitable but old ones should be replaced.
@silversurfer
1. heh, in standing put number 6 (0110) instead of 2 (0010) so persons get large had and torso, my fault want to simulate arms 
2. well, you cannot shoot through this person as integer number don't have holes this is just picture misguide as structure consist of (large) cubes.
4. agreed, plan to expand them but not beyond one tile, currently they spread in some directions to even three tiles, please put your suggestion we need to find solution
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
| Pages (42): [ 22 ] |
  |
Goto Forum:
Current Time: Sun Oct 13 01:12:09 GMT+3 2024
Total time taken to generate the page: 0.05645 seconds
|
Blog
Search
Help
Members
Register
Login
Home
