UFO: Alien Invasion Issue Tracker
UFO: Alien Invasion
Go to the previous open issue
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
icon_project.png UFO: Alien Invasion / Closed Bug report #1957 routing-CSV-files differ in size
Go to the next issue (open or closed)
Go to the next open issue
This issue has been closed with status "Closed" and resolution "Not determined".
Issue basics
  • Type of issue
    Bug report
  • Category
    Battlescape
  • Targetted for
    Not determined
  • Status
    Closed
  • Priority
    3. Normal
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (0)
There are no items
People involved
Times and dates
  • Posted at
  • Last updated
  • Estimated time
    Not estimated
Issue details
  • Resolution
    Not determined
  • Reproducability
    Not determined
  • Severity
    Not determined
  • Complexity
    Not determined
  • Platform
    Not determined
  • Architecture
    Not determined
Attachments (0)
There is nothing attached to this issue
Duplicate issues (0)
This issue does not have any duplicates
Description
[http://sourceforge.net/p/ufoai/bugs/1957 Item 1957] imported from sourceforge.net tracker on 2013-01-28 19:14:56

For a given map, the csv-files created by ufo2map and the debug_croute cmd comprise slightly different xy-ranges.
In order to compare the csvs for the excavation map with WinMerge, I had to adjust them a bit:

void Grid_DumpClientRoutes_f (void)
{
ipos3_t wpMins, wpMaxs;
VecToPos(map_min, wpMins);
VecToPos(map_max, wpMaxs);
wpMins[0] += 1;
wpMins[1] += 1;
wpMaxs[0] -= 3;
wpMaxs[1] -= 3;
RT_WriteCSVFiles(clMap, "ufoaiclient", wpMins, wpMaxs);
}

Of course, this is not a fix, just a workaround. But it illustrates that ufo and ufo2map have a different 'understanding' of the mins and maxs, which is potentially dangerous.

map_min and map_max are calculated in RT_GetMapSize() with a long series of boxtraces. Right before I started to look for a bug in that function, a question came to my mind:
We have the mins and maxs for every bsp (at the very beginning of the routing table) we add to a map, and we know the offset where we add it. With this data we could easily calculate the new map_mins and _maxs with a few additions.
Should be more exact and much faster.

Or did I miss something ?
===== Comments Ported from Sourceforge =====

====== wilminator (2009-01-01 18:07:24) ======

As the maps are loaded into ufo, the mins and maxs are buffered, increasing the size of the extents. This isn't bad per se- it is only used for optimizing functions from what I've seen, and if the functions scan where there is nothing, it does not hurt anything.
====== wilminator (2009-01-01 18:08:26) ======

If you want me to, I can look into not buffering the extents of the map, but it would be a low priority for now. Let me know.
====== aduke1 (2009-01-01 22:49:40) ======

As your recent fix seems to have blown away most - if not all - of the pathfinding problems with the exeption of stairs, let's hope we don't need the csv files anymore :)

But what do think of the suggested concept to simply calculate the new extents as
...
MapMaxs[i] = (TileMaxs[i] > MapMaxs[i]) ? TileMaxs[i] : MapMaxs[i];
...
instead of doing some 16,000 boxtraces in the void, however cheap they may be cpu-wise ?

====== wilminator (2009-05-18 03:30:57) ======

Closing because 1) it is an old ticket, and 2) the methods used to determine map bounds differ between ufo2map and ufo. I do agree that this should be looked into further, but imho is not critical.
Steps to reproduce this issue
Nothing entered.
Todos (0 / 0)
Issue created
footer_logo.png The Bug Genie 4.3.1 | Support | Feedback spinning_16.gif