Weigo

The order of the mods mentioned does not matter From the readme This mod is compatible with both Infinity Engine variants. Therefore, almost all Baldur&#39;s Gate variants are compatible with this version. Primarily with EET and BGT of course, but also with ToB (SoA is not enough) and BG2EE and also with BG1EE with or without SoD. TuTu_TotSC should also be compatible with BGGO, but has not been tested yet.<br> This mod is compatible with all mods that do not overwrite are, wed, tis, pvrz and bmp files. are and wed files should be patched then. Additional built-in mod compatibility: -Lure of Sirines Call -Baldurans Seatower<br> -Gavin NPC -TDDz

I am currently on a business trip and can only guess from the picture with the error. It says setup-bggo.exe.exe and only an exe actually belongs there. But that's just a remote diagnosis. I won't be back at my computer until next week. some mods are supported, BST, GavinNpc , Lure of Sirines Call come to mind. All other mods that add content should be installed after BGGO and preferably the areas should be patched and not overwritten. Mod own maps do not matter

Super. That's wonderful. That was an error in the tis file. I had to convert it manually by hand, as there are a lot of door and water parts, and I probably got a tile too far to the right Now it's fixed. The mos file is only meant for the minimap. Weidu doesn't seem to be able to extract the mos file from the original bif file. (Thats the error message, and the revised macros.tpa does not cancel the installation). With my BG1EE version the mos files can be extracted. But that shouldn't be a problem as the file exists in the game. The new and revised mos maps are already copied by the installation. Thanks again for your support. I uploaded the newest fixes on github. https://github.com/SpellholdStudios/BGGOEET

I'm slowly getting old and senile. I completely overlooked the fact that I took the two image files out of the directory that were not yet converted to 8-bit because of the three different installations I have running. @ParysSorry for the work this morning. Here are the two image files in 8-bit BG0700LN.BMPBG2600LN.bmp

It affected both engines. This post was sent to me by another forum. That's why I had to do it again, as game crashes are always bad. Please try this file again, if it works, then we have solved it with 8-bit lightmaps. BG0700LN.BMPBG2600LN.bmp If it works, then the error was my colour depth conversion program.

Very glad it worked and thanks for testing. I will convert and upload all the other lightmaps, day and night, at the weekend.

Good news. I have got the following versions to run without the red glow. EET, BG1EE and BGT. With 24 bit it worked for me. To test it, please copy the file in the attachment into the following folder bggo/base/bmpLN/ee or non-ee and reinstall BGGO. Copying into the override folder is not enough. If this works for you, then I will convert them all to 24 bit. BG2600LN.bmp Then the question is how it looks with the LM files.

It is very curious. The BG2600LN.bmp with 8bit also produces the red colour effect with EET. The same file with 24 bit does not produce a red colour effect. But with BG1EE the 24 bit again produces the red effect???? With BG0700 and the green effekt is the same.

I think this is a problem with the colours of the LN images. As far as I understand the function of the lightmaps, the animation graphics are coloured with the colours of the lightmaps (I don't know how this works in detail in the engine) In the images we can see which lightmap colour causes red (left) and which green(right). To rework it with the function suggested by @Sam., we need a new matching colour for the palette. However, there is still a problem with the function, it is for 4bit colour palette bitmaps and the lightmaps are 8bit. Nevertheless, we need matching colours for the lightmaps and we would need to revise 98 from ee version. The oBG version is then only a matter of form. These are all lightmaps that have been revised by BGGO (.../bggo/base/bmpLN/ee). Everyone is cordially invited to participate

I've done a bit of research. Couldn't the red glowing also be the Infravision? Can you please select a character without infravision (human) and see if that's still the case? @Parys I'm glad that the installation is working now. I will add the revised code in the next update.

The reddish colour is due to the night lightmap. BG2300LN.bmp @Parys Test the installation with this macros.tpa with the original version, which breaks off at BG3800 or AR3800. My suspicion is that it somehow can't access the bif files to extract the mos files. I can't test it unfortunately as my versions of BG work. BG2, BG2+BGT(ToB GoG and original CD version), BG2EE+EET, BG2EE, BG1EE EE is the Steam version

@deratiseur @Parys I tried it again with my installation and it ran without any problems. But somehow it is suspicious that it is exactly the same file. Copy the original AR3800.mos or BG3800.mos file from NI into the override directory and then install BGGO. I have the suspicion that the bif file is not working properly.

@Salk The Bg2 GoG version has the data/DATA folder. I installed BGGO on it and it recognised the directory structure without any problems. @Guest YLL I will change the directory. I had just adopted it like this at some point. Unfortunately I don't have the osx version of Baldur's Gate. Your installation my installation BG1EE + DLC Merger and BG2EE + EET Note the last line in each case. It could be that tileconv has not created the file after all and therefore cannot copy it over and therefore the installation is stopped. But unfortunately I cannot test this. @Probe88 Which BG version do you play? Can you please post a picture?

Thank you very much for your feedback, I will do my best to help you. I'll have a bit more time to look at your problems again tomorrow.

Download with this link: https://github.com/SpellholdStudios/BGGOEET/archive/refs/heads/master.zip Take another setup-xxx.exe or weidu.exe and rename it to setup-bggo.exe

I've only just seen your post. But it's great that you were able to solve it.

That's probably an example of how we've passed each other by It's because of my mediocre knowledge of English This was just an example of how the PVRZ image files were cut up by Beamdog and that the individual cut-outs are all 1 pixel larger at the edges. BG0100 has no lines and glitches in the original, but the old BGGO version does when converting from v1 to v2. But now in the new version it has none. But thanks anyway for your efforts.

I was just trying to search my thoughts from a year ago when I started BGGO to find the error. The script from you is a great thing, I'm not very good at programming. If you can solve the problem technically, that's always better. The B010013.PVRZ is a part of the BG0100 are (NW Baldurs Gate City)

I don't know. This is exactly what makes the whole issue so difficult. The error is somewhere in the baldur.exe file, probably where the tis files are put together to form an image. Beamdog then stupidly did not correct the error in the exe, but with the additional border pixels. That's why I took the pvrz files from the originals and transferred the graphical changes by hand. NI converts them much better and more robustly than tile2ee. Both use modified routines. Unfortunately I don't know how it assembles the edge parts of the map. At the beginning you have the 1024x1024 tiles. These always work without problems. Then come the tiles on the right and bottom edges. These are also put together in certain related areas (see example B010013.PVRZ). When they are set in a png by the routine, the border pixels are set. But this makes the routine incredibly complex. Or you can generally make a border pixel row around each tile for every the border areas tile.

This can also occur with the normal tiles on the background map. If the width of the pvrz image file is larger than the tiles section, then it is 1 pixel larger in the x direction on both sides. The same applies to the y direction. Only if image width = tile width or image height = tile height, then there is no pixel. Example t = tile Image section is 5 x 3 tiles t t t t t 5*64 Pixel = 320 Pixel = width t t t t t 3*64 Pixel = 192 Pixel = hidth t t t t t 1st case Pvrz file is 320 x 192 pixels => no additional border pixels 2nd case Pvrz file is e.g. 384 x 192 pixels => one additional pixel in each x direction => image section 322 x 192 The same applies in the y-direction or in both directions simultaneously if the sides are correspondingly larger. For example B010013.PVRZ All the image sections have border pixels. This is a bit complicated and I have problems putting it into words, especially in english

Great work with the script. Fireplaces are added with tiles. In overlay_0 several tiles are added to the tilemap_count at the location of the tilemap. eg: BG0169 tilemap 30 has 6 tilemap_counts. This means that the engine looks up the next 6 tilemap numbers in the tilemap_index. (77-82) These tilemap numbers are the positions in the tis file.

The only thing I can think of spontaneously is the Candlekeep map (BG2600). The flags on the spires are the tilemap animation, the water basins are overlays and there are plenty of doors. That is true. How did you know it wasn't a trap?

It was quick, just had to reduce the file from 8bit to 4bit and it worked. Here is the link: https://github.com/SpellholdStudios/BGGOEET/blob/master/bggo/base/bmpSR/AR1102SR.BMP Simply copy the file into the override folder or reinstall everything.

I have found the error, it is in the AR1102SR.bmp file. Somehow it doesn't like to read it properly and therefore you can't move. I will take care of it @Guest Guest Either delete the AR1102SR.bmp from the bggo/base/bmpSR directory and install bggo nue or copy the original file from BG2 into the override folder. Then it should work again. Or you wait until I have revised the bmp file.

Unfortunately, I cannot reproduce your error. I have tested both the EET version and the BGT version (classic, not the GoG). Everything ran smoothly. I tested all three accesses to the roof during the day and at night. For the destroyed (AR1300,AR1303) as well as for the restored (AR1304,AR1307) AR1303a (top of the map) to AR1300 (roof) AR1303b (bottom) to AR1300 (roof) AR1300 the wide staircase to the roof The same with the restored. All three ran without any problems.