Solved Navigator v19 inside v18 Problem! [Wrong Place to Post it! Sorry]

[Cikk]

Hello, i have implemented v19 navigator minimap into v18 files!
Took from L19.4 and put into L18
The problem i have is there is some random black lines in Flarine! but not outside of the town!

Its dosnt matter if i use the Normal Gold Theme Navigator or old one as you see in the picture! Let me know what the problem might be!
Best Regards: Cikk

 

[Fliperworld]

Imgur really hates my Firefox, lol.

I’m not entirely sure what’s causing this, but I’d suggest comparing the preprocessor blocks of L19.4 with those of L18, specifically looking at the __NAVIGATOR_V19 blocks in both versions. The issue could lie in a difference within these blocks, or even in some part of them, where code might be enabled in one version but inactive in the other. This type of inconsistency often arises when copying systems, usually due to dependencies or relationships with other defines.

Looking at the image itself, it seems like these artifacts are likely originating from two specific icons. If that's the case, it may just be a texture issue.

 

[zOmbie]

Moved @Cikk
I have the same issues with firefox, if you upload the image then right click and go-to view the raw image it always works, it's def a firefox issue @Fliperworld

Most of the changes with UI in 19.4 were not defined and most are listed as >=18 or >=19 more then likely i did not include the define for what your missing your gonna have to search lol.

 

[Cikk]

Imgur really hates my Firefox, lol.

I’m not entirely sure what’s causing this, but I’d suggest comparing the preprocessor blocks of L19.4 with those of L18, specifically looking at the __NAVIGATOR_V19 blocks in both versions. The issue could lie in a difference within these blocks, or even in some part of them, where code might be enabled in one version but inactive in the other. This type of inconsistency often arises when copying systems, usually due to dependencies or relationships with other defines.

Looking at the image itself, it seems like these artifacts are likely originating from two specific icons. If that's the case, it may just be a texture issue.

I've switch over to the v21 navigator to see if that fixed the issue, the issue still remains.

I've narrowed it down to the icons for sure.

Please login and(or) register to see this awesome content today.

Commenting this out makes the minimap completly normal however the icons don't render obviously.

Could it be the " 2drender.cpp " or "navigator.inc" file?

 

[Fliperworld]

navigator.inc is generally used to store positions, uv maps etc. A translated version of l19.4 should be something like this:

Please login and(or) register to see this awesome content today.

I honestly don't think the problem is in the include file, especially if the navigator works normally in other places....

If the m_texNavObjs.Render call causes the errors, the problem is probably before it, in this case the "pVertices" being calculated incorrectly.
This could be a problem with the map/world, with incorrect positioning.
Before calling m_texNavObjs.Render , the vertices are calculated... MAYBE removing/commenting out the distance check might help something
there are 2 of thoses above the mentioned line.
Try commenting out those blocks:

Please login and(or) register to see this awesome content today.

Edit1: What @zOmbie said about version-based macros is important, as the interface has changed a lot, it may be necessary to implement some codes that 'complement' the navigator app Unfortunately, it would require a bit of debugging and/or analysis of all the codes used/related to the navigator.

Edit 2: I will do some implementation tests on L18.1 non-custom

 

[Fliperworld]

I was unable to reproduce your problem.
I copied the navigator from L19.4 to a clean L18.1NC without any problems, with just a few small modifications for my convenience that should not interfere with anything.



Changed files for reference:

 

[Cikk]

I was unable to reproduce your problem.
I copied the navigator from L19.4 to a clean L18.1NC without any problems, with just a few small modifications for my convenience that should not interfere with anything.

View attachment 779

Changed files for reference:

Hmm wierd that our didnt work at first then ^^ maybe miss place anything! but should have not cus double checked with winmerge ^^ But it works now with some teamwork with my team! "not sure what he did doh" but if it comes back i will try the source/file you placed here! atm we tought it had to do with our "map" within flaris/flarine!

Cheers for the help and information @Fliperworld <3

Best regards: Cikk

 

[Cikk]

I was unable to reproduce your problem.
I copied the navigator from L19.4 to a clean L18.1NC without any problems, with just a few small modifications for my convenience that should not interfere with anything.

View attachment 779

Changed files for reference:

had to try this, but after implemented it this is what happend!



So so far we still think it has to do with our flarine map

 

[Cikk]

i followed the preprocessors 1:1
It breaks on this !



And

 

[Fliperworld]

Please login and(or) register to see this awesome content today.

It's an original Client call, not exactly something the system added.

The texture at index 44( 38 + 6) does not have m_ptCenter.
a temporary hack/fix would be to use something similar to this:

Please login and(or) register to see this awesome content today.

Usually m_nStructure are defined in the character.inc file...etc
ie: Losha

Please login and(or) register to see this awesome content today.

"SRT_FOOD" is defined in defineNeuz.h

Please login and(or) register to see this awesome content today.

In my source, I didn't find any npc that used any m_nStructure defined as 38

 

[Cikk]

Please login and(or) register to see this awesome content today.

It's an original Client call, not exactly something the system added.

The texture at index 44( 38 + 6) does not have m_ptCenter.
a temporary hack/fix would be to use something similar to this:

Please login and(or) register to see this awesome content today.

Usually m_nStructure are defined in the character.inc file...etc
ie: Losha

Please login and(or) register to see this awesome content today.

"SRT_FOOD" is defined in defineNeuz.h

Please login and(or) register to see this awesome content today.

In my source, I didn't find any npc that used any m_nStructure defined as 38

We use a custom m_nStructure calld SRT_CBTSHOP and another SRT_SALVAGE and thoes have define 38 and 39! thats might be why you dont have it!

 

[Fliperworld]

SRT_CBTSHOP and another SRT_SALVAGE have a too big define value...

lets analize the Navigator.inc file (npc icons)....
BOOL CTexturePack::LoadScript( LPDIRECT3DDEVICE9 pd3dDevice, LPCTSTR pszFileName ) will process this file...

Please login and(or) register to see this awesome content today.

focus on all Serialize...starting from :

Please login and(or) register to see this awesome content today.

from left to right....

4 means 4 'ícons'
5 = icon width
5 = icon height
0 = icon StartPosition-X
0 = icon StartPosition-Y,
0 = icon center_x,
0 = icon center_y


so , LoadScript will create 4 'textures' for this row....
At next iteration, it will create more 2 'textures' (serialize 2 5 5 0 5 0 0) etc ....

At the end of this inc file we will have 4 + 2 + 6 + 7 + 4 + 3 + 3 + 3 'textures' on m_texNavObjs .
32 ...plus one from 'pos' = 33....
Thats why we have 'number' 33 field.

Please login and(or) register to see this awesome content today.

Based on this Navigator.inc file , your last subtexture 'nIndex' must be 32 or less (0 based index...)...

so...

your nIndex = 6 + lpCharacter->m_nStructure.

your m_nStructure must be less than 26 ....or you can do something like:

Please login and(or) register to see this awesome content today.

Or change your SRT_CBTSHOP and SRT_SALVAGE defines values in a way that the calculation m_nStructure +6 results in the desired icon, as long as, of course, this does not affect any code that needs to compare/read the value of m_nStructure for a specific task of those NPCs...

My Conclusion:
I believe the issue does not stem from the L19.4 navigator itself, nor was it introduced by the original navigator. Instead, the problem lies in how the m_nStructure values were initially defined. While the original navigator may have already contained this issue, it wasn’t apparent because the graphical behavior didn’t expose it. The L19.4 navigator merely brought the issue to light.

The root cause is not the navigator code but the deliberate assignment of m_nStructure values without fully considering their broader implications. Specifically, for defines used in m_nStructure (e.g., SRT_PUBLICOFFICE, etc.), new defines do not always need to be the highest available number. In some cases, they may need to be smaller than existing defines, depending on the position of the subtexture used in the navigator or minimap. In other cases, their placement depends on the specific context in which they are applied. This oversight in value assignment likely led to the issue being misinterpreted as a bug in the navigators themselves.

 

[Cikk]

SRT_CBTSHOP and another SRT_SALVAGE have a too big define value...

lets analize the Navigator.inc file (npc icons)....
BOOL CTexturePack::LoadScript( LPDIRECT3DDEVICE9 pd3dDevice, LPCTSTR pszFileName ) will process this file...

Please login and(or) register to see this awesome content today.

focus on all Serialize...starting from :

Please login and(or) register to see this awesome content today.

from left to right....

4 means 4 'ícons'
5 = icon width
5 = icon height
0 = icon StartPosition-X
0 = icon StartPosition-Y,
0 = icon center_x,
0 = icon center_y


so , LoadScript will create 4 'textures' for this row....
At next iteration, it will create more 2 'textures' (serialize 2 5 5 0 5 0 0) etc ....

At the end of this inc file we will have 4 + 2 + 6 + 7 + 4 + 3 + 3 + 3 'textures' on m_texNavObjs .
32 ...plus one from 'pos' = 33....
Thats why we have 'number' 33 field.

Please login and(or) register to see this awesome content today.

Based on this Navigator.inc file , your last subtexture 'nIndex' must be 32 or less (0 based index...)...

so...

your nIndex = 6 + lpCharacter->m_nStructure.

your m_nStructure must be less than 26 ....or you can do something like:

Please login and(or) register to see this awesome content today.

Or change your SRT_CBTSHOP and SRT_SALVAGE defines values in a way that the calculation m_nStructure +6 results in the desired icon, as long as, of course, this does not affect any code that needs to compare/read the value of m_nStructure for a specific task of those NPCs...

My Conclusion:
I believe the issue does not stem from the L19.4 navigator itself, nor was it introduced by the original navigator. Instead, the problem lies in how the m_nStructure values were initially defined. While the original navigator may have already contained this issue, it wasn’t apparent because the graphical behavior didn’t expose it. The L19.4 navigator merely brought the issue to light.

The root cause is not the navigator code but the deliberate assignment of m_nStructure values without fully considering their broader implications. Specifically, for defines used in m_nStructure (e.g., SRT_PUBLICOFFICE, etc.), new defines do not always need to be the highest available number. In some cases, they may need to be smaller than existing defines, depending on the position of the subtexture used in the navigator or minimap. In other cases, their placement depends on the specific context in which they are applied. This oversight in value assignment likely led to the issue being misinterpreted as a bug in the navigators themselves.

@Fliperworld Thanks alot for alot of explaining and nagivating to our problem! After this it was all working well! Cheers alot for your kind help and explaining!