- class CItem
- {
- public:
- unsigned short GetPakHeader( );
- unsigned GetPakData( );
- unsigned GetVisInfo( );
- void Clear( );
- inline bool IsStackable()
- {
- return (itemtype >= 10) && (itemtype <= 13);
- };
- union
- {
- struct
- {
- BYTE itemtype;
- WORD itemnum;
- BYTE isCreated;
- };
- DWORD HEADER;
- };
- unsigned short gem;
- BYTE refine;
- short lifespan;
- UINT durability;
- bool socketed;
- bool appraised;
- unsigned short count;
- short stats;
- UINT durabLeft;
- int sp_value;
- int last_sp_value;
- UINT type;
- UINT raretype;
- short UStat[2]; //PY Unique stats that each item can have
- short UValue[2]; //PY The value in the unique stats
- };
L3nn0x wrote:Lol that should be the other way around actually
Anyway the pack macro is really only needed when dealing with raw buffer that you want to cast into a struct. Otherwise the best thing is just to let the compiler decide cause he's much smarter than us
I've seen this kind of error twice and it's really when you're messing around with raw pointers and uncontrolled buffer writes. And it's a real pain to debug because you have to check every new/malloc/realloc/delete/free and manually keep track of where and how much you write to those buffers... I'm thinking about raw heap allocated arrays mainly.
One last thing that hit me when reading your messages again Purple is that the best list container is std::list and not std::vector. And iterators are the perfect way to iterate over lists.
The problem with using std::list as opposed to std::vector is that there is no easy way to use random access in a list. It literally has to be iterated from the start every time.
That wouldn't be a problem really with visibility lists except for my rewritten (more efficient if it actually ever works) version where I delete elements that are no longer needed from the middle and push new ones onto the end making it a dynamically variable structure.
If we just keep doing it the old way then we build up a local list from the old one then delete the old one and copy the temporary one into it. That would work great for std::list
In a lot of places we aren't really using vectors the way they are designed to be used. You will barely find an 'erase' command anywhere in the whole server.
You are right that std::list would be better if that's all we ever do.
Having said that though, I think the problem isn't with the vector at all, I'm pretty sure it's a memory management issue related to the inventory structure. Every time I find a problem it seems to be that an inventory item has been written over a bit of memory already allocated to another structure.
These structures are all arrays which are defined at compile time so i need to be looking for a sub-structure that is dynamically modified at run time. I'm betting that when I go through it with a fine tooth comb I'll find something like a vector inside the structure that's throwing out memory allocation on a big scale. Since Vectors guarantee a contiguous block of memory this would make sense. A list, on the other hand would just grab a free space somewhere and set a pointer to it so the same problem wouldn't be likely to occur.