grids
why are they limited to 50 waypoints ?
is it possible to create for example 2 grid tables one called "grid" with id, type and type2 another called "waypoints" with grid_id, number, x, y, z, heading ? =) |
this sounds good idea : more functionnality as no limit to WP count, and space saved as empty WP account for nothing. Using correct indexes could keep overhead to a minimum.
Also, it relieves the error prone 'what value for an empty waypoint ? is it NULL, " ", 0 ?' unfortunatly, this can not be done without changing the code AFAIK, as you cant retrieve multiple lines data across a single line, what would leave the code untouched (but i may need SQL lessons) example using a wp table : create table wp (grid_id int(11),number int(4), x, float, y float, z float); insert into wp values (1, 1, 7,8, 34.5, -5.0); insert into wp values (1, 1, 8,9, 21.5, -5.1); Code:
bool Database::GetWaypoints(int16 grid, int8 num, char* data) { |
does ID's have a max value to make grids working ? i tried 107042 for a grid it didn't work, i tried 50 for the same grid it worked =(
|
there are several max defines in the EMuShareMem stuff, but none seems related to grids, at first glance.
The field size spawn2.gridpath and grid.id in the DB is int(10), so there should be no pb. Is it this ID, or another ID ? Or maybe, simply in the spawn command: Code:
else if (!strcmp(command,"spawn")) { |
it's the int16 that limits it =(
i have other suggestions =) 2 tables then : table : grid fields : zone, id, type, type2 table : waypoints fields : grid_id, number, x, y, z, heading, pause table : spawn2 fields : need to add a starting_waypoint, and path_reverse at this moment waypoints are limited to 50, with a waypoints table they won't be limited waypoints have no heading data =( with zone, we will be able to start grids ids at 1 for each zone ( i don't know if it's better or not than autoincrements ) with starting_waypoint, we'll then be able to share grids with different monsters and they'll start at different grid waypoints ( no more trains ! =) path_reverse would be nice if we want to make monsters start their patrol in different directions =) |
k, don't blame me, i'm just playing the bad guy here
Quote:
Quote:
Code:
mysql> select count(distinct spawngroupID) as nombre, pathgrid from spawn2 group by pathgrid order by nombre desc limit 100; reverse_path and starting_waypoint are not usefull if pathgrid is unique to each mob, else anywway starting_waypoint must be close to spawn point, so that's little change if any, and reverse_order is much like the patrol wandering option Sorry, that was the bad guy part. :oops: On the normal guy part : - i'd like to know of efficiency on real servers for the normalized (duno if it's the english word, that means table splitted) version of pathgrid. This should be little overhead (grids are loaded boot time, or spawn time, aren't they ?). If devs think this can be interesting, we could work on spawn 2 functions. - i believe this is a good idea. - Let's go a bit further : waypoints are 'you can be here' points, and path ordering is 'there is direct way from wp N to wp N+1'. One could define wp a b c d e f and say : grid #1 is 1:a 2:b 3:e 4:f grid #2 is 1:d 2:c and even : grid #3=#1 then #2 - there have been threads about wp design (i came across an old one like Nov 2002 today) dealing with grids. Recently, we discussed the matter of mobs fleeing, still to be done. Maybe changes to the grid system should now start thinking of the map and its usages (wandering, but also fleeing, whatever ...) imho - perf can be adressed fairly easily, so build clean. - there should be no limit to grid number - there should be no limit to wp in a grid - the easier for the world builder to define a grid, the better. |
for shared grids
if you look carefully at eqlive pathing, you'll see that a lot of monsters are sharing exactly the same path if you didn't find shared grids in your database it's because the actual system make us to create a grid for each monster else monsters will roam like trains =) for starting position it's needed when grids are shared because a monster won't always spawn close to the waypoint we want him to go at first reverse path is needed too for shared grids if the 2 monsters spawn at the 2 ends of the path, patrol will do its job, but if the 2 monsters spawn in the middle of the path and we want them to go in different directions and do a cycle it could be usefull ? =) |
That was clear from your post, and i didn't disagree.
What i meant is that pathing is a solution for mob displacement, that we experience the limits of. Let's change it, fine. So we must try to think of everything involved. http://www.eqemulator.net/forums/vie...highlight=path http://www.eqemulator.net/forums/vie...highlight=path http://www.eqemulator.net/forums/vie...highlight=path to mention only a few threads already discussed. *** added *** i was curious about tweaking the code. Below are changes according to the discussion. It may work (i need to sleep now, so just made the changes, compiled, but no testing whatsoever, not even running). It may not work. - did not update the commands, you must edit the DB by hand. - no starting point stuff. There is still something i can't figure out : how does the mob get from spawn point to the first waypoint ? There more to discuss about this. below are the diffs as of feb 23 cvs Code:
--- ./../common/_database.cpp 2004-02-28 04:51:14.000000000 +0000 Code:
--- _MobAI.cpp 2004-02-28 04:51:44.000000000 +0000 Code:
-- create waypoints table If you want to give it a try... |
any news about grids ?
=) |
All times are GMT -4. The time now is 02:05 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.