Well, this sucks…my motherboard died. I had to dust off an ancient Dell D620 laptop to post this.

I was scheduled to upgrade my PC in the next week or so anyway, so I’ll just do that. However, it will take me awhile to configure and install everything I want, port my files over, etc.

My hard drive on the dead machine is intact. I booted from a USB dvd with Knoppix (frickin’ awesome tool that has saved me before, BTW!) and I can see everything fine, so I’ll be able to copy it all. I also had most important stuff backed up on an external HD, too. But, it might take me awhile to situate myself again. Sorry for the trouble and delay this might cause my future responses in the near term.

I must be tired…I didn’t actually try to look. Sure, I can see the drive pretending to be mounted in /media, but nothing underneath. I’m going to bed LOL Hopefully if I take the drive out and plug it into something, it will still be useful. Ugh.

I appreciate the offers, but shouldn’t be necessary. While I’m sure it’s frowned upon by my employer, they supply me with a machine (though relatively weak considering my computing needs are mostly for a something akin to a thin client and my ‘real’ development is on a remote server-class machine. I remote desktop to them, so I don’t have much horsepower need for my laptop.). I use this machine to install Visual Studio flavors and things locally to play with, including this game 🙂 I suppose I’m also a bit unusual in that I don’t even own a personal computer. My wife does, my kids do, but not the software developer in the household. Guess I’m a Luddite LOL.

Now for the bad news. I’m not much a hardware guy, so I took it to some experts and I was wrong. While hoping for a controller problem or something, it was actually a hard drive failure. While I occasionally plug in an external drive and copy my work to it, the last I did so was about a month ago, so lost everything I did recently. In the past, ‘we’ had some work drives fail and the data recovery specialists can do considerable magic, so I’ve sent it off for such a feat.

Which means that I probably won’t have much to contribute code-wise until it comes back, which I’m fairly confident in their abilities. The consensus is that there is a bit of rattling, so it’s probably a broken arm mechanism or something and the surface is probably fine.

Cross your fingers 🙂

I am unfamiliar with the unzipping problems in later OS, that Devoidbrah mentions, but my kids have Win 8.1 and the easiest thing that seems to eliminate many problems is to run the game outside of Program Files. Put the game in its own directory, directly under C:\. This has worked the best for my kids’ computers running this game.

Later Windows OS protect writing to Program Files, and this game needs to write in its own directory. So try that first…put the game in C:\ERAS or something similar and run from there. Also try compatibility mode for the .exe, right-click properties and set to Win 7 or Win XP.

OK, I think I understand what you’re getting at. You are using F11 to launch that debug screen with all the F1-FXX buttons that you click to do different things?

If so, yes, I was using the F1 to test/change some things. I think in the patch it re-inits items/ships. That program is Programs/Interface/debuger.c. Right now, since my primary machine with everything on it is dead, I don’t have the code in front of me. But I think if you open that file, find void CalculateInfoDataF1(), look for where I put InitItems and InitShips…just put a // in front of those two lines and I think the rest of that function, that give $50,000 and will operate as it normally did. You can also just copy that same file Programs/Interface/debuger.c from COAS to ERAS to revert that back to stock.

I too have been a little slow in responding trying to transition to a brand new PC. For what it’s worth, I’ve got a new PC now, but still working on installing/configuring my ‘personal’ stuff (such as AoP projects). I am also reluctant to accept my last backup of that source (from about a month prior to the HD crash), so am still awaiting news about the reconstruction of my old drive, to see if I can get my latest work from that.

Oh, Devoidbrah, my new drive is solid-state, so yeah, I’m digging that. Super fast bootup and undoubtedly will prove better longevity without all those frail moving parts.

I am at least back to where my project stood a month before my disk failure. I have also converted to VS 2012. I had to make a couple config changes in my VS compiler options after the upgrade, but it’s all good and compiles/runs once again. However, I would still like to recover the work I did in the month since that backup copy, so I’m still waiting for word about my HDD recovery of that source I changed after my last backup copy.

But the good news is I am at least upgraded to VS 2012 and it compiles what I had from my last source backup.

Ha! Got my old data back the other day. Data Recovery team did the job. I’ll be able to restore all the lost source from the month between last backup and when the drive crashed.

Back in business! Restored my source, compiled under a newer Visual Studio 2012 and everything runs well. Gonna do some preliminary testing to be sure, but anticipate no problems since it’s the same code, just a slightly different compiler version.

So at this point, I’m exactly where I was prior to drive crash and ready to continue moving forward.

Update:

Haven’t had a ton of time to look at this, but was able to test the new VS2012 compilations a little bit and there was a slight difference in how the ‘free memory’ worked and it sometimes produced an error upon game exit (this wasn’t the case before, in the VS2010 version of the same source). I identified and rectified this one error. Still plan a little more testing before releasing in my MEGA link.

Again, the source was the same, but I was concerned the newer compiler might impart some different behavior; turns out my thinking was correct, so I want to be sure as many aspects/functions of the game still work correctly with how VS2012 compiles the game.

Ugh! VS2012 compiled version is slightly unstable. A few random crashes due to memory free problems inside the DX render. I think it may be due to crossing CRT boundaries: http://siomsystems.com/mixing-visual-studio-versions/

Went back to VS2010 and so far more stable.

Close…it’s Win7 (my new computer’s OS) and Doug Lea’s malloc within the CRT: http://stackoverflow.com/questions/4090971/dlmalloc-crash-on-win7

So, I can’t try to minimize the memory fragmentation like I wanted. Reverting back to vanilla malloc has stopped the new instances of memory violations I was getting on the new machine. But I now might still have to suffer the longer-term playing problem with possible memory fragmentation still causing a problem?

LOL, I’m not the only one with the dlmalloc idea that got bit by Win7. Starcraft problem: http://us.battle.net/forums/en/sc2/topic/2416202019

…windows xp 32 bit to windows 7 64 bit… This problem is not causing my system to crash, just the game…

Memory Usage Startup Error Current

CRT malloc
Bytes 0 0 0
Peak 0 0 0

MemAlloc
Allocated 3,418,924 855,363,788 855,667,136
Overhead 75,132 4,101,824 4,101,824
Header+Footer 0 0 0
# Blocks 18,782 1,025,298 1,025,298
Committed 3,997,696 865,468,416 865,468,416

dlmalloc Committed…

Oh well…

Ha! I did it…finally found a lingering memory leak that had been plaguing me forever: Leak: ‘xiutil.cpp’ line 79, size 11

Tough to find the culprit because that refers to a generic DuplicateString function that is called in several places that might have been neglecting to clean their own objects up when no longer needed. But through a tedious step-through, I finally tracked it down.

That leak is gone. Still doing some testing…

I was running this game for several hours yesterday, and it eventually crashed, with a bunch of ‘out of memory’ errors. Which was BS. My new machine has several gb. Back on the old machine, my limit was 2 gb, but I would have to close down a bunch of stuff and run only the game for any decent performance. With the new machine, I just leave a bunch of stuff running.

This error was curious, because the OTHER things on my machine were consuming a total near 2gb of memory, and I had compiled this as 32-bit (so it can run on older machines if needed), and perhaps that was the problem, as it will not be able to handle Large Address memory addresses? I also remember mention of a .dll trick to get the old app to become Large Address Aware on machines with 2+ gb memory. So, I have now compiled the .exe to be a 32-bit, Large Address Aware app (this can be done on compile), and handle 64-bit memory capabilities; it’s now built in. That should help.

OK, rescinding the Large Address Aware. I had one crash, looks due to some code storing a memory address in a DWORD, which is a data type constrained to 32-bit length as an integer, so it will truncate the address it refers to, if higher than 32-bit max, and when it’s reverted to a mem-pointer for retrieval, it is incorrect and can cause a crash. Also, the heap is application specific, so large addresses are not needed if the entire app consumes less than 2 gb of memory, rather than all apps combined, I have learned.

However, I have now disabled the memory pool allocation features for the release build that keep track of everything for debugging; it consumes extra memory itself and slows things down as well. I will keep it for the debug version, but it’s unnecessary for release builds. A simple preprocessor directive makes this alternative easy upon compile.

It’s snappier, the app uses less memory and less prone to error this way; so far I’m happier with it.

In my previous release, I found I inadvertently caused some sound service issues where I made an attempt to REUSE FMOD sound channels if applicable, caused mixing 2d and 3d sounds which can sometimes cause jumbling/stutters. I noticed this and have corrected it.

While trying out this VS2012 version, I notice that some things are a bit different, causing some occasional trouble that is ‘new’ in the sense these same issues didn’t seem to exist until now. I’m addressing them as I encounter them, but I’ve gone a bit astray with this ‘sound’ thing because of a discovery.

I have just uncovered that there is an attempt in the game to ‘manage’ different sounds with an array of sound information. For instance, the ship has properties for an ID to assign from an array of sounds/channels that was created for the appropriate sound files and what sound channel they relate to: SailsID and WaterID for sail/water sounds, when a ship is introduced on the Sea. This is where I recently found a problem. FMOD can reallocate/steal channels when it thinks it necessary due to 3d proximity and such. Since the channel is stolen/reused, the array the game uses for that ID/sound combo, that it assigned to the SailsID/WaterID, is no longer valid or applicable, yet during messages sent in Execute/Realize functions for drawing and creating the correct sounds for such, it still tries to use them, but will get an ‘invalid channel’ error.

This whole approach does not take into account that things can change during the lifetime of sounds/channels; it just doesn’t always work the way ‘they’ thought when assigning this SailsID/WaterID index without a way to know of FMOD changes, and/or recourse in the event something like that happens. Once the channel is changed by FMOD, that index is useless, but that portion of the game doesn’t take that fact into account as it continues to use the array index ID it was granted at the ship load. To rectify, would likely require rewriting the whole approach.

I think we need to reduce the texture file size of a few more things…well, more than a few. I played for a number of hours and eventually got this:

Texture C:\Playlogic\ERAS\RESOURCE\textures\CHARACTERS\SOLD_SPA_2.TGA.tx is not created (width: 2048, height: 2048, num mips: 12, format: D3DFMT_X8R8G8B8), not loading it.
CreateTexture: Direct3D could not allocate sufficient memory to complete the call
Texture C:\Playlogic\ERAS\RESOURCE\textures\CHARACTERS\SOLD_SPA_2.TGA.tx is not created (width: 2048, height: 2048, num mips: 12, format: D3DFMT_X8R8G8B8), not loading it.

It’s not game-breaking, but you will see models/character that are flat gray, no textures loaded. What happens, is that memory needs to be allocated for those textures each time, and memory allocation needs to be in contiguous blocks. But since some of the model texture files are 20+ mb, they can’t be allocated if the memory being used by the app becomes ‘fragmented’ in a sense that there may be enough overall memory, there are no spaces in between used segments large enough to allocate 20+ mb for the texture file. Then it fails. The app, being Large Address Unaware, can only use 2 gb total, and I note the app is usually using 1.3 to 1.5 gb right now.

So, I reduced the texture file sizes of the following to about 1/4 of what they were. They are still sharp looking, as I used an option to preserve sharpness, but just slightly lower BPP and smaller dimensions, similar to what was being used for others.

SOLD_SPA_1.TGA.tx
SOLD_SPA_2.TGA.tx
SOLD_SPA_3.TGA.tx
SOLD_SPA_4.TGA.tx
SOLD_SPA_5.TGA.tx
SOLD_SPA_6.TGA.tx
SOLD_SPA_7.TGA.tx
SOLD_SPA_8.TGA.tx
Spain_mush4.TGA.tx
33_Rona21.tga.tx
33_TG5D0.tga.tx
33_TG5D1.tga.tx
50Petra0.tga.tx
50Petra1.tga.tx
Benjamin_Addington.tga.tx
Berenddevor.tga.tx
Blaze2.tga.tx
Blood1.tga.tx
bucc_1.tga.tx
Bugman.tga.tx
capita4.tga.tx
Cheval.tga.tx
Citiz52xxxxx.tga.tx
Dragoo1.tga.tx
eng_girlbody.tga.tx
engl.tga.tx
Ernandovasces.tga.tx
GovSp1.tga.tx
granie_1.tga.tx
hero_pit_heyn)07.tga.tx
hol_sold_1.tga.tx
hol_sold_2.tga.tx
hol_sold_3.tga.tx
hol_sold_4.tga.tx
hol_sold_5.tga.tx
hol_sold_6.tga.tx
hol_sold_7.tga.tx
hol_sold_8.tga.tx
hu00xxxxx.tga.tx
hu09xxxxx.tga.tx
hu13xxx.tga.tx
hugnt18.tga.tx
indian1.tga.tx
Jack.tga.tx
Lucas.tga.tx
Lukas.tga.tx
MadJackSH.tga.tx
Man6_1.tga.tx
mishele_2.tga.tx
mr16xxxx.tga.tx
mr18xxxx.tga.tx
jy_gg2.tga.tx
Navy_off.tga.tx
Nfficer_6.tga.tx
OfEng3.tga.tx
Off19f2.tga.tx
OffFra18.tga.tx
Offic_Hol_1.tga.tx
Offic_Hol_47.tga.tx
Officer_Hol1.tga.tx
Officerer_09.tga.tx
pcteach.tga.tx
Pirat9.tga.tx
Raymod_B.tga.tx
shkiper.tga.tx
Shp01xxxxxx.tga.tx
Shp09xxx.tga.tx
sold_fra_1.tga.tx
sold_fra_2.tga.tx
sold_fra_3.tga.tx
sold_fra_4.tga.tx
sold_fra_5.tga.tx
sold_fra_6.tga.tx
sold_fra_7.tga.tx
sold_fra_8.tga.tx
sold_fra_1.tga.tx
SpaOfficerr.tga.tx
TomLinch.tga.tx
trader13.tga.tx
Whore01.tga.tx
Wily1.tga.tx

Excellent news…fixed the last of the consistent and prevalent memory leaks:

Unloading
System exit and cleanup:
Mem state: User memory: 800  MSSystem: 800  Blocks: 50
Leak: 'eras2dx9_2012\xinterface\questfilereader\..\..\common_h\templates\string.h' line 38, size 16
Leak: 'eras2dx9_2012\xinterface\questfilereader\..\..\common_h\templates\string.h' line 38, size 16
Leak: 'eras2dx9_2012\xinterface\questfilereader\..\..\common_h\templates\string.h' line 38, size 16
...
50 repeated lines

Now I get this on exit:

Unloading
System exit and cleanup:
Mem state: User memory: 0  MSSystem: 0  Blocks: 0

Zero. Which also means that this will reduce the memory fragmentation, because leaks cause fragmentation that can’t ever be resolved in a game session when those spots in memory are never freed up. So, combined with the smaller textures, and reduced fragmentation, game sessions use less memory, contain greater contiguous memory blocks and the sessions are prolonged, without error. Nice.

I also found one more problem with the pirate missions, when exiting to sea when the AISea object does not have an .Island attribute (this is a bug). Fixed that in scripts/PSHero.c.

I am probably going to release this newer version and make available in my links within a day.

OK, one more thing…

Another new thing with the VS2012 version is that sometimes, on game quit, the app would hang/freeze up and you’d have to kill the process with Task Manager. You were quitting anyway, but still annoying.

There must be difference in how threads left hanging in this new version somehow prevent the .exe from exiting. I found that threads created for the SEA object, are stopped using TerminateThread. This is bad practice as the threads might not finish up and dispose properly. I have now incorporated a couple new events that each thread and the SEA destructor respond to that allows the threads to terminate themselves gracefully and the problem seems to be gone as I’ve not been able to replicate the game-freeze-on-exit problem after many tries now, whereas before, I could get it about 1 out of 10. So I think I’m good.

Gonna go fishing for awhile, then I’ll package things up and put them out there.

New development…the multithread capability was actually broken in the sense that what I thought was causing the game-exit-hangup due to the thread’s inability to gracefully terminate was not really due to the SEA threads because the logic to create those threads was always disabled.

So it was due to something else, and still sometimes happens IF hypterthreading is explicitly disabled. I fixed the logic so that multi SEA threads actually do occur now, and my graceful thread termination works, but with the added bonus that you can actually get multithread now, whereas before you never could with the logic as it stood. Somehow, there is still an occasional problem on game-exit if multithread is DISABLED, but I’ve not yet narrowed the problem. However, again, it’s only when you’re terminating the game and all one has to do is QUIT, then when the Windows prompt that there is a problem comes up, simply CANCEL to terminate the app. It only happens on some save-games I load. And I’ve yet to get it when the fixed hyperthread capability is on, so that’s better.

I’ve also found that the DirectX FPS was being limited due to the instantiating call to Initialize DirectX. I’ve fixed that and the FPS is better overall. Also better to completely turn off the max_fps in the start.ini file, as it adds overhead to manually limit the FPS in a fairly unorthodox and disadvised way.

Files uploaded.

Change some of the start.ini options. Remove max_fps (preface with semicolon), enable hyperthreading (remove semicolon):

;max_fps = 120
HyperThreading = 1

The start.ini files in the downloads show as example. Added some to the Readme.txt files for the possibility of needing the newer VCR for older OS, like WinXP.

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

Did another change.

The detection of processors and whether to enable SSE and Multithread was outdated and inaccurate in the sense it only allowed multi for Intel and no other. I updated the code to determine multicore/multithread and SSE for both Intel and AMD, and also SSE and multi are now enabled by default if the processor supports multiple hardware threads. So no need to explicitly enable in the start.ini if your processor has the ability.

You can of course create multiple software threads without the processor multi-HW thread capability, but I’ve stuck with not enabling it unless the hardware supprorts multicore, as it was originally coded that way.

Granted, I’ve no AMD and not tested that part of the detection, but got the detection code from their site.

Uploading now.

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

That on-game-exit sometimes problem? Could never get it to happen in VS debug mode while running the game…only a release version I can’t get break stops or step through. However, through some debug log messages I sent to the system.log file, I have now got it narrowed to a single function. Message right before the function gets written to the file, prior to the crash, but the message immediately after that function call does not get written. So now I know the culprit and will undoubtedly find the issue.

Good news…I’ve isolated the problem to the SoundService class upon cleaning up/destroy.

In simplified terms, when the game is exiting, there is a loop to iterate the running ‘services’ and call Clear() to delete/destroy the service objects and their memory allocations.

Clear() simply does this:

delete pService;

Where pService is the SoundService pointer. When delete is called, the ‘destructor’ of the SoundService class is called and executed automatically. I put a trace message throughout the SoundService destructor method and at the very end, last statement, I put: api->Trace(“SoundService Destructor end”);

Also, in the Clear() method, I put:

api->Trace(“vmod Clear() enter”);
delete pService;
api->Trace(“vmod Clear() post delete “);
…

When things go well, I see this in the log:

FreeServices = SoundService
vmod Clear() enter
SoundService Destructor
SoundService Destroy Sounds
SoundService Post Close
fmod_system->release() Before
fmod_system->release() After
fmod_system->release() post error check
SoundService Destructor end
vmod Clear() post delete
vmod Clear() leaving
Post Clear

When it crashes, I get this:

FreeServices = SoundService
vmod Clear() enter
SoundService Destructor
SoundService Destroy Sounds
SoundService Post Close
fmod_system->release() Before
fmod_system->release() After
fmod_system->release() post error check
SoundService Destructor end

Notice I never get to the very next statement after the delete statement…the “Clear() post delete” one:

delete pService;
api->Trace(“vmod Clear() post delete “);

What happens during a delete is all ‘automagic’, the C++ compiler puts in the proper execution and the fault actually occurs in ntdll.dll:

Faulting module name: ntdll.dll, version: 6.1.7601.23418, time stamp: 0x5708a73e
Exception code: 0xc0000005
Fault offset: 0x00032a68
Faulting process id: 0x34e8
Faulting module path: C:\Windows\SysWOW64\ntdll.dll

So the actual SoundService destructor completes, but the invisible stuff that Windows does after that is failing. If not an actual bug in Windows, very likely, there could likely be some memory allocated somewhere during the SoundService object that is not properly released prior to the object being called upon to destruct. That might be causing the other ntdll ‘goo’ that happens during an object delete to crash when it tries to clean the object from internal memory.

I’ll sift through the SoundService code and see what I can figure out.

Much better!

First, SoundService was not releasing ‘sounds’ prior to system release, per FMOD: “Make sure any sounds, channelgroups, geometry and dsp objects are released before closing the system object.” I added a routine to do so.

Also, ParticleService was failing on Clear() and I fixed that.

Also, on occasion, the Window message WM_CLOSE called DestroyWindow, but that would sometimes hang and it might have to do if another, hidden window was created by another thread. I don’t see anything explicitly creating the CDebug window in another thread, but just in case, I moved the call to Destroy the CDebug window from after the Main DestroyWindow, to prior.

This is behaving much better when I exit the game. Weird it’s suddenly so finicky as I didn’t have this in VS2010 compile, but things change from version to version of the compilers and the newer, Win7 OS I’m running might also have something to do with requiring more stringent coding methods.

Anyway, I’m uploading the revisions now.

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

More news.

I have now sifted through through the code to adjust for dealing with large addresses, which would convert to a 64 bit number and if for whatever reason a program casts those memory pointers as a numerical value anywhere, it could break things. See here:

http://www.piratesahoy.net/threads/technical-storm-engine-2-8-question-hyperthreading-and-sse.21946/#post-475369

…start.exe main executable (to increase the available RAM the game uses) does actually improve the game performance, however it introduces instability and potential for crashes for no apparent reason.

This program does convert some pointers to a number, as I described, in some various ‘memory service’ procedures. I found all the code that does this and adjusted it to work for large addresses as a LONG64. So now I compiled it as LARGEADDRESSAWARE, which increases the RAM available for the game. If your computer has more than 2 gb memory, the app will be able to use more if needed. Combined with the memory leak fixes, this will ensure that even if there were memory fragmentation, if your computer has 4gb or more, there is no way one should get that OUT OF MEMORY error (which I got awhile back, before the leak fixes, after a many-hour test session) because a contiguous memory allocation should almost always be possible.

I’ve also made it a simple PREPROCESSOR flag in the event this poses a problem, it will be simple to toggle off the LAA compiler option, change my preprocessor value and the code reverts exactly to how it was before.

I’m going to test a bit more, but so far, even with top-down memory allocation turned on my machine, which causes any memory request to automatically receive the highest memory values first, I have not had any problems. Given how that setting works, I should crash pretty quickly: https://support.microsoft.com/en-us/kb/2555189

To enable top-down memory, add the following registry entry under the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
registry subkey:
Name: AllocationPreference
Type: REG_DWORD
Value: 00100000

So far, have eliminated the memory leaks, enabled the SEA multithread (BTW, that was originally coded only for SEA calculations and I note it makes very little difference as I temporarily enabled some of the test info buried in the code to check it out during my sessions), and now capable of higher RAM allocations. This should be an improvement. I’ll give it a go for awhile, then let you know when I post the files.

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

Uploading Large Address enabled. Give them a try:

ERAS.Patch.zip = patch files for original ERAS with fixes and Orazio’s cabin models, walkfiles, and ship camera fixes
AOP2.Patch. = patch files for vanilla COAS with fixes
GOF1.2Patch = patch files for GOF 1.2 with fixes
ERAS2Test.zip = Our source compiled ERAS in DirectX 8
ERAS2TestDX9.zip = Our source compiled ERAS in DirectX 9
AoPTest.zip = Our source compiled vanilla COAS in DirectX 8
AoPTestDX9.zip = Our source compiled vanilla COAS in DirectX 9
GOF1.2Test.zip = Our source compiled GOF 1.2 in DirectX 8
GOF1.2TestDX9.zip = Our source compiled GOF 1.2 in DirectX 9

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

When I first tried the widescreen adjustments for the Character, Ship, Item screen, there were a few minor glitches in some of the Title Caption red background not fully covering the background of the rectangle displaying the caption. There was also a slight bit of truncation in the +/- number displayed in red/green by the skill points. As promised, I saved that low-priority tidbit for later, but now have addressed and fixed that. The files are uploading now.

ERAS.Patch.zip = patch files for original ERAS with fixes and Orazio’s cabin models, walkfiles, and ship camera fixes
AOP2.Patch. = patch files for vanilla COAS with fixes
GOF1.2Patch = patch files for GOF 1.2 with fixes
ERAS2Test.zip = Our source compiled ERAS in DirectX 8
ERAS2TestDX9.zip = Our source compiled ERAS in DirectX 9
AoPTest.zip = Our source compiled vanilla COAS in DirectX 8
AoPTestDX9.zip = Our source compiled vanilla COAS in DirectX 9
GOF1.2Test.zip = Our source compiled GOF 1.2 in DirectX 8
GOF1.2TestDX9.zip = Our source compiled GOF 1.2 in DirectX 9

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

OK, OK, it’s a pain to keep re-downloading these files. But definitely do it this time!

I have great news! That app-hang-on-exit is very likely solved.

During some debugging, I noticed that the DX9 version initiates a few threads that are executing a function: wmt_CSSEShaderCode::ProcessPositionAndColors. What I noticed, is that even after exiting/releasing/destroying DX9 resources, those threads were still running and waiting by the time DestroyWindow was called. I then ran debug in DX8, and it doesn’t initiate these same thread functions. I also noticed that the DX8 version didn’t ever hang-on-close either; this freeze-on-close was a pretty new phenomenon. It struck me as possible that the DX9 difference in execution, with these thread functions, it might be constructing a hidden Window that was explained in my reading as something that could prevent DestroyWindow from ever returning.

So I fired up DirectX PIX for some tedious logging, and then noticed that several objects are never released/destroyed within DX9. And if that happens, you get both a memory leak within DX9 itself, but also prevents DX9 from properly releasing the entire device. This memory leak, if just launching and immediately exiting, was amounting to 600,000+ bytes. The unreleased resources were textures. I spent hours sifting through, looking for any missed Release calls on textures, surfaces, etc. It had looked like I found them all, but after hours of code-review and some testing, nothing done made a difference. Then I read that it can often be a case that the objects created within DirectX must also be released in the reverse order of how they were instantiated, because they can sometimes reference each other. This was daunting. But, I gave it a try, spent some hours finding and reordering the releases as best I could figure.

Holy smokes! It worked! PIX shows no more memory leaks, all objects get destroyed, and if I pause the program just before DestroyWindow call, those DX9 mystery threads no longer appear, though they did prior to the call to release the DirectX 9. I am willing to bet money this will eradicate that hang-on-close problem that would sometimes occur.

Download now, people! 🙂

ERAS.Patch.zip = patch files for original ERAS with fixes and Orazio’s cabin models, walkfiles, and ship camera fixes
AOP2.Patch. = patch files for vanilla COAS with fixes
GOF1.2Patch = patch files for GOF 1.2 with fixes
ERAS2Test.zip = Our source compiled ERAS in DirectX 8
ERAS2TestDX9.zip = Our source compiled ERAS in DirectX 9
AoPTest.zip = Our source compiled vanilla COAS in DirectX 8
AoPTestDX9.zip = Our source compiled vanilla COAS in DirectX 9
GOF1.2Test.zip = Our source compiled GOF 1.2 in DirectX 8
GOF1.2TestDX9.zip = Our source compiled GOF 1.2 in DirectX 9

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

While using top-down memory allocation, I ran into a problem in the geometry procedures where the game casts some pointer values to a 32-bit number type. This does not work and results in a crash. I also encountered discovered a buffer overflow problem in that scrolling text (I was hammering on changing shot types for a long while to watch the text and see what happens…) you can see at the top right of the screen for notifications. It looks like I’ve been able to correct both.

New uploads @

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

Don’t now why I didn’t think of this earlier. Most of my recent work has been to fix/adjust just the start.exe and .dll files, with no changes to other areas of the game. It seems too inconvenient to have someone download the entire set of other files that haven’t changed any time something is fixed. So in the cases where I fix or change anything in the .exe/.dll files, and you already have the other files, you can simply download the JustExecutables.zip. Those are the same for any game, but just make sure you use either DX8 or DX9 (both are contained in the one .zip), depending on which version you are using.

Just watch for any announcement I make, or check the file dates, if it becomes newer/updated. BUt it’s only 9 mb for both, so much more convenient.

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

Hey, welcome back, Orange.

I’ll eventually address your questions, but I’m a bit burnt and want a break, LOL. But, in the meantime, the reason for my crispy burnt nature today, is that I spent hours and hours trying to figure out why in some heavy, many ship battles, cannons and other sounds would go silent; this has been an ongoing problem since vanilla. I’ve even tried to tweak the sound a bit to correct, but to no avail. Today, I eventually figured out why. FMOD and virtual voices.

FMOD provides a way to specify ‘channels’ and there can be many. Supposedly, even if your hardware/software limits those channels, FMOD presumably allows many more than that and will manage it. In fact, the code of this game establishes 512 of them. Well, turns out that FMOD started to virtualize the channel sounds right around #40. So during my battle, all the sail sounds, cannon ball, ship, water, splash and cannon fire sounds, the cannon fire would get virtualized and I’d watch silent cannon fire from both myself, my squadron and my opponents. I actually set up a debug trace log to query each sound for isVirtual and output which ones were being virtualized and their ‘channel #’.

From what I read, any sound with a ‘higher’ priority, will never get virtualized instead of a lower priority sound, even if they are very distant and very low volume (‘higher’ is a bit backward as lower priority numbers are more important, and thus a higher priority, though a lower number value). Turns out, the priority set for all sail sounds in the sound_alias.ini is 10, but all cannon fire is 60. So the sail sounds, though much lower volume, and only discernible at close distances, won’t be virtualized for all those distant ships that I can’t even hear because their sails are too far away. The FMOD rule is that if a sound needs to be virtualized because you are at some sort of limit…it will eliminate the lower priority before the higher priority, and in a ship battle, the cannons get whacked before sail sounds. So, I changed all the sail priorities in the .ini.

Also, there is another feature when initializing FMOD to set all very low volume sounds (due to volume setting/distance) to automatically go virtual if they go below a certain volume. So I set that initialization up, set the ADVANCEDSETTING virtualvol to .001 and voila! My save that I was testing was full of cannon fire, whistling cannon balls, ball splashes…all the sounds that were getting whacked. About freakin’ time!

I’m going to play with it a bit to make sure in my tribulations I didn’t screw anything up. Before my testing/tweaking I kept a copy of the existing sound code for reference/fallback if needed.

I’m so glad that’s over, LOL

Ha! Anyone interested in being able to play full-screen mode and be able to alt-tab to another app, come back and not have it crash like it always has? Just for kicks, thought I’d see if I could fix that. I haven’t yet, but the major hurdle was making sure to release all DEFAULT_POOL resources…that was not done properly and that is why in the system.log during the DirectX ‘Reset’, one would see:

Device try to reset
Device reset bad

This is why it could never work. Well, I tracked them down and I just alt-tabbed and got this:

Device try to reset
Device reset successfully

There is still more work to do, but it shouldn’t be too bad…just time-consuming to make sure all the classes that try to render, need to wait in the Execute/Realize methods. Some of the work had already been done to reconstruct the DEFAULT_POOL resources during a Reset, but since they couldn’t get past the bad reset, it did no good. These don’t look complete, but might save me some time.

Haha! Check this!

Go ahead and go to the original game, change engine.ini top line full screen mode:

full_screen = 1

Save. Launch game, alt-tab to another app window, then alt-tab back. Go ahead. I dare you. Crash, right?

Now download any of the newest DX9 versions here: ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

AoP2TestDX9.zip
ERAS2TestDX9.zip
GOF1.2TestDX9.zip
…or the other GOF ones if you have ’em.

Change start.ini

full_screen = 1

Save. Launch game, alt-tab to another app window, then alt-tab back. Go ahead. I dare you. What? No crash?

It’s not perfect…still some glitches with some textures not always working right, and sometimes shaders. I’ve not yet figured it completely, but the hardest part to overcome looks resolved. Heckuva lot closer than it used to be!

I found a bug in Control Activation, download the newest copies:

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

ERAS.Patch.zip = patch files for ERAS
AOP2.Patch. = patch files for vanilla COAS with fixes
GOF1.2Patch = patch files for GOF 1.2 with fixes
ERAS2Test.zip = Our source compiled ERAS in DirectX 8
ERAS2TestDX9.zip = Our source compiled ERAS in DirectX 9
AoPTest.zip = Our source compiled vanilla COAS in DirectX 8
AoPTestDX9.zip = Our source compiled vanilla COAS in DirectX 9
GOF1.2Test.zip = Our source compiled GOF 1.2 in DirectX 8
GOF1.2TestDX9.zip = Our source compiled GOF 1.2 in DirectX 9

Hot off the presses! Get a new download. Fixes made. If interested about the details: https://buccaneersreef.com/forums/topic/bugs-and-fixes/#post-3368

ERAS, GOF & AoP COAS Files: https://mega.nz/#F!WtMDgRxK!hbeUg86kGLlQAqvWRNwTqg

Well, I’ve been up to no good. A short while ago, decided to resume looking at Pirates of the Caribbean…can it run with my compilations? Soon enough, yes it can.

http://www.piratesahoy.net/threads/potc-vanilla-running-in-2-8-coas-engine.28178/#post-551973

The last two days, also banged out Caribbean tales. Now my compilations can run:

POTC
AoP2: City of Abandoned Ships
AoP: Caribbean Tales
GOF 1.2
GOF 2.0
GOF 2.5
ERAS

Either DirectX 8 or DirectX 9…both work the same.

But I also don’t want 7 different copies of the same executables that are all the same, because there is no difference in the back-end code (there is a difference in DX8 and DX9, but either one can run all my versions of the game), only the Program scripts and Resources used. Wouldn’t it be handy to only have one? Took awhile, but got it done.

A command line switch will indicate which one to play. Then a simple shortcut, with start.exe -COAS for instance would play AoP COAS, start.exe -POTC…etc. Just added the following to the end of start.ini:

[POTC]
program_directory = Program.POTC
resource_directory = RESOURCE.POTC
ini_directory = RESOURCE.POTC\INI
sound path = RESOURCE.POTC\sounds
save_directory = SAVE.POTC

[COAS]
program_directory = Program.aop
resource_directory = C:\Playlogic\Age of Pirates 2\RESOURCE
ini_directory = C:\Playlogic\Age of Pirates 2\RESOURCE\INI
sound path = C:\Playlogic\Age of Pirates 2\RESOURCE\sounds
save_directory = SAVE.aop

[GOF]
program_directory = Program.GOF
resource_directory = C:\Playlogic\GOF\RESOURCE
ini_directory = C:\Playlogic\GOF\RESOURCE\INI
sound path = C:\Playlogic\GOF\RESOURCE\sounds
save_directory = SAVE.GOF

[GOF2]
program_directory = Program.GOF2
resource_directory = C:\Playlogic\GOF2\RESOURCE
ini_directory = C:\Playlogic\GOF2\RESOURCE\INI
sound path = C:\Playlogic\GOF2\RESOURCE\sounds
save_directory = SAVE.GOF2

[GOF25]
program_directory = Program.GOF25
resource_directory = C:\Playlogic\GOF25\RESOURCE
ini_directory = C:\Playlogic\GOF25\RESOURCE\INI
sound path = C:\Playlogic\GOF25\RESOURCE\sounds
save_directory = SAVE.GOF25

[ERAS]
program_directory = Program.ERAS
resource_directory = C:\Playlogic\ERAS\RESOURCE
ini_directory = C:\Playlogic\ERAS\RESOURCE\INI
sound path = C:\Playlogic\ERAS\RESOURCE\sounds
save_directory = SAVE.ERAS

[CT]
program_directory = Program.CT
resource_directory = E:\Age of Pirates - Caribbean Tales\RESOURCE
ini_directory = E:\Age of Pirates - Caribbean Tales\RESOURCE\INI
sound path = E:\Age of Pirates - Caribbean Tales\RESOURCE\sounds
save_directory = SAVE.CT

The bracketed subgroups can be whatever name you wish, as well as the program directory names, but for simplicity and so they stay grouped together, I just used Program dot names to correspond to the group name. But to get the desired result, the command switch must match whatever you make the group name. And of course the needed files are actually present where you indicate.

start.exe with nothing runs the default as normal.
start.exe -COAS runs AoP 2
start.exe -GOF runs 1.2 version
start.exe -CT runs Age of Pirates: Caribbean Tales
…etc.

The resource and sounds and save dirs were easy. However, the Program directory was a difficulty. Unfortunately, that Program path is actually stored as a data point in the game save state, and when a save is loaded, but the Program path (which in my case was always the default), was now different and if they happen to contain different code sets, then all sorts of problems… But, eventually figured a workaround and now I can get away with it.

The beat goes on…

Orazio, you are a star. Thank you for providing this explanation. Between you and I, with that explanation, we might be able to resolve this. At the very least, I now probably know exactly what shader to look at. I just poked around and found that the models use the Caustic_shaders.sha, and that is one that I had to change for DX9; I likely did it wrong.

Combined with your explanation, I found that the model vertex is defined with what is called a ‘fixed pipeline’ in DirectX. That part I did not change, and I see it appears to correlate with what you described. A texture set is set up: D3DFVF_TEX1, D3DFVF_TEX2, D3DFVF_TEX3, D3DFVF_TEX4. And the ‘fixed vertex format’ is set up as: D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_DIFFUSE | D3DFVF_TEXTUREFORMAT2. These are DirectX defined constants. Since I did not have to change that part, it is probably good. Where I messed up is probably in the .sha file, where I also had to correlate that ‘pipeline’ with specific declared types, which was not required in the old way. I see it is probably not correlated properly and I will experiment with a better educated attempt now that I know a bit better about what those .sha declarations are probably supposed to be. I will let you know if I get a better result.

Thanks for the help.

Ugh! New strategy.

I found it has nothing to do with those Caustic shaders, as they never get called by the town models…I think it’s for storms and such.

But I have a new plan to at least determine if I did this, or it was like that when I got the code. I am going to make a copy of this project. Since I figured out definitely that it’s the models, geometry, techniques, and renderer that combine to figure the ‘technique’ for shading and causes this issue, and those four didn’t contribute to prevent the compile of the original version when I got it, I am going to overwrite everything for those pieces with the original code. Then I will compile and see if the shading look OK, or if they do the same thing. If they look right, then it’s something I changed in one of those 4 places. I can then use a tool to compare what those pieces of code look like compared to mine…tweak my changes to better fit the original until it works. If they don’t, then it was like that when I got it and I might struggle to find a fix.

Carrying on…

Aha! Using the above-described method, replacing those 4 components, I do NOT get a green shade AND I see building shadows. So somewhere in my adjustments, something went awry. I will start comparing to find the difference that causes the problem.

I will start with techniques.

Another beneficial change is the message pump loop. This is the main loop to intercept messages, iterate execution/draws. They were using a time tick measurement that only resolves to roughly 15 ms per tick and Sleep command to throttle it, but I thought it would be better to use a higher resolution timer, down to clock counts per second…like microseconds, then instead of Sleep, a message wait-for that times out after 3 milliseconds, but will immediately time-out if a Windows message alerts it (like a mouse-move or something), to relinquish control back. This ‘alertable’ type of sleep seemed more appropriate.

I like it better so far.

Nearing ready…

I noticed the other day, LarryHookins over at PA! mentioned demasting CTDs. Alas! I was very glad he briefly mentioned that age-old, notorious problem, as I had almost forgotten about it. Ages ago, I had actually turned that off in my games, due to the dismasting instability causing CTDs, so the phenomenon had pretty much slipped from my memory (turn it off by assigning all damage in SHIP_MAST_TOUCH_BALL case of Ship_MastDamage() function to zero). If you make it a value of 1, anytime a shot hits the mast, it automatically demasts. I set about to debug and set the mast damage to 1 for all cases, then started rocking some action to debug this on the back-end. Got it resolved; no more crashes. The best way to debug was to launch GOF 1.2, find a Dutch merchant convoy protected by a few military ships (for some reason, the Dutch ships in GOF 1.2 are the worst offenders…something to do with the model geometry and in some cases, the lights info is actually what causes the problem). I could crash near instantaneously in every engagement. Not anymore though, so thank you LarryHookins for bringing up this forgotten tidbit 🙂

I want to run a bit more, but I will soon be able to offer Orazio an improved, missing-shadows-are-back, greenish-tint-gone, demasts-no-longer-crash-game version.

LOL…Pieter can suck it! New Horizons running DX9 and 2.8 engine. Just got to launch in a couple hours.

Ha! Look what we did with the flags yesterday. A few simple property additions and super flexible…no stupid hardcodings.

Just a sample of the power and control to simplify and improve things now. Starting to add features now, instead of simply bug/crash fixes. Flags are treated with a slicker method. To determine pennant vs. flag, POTC New Horizons had a special group name for labels. We don’t need that…simply measure the length/width ratio and add a few properties:

rigging.ini

[FLAGS]
TextureName = flagall_ship.new2.tga.tx
TextureRows = 5
TextureCols = 10

[PENNANT]
TextureName = pennant_ship.tga.tx
TextureRows = 5
TextureCols = 2

Standard flags are in one texture, pennants are in another.

AIShip.c

object Sail, Rope, Flag, Vant, Pennant;

Flag.ratioLimit = 1;
Flag.sizeRatio = 2.5;
CreateEntity(&Flag, ”Flag”);

Pennant.ratioExceeds = 1;
Pennant.sizeRatio = 2.5;
Pennant.iniSection = ”PENNANT”;
CreateEntity(&Pennant, ”Flag”);

BattleInterface.c

ref procGetRiggingData()
{
	int n;
	int retVal = 0;

	string datName = GetEventData();
	n = GetEventData();
	n = GetEventData();
	aref chr = GetEventData();
	int factor = 0;
		
	if(datName == "FLAGS"){
	if(CheckAttribute(chr, "RealEncounterType")){
		if(sti(chr.RealEncounterType) < 9)
			factor = 5;
	}
	else { if(CheckAttribute(chr, "EncType") && chr.EncType == "trade")
		factor = 5; }
	if(factor == 5 && CheckAttribute(chr, "Ship.Type.Mode") && chr.Ship.Type.Mode != "trade") {
		factor = 0;
	}
	if(CheckAttribute(chr, "HeroParam.HeroType")){
		if(chr.HeroParam.HeroType == "Merchant" || chr.HeroParam.HeroType == "Carpenter")
			factor = 5;
	}
	
	switch (n)
	{			
		case HOLLAND: retVal = factor + rand(4); if(retVal == 0) retVal = 1; break;
		case ENGLAND: retVal = 10 + factor + rand(4); break;
		case FRANCE: retVal = 20 + factor + rand(4); break;
		case SPAIN: retVal = 30 + factor + rand(4); break;
		case PIRATE: retVal = 40 + (rand(9)); break;
		retVal = 0;
	}
	}
	else { if(datName == "PENNANT"){

		switch (n)
		{			
		case HOLLAND: retVal = rand(1); break;
		case ENGLAND: retVal = 2 + rand(1); break;
		case FRANCE: retVal = 4 + rand(1); break;
		case SPAIN: retVal = 6 + rand(1); break;
		case PIRATE: retVal = 8; break;
		retVal = 9;
		}

	} }

	return &retVal;
}

Any flag locator in the ship, less than 2.5 length vs. width is a flag and pulled from the appropriate texture, any flag locator greater/equal 2.5 length ratio is a pennant and pulled from its texture. Simple. We do similarly for merchant flags.

To accommodate POTC New Horizon’s method, for their special label group in their ship models, same .ini info, but change the Entity instantiation:

Pennant.groupName = “penn”;
Pennant.iniSection = ”PENNANT”;
CreateEntity(&Pennant, ”Flag”);

Done. Will automagically work and no need for those extra .dll files they duplicated from rigging.dll and hex-edited to look for the different labels.

With the above single property, mine will now look for “penn” labels, instead of the default “flag” labels and display them accordingly; this is what I will change in my port of New Horizons, so I can get rid of all that extra code they needed in their scripts. Same for personal/pirate flags; they were limited in that the original game presumed a one-row texture file and they needed to dupe everything up to point at a bunch of different 8 column textures. Mine supports 2D texture files and right now, our latest has 10 columns by 5 rows, so 50 different flags and no need for multiple files to get the flag variety. If we want 100, just make that one texture file 10 by 10. So again, in New Horizons I will simply combine all the flag textures into one file (maybe a couple…can do that too), do away with all that other machination in the script to send the flag delete/init calls and simply query the appropriate character attribute to determine the correct flag in the callback (which is also something I added…send the character reference back to the flag processing event callback, so I know who we’re dealing with).

Just for comparison, you see above what I do now to support this…here is what New Horizon’s had to do. Yikes:

[FLAGS]
TexShpName0 = flags\shpflg1.tga
TexShpCount0 = 8
TexPntName0 = flags\shppnt1.tga
TexPntCount0 = 8
TexMerName0 = flags\merflg1.tga
TexMerCount0 = 8
TexMePName0 = flags\merpnt1.tga
TexMePCount0 = 8
TexPiFName0 = flags\pirflg1.tga
TexPiFCount0 = 8
TexPiPName0 = flags\pirpnt1.tga
TexPiPCount0 = 8
TexPeFName0 = flags\perflg1.tga
TexPeFCount0 = 8
TexPePName0 = flags\perpnt1.tga
TexPePCount0 = 8
TexFrtName0 = flags\frtflg1.tga
TexFrtCount0 = 8
TexShpName1 = flags\shpflg2.tga
TexShpCount1 = 8
TexPntName1 = flags\shppnt2.tga
TexPntCount1 = 8
TexMerName1 = flags\merflg2.tga
TexMerCount1 = 8
TexMePName1 = flags\merpnt2.tga
TexMePCount1 = 8
TexPiFName1 = flags\pirflg2.tga
TexPiFCount1 = 8
TexPiPName1 = flags\pirpnt2.tga
TexPiPCount1 = 8
TexPeFName1 = flags\perflg2.tga
TexPeFCount1 = 8
TexPePName1 = flags\perpnt2.tga
TexPePCount1 = 8
TexFrtName1 = flags\frtflg2.tga
TexFrtCount1 = 8
TexShpName2 = flags\shpflg3.tga
TexShpCount2 = 8
TexPntName2 = flags\shppnt3.tga
TexPntCount2 = 8
TexMerName2 = flags\merflg3.tga
TexMerCount2 = 8
TexMePName2 = flags\merpnt3.tga
TexMePCount2 = 8
TexPiFName2 = flags\pirflg3.tga
TexPiFCount2 = 8
TexPiPName2 = flags\pirpnt3.tga
TexPiPCount2 = 8
TexPeFName2 = flags\perflg3.tga
TexPeFCount2 = 8
TexPePName2 = flags\perpnt3.tga
TexPePCount2 = 8
TexFrtName2 = flags\frtflg3.tga
TexFrtCount2 = 8
TexShpName3 = flags\shpflg4.tga
TexShpCount3 = 8
TexPntName3 = flags\shppnt4.tga
TexPntCount3 = 8
TexMerName3 = flags\merflg4.tga
TexMerCount3 = 8
TexMePName3 = flags\merpnt4.tga
TexMePCount3 = 8
TexPiFName3 = flags\pirflg4.tga
TexPiFCount3 = 8
TexPiPName3 = flags\pirpnt4.tga
TexPiPCount3 = 8
TexPeFName3 = flags\perflg4.tga
TexPeFCount3 = 8
TexPePName3 = flags\perpnt4.tga
TexPePCount3 = 8
TexFrtName3 = flags\frtflg4.tga
TexFrtCount3 = 8
TexShpName4 = flags\shpflg5.tga
TexShpCount4 = 8
TexPntName4 = flags\shppnt5.tga
TexPntCount4 = 8
TexMerName4 = flags\merflg5.tga
TexMerCount4 = 8
TexMePName4 = flags\merpnt5.tga
TexMePCount4 = 8
TexPiFName4 = flags\pirflg5.tga
TexPiFCount4 = 8
TexPiPName4 = flags\pirpnt5.tga
TexPiPCount4 = 8
TexPeFName4 = flags\perflg5.tga
TexPeFCount4 = 8
TexPePName4 = flags\perpnt5.tga
TexPePCount4 = 8
TexFrtName4 = flags\frtflg5.tga
TexFrtCount4 = 8
TexShpName5 = flags\shpflg6.tga
TexShpCount5 = 8
TexPntName5 = flags\shppnt6.tga
TexPntCount5 = 8
TexMerName5 = flags\merflg6.tga
TexMerCount5 = 8
TexMePName5 = flags\merpnt6.tga
TexMePCount5 = 8
TexPiFName5 = flags\pirflg6.tga
TexPiFCount5 = 8
TexPiPName5 = flags\pirpnt6.tga
TexPiPCount5 = 8
TexPeFName5 = flags\perflg6.tga
TexPeFCount5 = 8
TexPePName5 = flags\perpnt6.tga
TexPePCount5 = 8
TexFrtName5 = flags\frtflg6.tga
TexFrtCount5 = 8
TexPeFName6 = flags\perflg7.tga
TexPeFCount6 = 8
TexPePName6 = flags\perpnt7.tga
TexPePCount6 = 8
TexPeFName7 = flags\perflg8.tga
TexPeFCount7 = 8
TexPePName7 = flags\perpnt8.tga
TexPePCount7 = 8
EnglandPennonTex = 0
SpanishPennonTex = 0
FrenchPennonTex = 0
PiratePennonTex = 0
EnglishFlagTex = 1
SpanishFlagTex = 4
FrenchFlagTex = 2
PirateFlagTex = 5
PortugalFlagTex = 3
DatchFlagTex = 0
PersonalFlagTex = 7
AmericaFlagTex = 8

#define FLAG_ENSIGN    "E"
#define FLAG_PENNANT   "P"
#define FLAG_NONE      "N"

#define SHIP_FLAG      -2
#define SHIP_PENNANT   -3

int CurrentShip = 0;
int CurrentFlag = 0;
int ShipFlagsQuantity = -1;
bool bShipWithoutPennants = false;

#event_handler("GetRiggingData", "procGetRiggingData");
ref procGetRiggingData()
{
	int n;
	int retVal = 0;
	int locidx = FindLoadedLocation();
	bool PirateOverride = false;															// PB: For Pirate Flags on Forts and Ashore
	ref chr;

	string datName = GetEventData();
	if (datName == "GetFlagTexNum") {
		n = GetEventData();
		n = GetEventData();
		if (n == SHIP_FLAG || n == SHIP_PENNANT) {
			if (locidx < 0)
				chr = GetCharacter(Ships[CurrentShip]);
			else
				chr = GetCharacter(iShips[CurrentShip]);
			if (ShipFlagsQuantity == -1) {
				ShipFlagsQuantity = GetShipFlagsQuantity(chr);
				bShipWithoutPennants = ShipWithoutPennants(chr);
				if (!bShipWithoutPennants) ShipFlagsQuantity *= 2;
				CurrentFlag = 0;
			}
			int pos = CurrentFlag;
			if (n == SHIP_PENNANT) {
				pos -= (ShipFlagsQuantity / 2);
			}
			string FlagType = GetShipFlagType(chr, pos);
			if (bShipWithoutPennants) {
				if (n == SHIP_PENNANT) FlagType = FLAG_ENSIGN;
				if (FlagType == FLAG_PENNANT) {
					n = SHIP_FLAG;
					FlagType = FLAG_ENSIGN;
				}
			}
			CurrentFlag++;
			if (FlagType == FLAG_NONE) {
				retVal = FLAGS_NULL_PICTURE_TEXTURE_INDEX;
				return &retVal;
			}
			if (FlagType == FLAG_ENSIGN && n == SHIP_PENNANT) {
				retVal = FLAGS_NULL_PICTURE_TEXTURE_INDEX;
				return &retVal;
			}
			if (FlagType == FLAG_PENNANT && n == SHIP_FLAG && bShipWithoutPennants == false) {
				retVal = FLAGS_NULL_PICTURE_TEXTURE_INDEX;
				return &retVal;
			}
		} else {
			chr = GetCharacter(n);
			PirateOverride = true;															// PB: For Pirate Flags on Forts and Ashore
		}
		n = sti(chr.nation);
		switch (n)
		{
			case HOLLAND:          retVal = 0;                                break;
			case ENGLAND:          retVal = 1;                                break;
			case FRANCE:           retVal = 2;                                break;
			case PORTUGAL:         retVal = 3;                                break;
			case SPAIN:            retVal = 4;                                break;
			case PIRATE:
				if(PirateOverride) retVal = 6;												// PB: For Pirate Flags on Forts and Ashore
				else			   retVal = GetPirateFlag(chr, &n);           break;
			case GUEST1_NATION:    retVal = 5;                                break;
			case GUEST2_NATION:    retVal = 6;                                break;
			case PRIVATEER_NATION: retVal = GetPersonalFlag(chr, &n);         break;
			case UNKNOWN_NATION:   retVal = FLAGS_NULL_PICTURE_TEXTURE_INDEX; break;		//added by KAM		// changed after build 11 by KAM
			case NEUTRAL_NATION:   retVal = FLAGS_NULL_PICTURE_TEXTURE_INDEX; break;		//added by KAM
			case PERSONAL_NATION:  retVal = GetPersonalFlag(chr, &n);         break;
		}
	}
	return &retVal;
}

int GetShipFlagsQuantity(ref chr)
{
	int iShipType = GetCharacterShipType(chr);
	if (iShipType < 0 || iShipType == SHIP_NOTUSED) return 0;
	ref rShip; makeref(rShip, ShipsTypes[iShipType]);
	aref arShip; makearef(arShip, chr.Ship);
	if (!CheckAttribute(rShip, "Flags")) return 0;
	int ret = 0;
	aref arFlags; makearef(arFlags, rShip.Flags);
	int nMasts = GetAttributesNum(arFlags);
	for (int m = 0; m < nMasts; m++)
	{
		aref arFlag = GetAttributeN(arFlags, m);
		string sMast = GetAttributeName(arFlag);
		if (GetLocalShipAttrib(arShip, rShip, "Ship.Masts." +sMast) == "1") continue;
		ret += GetAttributesNum(arFlag);
	}
	return ret;
}

string GetShipFlagType(ref chr, int pos)
{
	int iShipType = GetCharacterShipType(chr);
	if (iShipType < 0 || iShipType == SHIP_NOTUSED) return FLAG_ENSIGN;
	aref arShip; makearef(arShip, chr.Ship);
	ref rShip; makeref(rShip, ShipsTypes[iShipType]);
	if (!CheckShipAttribute(arShip, rShip, "Flags")) return FLAG_ENSIGN;
	int n = 0;
	aref arMasts; makearef(arMasts, rShip.Flags);
	int nMasts = GetAttributesNum(arMasts);
	int m = 0;
	int i = 1;
	if (CheckAttribute(chr, "surrendered")) return FLAG_NONE; // Screwface: to fix the white flags
	while (i <= nMasts)
	{
		string sMast = "Mast" + m;
		if (CheckAttribute(chr, "Ship.Masts." + sMast) == true && GetLocalShipAttrib(arShip, rShip, "Ship.Masts." + sMast) == "1") {
			m++;
			continue;
		}
		if (!CheckShipAttribute(arShip, rShip, "Flags." + sMast)) {
			m++;
			continue;
		}
		i++;
		aref arFlags; makearef(arFlags, rShip.Flags.(sMast));
		int nFlags = GetAttributesNum(arFlags);
		for (int f = 1; f <= nFlags; f++)
		{
			string sFlag = "Flag" + f;
			if (!CheckShipAttribute(arShip, rShip, "Flags." + sMast + "." + sFlag)) continue;
			if (n == pos) return GetLocalShipAttrib(arShip, rShip, "Flags." + sMast + "." + sFlag);
			n++;
			m++;
		}
	}
	return FLAG_ENSIGN;
}

bool ShipWithoutPennants(ref chr)
{
	aref arShip; makearef(arShip, chr.Ship);
	ref rShip = GetShipByType(GetCharacterShipType(chr));
	if (CheckShipAttribute(arShip, rShip, "Flags.NoPennants")) return sti(GetLocalShipAttrib(arShip, rShip, "Flags.NoPennants"));
	return false;
}

void SetFortFlag(ref rModel)
{
	int i, idx, iNation;
	ref chr;
	if (!CheckAttribute(rModel, "fortcmdridx")) return;
	idx = sti(rModel.fortcmdridx);
	if (idx < 0) return;
	chr = GetCharacter(idx);
	SendMessage(&Flag, "li", MSG_FLAG_DEL_GROUP, &rModel);
	if (IsEntity(&MerchantFlag)) SendMessage(&MerchantFlag, "li", MSG_FLAG_DEL_GROUP, &rModel);
	for (i = 0; i < PIRATEFLAGS_TEXTURES_QUANTITY; i++)
	{
		if (IsEntity(&PirateFlag[i])) SendMessage(&PirateFlag[i], "li", MSG_FLAG_DEL_GROUP, &rModel);
	}
	for (i = 0; i < PERSONALFLAGS_TEXTURES_QUANTITY; i++)
	{
		if (IsEntity(&PersonalFlag[i])) SendMessage(&PersonalFlag[i], "li", MSG_FLAG_DEL_GROUP, &rModel);
	}
	SendMessage(&FortFlag, "li", MSG_FLAG_DEL_GROUP, &rModel);
	iNation = sti(chr.nation);
	switch (iNation) {
/*		case PIRATE:
			GetPirateFlag(chr, &i);
			SendMessage(&PirateFlag[i], "lil", MSG_FLAG_INIT_NOCHAR, &rModel, idx);
		break;
		case PRIVATEER_NATION:
			GetPersonalFlag(chr, &i);
			SendMessage(&PersonalFlag[i], "lil", MSG_FLAG_INIT_NOCHAR, &rModel, idx);
		break;*/
		case PERSONAL_NATION:
			GetPersonalFlag(chr, &i);
			SendMessage(&PersonalFlag[i], "lil", MSG_FLAG_INIT_NOCHAR, &rModel, idx);
		break;
		// default:
			SendMessage(&FortFlag, "lil", MSG_FLAG_INIT_NOCHAR, &rModel, idx);
	}
}

void SetShipFlag(int chridx)
{
	if (chridx < 0) return;
	ref chr = GetCharacter(chridx);
	ref Pchar = GetMaincharacter();
	if (GetShipFlagsQuantity(chr) == 0 || CharacterIsDead(chr) == true || CheckAttribute(chr, "curshipnum") == false) return;
	int i = 0;
	int shippos = sti(chr.curshipnum);
	int ship_quantity = 0;
	if (FindLoadedLocation() >= 0)
		ship_quantity = locNumShips;
	else
		ship_quantity = iNumShips;
	int model_no = ShipModelrList[shippos];
	int next_model_no = -1;
	if (shippos < ship_quantity) {
		next_model_no = ShipModelrList[shippos + 1];
		if (next_model_no == -1) next_model_no = GetCurrentModelrNumber();
	}
	aref arModel;
	CurrentShip = shippos;
	ShipFlagsQuantity = -1;
	int iNation = sti(chr.nation);
	int j;
	if (FindClass(&arModel, "modelr")) {
		i++;
		while (FindClassNext(&arModel))
		{
			if (i >= model_no && i < next_model_no) {
				SendMessage(&Flag, "li", MSG_FLAG_DEL_GROUP, &arModel);
				if (IsEntity(&Pennant)) SendMessage(&Pennant, "li", MSG_FLAG_DEL_GROUP, &arModel);
				SendMessage(&MerchantFlag, "li", MSG_FLAG_DEL_GROUP, &arModel);
				if (IsEntity(&MerchantPennant)) SendMessage(&MerchantPennant, "li", MSG_FLAG_DEL_GROUP, &arModel);
				for (j = 0; j < PIRATEFLAGS_TEXTURES_QUANTITY; j++)
				{
					if (IsEntity(&PirateFlag[j])) SendMessage(&PirateFlag[j], "li", MSG_FLAG_DEL_GROUP, &arModel);
					if (IsEntity(&PiratePennant[j])) SendMessage(&PiratePennant[j], "li", MSG_FLAG_DEL_GROUP, &arModel);
				}
				for (j = 0; j < PERSONALFLAGS_TEXTURES_QUANTITY; j++)
				{
					if (IsEntity(&PersonalFlag[j])) SendMessage(&PersonalFlag[j], "li", MSG_FLAG_DEL_GROUP, &arModel);
					if (IsEntity(&PersonalPennant[j])) SendMessage(&PersonalPennant[j], "li", MSG_FLAG_DEL_GROUP, &arModel);
				}
				SendMessage(&FortFlag, "li", MSG_FLAG_DEL_GROUP, &arModel);
				switch (iNation) {
					case PIRATE:
						GetPirateFlag(chr, &j);
						SendMessage(&PirateFlag[j], "lil", MSG_FLAG_INIT, &arModel, SHIP_FLAG);
						if (IsEntity(&PiratePennant[j])) SendMessage(&PiratePennant[j], "lil", MSG_FLAG_INIT, &arModel, SHIP_PENNANT);
					break;
					case PRIVATEER_NATION:
						GetPersonalFlag(chr, &j);
						SendMessage(&PersonalFlag[j], "lil", MSG_FLAG_INIT, &arModel, SHIP_FLAG);
						if (IsEntity(&PersonalPennant[j])) SendMessage(&PersonalPennant[j], "lil", MSG_FLAG_INIT, &arModel, SHIP_PENNANT);
					break;
					case PERSONAL_NATION:
						GetPersonalFlag(chr, &j);
						SendMessage(&PersonalFlag[j], "lil", MSG_FLAG_INIT, &arModel, SHIP_FLAG);
						if (IsEntity(&PersonalPennant[j])) SendMessage(&PersonalPennant[j], "lil", MSG_FLAG_INIT, &arModel, SHIP_PENNANT);
					break;
					case NEUTRAL_NATION:
						SendMessage(&FortFlag, "lil", MSG_FLAG_INIT, &arModel, SHIP_FLAG);
					break;
					// default:
						if (IsEntity(&MerchantFlag) && IsShipMerchant(chr)) {
							SendMessage(&MerchantFlag, "lil", MSG_FLAG_INIT, &arModel, SHIP_FLAG);
							if (IsEntity(&MerchantPennant)) SendMessage(&MerchantPennant, "lil", MSG_FLAG_INIT, &arModel, SHIP_PENNANT);
						} else {
							SendMessage(&Flag, "lil", MSG_FLAG_INIT, &arModel, SHIP_FLAG);
							if (IsEntity(&Pennant)) SendMessage(&Pennant, "lil", MSG_FLAG_INIT, &arModel, SHIP_PENNANT);
						}
				}
			}
			if (next_model_no > -1 && i >= next_model_no) return;
			i++;
		}
	}
}

void SetTownFlag(ref loc, object mdl)
{
	int i, idx, iNation;
	string town;
	ref chr;
	if (!CheckAttribute(loc, "townsack")) return;
	SendMessage(&Flag, "li", MSG_FLAG_DEL_GROUP, &mdl);
	SendMessage(&MerchantFlag, "li", MSG_FLAG_DEL_GROUP, &mdl);
	for (i = 0; i < PIRATEFLAGS_TEXTURES_QUANTITY; i++)
	{
		if (IsEntity(&PirateFlag[i])) SendMessage(&PirateFlag[i], "li", MSG_FLAG_DEL_GROUP, &mdl);
		if (IsEntity(&PiratePennant[i])) SendMessage(&PiratePennant[i], "li", MSG_FLAG_DEL_GROUP, &mdl);
	}
	for (i = 0; i < PERSONALFLAGS_TEXTURES_QUANTITY; i++)
	{
		if (IsEntity(&PersonalFlag[i])) SendMessage(&PersonalFlag[i], "li", MSG_FLAG_DEL_GROUP, &mdl);
		if (IsEntity(&PersonalPennant[i])) SendMessage(&PersonalPennant[i], "li", MSG_FLAG_DEL_GROUP, &mdl);
	}
	SendMessage(&FortFlag, "li", MSG_FLAG_DEL_GROUP, &mdl);
	town = loc.townsack;
	iNation = GetTownNation(town);
	idx = GetTownGovernorIndex(town);
	if (idx < 0) idx = GetTownFortCommanderIndex(town, 0);
	if (idx < 0) idx = GetMainCharacterIndex();
	chr = GetCharacter(idx); // PB
	switch (iNation) {
/*		case PIRATE:
			GetPirateFlag(chr, &i);
			SendMessage(&PirateFlag[i], "lil", MSG_FLAG_INIT_NOCHAR, &mdl, idx);
		break;
		case PRIVATEER_NATION:
			GetPersonalFlag(chr, &i);
			SendMessage(&PersonalFlag[i], "lil", MSG_FLAG_INIT_NOCHAR, &mdl, idx);
		break;*/
		case PERSONAL_NATION:
			GetPersonalFlag(chr, &i);
			SendMessage(&PersonalFlag[i], "lil", MSG_FLAG_INIT_NOCHAR, &mdl, idx);
		break;
		// default:
			SendMessage(&FortFlag, "lil", MSG_FLAG_INIT_NOCHAR, &mdl, idx);
	}
}

void RefreshFlags()
{
	if (FindLoadedLocation() >= 0 && locNumShips > 0) {
		SetEventHandler("frame", "BLI_SetFlags", 1);
		return;
	}
	if (bSeaActive && !bAbordageStarted) {
		SetEventHandler("frame", "BI_SetFlags", 1);
		return;
	}
}

// Screwface
void FlagsDelay()
{
	if (FindLoadedLocation() >= 0 && locNumShips > 0) {
		SetEventHandler("frame", "BLI_FlagsDelay", 1);
		return;
	}
	if (bSeaActive && !bAbordageStarted) {
		SetEventHandler("frame", "BI_FlagsDelay", 1);
		return;
	}
}

int GetPirateFlag(ref chr, int ntex)
{
	ntex = 0;
	// Use character-specific flag if available
	if (CheckAttribute(chr, "Flags.Pirate.texture")) ntex = sti(chr.Flags.Pirate.texture);
	if (CheckAttribute(chr, "Flags.Pirate")) return sti(chr.Flags.Pirate);
	if (IsCompanion(chr))
	{
		ref PChar = GetMainCharacter();
		ntex = sti(PChar.Flags.Pirate.texture);
		return sti(PChar.Flags.Pirate);
	}
	else
	{
		ref cmdr = Group_GetGroupCommander(GetGroupIDFromCharacter(chr));
		if (!CheckAttribute(cmdr, "Flags.Pirate") || !CheckAttribute(cmdr, "Flags.Pirate.texture")) {
			ntex = rand(PIRATEFLAGS_TEXTURES_QUANTITY - 2); //PW: -2 to disable last row in random encounters
			cmdr.Flags.Pirate.texture = ntex;
			cmdr.Flags.Pirate = rand(FLAGS_PICTURES_QUANTITY_PER_TEXTURE - 2); // PB: -2 to disable last column in random encounters
		}
		ntex = sti(cmdr.Flags.Pirate.texture);
		chr.Flags.Pirate.texture = ntex;
		chr.Flags.Pirate = sti(cmdr.Flags.Pirate);
		return sti(cmdr.Flags.Pirate);
	}
}

int GetPersonalFlag(ref chr, int ntex)
{
	// PB -->
	// Use character-specific flag if available
	if (CheckAttribute(chr, "Flags.Personal.texture")) ntex = sti(chr.Flags.Personal.texture);
	if (CheckAttribute(chr, "Flags.Personal")) return sti(chr.Flags.Personal);

	// Otherwise use the player's own flag
	ref PChar = GetMainCharacter();
	ntex = sti(PChar.Flags.Personal.texture);
	return sti(PChar.Flags.Personal);
	// PB <--
/*	ntex = 0;
	if(IsCompanion(chr))
	{
		ref PChar = GetMainCharacter();
		ntex = sti(PChar.Flags.Personal.texture);
		return sti(PChar.Flags.Personal);
	}
	else
	{
		if (CheckAttribute(chr, "Flags.Personal.texture")) ntex = sti(chr.Flags.Personal.texture);
		if (CheckAttribute(chr, "Flags.Personal")) return sti(chr.Flags.Personal);
		ref cmdr = Group_GetGroupCommander(GetGroupIDFromCharacter(chr));
		if (!CheckAttribute(cmdr, "Flags.Personal"))
		{
			ntex = rand(PERSONALFLAGS_TEXTURES_QUANTITY - 1);
			cmdr.Flags.Personal.texture = ntex;
			cmdr.Flags.Personal = rand(FLAGS_PICTURES_QUANTITY_PER_TEXTURE - 1);
			chr.Flags.Personal.texture = ntex;
			chr.Flags.Personal = sti(cmdr.Flags.Personal);
			return sti(chr.Flags.Personal);
		}
		ntex = sti(cmdr.Flags.Personal.texture);
		return sti(cmdr.Flags.Personal);
	}*/
}