1. GOG.com logo

    Thanks to YOUR votes, GOG.com now sells:
    - Sea Dogs - Sea Dogs: Caribbean Tales
    - Sea Dogs: City of Abandoned Ships

    Vote now to add Pirates of the Caribbean to the list!

    Dismiss Notice
  2. Under the Crossbones Podcast

    A Pirate Podcast with Interviews
    Music, Comedy and all things Pirate!

    - Episode Guide - About - Subscribe -
    - Twitter - Facebook - iTunes - Android -
    - Youtube - Fill the Coffers -

    Dismiss Notice
  3. New Horizons logo

    Quick links for PotC: New Horizons
    - Download latest version
    - Wiki - FAQ - Report bugs here
    - ModDB profile

  4. GOF logo

    Quick links for AoP2: Gentlemen of Fortune 2
    - Downloads and info
    - Historical Immersion Supermod
    - ModDB Profile

Dismiss Notice
New to the forum?
Please take a moment to read our Welcome Message and Forum Rules.

Guide TEHO modding (tehomod and scripts are here)

Discussion in 'Sea Dogs : To Each His Own' started by kb31, Jan 22, 2017.

  1. kb31

    kb31 Sailor Apprentice Storm Modder

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

    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
  2. kb31

    kb31 Sailor Apprentice Storm Modder

    Jan 13, 2017
    tehomod 0.9:
    fixed crash when engine tries to access mod marked as outdated
  3. kb31

    kb31 Sailor Apprentice Storm Modder

    Jan 13, 2017
    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:
    create tehomod_test.ini and place it beside ENGINE.EXE(and d3d8.dll):
    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:
    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:
    tehomod 1.0+ will rename BindsEnabled to just Binds
  4. kb31

    kb31 Sailor Apprentice Storm Modder

    Jan 13, 2017
    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? :D
    Last edited: Apr 21, 2017 at 6:41 AM
  5. Myth

    Myth Sailor

    Mar 25, 2014
    to bad this cant open "dead men chest"
  6. kb31

    kb31 Sailor Apprentice Storm Modder

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

    kb31 Sailor Apprentice Storm Modder

    Jan 13, 2017
    DMS(СМ) scripts uploaded
  8. ChezJfrey

    ChezJfrey Sailor Storm Modder

    Apr 24, 2015
    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.
    Last edited: Apr 23, 2017 at 9:13 PM

Share This Page