Guide TEHO modding (tehomod and scripts are here)

[kb31]

It's basically SE 2.8 then.

I can suppose that some changes could be "hidden" inside, but without dx9 I would still call it 2.8.1

They probably want to permanently lock scripts and BMS doesn't want anybody to mess with their product.

If they really wanted so I probably couldn't unpack them in 40 minutes and make packer/unpacker in next several hours
Initially scripts were leaked in a few months after game release, but they differed from the original scripts

Anyways, it's not a reason to hardcode locatization. AFAIK, all the necessary tools for localization are built into XINTERFACE

 

[kb31]

tehomod 0.9:
fixed crash when engine tries to access mod marked as outdated

 

[kb31]

tehomod 1.0 BETA(download):
mostly rewritten to c++
many stability fixes/improvements
fixed crash when key bound to non-void function
changes in config keys, has legacy checks for now
added ability to execute code during pre-OnLoad and pre-OnSave events
tehemod will probably work with other mods now(not only TEHO)

Example of code execution:
create test.c file and place it into PROGRAM folder:

int func_from_test()
{
Log_Info("func_from_test executed!");
}

create tehomod_test.ini and place it beside ENGINE.EXE(and d3d8.dll):

[Mod]
Enabled=1
Binds=1
Execute=1


[Execute]
OnLoad=LoadSegment("test.c");
OnLoad=Trace("test.c loaded!")

OnSave=UnloadSegment("test.c");
OnSave=Trace("test.c unloaded!")


[Binds]
ExecuteOurFunc.0x20=func_from_test();

Now load game and press space
func_from_test executed! message will be shown
These techniques can help to avoid existing scripts modifying in many cases

Notes about binds:
Binds available since tehomod 0.6, however there was a bug which led to crash if specified function had non-void return type
The structure of binds remains the same:
Comment.Code=FuncToExecute()
Although Comment is not currently used, it must exist and be unique
Code should be correct Virtual-Key Code represented in either hex or dec
You can't rebind in-game hotkeys, but can make additional bind to any of them

Another example of using binds:
Someone asked to make additional acceleration binds for notebooks without num-pad. Here it is:

; espkk. Additional binds for acceleration keys

[Mod]
Enabled=1
BindsEnabled=1

[Binds]
TimeScaleFaster.0xBB=PostEvent("Control Activation", 0, "s", "TimeScaleFaster")
TimeScaleSlower.0xBD=PostEvent("Control Activation", 0, "s", "TimeScaleSlower")

tehomod 1.0+ will rename BindsEnabled to just Binds

 

[kb31]

tehomod 1.0 BETA1(MEGA):
fixed crash when stormext.dll is not present

Tested with
COAS: all features (most likely) work
Caribbean Tales: new execute code feature doesn't work

Maybe I should rename TEHOmod?

 

[Myth]

tehomod 1.0 BETA1(MEGA):
fixed crash when stormext.dll is not present

Tested with
COAS: all features (most likely) work
Caribbean Tales: new execute code feature doesn't work

Maybe I should rename TEHOmod?

to bad this cant open "dead men chest"

 

[kb31]

to bad this cant open "dead men chest"

Этот мод никак не связан с открытием скриптов, это делает другой мой проект. А скрипты из того мода, я уже говорил и не раз - зашиты старфорсом, а не как в вмл, кс или гпк от бмс. Если это столько времени тебя интересует, нашел бы уже давно исошник диска да выпилил бы скрипты, я же говорил что анпакер для SFFS уже несколько лет существует в паблике

 

[kb31]

DMS(СМ) scripts uploaded

 

[ChezJfrey]

It's basically SE 2.8 then. I wonder, upgrading it to DX9 was really that hard? That's true, I didn't do it yet, but my aim is to rewrite a code to allow support for various rendering libraries, both DirectX and OpenGL. Other thing is, that despite trying of various ways to achieve that, I didn't succeeded yet.

Besides the deprecated methods, and some parameter changes, sampler states changes to be separated into sampler/texture stage states with different enumerations/methods, etc., there are a number of things going from DX 8 to 9 that break and have to be redone a different way. From what I remember:

Shadows for characters (not buildings) gets broken, creating artifacts, and there is a 'trick' to get the complete shadow to display on the ground surface.

Screenshots to render both a file and the texture image used for save games gets broken and has to be rewritten.

Videos for DX 8 are rendered using ddraw, and I found that still worked for WinXP in DX9, but breaks for Win7, and presumably later OS as well. This had to be completely rewritten. While Windows Media Foundation is the latest, not knowing enough about that stuff and not finding a readily available example to translate how the existing game code did things to Media Foundation, I opted to use DirectShow, which is still dated, but I was able to adopt a quick way to convert how things were done to use that instead. That required making a DirectShow project, compiling all the Direct Show libraries in the SDK so I could reference them. Then it turned out that set of libraries has to be compiled with all the exact same compile options as the project you intend to use them with, else you get linker errors galore due to method signature differences.

Techniques requires some work as all the shaders need to be declared in a different manner, as the STREAM method used in Techniques is no longer supported in DX 9. This required some changes to .sha files in some cases (which was trial/error for me as I don't really know much about it). Then the shader declarations need to be coded into a special array on the back end, to match the registers from the shader that will be used.

Also noticed that DX9 was more particular about resource release and during exit/shutdown of the game, the process would sometimes 'hang' unresponsive or crash because resources have to be released in reverse order of how/when they were created (textures, surfaces, vertex/index buffers, etc.). If not done in proper order, the ->release call on the dx9 object in question would not actually do anything and it stayed in memory. So, in the render deconstruction, I had to reorder all the preserved resource releases until nothing was left. I used PIX to figure out what wasn't being released even if a release was called and reordered until it was all figured out. Fun times.

I suppose I'm just saying it wasn't as trivial as hoped. Though I am curious about what BMS hangup turned out to be. They released, then dropped it? Wonder what they missed to cause issue? So far mine seems to be doing OK compared to how DX8 worked.

BMS should try 64-bit conversion, if they think DX9 was bad. That was brutal! Have to get rid of all the ASM usage just to even compile it, which means rewriting the asm as C++, find all the data types that were intended to store pointers as ints, then later derefenced, but ints are too short for 64 bit pointers, so crash no good...etc., that was fun! LOL But someone's been testing that for me and 64 bit appears to be stable so far.

Anyway, I've always like that idea you proposed about supporting various renderers, and while I can picture in my head how to maybe tackle it, that would still be a beast of a task to abstract out all the direct type/method references in the various parts of the source, in order to pass through to a 'black box' that can then pass off the necessary commands to the rendering device selected. Cool idea, but I'm not anxious to jump on that in the near future, LOL.

 

[kb31]

tehomod 1.0:
fixed beta version crashes
added event "Main". now it looks like this:

[Mod]
Enabled=1
Execute=1

[Execute]
Main=Trace("Trace before Main")
OnLoad=Trace("Trace before OnLoad")
OnSave=Trace("Trace before OnSave")

 

[konradk]

BMS should try 64-bit conversion, if they think DX9 was bad. That was brutal! Have to get rid of all the ASM usage just to even compile it, which means rewriting the asm as C++, find all the data types that were intended to store pointers as ints, then later derefenced, but ints are too short for 64 bit pointers, so crash no good...etc., that was fun! LOL But someone's been testing that for me and 64 bit appears to be stable so far.

I got rid of all asm code about two or three years ago. The version from the last year which I uploaded in the forum has no assembler code at all. I also tried to rewrite calculations on matrices using SSE, but I need to work more on that. I was also thinking about porting to 64-bit, but it won't be possible at all until we go at least to DX9 – you know, for 64 bit executable all dlls must be 64 bit too, and the earliest 64 bit for DX is version 9.

 

[kb31]

but it won't be possible at all until we go at least to DX9

I think it's already done
As well as

porting to 64-bit

 

[konradk]

I think it's already done
As well as

Fantastic! Where is that “already done” for DX9 and 64-bit version?
Прекрасно! Где эта «уже сделана» для ДиректX 9 и 64-битая версия?

 

[Myth]

I got rid of all asm code about two or three years ago. The version from the last year which I uploaded in the forum has no assembler code at all. I also tried to rewrite calculations on matrices using SSE, but I need to work more on that. I was also thinking about porting to 64-bit, but it won't be possible at all until we go at least to DX9 – you know, for 64 bit executable all dlls must be 64 bit too, and the earliest 64 bit for DX is version 9.

I think it's already done
As well as

You can add support DX9 or porting on 64-bit. But this is not available in the public domain. I would gladly launch COAS on DX 9.

 

[kb31]

Fantastic! Where is that “already done” for DX9 and 64-bit version?
Прекрасно! Где эта «уже сделана» для ДиректX 9 и 64-битая версия?

I think this is a question to ChezJfrey =)
Age of Pirates 2 COAS and GOF - JLB version

 

[Myth]

I think this is a question to ChezJfrey =)
Age of Pirates 2 COAS and GOF - JLB version

I tried to add to his fashion his fmod.dll and stuff but the game does not start

 

[kb31]

I tried to add to his fashion his fmod.dll and stuff but the game does not start

Уверяю тебя, они не понимают что ты пишешь

 

[ChezJfrey]

Fantastic! Where is that “already done” for DX9 and 64-bit version?
Прекрасно! Где эта «уже сделана» для ДиректX 9 и 64-битая версия?

Yes, I have a working copy of 64-bit with DX9...but so far only myself and one other person is using it. So far, no issues.

 

[ChezJfrey]

I tried to add to his fashion his fmod.dll and stuff but the game does not start

That can only work if using everything supplied by me, Program code, start.exe and all the .dll files must work together and there is only one version available to the public and that 'one' version of the game that is mostly a verboten subject here. But can be found here:
MEGA

Apply .7z files first, then the Update.zip over that.

 

[konradk]

Yes, I have a working copy of 64-bit with DX9...but so far only myself and one other person is using it. So far, no issues.

Congratulations.

 

[kb31]

Finally! 1.5.1 Eng came out
Scripts uploaded

Quote from steam article:

Another great news: we are thinking of giving a free access to the game's scripts so you guys will finally have an unlimited freedom to mod it. Our publisher have already greenlit this decision, but we would like to hear your opinion first. Do you want to have an opportunity to tweak and mod the game?

I was sure this would happen after I release the scripts, and I hope so it will be