llde / xOBSE

Oblivion Script extender source
243 stars 35 forks source link

xOBSE 22.10beta causes console spam for Lovers with PK script xx0090ea #220

Closed Hotdog3223 closed 10 months ago

Hotdog3223 commented 10 months ago

This is a script that just does a simple check to see if OBSE is actually running or not.

Deleting the script itself in xEdit stops the spam. Older versions of xOBSE did not have this spam problem.

llde commented 10 months ago

Revert. The beta has some issues.

calebtt commented 10 months ago

What is it spamming?

Hotdog3223 commented 10 months ago

It just keeps spamming the script id & null, it doesn't actually have any impact on the mod's functionality but it spams the console with that over and over endlessly

llde commented 10 months ago

Yeah I think I mistook an hook for another in 5c31c42

BTW @calebtt Seems that there is an issue for 0d71ba4 that can cause corruption and exploding cosaves.

llde commented 10 months ago

@calebtt Seems that using std::array<char,dim> instead of a direct array cause this corruption. Do you have any idea why?

EDIT: IT's actually a bit different: SetElementString(arrayID, newKey, std::string(buffer.cbegin(), buffer.cend())); if I create the std::string using an iterator ()either const cbegin/cend or normal begin/end) the resulting cosave is partially corrupted and explode in size. If I create the string using the std::Array data() inner pointer then it's correct and with the right size (940KB (ok) vs 14 MB (wrong)) Do you have an idea on what's is going wrong? @calebtt I tried to print the string content but they are equals

llde commented 10 months ago

Actually in this case it seems the script have an issue (maybe it wasn't recompiled properly?) as even in MessageLogger with 22.9 I have 2023/09/15 10:12:42 [005170B1] [WARNING] Unable to find function definition for command 0 in script 'xLoversCheckObse2QuestScript'.

Now the last beta have actually an issue where the message buffer wasn't saved properly or was corrupted, causing the message to be strange

calebtt commented 10 months ago

I'll try to look into that

calebtt commented 10 months ago

@calebtt Seems that using std::array<char,dim> instead of a direct array cause this corruption. Do you have any idea why?

EDIT: IT's actually a bit different: SetElementString(arrayID, newKey, std::string(buffer.cbegin(), buffer.cend())); if I create the std::string using an iterator ()either const cbegin/cend or normal begin/end) the resulting cosave is partially corrupted and explode in size. If I create the string using the std::Array data() inner pointer then it's correct and with the right size (940KB (ok) vs 14 MB (wrong)) Do you have an idea on what's is going wrong? @calebtt I tried to print the string content but they are equals

iterators would iterate over the entire array, I think using .data works because you have it null padded after the string's contents. As long as you initialize the array to zero.

Oh I see we're actually setting a 0 value at the string's length.

calebtt commented 10 months ago

Instead of the iterators I think it should be .data()