sprites: request to devs

[paradoxharbinger]

i'd forgotten about there being sprites in there that arent in the game. basing the db off of edis tables and then having them reference another table with the sprites in it sounds like a good plan. i cant remember how you handled special abilities (ie regenration). special consideration might have to be given to them since not every unit even has them let alone the same number of them.

[Gandalf Parker]

Keep in mind the headache that will be caused by units with more than one form. 2 forms, 3 forms, whats the max? 5?

[paradoxharbinger]

so we'll have an intermediary table between the actual units and the sprite table. this new table point to a unit and to any sprites associated with it. no problem.

[Edi]

Paradox, take a look at the Dom3DB. Once you take a look at the BaseU page and the glossary, the structure should be fairly clear for you. It'll be a lot easier to also plan the rest of the SQL DB that way.

The way regeneration works is a percentage of hit points, rounded up (so HP 10 is regen 1 and HP 11 is regen 2 etc). The percentages weren't too difficult to figure out from the units. Resistances, forge bonuses and other such are also percentages, which means they are between 0 and 1 after you strip the spreadsheet formatting out. All special abilities that are either on or off (like forest, mountain and swamp survival or flying) are 1 or 0.

Not quite all abilities are listed (such as Belial's corrupt commander, those would be in the Special column, which has all sorts of things that did not warrant their own category.

Awe values should default to -1 (unit does not have it) in the SQL DB and fear should default to null.

[paradoxharbinger]

from a database perspective, i dont like that baseu table WAAAAY too much wasted memory for the abilities, though i will admit that it would be fast to run a query against. that's often the trade off that has to made with this sort of stuff. i don't know how to make a decision on that trade off, as my experience is with a corporate database that is just in the other room, so speed is not something that i am too terribly concerned with when writing queries. if i were to design it myself, and didnt have the speed of the internet to factor in, i would probably do something similar to what i suggested for the sprites. one table has a row for each skill (this would allow for descriptions to be stored for each skill as well without taking up a horrendous amount of memory) and a second table is a map between units and the skills.

it could be queried like this
Code:

---

 



select UnitID

from tbUnit

	inner join tbUnitSkillMap

	on tbUnit.UnitID = tbUnitSkillMap.UnitID

	inner join tbSkill

	on tbUnitSkillMap.SkillID = tbSkill.SkillID

where SkillName = "some skill name here";

 

---

[Edi]

If you want to do it that way, is it possible to chop the BaseU table up to get the required tables? I can also ask my friend Kaljamaha to pitch in on this, he works with SQL stuff all the time, perhaps he could come up with some ideas.

[paradoxharbinger]

all im suggesting is that taking this sort of approach might save alot of space in a database, and since space = $ on the internets...

it probably would not be too difficult to extract the data we'd need to do it.

by all means, go ahead and talk to your friend, any extra incite in how we should proceed with this would be welcome