Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(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.


There are no "problems" with the stretching, you  just don't like the Maelstrom default that is meant to be a compromise, and it is intentional.

First, the Storm 2.8 stretches all screens to full width, even widescreen, and it does not do what your screenshot 2 shows.  I launched COAS, using the original cd version of Storm 2.8 with 1920x1080 and here is the result:

What you want is probably from TEHO's version, but I don't have their source code, so I'm not sure what they are doing, but I think they are constraining all screens, except for the background image, to 800x600 ratio, but I don't want to do that because it creates too much empty space for my tastes.  So the Maelstrom compromises, by stretching some by default, but not the full width; I just think that looks better...apparently some people disagree.  Maelstrom in 800x600:


Same screen, Maelstrom default in 1920x1080, stretches a little, but less than Storm 2.8:


If the screen's .ini config file contains noresize = 1, then it will stretch the full width, just like original Storm 2.8 did (first screenshot, above).

But apparently the small stretch greatly frustrates the Russian modders, because you are probably the 3rd modder to complain that it doesn't act like TEHO.  So, in order to once again compromise, I just updated Maelstrom today and there is now a way; add resizeFactor = 1.0 to the [COMMON] section of the RESOURCE\INI\interfaces\interfaces.ini file:

[COMMON]
resizeFactor = 1.0
....
....

If the screen .ini does not contain the noresize = 1 value, and your resizeFactor in the interfaces.ini file is = 1.0, then you will get this:


Hopefully this is satisfactory.

Thank you so much for compromising and helping modders!
I checked everything. Now the whole interface works as we want!
Best regards, LEOPARD!

Everything became as it should be everywhere, except for NationRelation.ini.

There it is shown like this at a resolution of 1920x1080. In a 4: 3 ratio, everything is fine.


Hmmm, that is because that screen is all "dynamic" using CreateImage() and CreateString() in the Program\INTERFACE\NationRelation.c script where the positions are provided by the script, not the .ini file.  During those function calls, it sends a message, but the message is not sent to a "node" that knows whether the noresize value in the screen's .ini file is present, so this becomes a little trickier...I will think about a resolution for the case of CreateImage and CreateString.  In the meantime, a workaround is to change the NationRelation.c script values for the sx, sz and deltaX values for the nation matrix loop that calls CreateImage and the X position value for CreateString.  I will get back to you about the possibility of reverting the workaround back and have it more automatic when I find a decent solution to provide the noresize/resizeFactor for this specific situation of dynamic strings/images from the scripts vs. the .ini file.

Another solution that we used in ERAS, is this screen is marked noresize=1 in NationRelation.ini, which will stretch the entire thing back to full width, but we also added an extra country, which required more space anyway.

Never mind about a workaround, I found a way for this to work.  I'll update it sometime this week.  I just need to change a few of my own mod scripts for cases where I don't want the CreateImage/CreateString positions to adjust for noresize.  In your case, you will not need to do anything once I update Maelstrom; it will work with just the resizeFactor setting and will only require a script change if you want the full width stretching, which you do not wat, but I do want in some of my screens, so I need to fix them for this new feature before I upload.

Thank you so much for what you are doing and for the great news! We will wait for the update.

While we were redoing everything, we found a few minor nuances in other interface windows with resizeFactor = 1.0 enabled.

The ranks of the characters move out a bit.


And also the location of the text with the weight and the icon is almost completely removed when there is an exchange with officers / chest.


It's all about interfaces.




We are now introducing generated quests from the Russian modpack 1.3.2 AT and ran into problems.
1. The function with random weapons does not want to work for us. The comments indicate that it was transferred to engine processing. Does MS have this? Or what are we doing wrong?
Here's the function itself:
{
/ *
    for (int i = 0; i <TOTAL_ITEMS; i ++)
    {
        if (CheckAttribute (Items [i], "ID") && Items [i] .id == sItemID)
        {
            return i;
        }
    }
    return -1;
* /
    // Warship 07/07/09 Transferred to the engine function - in theory, it should work faster
    return NativeFindCharacter (& Items, sItemID);
}

In the original COAS 1.3.0 on MS, it looks different:
int FindItem (string sItemID)
{
    for (int i = 0; i <ITEMS_QUANTITY; i ++)
    {
        if (Items [i] .id == sItemID)
        {
            return i;
        }
    }
    return -1;
}

We can't do it on TOTAL_ITEMS.
We will be glad for any help!
Best regards, LEOPARD.

The character rank is adjusted by "xoffset" that I did not account for in the reposition.  I have fixed that and uploaded to Itch today.

I do not have the same problem in the itemsbox for trading in my COAS test.  You might want to check the Program\INTERFACE\itemsbox.c for the string creation.  COAS shows this:

CreateString(true,"MainWeight","",FONT_NORMAL,COLOR_NORMAL,215,265,SCRIPT_ALIGN_LEFT,1.0);
CreateString(true,"BoxWeight","",FONT_NORMAL,COLOR_NORMAL,215,302,SCRIPT_ALIGN_LEFT,1.0);

Assuming that the itemsbox.ini is the same sizing as COAS, that should be the same too.  Also be sure that itemsbox.ini does not have noresize specified (if it is missing from the .ini, it will assume 0) or if it does, that it is zero: noresize = 0

Maelstrom does have that same function NativeFindCharacter.  It works with any script array object if there is a .id attribute.  So it would work for:

NativeFindCharacter (&Items, "blade1");
NativeFindCharacter (&RandItems, "blade1");

Make sure whatever object you send in the first parameter is an array and that it has .id attribute for each element; it searches for .id = "searchname".  I tested both of the examples above and it worked fine.

(1 edit)

Thanks again for editing the interfaces!

Again we)
Only this time things are already with the music.
We don't know how to make our music work?
We replace music_alias with our own. In the sound.c script everything is written as we need, in the ini files too. But music stubbornly refuses to work out of other ways. The system log constantly writes FMOD_SOUND: createStreamCB error! (18) File not found.
ERROR: fmod_system-> createStreamCB (RESOURCE \ sounds \ music_spokplavanie, FMOD_DEFAULT | dwMode, 0, & sound)
We even made schemes with music by analogy from ERAS, all the same, the engine tries to play music only in standard ways.
What are we doing wrong?

(6 edits)

I also had this problem with some of the music in other mods and I think it must be the program that created the old music files.  I just used a newer program (like VLAN) and if the file is musicfile.ogg, I just used the convert feature, but converted it to the exact same .ogg format.  If it is musicfile.mp3, I converted it to the same .mp3 format.  That solved the problem for the files that would not play.  I don't know what the problem is, but I guess perhaps the metadata in the file is old, deprecated or wrong format for the newer FMOD.  By converting to the same file format, but with a newer editing program, solved the issue.

Also, in your post, it is searching for RESOURCE\Sounds\music_spokplavanie.  That is not a sound file.  An alias must have no slashes in the name, where it will look in the alias.ini file for the name and grab the file path there.  The play sound function should just send "music_spokplavanie" for an alias.  If it is a specific file name, then the play sound function should send "Music\soundfile.ogg"

Also, if your aliases are not in RESOURCE\INI\aliases directory, then you must also specify the directory in start.ini:

ini_directory = RESOURCE\INI\

[sound]
sound path = RESOURCE\sounds\
aliasDirectory = someotheraliasdir\
...
...
...

If you do not put aliasDirectory in the [sound] section, then it will by default look in RESOURCE\INI\aliases.  Example format for the files is the same as original...example:

[music_main_theme]
prior = 192
name = MUSIC\01-Pirates.mp3
name = MUSIC\01-VivaldiCoAS.ogg
name = MUSIC\133-VanhalG1.ogg
name = MUSIC\138-VoorhetVaderland.ogg
name = MUSIC\139-ZelenkaCave12.ogg
name = MUSIC\175-Seahawk.ogg
name = MUSIC\180-Ghostship1.ogg
name = MUSIC\217-CorelliGrossoNo4D2mvt.ogg
name = MUSIC\218-CorelliNo4D2mvt2.ogg

Thank you for help! Everything, now everything is sorted out)

Hello!

Again I ask you)
Can you make an interesting and useful change to the engine?
It's about battle_interface, or rather, about adding a gunpowder icon. Below is an example on the screenshot of how it was done on another engine.


We understand that in GOF2 ERAS there is something similar, but it was done in text and in scripts. But if it's easy for you, can you do the same for MS? It seems to me that this fits very succinctly into the interface.
Best regards, LEOPARD!

If you send me a copy of the Program\battle_interface\BattleInterface.c file, I can review it so that we use the same attribute names for the icon addition/placement and the icon code would remain compatible.