DBEditor:MigrateZone - Revision history

John adams at 23:00, 12 March 2013

2013-03-12T23:00:37Z

John adams: /* Migrate All */

2013-03-12T22:56:52Z

‎Migrate All

John adams: /* The Grid */

2013-03-12T22:54:46Z

‎The Grid

John adams at 03:13, 11 February 2012

2012-02-11T03:13:04Z

John adams at 02:58, 11 February 2012

2012-02-11T02:58:36Z

John adams at 02:58, 11 February 2012

2012-02-11T02:58:04Z

John adams: Created page with "'''DBEditor - Migrate Zone''' The Migrate Zone script is meant as a ''controlled'' method of populating a zone, versus throwing everything the Parser has into it. For instance i..."

2012-02-11T02:17:27Z

Created page with "'''DBEditor - Migrate Zone''' The Migrate Zone script is meant as a ''controlled'' method of populating a zone, versus throwing everything the Parser has into it. For instance i..."

New page

'''DBEditor - Migrate Zone'''

The Migrate Zone script is meant as a ''controlled'' method of populating a zone, versus throwing everything the Parser has into it. For instance if we spawned our world using just PacketParser -populate eq2world, the outcome might look something like this --

[[File:DBE_Admin4a.jpg|500px]]

Yowza, huh? Besides there being thousands of unnecessary spawns of a single type, there are probably thousands of '''every''' type, because the Collector is not picky about what it collects. This is what the tainted sapswill invaders records look like in the Migrate Zone script, before they are popped --

[[File:DBE_Admin4b.jpg|500px]]

If you think that's ugly, you should see Antonica... But anyway, we chose to pop our zones in a more controlled manner that does not end up with us crashing our clients, or unable to maneuver the zone at 0fps.

== Spawn This ==
Instead, we'll select individual Sapswills from that god-awful list and pop only the dozen or so we need, basesd on their x,y,z coordinates. You do not have to be precise, because you can pick them up and move them once they are in-game. For our example, we'll pop just 1 lonely sapswill.

[[File:DBE_Admin4c.jpg|500px]]

Here, we're picking a single spawn location that is near where our character is standing in the zone (I did a /loc, then searched for nearby coordinates). Since I just want this ONE SINGLE record, I will click "Spawn This", and the script will insert a new spawn record (if it doesn't already exist), and place the spawn at the location defined.

Doing a quick
/reload spawns
shows us our results.

[[File:DBE_Admin4d.jpg|500px]]

Now isn't that much nicer?

== Spawn These ==
The '''Spawn These'''option merely takes the current spawn ID and every one of it's spawn placements, and loops through the whole batch spawning them all just as they were in the Raw Data. This is helpful if you know there are minimal duplicates in your spawn (like objects, doors, signs, etc) and you just want to pop them as-is.

I usually use Spawn These for all Groundspawns, because I like to see patterns in how they are spawning in order to make [[Commands:SpawnTemplates|Spawn Templates]] out of them to make my job easier.

← Older revision		Revision as of 23:00, 12 March 2013
Line 126:		Line 126:

	When everything inserted into the destination DB without error, the last thing the script does is reach back into the RAW database and mark the spawn as "processed", with the value of "1" in the spawn.processed and spawn_location_placement.processed fields.		When everything inserted into the destination DB without error, the last thing the script does is reach back into the RAW database and mark the spawn as "processed", with the value of "1" in the spawn.processed and spawn_location_placement.processed fields.
		+
		+
		+	== Spawn Group IDs ==
		+	Spawn "groups" are those spawns you target in game and more than 1 NPC will light up, attack, etc. Parser does a pretty good job of determining spawns that are in groups when the collector runs passed them. There are many cases where it does not, however - so this is not a 100% fool-proof option. Some editing will need to be done.
		+
		+
		+	Because of this, when you Migrate a spawn to the destination DB, if it is part of a spawn group, then all of it's spawn "buddies" get migrated and processed as well. Keep this in mind if you are Spawning an NPC that has a group_id value. NEW In the editor, you should see similarly colored backgrounds for matching spawn groups for easier identification.
		+

@@ Line 104: / Line 104: @@
 == Migrate All ==
-This is not currently an option, due to the sheer volume of spawns we have per zone, so this option does nothing anymore. I leave it in for local testing when I am in a hurry :)
+Migrate All has recently been put back in, because some zones were collected "clean" enough to warrant populating everything at once. After you pick the zone, pick the spawn type to populate. If the list looks nice and clean, click Migrate All and all those spawn (types) will be send to the destination DB.
 == The Process ==

@@ Line 33: / Line 33: @@
   Z                 : Z coordinate
   H                 : Heading
-  group_id          : ''unused''
+  group_id          : whether or not the spawn is ''grouped'' with another spawn - careful!!!
   Spawn This button : Spawn this ONE placement for this one spawnID
   Hide This button  : Hide this ONE placement for this one spawnID
@@ Line 44: / Line 44: @@
 None of these should matter to choosing what to spawn, however.
 == The Messy Way ==

@@ Line 12: / Line 12: @@
 . The Zone Selector
 . The Spawn "Type" Selector (NPC, Object, Widget, Sign, Groundspawn)
-. Single-spawn filter ''Optional''
+. Single-spawn filter ''optional''
-. Migrate the entire zone as-is '''Disabled'''
+. Migrate the entire zone as-is ''disabled''
 . Show/Hide the Hidden spawns/locations

← Older revision		Revision as of 02:58, 11 February 2012
Line 38:		Line 38:


−	~~===~~ Spawn Types ~~===~~	+	'''Spawn Types'''
		+
	The grid data changes slightly when you select different Spawn Types to migrate. The changes are minor, so I won't get into much detail. An example is that for NPCs, we show the group_id (which is no longer needed anyway). For Objects and Groundspawns, we show the visual_state value. And for Signs and Widgets, the widget_id.		The grid data changes slightly when you select different Spawn Types to migrate. The changes are minor, so I won't get into much detail. An example is that for NPCs, we show the group_id (which is no longer needed anyway). For Objects and Groundspawns, we show the visual_state value. And for Signs and Widgets, the widget_id.

@@ Line 1: / Line 1: @@
 '''DBEditor - Migrate Zone'''
-The Migrate Zone script is meant as a ''controlled'' method of populating a zone, versus throwing everything the Parser has into it. For instance if we spawned our world using just PacketParser -populate eq2world, the outcome might look something like this --
+The Migrate Zone script is meant as a ''controlled'' method of populating a zone, versus throwing everything the Parser has into it.
 [[File:DBE_Admin4a.jpg|500px]]
-Yowza, huh? Besides there being thousands of unnecessary spawns of a single type, there are probably thousands of '''every''' type, because the Collector is not picky about what it collects. This is what the tainted sapswill invaders records look like in the Migrate Zone script, before they are popped --
 [[File:DBE_Admin4b.jpg|500px]]
-If you think that's ugly, you should see Antonica... But anyway, we chose to pop our zones in a more controlled manner that does not end up with us crashing our clients, or unable to maneuver the zone at 0fps.
+If you think that's ugly, you should see Antonica...
@@ Line 36: / Line 85: @@
 I usually use Spawn These for all Groundspawns, because I like to see patterns in how they are spawning in order to make [[Commands:SpawnTemplates|Spawn Templates]] out of them to make my job easier.