• New Horizons on Maelstrom
    Maelstrom New Horizons


    Visit our website www.piratehorizons.com to quickly find download links for the newest versions of our New Horizons mods Beyond New Horizons and Maelstrom New Horizons!

New Horizons on JLB Maelstrom 2.8.2 engine

OK tried it a bit more and got more familiar with it, I was initially confused by the redundant chooser from give order - which is now superfluous. Intuitively I would prefer the interface to revert to the PChar line on exit after a command or esc since that is where most of the commands apply but I guess it is just a question of acclimatisation. The possibility of adding a reload command to your companions (is this already a COAS feature) could add to gameplay options.

I wonder if it is feasible to add the green arrow pointing over the selected companion when you have their line active (as in previous NH chooser) since I often use that to identify which of my ships I want to order to act in a given situation - but no big deal.

I have addressed a few things here:

I added support for an option to revert your last command, upon escape, back to the main character, if desired as a default.
I added support to highlight the currently active ship the commands correspond to.
I removed the 'Give Order' since it no longer applies.

The two, new options can be set with two different attributes, found in BI_InitializeCommands (I turned them on in the example):

BattleInterface.HighlightActiveShip = true;
BattleInterface.EscRevertMainChar = true;

MEGA

NHProgramUpdate2.zip
 
I'm just slowly working through the various interfaces, in game stuff is more problematical for me to comment upon. Well OK The bigee, which you already know about, is particle effects - for example a booby trapped chest originally blows up with a short explosion - the new engine effect is a lasting flame which doesn't stop until you leave the location. I don't think you or I are going to do the work to get XML equivalents but the system to accept XML (even if the effect changes are by trial and error) is for you (if anyone) I think.

The only other issue, I currently held back, is no secondary interface when you select colonies after pressing F2. Not that that means there aren't other (probably minor /cosmetic) bits. I really am not that familiar with all the effects and different playing choices/styles myself. I haven't played (apart from stock POTC) in a couple of years (yes there's a backstory to that) and then only the main storyline twice and a quick dabble with some of the others.

The colonies screen was a problem in Tradebook.c. I fixed that.

The particle XML format file read is in fact already built into the game (I added a start.ini value to indicate use the XML particles), and I actually have already output all the existing .xps files as .xml. I haven't offered the XML files themselves, or given the option value out, but I have tried it and the particle effects work as usual.
 
If you mean anywhere near the mainland or Cuba, that's because the scale is different there and things don't quite work right. Haven't figured out anything that can be done about it.

Hook

One certainly was at the mainland (although I wasn't) anyway enough for this purpose to know it is inherent so thanks for the confirmation.

I have addressed a few things here:

I added support for an option to revert your last command, upon escape, back to the main character, if desired as a default.
I added support to highlight the currently active ship the commands correspond to.
I removed the 'Give Order' since it no longer applies.

The two, new options can be set with two different attributes, found in BI_InitializeCommands (I turned them on in the example):
Thanks and good scheme to have them as user selectable, it may be that I soon see the're better turned off too after a bit more familiarity.:D
The colonies screen was a problem in Tradebook.c. I fixed that.

The particle XML format file read is in fact already built into the game (I added a start.ini value to indicate use the XML particles), and I actually have already output all the existing .xps files as .xml. I haven't offered the XML files themselves, or given the option value out, but I have tried it and the particle effects work as usual.

Ok good to know the particle effects is not only conceptually covered but functional.
I'm still away travelling and that part of real life is about to kick in again :8qso I'll just try a bit more in the background and stop bombarding this thread for a week or so. Thanks for all the support this far though. :bow
 
You can't exit the sea, because as soon as you go back to worldmap, the storm is still there, you get caught in it again, and are immediately placed back in sea, during a storm. I didn't know if that was intentional or not, so left it, because I did not change the weather code at all, and looking at my changes to worldmap, they are minimal and have nothing to do with storm generation and/or whether the storms 'stick' like they appear to do. Again, I didn't know if that was by design.

Having looked at the almost identical code I compared storms in NH between the two engines and storms seem to persist longer with the new engine mostly lasting for several days, the call is different so obviously some changes in storm coding (sorry couldn't resist that) have taken place in the later engine. The weather "on sea" dying back so you can enter map and the storm on world map don't correspond. I then looked at AOP2 and saw quite a bit of different front end coding too. Rather than get into that I set an attribute when a storm forces you back to sea from world map so that next time it happens you can go back to world map you can stay there even when under the storm cloud - however I decided to wipe the attribute within daily crew update, so you have to be quick to get out the storm and sometimes you are dropped back in if daily crew update runs before you have escaped.

I added
Code:
if (CheckAttribute(pchar, "stormIndex")) return; // PW storm immunity otherwise locked in storm
    pchar.stormIndex = stormIndex;//PW set up variable for storm immunity (cleared in daily crew update)
at the end of wdmEvent_PlayerInStorm() in worldmap_event.c and a cancelling
Code:
DeleteAttribute(pchar, "stormIndex");// PW end temporary immunity from storm
at the end of DailyCrewUpdate.c
I'm sure a more attractive solution could be found, or even moving to AOP2 code may solve the issue but for now it works so I have moved on.


There is an instance of locking up on world map. This one involves the non-appearance of the skip encounter option screen when you come across hostile ships. Instead only the word "engage?" appears and the game locks. You need to stop the whole process to escape and I haven't managed to get a screen dump either.

Another thing I have seen is a flag remaining in the battle screen when I lost a mast - no graphical anomalies just the flag at the right position as though on an invisible mast where the ship was at the time - it remains at that position. So this is not fully resolved in the new engine for NH but there were always problems previously.

Also when sailing away from an island the added structures (towns, ships etc) are opaque rather than textured and in some instances ships are there on the compass display and locking your escape to world map but not visible on screen although obviously ought to be in visual range. So still some texture issues. Next time I get the effect I'll save a game and get some screenshots.

I decided to play through "Tales of a seahawk" for a more structured test and have so far progressed to the search for Raoul Rheims - there are a few old bugs (most of which have been fixed in the latest version anyway) no showstopper down to the change in engine though. I have been using god mode and arcade so as many features are skipped of course.
 
Last edited:
Having looked at the almost identical code I compared storms in NH between the two engines and storms seem to persist longer with the new engine mostly lasting for several days
Out of curiostity, are these storms in 3D Sailing Mode or on the WorldMap?
 
Out of curiostity, are these storms in 3D Sailing Mode or on the WorldMap?
They are storms on the world map - which drop you back to sea in the storm. When the world map icon eventually appears, and usually the storm has reported now a breeze, press for world map it tries but since you are still in the storm (on world map) you don't get there and drop back to sea (ad infinitum). I have experienced up to three returns to storm with the original engine but usually by then the storm had disappeared from world map.
 
They are storms on the world map - which drop you back to sea in the storm. When the world map icon eventually appears, and usually the storm has reported now a breeze, press for world map it tries but since you are still in the storm (on world map) you don't get there and drop back to sea (ad infinitum). I have experienced up to three returns to storm with the original engine but usually by then the storm had disappeared from world map.
Thanks! Indeed that definitely sounds like an engine thing.
Pretty cool actually that storms persist in the 2.8.2 engine! They definitely don't in 2.0, which is... unrealistic to say the least.
 
I was already superstoked, but with working higherpoly models I feel like Im gonna burst into flames :bounce dunno if I can help as much as @pedrwyth as I dont know as much about the engine and I have a severely short attention span but Id love to help chase bugs if thats of use. but where do I find the engine..? :eek:
 
They are storms on the world map - which drop you back to sea in the storm. When the world map icon eventually appears, and usually the storm has reported now a breeze, press for world map it tries but since you are still in the storm (on world map) you don't get there and drop back to sea (ad infinitum). I have experienced up to three returns to storm with the original engine but usually by then the storm had disappeared from world map.

Though I've not looked into the detail, I suspect that the early versions had the storm abatement time (in worldmap) coded into the engine -- arbitrary and inflexible, whereas later version probably allows for the programs scripts to make that determination/handling. I suspect if you continue to compare COAS code, there is some sort of message or attribute to remove the worldmap storm.
 
Though I've not looked into the detail, I suspect that the early versions had the storm abatement time (in worldmap) coded into the engine -- arbitrary and inflexible, whereas later version probably allows for the programs scripts to make that determination/handling. I suspect if you continue to compare COAS code, there is some sort of message or attribute to remove the worldmap storm.

Yep a matter for me to chase up, like the possibility of changing companion cannon charge types, once I have migrated to the latest code for NH on return from travelling. In fact given the intention to post another NH version on Moddb in the new year I will be aiming to conform to that one as I try to match up to the new code.

Also when sailing away from an island the added structures (towns, ships etc) are opaque rather than textured and in some instances ships are there on the compass display and locking your escape to world map but not visible on screen although obviously ought to be in visual range. So still some texture issues. Next time I get the effect I'll save a game and get some screenshots.
I would leave looking at this until I can confirm it and provide some more info (I could be imagining the difference in the structures) although the invisible ships were real enough (if you follow that logic). However with the companion choice enabled I have seen which ship I am looking at/from step through different ships and views from them on sail to rather than from your vessel even when looking at say a port, beach combination, don't know if this was always the case with the new engine (I don't really pay much attention to the ship details). So I might just have got confused as to which ship perspective I was actually looking from.

EDIT the above is a bit incoherent if you haven't seen the effect - so here is a saved game where moving along the command icon line changes ship perspective which should make my rambling clearer. ENDEDIT
 

Attachments

  • standard.7z
    1.5 MB · Views: 167
Last edited:
There is an instance of locking up on world map. This one involves the non-appearance of the skip encounter option screen when you come across hostile ships. Instead only the word "engage?" appears and the game locks. You need to stop the whole process to escape and I haven't managed to get a screen dump either.

Here's a screen dump from in 2.8.2 and a comparison in the old engine.
 

Attachments

  • engage.jpg
    engage.jpg
    191.5 KB · Views: 262
  • sailho.jpg
    sailho.jpg
    196.5 KB · Views: 289
Here's a screen dump from in 2.8.2 and a comparison in the old engine.

That is the same problem as that quest character screen. The path to the .ini file no longer needs RESOURCE\INI\ and you can remove that portion of it. Looks like I missed several of those. The one in question for your specific error is in boal_map.c. Change to:

if(bAnimation && bNewInterface) iniName = "NEW_INTERFACES\ANIMATION\boal_map.ini";

Since this has happened a couple time, I took a further look and some more were missed in:

endgame.c
fortcapture.c
transfer_goods.c
Reinit.c
transfer_cannons.c
etc.

You may want to check them out and change if necessary.

ETA: BTW, the system.log will show this error and gives the path it tried to use, where you will see the RESOURCE\INI is repeated in the path being sought. That's how I found the root problem.
 
That is the same problem as that quest character screen. The path to the .ini file no longer needs RESOURCE\INI\ and you can remove that portion of it. Looks like I missed several of those. The one in question for your specific error is in boal_map.c. Change to:

if(bAnimation && bNewInterface) iniName = "NEW_INTERFACES\ANIMATION\boal_map.ini";

Since this has happened a couple time, I took a further look and some more were missed in:

endgame.c
fortcapture.c
transfer_goods.c
Reinit.c
transfer_cannons.c
etc.

You may want to check them out and change if necessary.

ETA: BTW, the system.log will show this error and gives the path it tried to use, where you will see the RESOURCE\INI is repeated in the path being sought. That's how I found the root problem.

OK thanks, looks like we're at a point where the problem is more likely to be changes required in the front end scripts and as such a matter for NH modders to resolve. For example the change in boal_map.ini does bring up the full engage yes/no screen but a choice of no takes us back to the locked equivalent of the storm situation. That is because at world map you are still at encounter the question (with sail ho sound) repeats ad infinitum. So either needs the attribute approach (which I originally saw for collisions) or a deeper study of how COAS treats world map stuff (a move further away from "stock" NH).

I think all the instances you quote above do need RESOURCE\INI removed and it just shows how much more depth to testing is required (NH in all its storylines and playstyles is big). I would I suppose have got to all of those above in due course following TOSH but under no other circumstances would I be getting to fortcapture and thence colony capture (for example) because I don't do that. Given your "etc" a search for RESOURCE\INI shows a number of examples where it is either a comment or part of a file path and where further consideration may be required on whether they need to stay.

So from now on I may well note stuff here for reference as I find it (and if I can fix it). I will study the logs carefully and try to resolve whatever, this will mean slower progress - good thing I will be back home in a week or so (not really). It may remain here as the equivalent of a bug report thread. If I can't fix it (quite likely!) and have no clue I will probably tag @ChezJfrey in the post but if it is a note of a resolved something will not.

Hope this makes sense.
 
Last edited:
OK thanks, looks like we're at a point where the problem is more likely to be changes required in the front end scripts and as such a matter for NH modders to resolve. For example the change in boal_map.ini does bring up the full engage yes/no screen but a choice of no takes us back to the locked equivalent of the storm situation. That is because at world map you are still at encounter the question (with sail ho sound) repeats ad infinitum. So either needs the attribute approach (which I originally saw for collisions) or a deeper study of how COAS treats world map stuff (a move further away from "stock" NH).

In worldmap encounters, it looks like an attribute is precisely how they deal with opting out of encounters from worldmap.

worldmap_events.c::wdmEvent_ShipEncounter sets pchar.eshipindex and calls LaunchMapScreen()
Interface\map.c, on cancel, sets pchar.SkipEshipIndex = pchar.eshipIndex;
Then later in the subsequent firing of wdmEvent_ShipEncounter
This line skips having to repeat (CheckAttribute(pchar, "SkipEshipIndex") && pchar.SkipEshipIndex == eshipIndex) return; // boal

For worldmap encounters/storms, it might also be beneficial to review the liveTime and needDelete attributes/settings used in worldmap files; those appear to particular to the new approach for managing.
 
Ah, I found something for you about worldmap release of events/encounters that is also relevant.

In COAS wdmReloadToSea() and Map_ReleaseQuestEncounter, the following line kicks of the logic within the engine to review liveTime <= 0 and the needDelete attribute of the various elements roaming the worldmap.

worldMap.deleteUpdate = "".

I know it looks strange that would accomplish anything, but within the engine, that is considered an attribute change for the worldmap object (script assigning a value), and when that particular attribute is deemed 'changed', then the engine will iterate the live worldmap objects (ships, storms) and remove whatever has a liveTime <= 0 and also anything with the needDelete attribute set.
 
In worldmap encounters, it looks like an attribute is precisely how they deal with opting out of encounters from worldmap.

worldmap_events.c::wdmEvent_ShipEncounter sets pchar.eshipindex and calls LaunchMapScreen()
Interface\map.c, on cancel, sets pchar.SkipEshipIndex = pchar.eshipIndex;
Then later in the subsequent firing of wdmEvent_ShipEncounter
This line skips having to repeat (CheckAttribute(pchar, "SkipEshipIndex") && pchar.SkipEshipIndex == eshipIndex) return; // boal

For worldmap encounters/storms, it might also be beneficial to review the liveTime and needDelete attributes/settings used in worldmap files; those appear to particular to the new approach for managing.
Yes where do you think I stole the idea from, you had already added most of that into NH wdmEvent_ShipEncounter() although it wasn't being used for the weather of course, I'm not generally that creative especially if there is something to hand.

However it was what setting needDelete accomplished and where that had an impact which I couldn't quickly follow in the COAS code so this

Ah, I found something for you about worldmap release of events/encounters that is also relevant.

In COAS wdmReloadToSea() and Map_ReleaseQuestEncounter, the following line kicks of the logic within the engine to review liveTime <= 0 and the needDelete attribute of the various elements roaming the worldmap.

worldMap.deleteUpdate = "".

I know it looks strange that would accomplish anything, but within the engine, that is considered an attribute change for the worldmap object (script assigning a value), and when that particular attribute is deemed 'changed', then the engine will iterate the live worldmap objects (ships, storms) and remove whatever has a liveTime <= 0 and also anything with the needDelete attribute set.

For worldmap encounters/storms, it might also be beneficial to review the liveTime and needDelete attributes/settings used in worldmap files; those appear to particular to the new approach for managing.
is certainly useful when I come to implement COAS like behaviour rather than just a quick attribute workround. In fact I originally set the index for the storm with a check for the same storm based on the encounter equivalent index method but then realised it was always going to be the same storm whilst the attributed existed so just the existence of the attribute was test enough.
In the event for encounters changing your pchar.eshipIndex = eshipIndex; in wdmEvent_ShipEncounter() to pchar.SkipEshipIndex = eshipIndex; is enough to get it working to avoid the encounter for now.

For the future with storms rather than marking them for deletion because you blundered into them it might be good to put your ship just outside their effect radius on return to world map after riding out the storm (but checking that's not into a landmass:)) but leave nature taking its course with the storm on world map. The running check for nearest land could help here too I would think.
 
Last edited:
I was already superstoked, but with working higherpoly models I feel like Im gonna burst into flames .... Id love to help chase bugs if thats of use. but where do I find the engine..?
I think it is likely that non-performing elements of NH on 2.8.2 will now mostly if not entirely be down to front end coding not the engine change per se as such I would be happy to see others looking for any such areas that need resolving.

This is currently a matter of trying to get the earlier version (roughly moddb latest) running as well as possible (or as least as well as the original!), so one step back for now before (hopefully) migrating to latest WIP which by then may also be current moddb published.

Several changes to the engine and associated files have taken place so only @ChezJfrey can provide a link/links to what is currently required to generate the latest, particularly with regard to integrating the larger poly model, so I suggest you PM him (if you haven't already).
 
Last edited:
This is currently a matter of trying to get the earlier version (roughly moddb latest) running as well as possible (or as least as well as the original!), so one step back for now before (hopefully) migrating to latest WIP which by then may also be current moddb published.
Just a thought: We intend to get another version ready for ModDB soon.
Do you think it would make sense to get that version running with 2.8.2 instead of the one currently on ModDB?
 
Back
Top