Depth Filtering - no more negative numbers?

[curio]

My current SEQ wont take depth filtering numbers below zero anymore. The UI wont accept a number below 5. Editing the XML file lets me put in a negative number, but the UI forces it back to 5s.

Negative depth filternig is important in places like CoD, where most of the zone exists "below" the 0 depth. If you're doing Bertox ring, the depth settings I used to use were something like -500 -200.

Anyone else seeing this?

Once I find the file that controls this, I'll look for the CVSblame that changed that line. :)

[showeqnewb]

Yeah, I am seriously missing Depth filtering :)

http://seq.sourceforge.net/forums/showthread.php?s=&threadid=3657

[curio]

Well i found where the UI is locking down the depth filtering to positive numbers. That was easy to change.



diff -r1.37 map.cpp
4633c4633
< m_head = new QSpinBox(5, 3000, 10, m_depthControlBox);
---
> m_head = new QSpinBox(-3000, 3000, 10, m_depthControlBox);
4637c4637
< m_floor = new QSpinBox(5, 3000, 10, m_depthControlBox);
---
> m_floor = new QSpinBox(-3000, 3000, 10, m_depthControlBox);


Or for those who want it in patch format.

[LordCrush]

Ty =)

[showeqnewb]

I am hoping I am making sense out of this. Do I turn the two 5's into -3000's?

[suseuser7341]

correct. The first two parameters to QSpinBox in this call are min and max value.

So all that needed to be done was change the min to neg 3k.

[Jules]

I changed my min and max to -5000 and 5000. But, the Z azis filter is still fubar for some reason.

My guess is the problem lies in the parsing of the actual Z posistion of the player.

[showeqnewb]

I changed the numbers but still do not get the different layers on the map.

For a test I use Ssra and run down to the basement. It still shows just the first level on the map.

Thanks for looking into it :)

[suseuser7341]

I spent a closer look at the depth filtering:

To me it seems perfect right to limit m_headRoom and m_floorRoom to positive values greater than 5.

The interval against which depth filtered items are checked is calculated like
[curPlayer.z -floorRoom, curPlayer.z+ headRoom]

negative values make no sense at all

Maybe try to relog in some place where map filtering does not work. If the map shows up correct after you log back in, the cause is in Z value updates for the player rather than in the map display.

[Dok]

I'm no familiar with the seq code, but if I remember right, wasn't the Z-axis shown by /loc and the one shown by showeq different at one time by a multiple of 10? After playing in Tactics pit a while, I've noticed that the Z-axis seems to be working properly, but just off by a certain amount. (While in the pit, it'd draw the main floor)

The Z-axis works fine with spawns, but its just not showing the lines on the map correctly, so maybe it was just something missed while drawing the map.

The best example I can give of this is in PoK with the CVS map. First, turn the head and foot settings to like 10ish, then head to the second floor of the library (Mage floor? 32.5 Z-axis). You'll see the layout outside of the library. (about 3 Z-axis). If you go up another floor and up the next set of stairs to about 70 Z, you'll see the layout of the library main floor (outside mapped at about 6.5 Z)

After further investigating, the map files themselves may be the over all problem with the old style Z axis. Locs of 3 were written as 30, 70 were written as 700, etc. So all that might be necessary is someone to write something to fix all the maps themselves. (Maybe this would be a good time to update all the maps with newer, more complete versions on the CVS)

Anyway, just some ideas being thrown out and I'll let ya'll take it from here.

[Roads]

For a good example of the problem goto SSRA, was there last night and no matter what lvl you goto or settings you use, if you have filtering on you can only see like 2 rooms of the whole zone..

[suseuser7341]

Thanks for the hint. Since I already spent my time looking at this stuff, I will try to bring up a patch if I can make some sense out of what you observed.

[suseuser7341]

The factor 10 seems perfect right for PoK.
I could only test PoK, so not sure if the change works for everything.

Changing CurZ to CurZ/10 in lines 1459 and 1479 of mapcore.cpp worked for me. There may be a typo in line 1475, I did change the "0" to "i" in that line as well. Sorry for not bringing up a patch, but my editor somehow changes empty lines, which brings up a huge diff file.

[ieatacid]

Wow, that did the trick :)

Thanks a bunch!

[showeqnewb]

Ok let me see if I have this straight.

Change map.cpp back to 5/3000's from the -3000/3000 that was stated earlier

Then edit the mapcore.cpp and add a /10 to the end of the CurZ in lines 1459 and 1479?

Correct?

[suseuser7341]

For now just add the divide by 10 in the two mentioned lines in mapcore.cpp.

I have actually conceived a use for negatives values that I may implement within the next weeks so just leave the changes curio suggested. They won't harm your Seq in any way, however useful values are positive ones.

[Jules]

Excellent fix! alt-3 is still flaky, but having alt-2 working is better than nothing at all :)

[AMonk]

I have been trying to script the changes in the .map files. So far, I have had no success. I am just learning PERL now. The best I have come up with so far is:

#! /usr/bin/perl
print "What map file?";
$map = <STDIN>;
chomp ($map);
open (IN, $map) || die "Can't open file $map: $!";
$^I = ".bak";
sub convert {
while (<>) {
if $_[0] == "L" {
$_[3] = $_[3] / 10;
$_[6] = $_[6] / 10;
}
}
}
close (IN) || die "Can't close $map: $!";


Obviously, this doesnt work. Syntax errors on line 9 and 16.

Could someone lend a hand with this please?

[suseuser7341]

I don't think it is a good idea to fix the maps, since there are too many tools (e.g. EQ <-> SEQ converter) out there that depend on the current file format.

I have already found the map loader, but I am too busy to bring up a patch before next week. Once it is fixed there all display modes should work as they used to do so.

Edit: as a sidenote, "L" lines are 2 dimensional. Height is rarely (only highkeep.map) assigned with "H" lines. 3d mapping is done in "M" lines, which contain coordinate triplets as your script assumes.

[Dok]

Since the patch, the only problem left that I see is if someone were to make or add to an existing map, the Z axis in the map file will be the correct Z axis, where we'd need it to be * 10. Looks really good though :)

[Jules]

Bad news kiddies. After putting a blanket divide by 10 into the loadMap method for all lines, I find out that this is not a full fix.

Guess what.... there are .map files out there that have the CORRECT Z value in them. Grimling, Hallowshade, etc... all have values that do not need adjustment. Some zones need a /10 and some do not. A blanket /10 will make one set of maps start working and it will break the ones that were working.

IMO, we need to find which maps are which and run one set thru a converter to make them all agree. My guess would be that all SoL and later zones are mapped this way.


/gumble and bitch

[Jules]

Scratch that SoL and later thing... Some PoP map files need the adjustment as well.