"Raw Data Ethics" battle ;)

[John Adams]

I am waging a war within myself over the semantics of "Raw Data", maybe you can help.

Currently, PacketParser will identify a spawn based on various unique properties. Name, class, race, gender, and more recently, individual appearances (eye color, hair type, etc). This makes for a LOT of raw spawns that previously did not exist. Ie., back in 2008 before LE added Appearances comparisons for me, we would parse maybe 30,000 spawns. Now, because each eye shape tweak is considered unique, we will parse over 60,000 spawns - for example.

What I have done with Parser currently was modify it so while it is detecting the uniqueness of a spawn, instead of inserting a NEW spawn for an eye shape tweak, it flags the spawns "randomize eye_type" signed values and saves that to the raw_spawn_info record instead... thus cutting down tremendously on the number of Raw Spawns to -populate.

However, in looking over the new dataset, while it looks exciting and clean, I am now struggling with the original premise of "raw data" in that now, there will never be a source of TRULY raw spawned info to refer to.


So my internal debate, that i bring to you to help me solve (quickly) is, do I really give a shit? This will cut down on Hours, Weeks, maybe even Months of effort to consolidate spawns in our database. Running -populate will put spawns into the dev database already merged, randomized, and ready to pop without any additional effort. Should any data be questionable, we would merely need to re-parse the log that spawn came from using an older parser (or I will add -params to allow it with the current).

I think you all have helped me with my dilemma immensely! Thank you! hahaha... no seriously, if you have any opinions, shout em out before I get too much further into this.

Thanks

[John Adams]

Examples --

Running Normally, I will get these entries for a Bloodskull Lumberjack:

normal.jpg

Note, of all these UNIQUE spawn IDs, the only difference (besides level) is their appearances (colors, shape of features)


Running with the new -consolidate switch:

consolidate.jpg

Level range is set in RAW data, and a Randomize has been calculated before you even populate your world.


Do you think this is a better way? Please let me know, before I start parsing the whole pile over again
PS: Example of parser console output:

output.jpg

[xinux]

do I really give a shit?

My personal opinion is no running with the consolidate switch to me look's like would save a ton of time and do you really need to populate with all those raw spawns when the randomized value will work just fine.

[ilythor]

Randomize all the way!

From a player's perspective, is it possible that we would get 12+ of an identical mob populating an area? (If there are 12 spawns, or a group encounter etc. I am merely asking about appearances)

Nvm, I just realized we're playing an MMO and all the mobs look the same.

[John Adams]

There is another ethics battle I have waged with myself, and due to not much interest in how I do things from the rest of you I have made a command decision myself.

Previously, I was taking all "common throughout the world" spawns and making then generic, so to speak. Like, a "?" spawn would be spawn_id 100, period. It would appear in any zone, but be called spawn_id 100.

After a fiasco trying to deal with ground spawns that have different results, I've decided saving 1000 DB rows is not really worth the headache of trying to remember "Where the hell did I put that Creature Den (model 2939) anyway? Oh yeah it's a common spawn, at ID 502".

Screw that. We'll see how this looks, and make another decision later if it looks too dirty.

[Scatman]

So you're just letting them become whatever ID they are given?

[John Adams]

Yes. The way we have it in Milestone 1 is cool, but just too much effort to maintain (imo). I'll take 2nd opinions, if there are any. Pop hasn't begun yet, but working out the final issues with my scripts tonight.