Visual States table ain't right!

[ZexisStryfe]

Hey John,

Something isn't right with the visual states table in the database. I noticed that well over 50% of the visual states have the wrong IDs compared to the App_states.dat file. The numbering is correct up until 48397 and then for some reason it jumps to 99993. I do believe with incorrect ids we won't be able to call these new visual states from the client, correct?

I also noticed the table structs are totally different in on the Tess dev server are different than the production ones. In prod there is only id and name. In dev there is id, visual_state_id and name. Any reason why?

[John Adams]

The reason for the different table structures is that every table should have a unique key (primary key) and not have that key interfere with foreign keys or other "id"s such as visual_state_id. For example, when I try to update visual_states and the PK is on the id for the visual state itself, I get errors, or the PKs wind up incrementing to invalid ranges. Regardless of the 100 work arounds I could have done to avoid this, I have changed MY local DB to be "correct", and tried to update this for everyone else but could not figure out how LE delivers these 3 tables of static data. Which is also why the IDs are missing.

Since LE is not coming around anymore at all, I may just need to stop using the DB Update service and deliver SQL files like everyone else does via SVN. Don't like the idea, but we might have had to do that anyway once Content starts getting released. Too much data.

[ZexisStryfe]

So, if I source in the visual tables data straight from the app_states.dat file I should be fine, correct?

[John Adams]

Yes, that's usually all I do, too.

Code: Select all

TRUNCATE TABLE `appearances`; 

then import the delimited text file.

[ZexisStryfe]

I am talking visual states table, but same diff

[John Adams]

I wish you'd make up your mind what I am talking about. Appearances, visuals, blah.

Btw, I would think Appearances would be in more dire need than states... let me know when you figure out how to get it to work

[ZexisStryfe]

I'll hook you up with up to date appearance and visual states tables if you (or someone!) can describe to me the difference between visual_state, initial_state, action_state and activity_status (I got a grasp on mood_state). Its really starting to annoy me.. that and many animations only work in one of the aformentioned state fields.

Yay for extortion!

[John Adams]

I know how to get data out of the assets too, silly man. I just like when you give me pretty spreadsheets of model types, so I keep you around

I'll have to get some sleep and thing about those states. I remember something about them, but not much. Like making something "dead" or "tainted" is an action state, not a visual state, or vice versa... Go check out our Queen's Colony data, the dead/tainted guys. Might give you something to do while I sleep.

[ZexisStryfe]

Actually, the model lists are pretty much up to date. They actually encompass more models than the current client has access to. I will do all the new ones when we get a client bump since at this point there is no need to catalog models no one can use.

I am however thinking about doing a catalog of visual states (the descriptors in the app_states.dat file suck for actually trying to figure out what is what), however that will be rediculous tough since it will be a trial and error type of thing. Most visual states only work in one of the assorted state fields, hence my questions!

[ZexisStryfe]

Hey John, In my poking around the Tess data I noticed most of your mobs have initial_state entries equal to either 16512 or 16516. In the app_states.dat file, this visual state doesn't exist...

[John Adams]

That's the data that comes straight from packet collects. Part of what we haven't really figured out yet, or at least I myself do not know.

Like I said, the initial_state of "a dead deer" is 228. I also think when a Statue is speaking, throwing it's arms about, that might have a different action_state. That's the extent of my knowledge of what makes each of those states somehow different.

Maybe Scat knows more.

[John Adams]

Ok, I think I have sorted out what was wrong with visual_states. This requires a DB change, which will come to your servers after tonights SVN update (rev 415). However, due to how our DB update services currently work, anyone connecting a server today will likely get a madhouse full of SQL update errors Nothing I can do about that, since Visual States is just too big to work with properly.

On top of that, due to some odd bug in the DB Update service previously unknown to us, it seems to set the download_version BEFORE the download is considered successful - not sure what's up with that. So, what you will likely need to do after tonight is go to your `table_versions` table, and run this query manually:

Code: Select all

DELETE FROM table_versions WHERE `name` = 'visual_states';

Then, connect to LS using the latest public SVN exe (415). This will reset your visual_states to a fresh state.


Alternatively, here is a SQL dump that should get you current.