New Horizons on JLB Maelstrom 2.8.2 engine

[pedrwyth]

Had a further look at New Horizons on @ChezJfrey 's Maelstrom 2.8.2 engine. A short spin through the opening few scenes raises a few issues

The random voice animations are missing - system log shows an extra \ in the reported problem path name

Can't find cache for sound !!!!RESOURCE\sounds\\VOICE\English\Dut_m_a_031.wav

The officer ability interface screen doesn't appear when you try and see their qualities prior to hiring

error.log shows

COMPILE ERROR - file: interface\officer.c; line: 44
Duplicate variable name: PChar

Some characters (like Nathaniel Hawk) have portraits but many (like Julian Mcallister - freeplay default, either Ardent) do not. There is a further log in system.log

Can't load texture1 RESOURCE\textures\face_558.tga.tx

or other similar for other faces which may relate to this?

I don't know which, if any, of these relate directly to the compile of the engine which @ChezJfrey may take a further look at and which are the sort of "remaining issues" in the front end scripts left for New Horizon modders to resolve to work in 2.8.

 

[ChezJfrey]

#1
Typically, the extra backslashes are ignored, so that is not likely the problem for the missing sound file.

In Greetings_alias.ini I show:

[Gr_Friedrich Corleis]
...
name = VOICE\ENGLISH\Dut_m_a_031.wav

With that full \ENGLISH as part of the path to the .wav, but in my resource content, the actual path to that file is VOICE\Dut_m_a_031.wav

So, presumably, those VOICE files should all be moved to the ENGLISH subdir, given that is their definition in the alias file?

#2
To make the game more consistent with later versions, I added a pchar definition in globals.c. Therefore, all other definitions that were of global scope needed to be removed. I missed it in officer.c. Should change line 44 to remove it because it's already defined at global scope:

//ref PChar;

#3
I changed the texture lookup in the engine, to start at the requested directory and if not found, iterate back each subdir of the requested path, and look in each one, until reaching the root texture directory. Prior to my change, if SetTexturePath was issued in the script, it would search back a max of 3 dirs, and without a SetTexturePath call, it failed for first attempt. Now, if fail, it keeps searching backward. An unfortunate side effect is that if you ask for "dira\subdirb\subdirc\fileX", and it can't find the fileX in subdirc, subdirb, dira, the message will be "Can't find dira\fileX, even though you originally asked for dira\subdirb\subdirc\fileX. This makes it a little trickier to identify the code that initiated the request.

With that said, it looks like these files use faceid: LandInterface.c, character.c, gamble.c, itemsbox.c, money.c, officer.c, option_screen.c, ransack_main.c, select_storyline.c, transfer_cannons.c, transfer_crew.c:

Each one of them prepends with "interfaces\portraits\xxx\" and I found face_558.tga.tx in each of the interfaces\portraits subdirs.

LandInterface.c does have one function, SetCharacterIconData that looks in battle_interface\portraits, but that dir does not contain face_558.tga.tx. I suppose my question, is what particular screen or interface was this portrait missing? Can you direct me to the screen you noticed this, so I can look at the code that generates?

 

[pedrwyth]

Thanks @ChezJfrey Yep 1# and 2# resolved.

The portrait I refer to is the one in the now AOP style character icon. Here's an example

I also noted that the sell button in the shipyard is not getting its text.

Meant to come from IsEnableSellShip() in interface/shipyard.c

string SellButton = "Sell";
    makearef(arCurShip, Characters[cn].ship); // PRS3
    switch (ShipAcquiredState(arCurShip))
    {
        case "bought":    SellButton = "Sell Owned Ship";        break;
        case "taken":    SellButton = "Auction Prize Ship";    break;
        case "pirated":    SellButton = "Sell Pirated Ship";    break;
    }
    SendMessage(&GameInterface, "lsls", MSG_INTERFACE_MSG_TO_NODE, "SELLSHIP_BUTTON", 0, SellButton);

So I presume the call to the engine should be handled differently now?

EDIT PS There are a number of other instances of buttons without text which probably relate to this type of call being used elsewhere, so if you can give me a working call to do this, I can search out the others ENDEDIT

 

[ChezJfrey]

Meant to come from IsEnableSellShip() in interface/shipyard.c

string SellButton = "Sell";
    makearef(arCurShip, Characters[cn].ship); // PRS3
    switch (ShipAcquiredState(arCurShip))
    {
        case "bought":    SellButton = "Sell Owned Ship";        break;
        case "taken":    SellButton = "Auction Prize Ship";    break;
        case "pirated":    SellButton = "Sell Pirated Ship";    break;
    }
    SendMessage(&GameInterface, "lsls", MSG_INTERFACE_MSG_TO_NODE, "SELLSHIP_BUTTON", 0, SellButton);

So I presume the call to the engine should be handled differently now?

EDIT PS There are a number of other instances of buttons without text which probably relate to this type of call being used elsewhere, so if you can give me a working call to do this, I can search out the others ENDEDIT

Portrait problem is what I suspected in SetCharacterIconData. Turns out that was a function directly copied from COAS and the path is incorrect for NH. Texture path should have been changed to interfaces\portraits\64.

Some research shows that a zero message (number following node name in message) to node type TEXTBUTTON (as defined for SELLSHIP_BUTTON in shipyard.ini) has been changed in the engine. If the string is either hardcoded, or already translated, vs. sending a string name that is loaded into the string service (loaded in things like common.ini), then it now has to be prefaced with a "#"; this was apparently a change implemented between POTC and CT/COAS engine versions:

SendMessage(&GameInterface, "lsls", MSG_INTERFACE_MSG_TO_NODE, "SELLSHIP_BUTTON", 0, "#"+SellButton);

I performed my own search for the same message to other textbuttons, with the same message number and parm format of "lsls" and found them in:

shipyard.c
TradeBook.c
NationRelation.c
capture_colony.c
character.c
items.c
itemstrade.c
kam_shipberthing_windows.c
mutiny_map.c
option_screen.c
passengers.c
ransack_main.c
shiphold.c
store.c
transfer_goods.c
interface.h

I took the liberty of updating them all and zipped just the program files @ MEGA

NHProgramUpdate.zip

Download and give it a try.

 

[pedrwyth]

That seems to have nailed those , thanks for the extra fixes too.

I have now encountered my first bad save (out of about twenty I guess) which also screwed up the options file such that the saved games didn't appear with the player portrait and name - wiping the options file cleared that element - so if it doesn't happen with other flavours (COAS,CT etc) then it could be coming out of POTC NH scripts after all. The bad save is only 1k and in reality is just a few bytes after the initial save at the start of the file.

The icons that appear on "sail to" have lost their text or flags (nationality or location name , and port/fort if friendly/hostile)- I take it that is a work round due to the problems with NH font textures?

I see the particles are now simply the imported later storm engine(s) .xps ones. Previously you did mention here
Age of Pirates 2 COAS and GOF - JLB version

.ini particles from NH would not now be used in the later engine but also work to try and move to using XML and allow particle modding across all storm engine games. Is that still an aim? If not, could a halfway house be to produce the whole suite of .xps in XML (however you did that) which may allow some understanding of which bits of an .xps to hex edit to produce altered effects for those hardy souls who have a grasp of what the particle coding means (not me). I do feel the loss of the modded particle effects in NH, particularly when .xps remains locked, would be a problem moving forward . What are your current thoughts @ChezJfrey ?

I will post here any other issues I spot, but I won't have time to look again at the game for a week or so

 

[ChezJfrey]

The icons that appear on "sail to" have lost their text or flags (nationality or location name , and port/fort if friendly/hostile)- I take it that is a work round due to the problems with NH font textures?

I fixed the sail to labels for the battle interface; just some missing code.

MEGA

NHProgramUpdate.zip

Curious about the bad save. That never happens anymore in the COAS derivatives, so might have to investigate if there is something missing in save_load.c

I have already exported all the COAS particle .xps files as .xml, and have written and briefly tested a feature to indicate in start.ini to use XML particle files instead, loaded them up and they appear to work OK. So that may be an option going forward. From what I've been able to determine, they probably had a particle testing harness in a modeling program or something, that would allow effect tweaking and test display, then probably some sort of custom export into user-defined file format (similar to the .gm export plugin for Maya) for use in the game. The unfortunate aspect of the XML format is there is much data and no easy way to determine what values affect what aspect of the effect and it would be much trial/error of loading a game and seeking a scenario in-game that produces said effect.

 

[pedrwyth]

I fixed the sail to labels for the battle interface; just some missing code.

fast service indeed! I'll download that for when I can next try it

Curious about the bad save. That never happens anymore in the COAS derivatives, so might have to investigate if there is something missing in save_load.c

Well I don't make a great tester because I don't always remember quite what I was doing. However I do know I had been messing in options interface, partly to see the fixed button text but also to see they still delivered. When I resumed and went to save the engine crashed (I think) and on a new load the interface was screwed as I described so I exited, deleted options and tried again. Now the profile was correctly presented but when I selected it saw the last save was "bad" . So I'm pretty certain it crashed during the save routine.

The unfortunate aspect of the XML format is there is much data and no easy way to determine what values affect what aspect of the effect and it would be much trial/error of loading a game and seeking a scenario in-game that produces said effect.

I guess much of the modded particle .ini work was trial and error but maybe @Jack Rackham can shed light on how much is straightforward understanding of the effect and how much experimentation.

 

[ChezJfrey]

While looking into the save problem, I noticed a mismatch. Don't know if it contributed to the problem, but here:

SetEventHandler("evntSave","SaveGame",1);

SaveGame expects 3 pieces of data:

void SaveGame()
{
string savePath = GetEventData();
string saveName = GetEventData();
string saveData = GetEventData();
.
.
.

In quicksave.c:

PostEvent("evntSave",0,"ss", GameInterface.SavePath + "\\" + curSave, sSaveDescriber);

This only sends two, and judging by the other calls I found, it should be:

PostEvent("evntSave",0,"sss", GameInterface.SavePath, curSave, sSaveDescriber);

 

[pedrwyth]

While looking into the save problem, I noticed a mismatch. Don't know if it contributed to the problem,

I generally don't use quicksave because I got used to going to the save menu and then trying the load menu to check what it thought of the save before proceeding if I was at a "mission critical" point just because of the bad save issue in the past - which was more frustrating if I didn't check and then found out later when I "needed" it.

 

[ChezJfrey]

If you are still taking a look, I found something I was unaware of in NH. There are 'buildings' constructed from NPC entities. I was sometimes experiencing strange graphical anomalies while at port and it turned out it was these 'buildings'. After some troubleshooting, I found the problems were due to a missing animation action definition for 'building' in the man.ani. So I included that in the update and also some code to further support task switching in fullscreen mode when at the save/load screen (rebuilds save file list screenshot thumbnail textures). There are some other updates to fix a texture reference count in the engine, and an added function to more easily determine string length based on font width per character.

MEGA
NHProgramUpdate.zip

MEGA
EngineUpdate.zip

 

[pedrwyth]

I found something I was unaware of in NH. There are 'buildings' constructed from NPC entities. I was sometimes experiencing strange graphical anomalies while at port and it turned out it was these 'buildings'. After some troubleshooting, I found the problems were due to a missing animation action definition for 'building' in the man.ani.

Yes the building set approach is a bit counter intuitive in making buildings by putting them on NPCs. I noticed some were not exactly placed as per NH in the old engine which can spoil their look and hope the additional missing animation, which should be static of course, will fix it and also the extensive error logging of missed animations when in a location that had these extras - so good you found it too. I will have a chance in a couple of days to look again but the entrance to the town from port where you start in Tales of a Seahawk is a good example to check/compare which didn't quite match.

Thanks for the changes I'll put the revised files in for when I load it next.

I found your workround for sensing if you are near an island but I think I did not end up at the island I expected on direct sail (not something I usually do but it is a popular feature) I'll be concentrating on that when I get back to it to see if I am mistaken and somehow missed where I thought I was headed so leave that with me. I found the change because of trying to look at some of the errors in error.log.

The weather missing attribute stems from the changes in WhrSky and tweaking that code clears the error I think, but I don't know quite if that then works as intended. So I'll leave it to you.

 

[ChezJfrey]

Looking at the error log, I see the sky dir problems, and comparing the code vs. original, I see the extra DeleteAttribute I added. I am not sure what my motivation for that change was, though it may have been something before I added the .useOld feature for the handling of different sky texture names and when I incorporated that, forgot to remove the DeleteAttribute. For now, I will remove that extra line, it should operate as it did before and will take time to note behavior.

The "Can't create class" is new to me and I see that it is due to some hex-edited versions of battle_interface.dll, ILogAndActions entities I did not yet notice. Does anyone know why it used replicas, vs. just using additional ILogAndActions references? For now, I will change that to instantiate additional ILogAndActions to see, but if someone knows whether those hex-edited versions disable or require some sort of different handling than stock ILogAndActions, I can simply add some form of attribute check (similar to what I did for the flags ini file section read, or the sky .useOld feature). That way, the implementation of ILogAndActions will work for these derivatives; though if there are really no difference in features between the two, it will just work, regardless.

 

[ChezJfrey]

Never mind. I figured it out: one for the action icon pop-up, then the others for various, yet discrete logs that display in various portions of the screen. This also explains why the alternate, hex-edited versions, because that is not possible...well, it wasn't until now. Now that I see what was being done, I also discovered why it wouldn't work. But, with some modification in the engine, it does now. Requires some new downloads:

MEGA
NHProgramUpdate.zip

MEGA
EngineUpdate.zip

I did not reposition the log displays and they write over the relocated man-sign in the top left. I leave that to another's decision where/what to do with it.

 

[Levis]

So I probably missed this. What is this new engine? Any more info on it?

 

[pedrwyth]

So I probably missed this. What is this new engine? Any more info on it?

Really one for @ChezJfrey to respond but basically, as I understand it, it is a fresh compile from 2.8 storm engine source code having fixed the original problems also with changed program code and dlls to suit and no doubt much more besides. If you search his posted content you will find more.

I did not reposition the log displays and they write over the relocated man-sign in the top left. I leave that to another's decision where/what to do with it.

First I have tweaked the character and companion ship icon locations in battleinterface.c to put them roughly down at the bottom left where NH had them before. This removes them from the log message area.

The settings I currently have are

BattleInterface.ShipIcon.iconoffset1 = "70,680";
BattleInterface.ShipIcon.iconoffset2 = "198,680";
BattleInterface.ShipIcon.iconoffset3 = "326,680";
BattleInterface.ShipIcon.iconoffset4 = "454,680";
BattleInterface.ShipIcon.iconoffset5 = "582,680";

I have looked how to move the moor/world map icon etc back into the now vacant position top left but haven't yet found where that is set - if it were returned it would be under the relevant text which is still being set on the left. If this clears the overlaps I presume this would have to be done in all relevant interfaces for consistency.

I have a problem with storms, the rolling messages that tell you how badly you're sailing (usually top centre under the date) do not appear. The storm seems to lock you into sailing after since when world map should become available it fails to load and dumps you back in sea. Just sailing also fails to arrive anywhere I think - so I think possibly the world map coordinates of pchar location have been lost - but it could be anything really.

When you get companion ships the "give order" choice has the wrong icon (should be a flag not a sail) and although you do get choice of companion no command icons are presented so you cannot action a command.

I attach a save in the post storm situation and another moored with companions for you to check out the issues if it helps.

 

[Pieter Boelen]

I have a problem with storms, the rolling messages that tell you how badly you're sailing (usually top centre under the date) do not appear.

How about the on-screen display of the date and time at the top? That is handled in the same way.
It was originally done by @konradk by "hacking" the Storm 2 engine, so I could imagine it wouldn't be properly compatible with the new one.

The same applies to the "Different Flags" mod, but if I understand correctly,
@ChezJfrey created a brand new system for that which is built into the engine properly.

 

[pedrwyth]

How about the on-screen display of the date and time at the top? That is handled in the same way.
It was originally done by @konradk by "hacking" the Storm 2 engine, so I could imagine it wouldn't be properly compatible with the new one.

I think post #12 and #13 are relevant to the hacking for messages and most now appear (they were missing before these changes). Date and time were there though.

The same applies to the "Different Flags" mod, but if I understand correctly,
@ChezJfrey created a brand new system for that which is built into the engine properly.

He has indeed created an improved flag system but according to
Age of Pirates 2 COAS and GOF - JLB version

did not do the extra work to fully implement it for NH but stuck with a halfway house.

 

[ChezJfrey]

I think post #12 and #13 are relevant to the hacking for messages and most now appear (they were missing before these changes). Date and time were there though.

He has indeed created an improved flag system but according to
Age of Pirates 2 COAS and GOF - JLB version

did not do the extra work to fully implement it for NH but stuck with a halfway house.

Yes, the flag issue is this:

The modification I made, allows one to specify in the code, a rigging.ini 'segment' name, where one can specify a different texture name for an arbitrary 'segment', and other flag settings, and add that segment name in the script code for a discrete and different 'flag' entity object; my adjustment also allows the texture file to have more than one row of individual flags. This was done to extend the flags we wanted in another mod, but also, as a side-effect, accommodates New Horizon's hex-edit hack for the multiple flag entities that were made to read several different flag .ini files. Now, NH does not need multiple .ini files, but can read from just one rigging.ini file, with added segment names for all the additional .tx files wanted, and simply add an attribute to the flag entity instances in the script to correlate the flag entity with the .tx desired for that entity. The part I did not do, is that now, fewer flag entites could also be used in NH, and simply consolidate the correlated .tx files into one, with multiple rows of individual flags, which would also require editing the procRiggingData to adjust the flag index to account for the multiple rows now available in the texture file. Example, all pirate flags could be in one .tx file and use just one pirate flag entity, same for merchant, etc. That latter is the part I did not do, and simply left it as many flag entities as existed previously. But now, at least no additional rigging.dll hex-edit hacked files are needed anymore.

The message log adjustment also does away with the hex-edit hack of multiple .dlls, as before, multiple instances of the log were not possible...well, they were 'possible' in the sense you could do so in the script, but they would not work properly. I simply did away with the restrictions that caused multiple instances to essentially stomp on each of their respective functions/data and they now work individually, simply by creating them in the script, but without the additional, hacked .dll files previously needed to avoid dysfunction.

I will take a look at the save files in the above post and see where I might have missed some script adjustments for the scenarios you described.

 

[ChezJfrey]

So I probably missed this. What is this new engine? Any more info on it?

Hey, where ya been? It's been out for a couple years now

Not only was it recompiled successfully from the original source, but it's also been upgraded to use DirectX 9 as well. I also have a 64 bit version, that screams, performance-wise, but that remains just for my special friends at the moment...

Some of the notable work done:

Upgrade from DirectX 8 to DirectX 9
Memory allocation changed from Microsoft's, to a faster/better efficient algorithm, improving speed of allocation and reducing memory fragmentation
Infamous battle_interface CTD is resolved (previous problem: Solved - Heap Corruption, Random Crashes)
Upgrade to FMOD 1.10.01 - 11/01/17 (also added some FMOD parameters in start.ini, to allow some flexibility in various buffer settings)
Infamous save game CTDs resolved.
Infamous mast-fall CTDs resolved. (see GOF for most prominent problem)
Eliminated hundreds of memory leaks, index out-of-bounds, potential dereference null pointer problems
Removed several, redundant file reads that would occur every game-loop, that now occur only at initialization (performance enhancement)
Geometry read file performance enhancement
Added music feature to rotate shorter tracks, randomly, instead of only allowing a constant loop
Added multiple row flag texture feature
Added multi-instance log/action entity support
Added multi-instance dialog entity support (just for New Horizons, as I noticed that feature the other day when doing the action/log)
Added the ambient light feature, attempted in CT/COAS script files, but did not actually work due to a problem in the engine; it is fixed and enabled now
Texture file lookup feature no longer restricted to 3 directory backtrack for lookup, but will now traverse any number of directories, all the way to Texture root dir.
Fixed task-switching in fullscreen mode CTDs, so now fullscreen can toggle/alt-tab from game to other apps, without crash
ETA:
Now supports HLSL shader read from .sha files (in lieu of strictly ASM)
Also can export/import XML particle file format (to allow editing of previously un-editable .xps files)

The following games, I have altered the script to work with this new engine, and they all play successfully:

City of Abandoned Ships
Caribbean Tales
Caribbean Tales Supermod
GOF 1.2
GOF 2.0
GOF 2.5
ERAS II
Pirates of the Caribbean
New Horizons

 

[Pieter Boelen]

Hey, where ya been? It's been out for a couple years now

Levis has been very busy with real life and isn't around all that often.