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...
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.
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.
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.
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.
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.
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.
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+.
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?
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).
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+.
