FarCry0177 image

www.youtube.com/watch?v=vflciGcqHtY&feature=youtu.be
Still not dead :D
sorry for showing this stuff still in a developer map / environment.
Working since several weeks everyday 4-10 hours on the mod. and ONLY on the attachements, Inventory menu and fastload integration.

i stumbled over some very unexpected Problems, and every new Problem (...bug) which i solve, brings up atleast 2-3 new problems or bugs. one example:
all what you see in the Inventory menu, is not real: the rotating objects are real objects, but once attached to the playerpuppet, they are ...gone... the attachements on the puppet and on the player (the model in Inventory is not the player), are loaded to that puppet as "child" models into seperate slots. if i draw them back to the backpack slots, i have to create on the fly the new rotating models.
but now the new problem comes:
if i now draw them to the dropzone, and leave, the attachements will be spawned new as attachements, filled with the stored values / properties and all is fine. if i then save the game and do a fastload, the items will be loaded, but mostly stay invisible and i dont find the trick to awake them.
i have created special routines which reads out the entity which is in front of crosshair, and the invisible ones are even not recognized by
cryengine itself. so far so buggy as expected if i would have done a mistake, but is not:
if i now leave that area, lets say more than 200 meters and come back, the items are then correct initialized, visible and can be readen out with that
crosshairtool.
the (not so) funny thing: the leave area and come back works only if the devkid entity streamer is active. I (!!!) have totally programmed this and i
totally know what this routine do, basically unhide and rephysicalize. and ofcourse i do all this stuff on that fastloaded attachements, but ... no reaction...
this type of problems appears actually since weeks, every day, together with the bugfix vs newbugs amount i mentioned above.
but i come closer to an end every day.
the hardest thing i have solved today, was a also unexpected problem: during fastload i step trough the ID's of existing entities in the map and load then
for this things each the stored data from (fast)savefile.
buuuuuuuuuuuuuut: i stumbled over a ugly thing: the attachementdrops which are in the savegame, does not exist in a fresh started map, so i spawn them
on the fly during fastload. sounds like a plan, ey? buuuut, not so fast little padawan: unfortunately cryengine gives "random" ID numbers to fresh spawned
items, which always start with 65200. so, the chance, that in the savefile a entity with the same ID is existing, was even on that little map 100% .
that means the new on the fly spawned attachement loads then the stuff from an total different entity, lets say a door or a fuse (ok, it was a fuse, because they are also spawned on the fly).
so i have written today very complicated routines, which first step trough the savefile and collect all ID's into a table. then i do the spawn of the attachement and then i look which ID the new spawned attachement have: if this ID is in the savefile table, i have to spawn again the same attachement, delete then
the previous one an compare it again with the savefile ID table. and then do this in a loop until i have a new, origin entity with new ID.
this **** took about 19 hours (find and track the problem ~12 hours, code the routine 2 hours an 5 hours to get this bugree running).
and this is only ONE problem / bug which appears out from nothing and unexpected.
i stay tuned ...^^