Give Feedback
About this image
if you're consider yourself a Good modder
you should aware of this issue
for more information see this link :
http://forums.bethsoft.com/topic/1530052-rel-oblivion-script-extender-obse-0021/?p=25201540
Conclusion : storing any array_var in Token is RISKY
the can still exist in physical obse save game,
even after the token is gone. There is THREE way to free this bloat, first by deactive the ESP --- save your game --- activate again that ESP. Second method is, by using Drop command. somehow if player drop the token all of variable attached to it will be gone. but hence, another problem arise, Drop command is create another Dynamic Reference to the world. THAT is another story of savegame bloat. Third method is the most efficient and effective, before you remove the token you should clear the array_var DONE ! then you can safely remove it...
NOTE : to those who don't know savegame bloat, you know ... while I'm testing this bloat. can you guess how long I save the game ?
IT'S 40 SECONDS !!
BEFORE I CAN MOVE AGAIN !!
soooo ... get what I mean ? you'll encounter 'saving takes forever' issue if you installed many baddie mod, especially mod that using CloneForm a bit much
as modder it's our resposibility to give user peace of mind
one more thing, DON'T TRUST Persistent Object to store your variables ... I've seen it, the persistent object can be deleted by using command DeleteReference
that syntax is powerful enough to delete even the Quest item or Quest actor. I've tested it myself
6 comments
1) We have an object with an associated script. In that script we allocate some memory and store it in, say, array_var bloat. The savegame is BIG. We expect that. We also expect that it takes a rather long time to save/load.
2) Now we want to get rid of the object. In order to do this we delete the array first:
Ar_Erase bloat
Then we remove the object from the game. And the savegame is still BIG.
Is this what you said? That is bad if it is so.
EDIT: It seems it isn't. Ar_Erase comes, and does it's job, whenever you call. *big sigh of relieve*
--
On the other hand, if you put the following script on your favourite shoes, then Ar_Erase works (save, when shoes on ==> BIG; save, when barefoot ==> back to normal).
scn bloatOS
array_var bloat
long i
begin onEquip
let bloat := Ar_Construct "Array"
set i to 1000000
while i > 0
Ar_Append bloat, i
set i to i - 1
loop
printc "onEquip"
end
begin onUnequip
Ar_Erase bloat
printc "onUnequip"
end
Heh, by the way, back in the bad old times I managed to assemble a savegame of more than 50MB. :^)
you should visit this
http://forums.bethsoft.com/topic/1530052-rel-oblivion-script-extender-obse-0021/
quote : " I managed to assemble a savegame of more than 50MB "
A : wow ... that is like hell, how do you even keep playing that savegame LOL
if you use kuertee auto Savegame I am pretty sure you'll be annoyed
or using similar autosave with smaller interval (like 1 minute or 2)
quote : " then Ar_Erase works "
A : hey ... not all modder do this man. and that ar_Erase can't be called properly if that item removed either by cell reset routine or deleted by DeleteReferece / RemoveMe / actor.RemoveItem itemRef
up to this day, I am PRETTY SURE that 95% or less mods is HAVE BLOAT ISSUE
including my mods (yeah ... it's breaking sad news)
Conclusion : I want to remind OBSE team and make them to handle this issue
so I hope in the future
we can have maybe 2 MB at MAX even with all of bloated mod in our mod list
I want this ... I think this can be achieved,
ah this I dont understand
quote : " say, array_var bloat. The savegame is BIG. We expect that. "
>>> what do you me you expect bloat, how can you say that lol
no user want to have bloated mod from start
In my example, I have got the shoes with my 1.000.000 handcrafted numbers equipped. I want the data back on reload. Therefore they have to be stored somewhere -- in the savegame, that is. Don't you call it "bloat", no sir!, just because I've named the array_var BLOAT.
'Bloat' is junk, left over by buggy code, as opposed to 'data', that you expect to be in place later in the game, after a reload, for example.
--
Sure, with OBSE, the developer has to keep manual memory managament in mind. If OBSE 22 wants to do automatic MM all over the place, they should really call it OBSE 1e22. They have my blessings.
--
Thank you for your expression of sympathy concerning my 50MB savegame. After its demise I turned to Wrye Bash -- so, no regrets. ^^
now I understand...
lol
if I were you
I think I will go with 1 million persistent reference
I can use TES 4 Edit script
to generate 1 million persistent reference with ease. so you want 2 million ? 5 million ? noprob lol
then use this powerful script
http://cs.elderscrolls.com/index.php?title=SetBaseForm
or you can set each shoes mesh and stat and store it in array
and I believe my savegame is less than 2 MB, even if I have 1 million different shoes
am pretty sure of it
since the limit to base object in ESP is FFFFFF = 16.777.215
Only one pair of shoes, but it has a script that has a variable that points to an array that has 1.000.000 numbers assembled in an array, and this results in a ~16MB bigger savegame.
I destruct the array, and the ~16MB are gone. That's to say, No "bloat". It's a huge savegame for a huge amount of data. (Or, barefoot, a small savegame for almost no data.)
1.000.000 32-bit (4-byte) numbers take only 4MB (of uncompressed) storage. But remember: OBSE-Array's versatility comes at a cost. I have no idea about the underlying data structure. If it was a doubly linked list, however, one would need -- per data item, in this case a 32bit number -- a PREV pointer, a NEXT pointer, and a DATA pointer (32bit each). Sums up to 16MB.
In real life, savegame bloat happens incrementally. 10kb here, 1kb there. Do bugs appear in mods, or in software in general? Sure. Statistically, in professional context, every 1000th line is buggy (and it's not unlikely that the line in question has something to do with memory management).
Expect the worst. ^_^
well done
you've describe it wonderfully