Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

The mod RESOURCE and PROGRAM scripts determine what languages are are listed and supported by the mod.

The Config.exe dropdown list for the mod is populated from a section added to the RESOURCE\INI\texts\language.ini.  Add a list of supported languages to the file, like this:

[ConfigList]
cfgLang = English
cfgLang = French
cfgLang = German
cfgLang = Italian
cfgLang = Spanish

If you want multiple languages (i.e. more than one language), then move your files for each language into separate directories with the the name of the language as the subdirectory name, and in your Program script code include files, you can use the special $language preprocessor in the file path and the user's selected language will replace that path with their current language.  The Maelstrom engine will replace all instances of $language in the code script with the selected language during the game startup while compiling the game scripts.  Example from Program\DIALOGS\portuguese\Capitans_dialog.c and Program\DIALOGS\english\Capitans_dialog.c

#include "DIALOGS\$language\Rumours\Common_rumours.c"
#include "TEXT\$language\DIALOGS\Capitans_dialog.h"

If the player selected portuguese, Maelstrom will use the file from TEXT\portuguese\DIALOGS\Capitans_dialog.h and if they selected english, it will use TEXT\english\DIALOGS\Capitans_dialog.h file.

Of course the additional work for the font.ini files, and font.tga textures must also be set up for each language, but that is also the mod responsibility.

Thanks for the detailed clarification!
Another question is, so as not to create a new topic.

We have two dlls in our project, "personalflag.dll" and "questflag.dll". We do not know what is in them. This was done by BMS on the latest versions of the city of lost ships. I believe that this concerns locks for the pirate line. but I can't say for sure. Your engine refuses to enable them.
How should we be?

I don't know what they are.  It is possible they hex-edited the original rigging.dll, similar to what the New Horizons modders did.  If they are duplicate rigging object .dlls, Maelstrom provides two solutions that were provided.  The reason NH needed to hex-edit multiple rigging.dll files is because they wanted separate flag textures, because the original game only allowed a single row of flags in the texture file; Maelstrom now allows many rows and to see how that works, see the ERAS RESOURCE\Textures\flagall_ship.new.tga.tx, RESOURCE\INI\rigging.ini and Program\battle_interface\BattleInterface.c function procGetRiggingData.

New Horizons could use that same technique, but the quicker way, so that their textures and script code can remain mostly the same, was Maelstrom added a feature to give an alias to various rigging instances within the script code.  You can see this in the Maelstrom New Horizons version that I edited PROGRAM\SEA_AI\AIShip.c, where there is an option to add a unique .iniSection and .lblGroup to the flag objects to indicate what locator group on the ship model to use, and the iniSection refers to configuration sections for different .tga.tx files to use for that name, which you can see an example in the Maelstrom New Horizons RESOURCE\INI\rigging.ini file.  This allows them to still use the multiple flag textures, but with just one rigging.dll because it will accomplish the same thing their hex-edited .dll files with these new features I added just so that it could work similarly, without the need for additional hex-edited .dll files.

If the personalflag.dll and questflag.dll are not used for ship flags like New Horizons, then I do not know what they do in their mod, so I can't answer the question.

We have a wish for you to improve.
Now there is one very extremely incorrect situation associated with the combat mode of the GG. The situation is as follows: if you shoot from a pistol, then if an ally is in front, then the shooting goes at him. The same goes for enemies. When there are massive battles, as well as boarding, then such shots can greatly reduce the effectiveness of the boarders.
Is it possible to make it so that only enemies are selected?
In corsairs - to each his own - this is corrected.
Best regards, LEOPARD.

Newest update now restricts NPC to target/shoot only enemies.  Player can still shoot friend/foe so still has to manually ensure an enemy is targeted.

(1 edit)

In order not to create new topics, I will continue here again.
We have already done Russian localization, but we faced a number of problems.

COAS 1.3.0 Game
1. Most likely a problem with the DX9 64bit engine. If you spend the night in a tavern in the common room, flickering textures appear on the floor.
2. Excessive yellow light illumination in some rooms. It's very strong. This is especially true in taverns and brothels.
3. Misty shroud strongly hides ships. There is no such thing in the Russian version of the old storm.
4. The sea changes the waves very abruptly, it seems that physics is not being worked out correctly.
5. The problem is in stretching the interface. If on the old storm in the script "interface.c" change the line "showWindow.aspectRatio" and set the values "showWindow.aspectRatio = 1.0;" then the interface doesn't stretch and looks great. This fix does not work on Maelstorm. There is no way I can properly make the interface for 16: 9 ratios so that the main frames are centered. They stubbornly stretch everywhere, which makes a very ugly picture. At 4: 3 ratios everything is fine, but this is already the past.

I sincerely hope that you can help us fix these issues. Best regards, LEOPARD.

1: Using Maelstrom 64 bit, I can spend the night in the tavern in our copy of COAS, GOF 1.2, GOF 2.0, GOF 2.5 and ERAS 2 and I see no flickering textures on the floor.  I can guess that the problem might be the sea is still enabled in your location; disable the sea for that location load in your scripts, or if you do want the sea enabled, change your sea height in the scripts to make sure it is lower than the floor.

2. The original scripts tried to set ambient light for locations with a function:  ExecuteTechnique("amb_tavern")  But that function had no effect, and never worked from the scripts because the Storm engine did not perform that feature properly.  I changed it use a message instead, during model load:  MSG_LOCATION_SET_AMBIENT_LIGHT.  If your location color is disturbing, either change the .col files for that location/hour, or you can set the ambient color with that message in your location loader script and the color you send will imbue that tint into all the textures of that location as ambient light.

3: The original City of Abandoned ships had lots of fog at sea.  ERAS 2 has little or no fog.  This is all set in the weather scripts, so if you have too much fog, change your weather scripts.

4: I changed none of the wave calculations from what I was given.  The only things I changed for the sea is to more properly handle the multi-threading event responses, increase the number of supported polygons and detail allowed, and doubled the size of the wave square surrounding the ship.  If your waves are too fast, too abrupt, then change your weather sea attributes for animation speed, wave frequency, sea and wave heights, sea color, etc. in your weather scripts.

5: The showWindow.aspectRatio attribute does not affect anything in the original Storm engine and does not change anything in the GUI screens; that attribute is only used in two functions:  RecalculateVIcon and RecalculateVIconScaled.  Those two functions only change the icon sizes displayed in the spyglass and battle interface HUD icons, nothing else.  The original COAS cd also stretched everything in the character GUI interfaces, because it presumes a 4x3 display and everything was defaulted to assume 800x600.  Maelstrom, by default will resize the screen elements (except a background image, which will always fully stretch) in the GUI by trying to retain the GUI element's WxH ratio, but within the actual monitor's resolution.  For example if you define a 800x600 box in the screen, but your monitor is 1920x1080, the box will expand to 1440x1080, still the same ratio as it was defined in the .ini file, but fit within the current display resolution.  A 400x300 box would expand to 720x540.  If you want everything to stretch like the original cd for COAS does, adding noresize=1 to all the screen .ini files will cause Maelstrom to act just like original Storm and stretch to fit the entire screen.  Otherwise, it will resize as I described in my 800x600 box example, turning it into a 1440x1080 sized box in a 1920x1080 screen.  There was a bug in the table column width calculation, but that is fixed in the next update.

If this is too much trouble, or still unsatisfactory, then perhaps just use the Russian version of the old Storm, since that appears to be your preference anyway.

(1 edit)

Thank you very much for the clarification!
We will deal with points 1-4 already in the scripts.
With point 5, we will wait for the stretch marks to be corrected.
And no, we don't like the old storm. I just gave an example that it worked there, but here we just did not know how to solve the problem.
If we liked the old storm, we would not buy your engine and transfer the largest mod to its base. The old storm is in the past. We've already done a tremendous job and there is still a lot to migrate to MS.
Best regards, LEOPARD!


PS.  Yes, I put noresize = 1 everywhere and it worked! We will wait for fixes from the full stretch.

I'll show you as an example:

Maelstorm


Storm



Engine was updated yesterday and someone else confirmed they are more satisfied with the table sizing now, so it should be good.

Yes, we have already made sure that all this works as it should! Thank you for your responsiveness!
Also thanks for making support for other texture formats. This is really cool! I've already checked everything on the interfaces, everything works flawlessly! Finally, it will be possible to reduce the weight of the game by 3 times)

Let's hope that someday you will add a new scene format to the game, otherwise the old GM models are not at all what is needed for the new engine :)
Best regards, LEOPARD!

(3 edits)

Hello!

There are still some problems with the interface. I will try to explain everything in detail.

The fact is that after the correction, some tables stopped moving from their positions, yes, it was corrected and obvious. But still the interface stretches.
I can't set my screen resolution to 1500x1200. the fact is that MS, with such parameters, starts immediately in FHD, and the interface itself is stretched to its full width. I think the stretching of the interfaces is in there somewhere. You naturally know better - where it is in the source code, I'm just guessing.
Now I will try to give examples of what we want to achieve.


Here's a look:
1 screenshot - this is MaelStrom in FHD resolution and the interface in ini is disabled by noresize. Here you can see how the interface has stretched.


Screenshot 2 is an old storm in FHD resolution. Here the interface does not stretch from the base 800x600.



Now let's look at the same thing, but with a normal aspect ratio of 4: 3, as it was originally for the storm.
In both screenshots, everything looks as it should.



The point is, we cannot do the same thing as it works on the old storm. If you know how to help us, please let me know.

Best regards, LEOPARD!

P.S. I'm sorry, but I seem to remember something. 3 years ago, when we just started making our mod, one person helped us with the interfaces, who had the source files of the storm. He changed something in the XINTERFACE.dll module and everything began to work for us as it should. MB is something that will help.


To be precise, this is how it can work with noresize = 1 disabled. And full stretch without noresize = 1
This would be ideal.