Method: Prototyping vs Objecting in scripting

Discussion in 'General Modification' started by anatoliy, Dec 4, 2017.

Remove all ads!
  1. anatoliy

    anatoliy Established Member

    Joined:
    Feb 18, 2017
    Messages:
    635
    Likes Received:
    200
    Story
    Let's say you have a Prototype of Generic Girl. This prototype has common reaction when attacked screaming "Aaa", that is implemented in Python script "data\scr\py1234.py". Reference to this Python script is written in the protos.tab in this Prototype section.

    But what if you have a room with three girls, one screams with "Aaa", second "Bbb", third "Ccc".
    How to implement that?

    Methods

    Duplication
    The Method is to duplicate Prototype for each Girl, and duplicate Python files.

    Script Switch
    You leave Prototype and script file, but in this prototype's script you'll specify that for some particular Girl other scream text should be defined.

    MOB Script Duplication
    You leave Prototype and prototype's script unchanged, but duplicate script file to new one for each and then reference this new script in MOB through Script Attachment Point.
    It seem to me that this method is rarely used by the Community. Perhaps because ToEEWB didn't implemented SA Points editing...

    I wonder if in new script files you can call Generic Girl reaction if you want to...
     
  2. marc1967

    marc1967 Established Member

    Joined:
    Jan 19, 2014
    Messages:
    578
    Likes Received:
    60

    You can give each of the 3 mobs a different object name (say 8201,8202,8203), then in san_start_combat() do something like this:
    Code:
    if attachee.name == 8201:
        attachee.float_line(100,triggerer)  # scream "Aaaaa"
    elif attachee.name == 8202:
        attachee.float_line(200,triggerer)  # scream "Bbbbb"
    elif attachee.name == 8203:
        attachee.float_line(300,triggerer)  # scream "Ccccc"
    If you think using up new object name just for a slight dialog change is overkill, you could set something else slightly different in the mob to tell them apart, such as the HP value or the X,Y standpoint.
     
  3. anatoliy

    anatoliy Established Member

    Joined:
    Feb 18, 2017
    Messages:
    635
    Likes Received:
    200
    Naming is in data\mes\description.mes right? Or it can be in modules\toee\gamedesc.mes ?
     
  4. anatoliy

    anatoliy Established Member

    Joined:
    Feb 18, 2017
    Messages:
    635
    Likes Received:
    200
    Personally I would rather query GUID and test against it, if it's possible through Python ToEE API.

    Another way I'm considering, is to use Counter0 as parameter to san_start_combat script. It's kind of interesting concept.
     
  5. marc1967

    marc1967 Established Member

    Joined:
    Jan 19, 2014
    Messages:
    578
    Likes Received:
    60
    The file description.mes is just the list of English language names for each proto.

    The object name, which is a number, is found in attachee.name, and is different for each proto. It is often the same number as the proto number, but a different number can be assigned either in the proto itself or later on when a MOB is made. The list of these are in data\oemes\oname.mes.

    I don't know what gamedesc.mes is.
     
  6. anatoliy

    anatoliy Established Member

    Joined:
    Feb 18, 2017
    Messages:
    635
    Likes Received:
    200
    Python obj.name (PyObjHandle_GetNameId) is transferred to obj.h\Objects->_GetInternalFieldInt32(handle, obj_f_name), meaning that it's a property obj_f_name of type UInt32.
    And
    Python obj.description (PyObjHandle_GetDescription) is transferred to return PyString_FromString(objects.description.getDisplayName(self->handle)), meaning that it will open dictionary of name_id strings.

    This dictionary of name_id strings is built somewhat differently in TemplePlus.exe, as stated in release notes:
    * - description.mes (*.mes files in mes\description\ folder)

    you can create folder named description in data\mes = data\mes\descripton and put there any *.mes file that will be treated as part of main description.mes. Which I consider to be very cool feature indeed.
     
  7. Sitra Achara

    Sitra Achara Senior Member

    Joined:
    Sep 1, 2003
    Messages:
    3,613
    Likes Received:
    537
    Note that these are Temple+ features not present in vanilla ToEE.
     
    anatoliy likes this.
  8. anatoliy

    anatoliy Established Member

    Joined:
    Feb 18, 2017
    Messages:
    635
    Likes Received:
    200
    Let's say I want to create a Girl named Anna. How would I do that?

    In description.mes (message) file there is a comment-header "Unless you are adding a prototype, DO NOT PLACE NEW MESSAGES IN THIS FILE. New descriptions and such go in a module-based file called gamedesc.mes".

    So adding new Girls is actually adding object, which will be stored in the module folder (modules\module\maps\somemap\anna-guid.mob). In this mob I will put newly generated name_id into field "Known" (obj_f_critter_description), leaving Prototype name_id in (obj_f_critter_description_unknown). It means that unless Player met Anna, her name will be displayed as Girl (from protos.tab). But after meeting (talking to only?) her name will be displayed as name_id lookuped from description message dictionary.

    Logically, if Anna is not Prototype but unique Object, then I should put this new name into module based message file. But which file?

    IF you unpack vanilla toee.data, you can see that there are interesting files in modules\ToEE\mes folder:
    gamearea.mes
    gamebless.mes
    gamebook.mes
    gamecurse.mes
    gamedesc.mes
    gameitemeffect.mes
    gamenewspaper.mes
    gamenote.mes
    gameplaque.mes
    gametelegram.mes
    StoryState.mes
    Some of them, off-course, are leftovers from Arcanum, like newspaper :)

    But, nevertheless, gamedesc.mes is here, AND this file is referenced in temple.dll (checked through strings window in IDA).

    I also checked WorldEd editing Object name, and yes it references \modules\toee\mes\gamedesc.mes but only if name_id is greater than 30000 (tested 30364 - worked, 20364 - not worked).

    Unfortunately, current version of Temple+ has rewritten portion of mes loading, and although there is handle of gamedesc.mes - gameDescMes, but file loading is not written. I guess it could be added, do agree, @Sitra Achara ?

    In conclusion, I believe it would be best strategy, leaving description.mes unclogged and dedicated only to prototype names, to add new name_id into module based file gamedesc.mes.
     
  9. Allyx

    Allyx Master Crafter Global Moderator Supporter

    Joined:
    Dec 2, 2004
    Messages:
    5,001
    Likes Received:
    250
    I personally make my mods compatible with Temple+ but not dependant on Temple+, because it adds a layer of hardware requirement over and above the original game's minimum hardware requirements.

    I know ToEE is an old game, but perhaps not everyone using it has a new PC to play it on.
     
  10. anatoliy

    anatoliy Established Member

    Joined:
    Feb 18, 2017
    Messages:
    635
    Likes Received:
    200
    What hardware requirements are you talking about?
     
  11. Allyx

    Allyx Master Crafter Global Moderator Supporter

    Joined:
    Dec 2, 2004
    Messages:
    5,001
    Likes Received:
    250
    ToEE was designed to run on hardware capable of running DirectX 9.0c, Temple+ increases the requirement to DirectX 11 IIRC, which means older GFX cards that could run vanilla ToEE, but are incapable of using DirectX 11, would not be able to use Temple+.
     
  12. anatoliy

    anatoliy Established Member

    Joined:
    Feb 18, 2017
    Messages:
    635
    Likes Received:
    200
    I suppose TemplePlus.exe only requires library DX11 to bi installed. I don't think the game really uses DX11 only features.

    But yes, I see your point.
    @Sitra Achara did you choose DX11 lib because of particular features, or just modernized the build?
     
  13. Sitra Achara

    Sitra Achara Senior Member

    Joined:
    Sep 1, 2003
    Messages:
    3,613
    Likes Received:
    537
    That's @DarkStorm's area of expertise but IIRC it's because it's impossible to debug dx9 in modern systems (unsupported by windows IIRC).
     
  14. DarkStorm

    DarkStorm Established Member

    Joined:
    Oct 2, 2003
    Messages:
    514
    Likes Received:
    3
    We are using DX11 features (no fixed function pipeline) because Dx9 is barely in maintenance mode anymore. DX11 gives better forward compatibility for newer operating systems.
    And yes, it's practically impossible to debug DX9 in Windows 10+.
     
Our Host!