Weigo

2 hours ago, Salk said:

A follow-up question: if it's recommended to not use those modified .WED files with BGGO, does it mean that the Searchmap part of the code for those areas is not needed? What I am trying to ask is: is there any point for the searchmap changes in those two areas if the .WED files are not changed too?

@Salk

I will have a closer look at this over the next few days. Maybe we can get a compatibility so that we can install both mods together without problems.

This will be due to the fact that the night map does not exist in BGEE and ET and therefore BST is installed with the PVRZ index of 0. BGGO uses the same index numbering from the day map.

As far as I know, with the argent77 PVRZ function for free indices you can also specify at which index it should start. That means, if we add this to BST, it should always work.

Zeile 1572 in der setup-bst.tp2

LPF UPDATE_PVRZ_INDICES INT_VAR target_base_index = 8 RET original_base_index new_base_index END

I will test it tonight.

At the moment it is better to install BGGO first, then BST.
 

When I‘m back home, I will take a Look on it.

Quote

Bit the Logiker Wolldecke be helpfull

Stupid autocorrect.

The problem with the graphic errors in the nashkell mines already comes from the BG1 original.

If someone could prepare the file in the link below, then I can include it in the BGGO. You would have to rework those weird color pixels in the impeller. The night map unfortunately also has this error.

https://drive.google.com/file/d/1EHWQuAuxpGN9k4WxYXktIV2vQn6UCGy7/view?usp=sharing

The day map Nashkel Mines is not updated by BGGO at all.

Quote

 

I play with a custom size map, created from the base that is shipped with bp-bgt-worldmap. It is smaller than the small one because with oBG the map viewer is really small and having a "huge" map is harder to handle.

 

That is the advantage of the EE map, you have a larger section.

One possibility would be to include a small map version for the BGT users, perhaps also similar to EET.

@Imiona

the problem is now solved and uploaded to the github folder.

https://github.com/SpellholdStudios/BGGOEET/tree/v3-beta

The problem was that the coordinates of the candles and lights of the individual areas were not deleted and you therefore saw the lights from another area.

This must be the master branch of BGGOEET and not the v3-beta. Here is a photo of the v3-beta.

I see this area every time I test a new area and I would have noticed this already.

Now I have to give a little update on how far the mod has progressed.
After Yovaneth and I have decided all areas also from BG2/ToB and SoD to give a night map, it still takes some time.
At the moment we are at a quarter of the areas. And the areas are getting great. The art work of Yovaneth is outstanding. That's why I want to share with you a picture ahead of time, I think it's incredibly awesome.

It's a lot of handwork to get the areas into the extended night version, so it's going to take weeks to get everything done.
At the same time, I'm in the process of making the mod more open, so that compatibility and extensibility will be easier.

Unfortunately, it is not that simple either. Otherwise I would have finished months ago.
1. is the PVRZ 1024x1024 of a continuous card => no problems with the 64x64 tiles
2. if one of the border parts on the left or right side of the map is smaller than 1024 width or height => for the corresponding part you have to add +1 pixel on each side that is smaller than 1024.
3. doors, waters: if the pvrz is only 64 wide, then the heights must be 66 pixels per part or vice versa.
3.1 If the PVRZ is larger than 64, then all parts are 66x66
4. accordingly, the coordinates must also be adjusted in the tiv v2, there are the x, y coordinates of the individual tiles in the PVRZ image.

The whole thing is wild as a bird. It will certainly be hard to automate this. That's why it takes so long for me, because I have to copy all the overlay parts (doors+waters) in by hand.
 

Hello all. I had exactly the same problem with the lines at BGGO. The problem is that the system that reassembles the map from the PVRZ snippets has a bug. The lines occur with the overlays. In the code is somewhere an error that just here is assembled offset by 1 pixel. Beamdog already had this problem, because they made the 64x64 tiles a bit bigger. At the edge 64x66 or 66x64 and in the middle of the PVRZ file 66x66. I had to correct all that by hand with BGGO and that's why I've been sitting with it for over 4 months.
If you have any questions about how the Wed file works with its overlays and doors, you can ask me.

@Roberciiik

You don't have to convert the wt*.tis files for the overlays to pvrz format. The v1 files are sufficient.

Now I can only help you from memory, as I am now on vacation. 
The wall polygons in AR4100 determine whether the character stands in front of or behind the wall (is displayed transparently or not). One would have to investigate.
Also the open and closed doors are in the wed file 2 times inside. 1. which tis tiles belong to the door (open door) 2. in the overlay0 is the secondary tile (closed) at the corresponding tile

It depends on what was changed.
In principle, you have only the contents of one or the other mod. Unfortunately, there is almost nothing for wed files such as the fj_are_struct. More we can discuss after the vacation 

Translated with www.DeepL.com/Translator (free version)

On 7/16/2023 at 3:58 PM, Salk said:

The original AR4100 has the same number of wall polygons but the vertices offset is 10286 h vs 10292 h. There are then differences between the original and the modified versions of course but I cannot really understand what those differences are.

This is a bit more complicated. The polygons are there to simulate different states of wall, tress ...
The different flags are from iesdp

Quote

Indicates whether this polygon is a polygon or a hole (i.e. whether it is a section of impassability, or one of passability). The default behaviour is that wall shades animations from both sides.

bit 0 : Shade wall
bit 1 : Hovering.
bit 2 : Cover animations
bit 3 : Cover animations
bit 4 : Unknown
bit 5 : Unknown
bit 6 : Unknown
bit 7 : Door?

AR3700 New wall polygons are hiding here somewhere. You just have to find them.

The function of the wed file is a bit more complex. The polygons are placed in the wall groups, which are sections of the map of 10 x 7.5 tiles. There all polygons are simply counted and listed with an index table.

The index table again tells at which index number it starts and how many polygons there are.
Then the engine knows, by the wall polygon index table, that is a second table, in which just every single polygon is assigned to its arbitrary numbering. And it can happen that a polygon goes over 2 wall groups or even at the corner over four wall groups and thus some polygons appear 2 or 4 times in the wall polygon index table.
(AR4100: wall polygon index 143: 384 and wall polygon index 68: 384)

Example: AR4100
wallgroup15: 189, 14 (start at number 189 and there are 14 polygons).

wall polygon index 189: 54
wall polygon index 190: 55
wall polygon index 191: 56
wall polygon index 192: 57
wall polygon index 193: 58
wall polygon index 194: 59
...
wall polygon index 202: 334
 

wall polygon 54: vertices and flags
wall polygon 55: vertices and flags
wall polygon 56: vertices and flags
wall polygon 57: vertices and flags
wall polygon 58: vertices and flags
wall polygon 59: vertices and flags
...
wall polygon 334: vertices and flags
 

I hope I could help a little bit, but unfortunately this is a bit complicated to explain.

5 hours ago, Salk said:

one question: I have taken a look at BGGO's base/wedD/non-ee folder and I don't actually see there the corresponding files: BG4800.wed (Nashkell) and BG5100.wed (Gnoll Stronghold), if I am correct? Doesn't this mean that BGGO does not change the original .wed files for those two areas? If that is the case, why would Jarl's overwriting the original .wed files be a compatibility problem?

You are right, for the non-EE version there are no day wed files. The day wed files are no problem, but for the night wed files.

The changes must always be made for day and for night with BGGO.

Regards

Weigo

@Salk

You just need to comment out the last two lines, then the mod should have better compatibility.

You would just have to check what the two wed files have more than the original ones.

@Endarire

9 hours ago, Endarire said:

Weigo, who did you pay for the door repair charge?  (Reference)

I talked to the old man, of course. But he did not want my gold but only rupees. Unfortunately, I had none with me.

Somehow my Baldur's Gate savegame would not start in Zelda.

@Salk

The ALTER_SEARCHMAP function is compatible because the changes to the searchmap bmp file are added bit by bit to the image file present in the game and are not completely overwritten. There is only a conflict if 2 mods overwrite exactly the same pixel with a different color/value.
The situation is different for the two wed files. AR3700.wed and AR4100.wed, they are completely overwritten and there is no night version of them. There you would have to write a weidu code.

16 hours ago, Parys said:

I noticed a misaligned door texture in North Baldur's Gate area (AR0200):

Door is repaired

12 hours ago, TotoR said:

I have found a bug on oBG2 (BGT to be exact, but should be the same on Tutu): https://github.com/SpellholdStudios/BGGOEET/issues/2

Problem solved.

Yovaneth sent me the night map from the IceIsland. He also did a wonderful job on the IceIslandMaze.

The maze is now equipped with torches. Both maps are now part of the BGGO.

Now everything is ready so far. Now it's time to test. It would be nice if we could test everything ingame. I have already tested a lot of things, but a few more eyes to look would be good. And then we can finish the release.

The Baldur's Gate city areas are ready. Now I have to rework the water overlay tis files.

@Salk

you have found the correct code section. These lines are for installing the water textures that serve as an overlay to animate the large area maps.
I had the same problems with the EE variant, so I removed the tbc compression, which requires the tileconv. The uncompressed tis files are only a few hundred kb in size and should therefore not be a problem.

But I still have a small bug in the code, the % around the ee directory is too much. Could you test an installation again?

//	ACTION_IF GAME_IS ~eet bgee~ BEGIN
		ACTION_BASH_FOR ~%MOD_FOLDER%/base/tbcN/ys/ee~ ~^.+\.tis$~ BEGIN
			ACTION_IF NOT FILE_EXISTS_IN_GAME ~%BASH_FOR_FILE%~ BEGIN
				COPY + ~%MOD_FOLDER%/base/tbcN/ys/ee/%BASH_FOR_FILE%~ ~override~
			END
		END
//	END

The bam files also always caused problems with biffing during the EE installation, so I have them copied into the override. For this reason I have omitted the biffing for all as a precaution.

	ACTION_BASH_FOR ~%MOD_FOLDER%/base/bam~ ~^.+\.bam$~ BEGIN
		//ACTION_IF NOT FILE_EXISTS_IN_GAME ~%BASH_FOR_FILE%~ BEGIN
//			ACTION_IF !GAME_IS ~eet~ BEGIN
//				COPY + ~%MOD_FOLDER%/base/bam/%BASH_FOR_FILE%~ ~%MOD_FOLDER%/bif/bggom~
//			END ELSE BEGIN
				COPY + ~%MOD_FOLDER%/base/bam/%BASH_FOR_FILE%~ ~override~
//			END
		//END
	END

@Salk,

I tried it on a BGT-only installation, without any other mod, and it worked. According to your debug file, the problem is with the installation of the water textures files. Try the macros.tpa in the attachment, there I modified the installation.

@Galactycon @Sam

Unfortunately, I haven't heard of this problem yet. I would first have to familiarize myself with it. But I would like to finish the BGGO to the extent that it was until now and then we can look further.

macros.tpa

32 minutes ago, Salk said:

Is there any work left to do for Yovaneth or have you got all the material you need, Weigo?

Cheers!

I am still waiting for a package from him.