View Single Post
Old 31-07-18, 22:13   #231
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 3,658
Default

Dear anybody who wants two test my new plugin!

In the next afternoon (Wednesday) I will launch my new plugin in the test forum. Please, come and test it.
If you want to test, seriously, but you don’t have access to the forum, then just tell me here or in PM, and I will tell you the route and the password, taking you in the test team.

The contents that need to be tested:

SHADOW FEATURE

The shadows of enemy slots (or Lara) can be removed (F585), restored (F586) or checked if they just exist (C115).


VARIABLE FEATURE

- To perform different operations with old/new variables or memory zone fields.
- To check old/new variable or memory zone field values with condition triggers, log records or diagnostic screens.
- To print new variable or memory zone field values on the screen in custom texts.

About new variables (shortly: nvars):

a, I made them for this plugin. They have nothing to do with Paolone’s “old” variables, like Global Long Alfa, Local Byte Beta3 etc.
b, The main purpose of nvars: if the low numbers of old variables are not enough for your game.
c, New features in nvars:
- The old variables are overlapped with each other (like eg. Global Long Alfa with Global Short Alfa1 etc.). On the other hand, nvars are all independent both from each other and the old variables. I.e. you can always freely use an nvar, even if you use any other nvar or old variable.
- The old variables can handle only integer numbers. Mostly nvars, too, but a few nvars are made to handle floating numbers (till three digits).
- Even if they are “global”, you cannot transport data with the old variable from the title into the game or vice verse. But a few integer/floating nvars can do that (except: if you quit the exe, losing the title variable value).
d, The similarity to old variables:
- They are “local” to keep the values for their own levels or “global” to keep the values for the whole game.
- They have “long” size to store even really big numbers – moreover, nvars are all “long”, there are no “short” or “byte” sizes in their cases.

The 100 nvars are:
- From Local Int Nvar1 (LIN1) to Local Int Nvar45 (LIN45).
- From Local Float Nvar1 (LFN1) to Local Float Nvar5 (LFN5).
- From Global Int Nvar1 (GIN1) to Global Int Nvar40 (GIN40).
- From Global Int Nvar41 (GIN41) to Global Int Nvar45 (GIN45) – for title/game transport.
- From Global Float Nvar1 (GFN1) to Global Float Nvar3 (GFN3).
- From Global Float Nvar4 (GFN4) to Global Float Nvar5 (GFN5) – for title/game transport.

Tool – Parameters= PARAM_VAR_MASTER:

- To perform different operations with old/new variables or memory zone fields (F587).
- To check old/new variable or memory zone field values with condition triggers (C114).

The tool is useful first of all, because:
- This is the only way to set/change the value of an nvar.
- With this tool, you can set/change/check the values of all the memory zone fields directly, without using variables. Previously you could do that only for some operations, for some memory zone fields.
- Together with classic operations (addition, subtraction, setting memory zone subject etc.), new operations are also available: raise to any power, square root, storing the remainder of the division.

Possible sources are:
- numbers (integer/floating)
- old variables (integer)
- memory zone fields (integer)
- nvars (integer/floating)

Possible targets are (to change their value using the source value, or to compare their value to the source value):
- old variables (integer)
- memory zone fields (integer)
- nvars (integer/floating)

Tool – Parameters= PARAM_DIAGNOSTIC:

To check new variable or memory zone field values with diagnostic screens (F588).

It is useful in these cases:

- Nvars have their own diagnostic screen.
- Till now, there was no diagnostic screen for the memory zone fields, you could check them only copy/pasting them in old variables, seeing the diagnostic screen of the old variables.
-You can also check on the screen now even if the new variables have a bit set or clear.

Notes:
- Till you close the diagnostic screen, it will follow you on the screen, even durin menus, loadscreens. See F593 of the plugin later, to solve this.
- See F598 of this plugin later if the game removes these diagnostics during static/flyby camera screens.

Tool – variable log:

Write (F589) a log record about new variable or memory zone field values, or remove it (F590).

It is useful in these cases:

- Nvars have their own log records.
- Till now, there were no log records for the memory zone fields, you could check them there only copy/pasting them in old variables, seeing the log records of the old variables.

Notes:
- See F593 of the plugin later, to refresh the log even during menus or loadscreens.
- See F598 of this plugin later to refresh the log during static/flyby camera screens.

Tool – Parameters= PARAM_PRINT_VAR:

To print new variable or memory zone field values on the screen in custom texts (F591).

It is useful in these cases:

- You can print nvar values on the screen, in a custom text.
- Till now, there were no custom text for the memory zone fields, you could print them only copy/pasting them in old variables, printing the texts of the old variables.
- This is the only way to print custom texts during menus or loadscreens (see F593 later). So, even if you don’t want to print a variable/memory zone field there.

Notes:
- See F593 of the plugin later, the loop feature if you need a blinking text, even out of menus.
- See F598 of this plugin later to print during static/flyby camera screens.


LEVELJUMP FEATURES

- F592 allows you to export a Finish trigger into the Script, even when transporting Lara to a LARA_START_POS at the level jump.
- C113: you can check the ID of the previous level (which could be important for you eg. in some cases when Lara can get the actual level from more than one other level).

NEW SPRITE FEATURE

Parameters= PARAM_SPRITE_DISPLAY (F595) almost does the same what the classic Parameters= PARAM_SHOW_SPRITE does, but these are the new features:

- Variable-based coordinates (optional). So even if you have only one F595 trigger, the variable value in it could be different, that is why the sprite position also could be different with that single trigger.
- Fading in and fading out.
- This is the only way to show sprites during menus or loadscreens (see F593 later).

Note:
See F598 of this plugin later to show sprites during static/flyby camera screens.


RAINDROP AND DRIPPING LARA FEATURES

F597 is simply lets you simulate the 100 seconds’ long dripping of Lara with a trigger, what you usually can see when she comes out of water.
F596 (Parameters= PARAM_RAINDROP) has an “embedded version” of F597, because this is the purpose of F596:

- Raindrops or similar marks (sprites), changing dinamically and randomly “on the camera lens”.
- And/or waterdrips from Lara.

These drops/drips are made by at least one of these situations:
- Being in rainy/snowy room.
- Being close to waterfalls.
- Special but simple setups, like “mud splashes on the lens” etc.

Note:
See F598 of this plugin later to show sprites during static/flyby camera screens.


MENU/LOADSCREEN TRIGGER FEATURE

F593 (Parameters= PARAM_MENU_TRIGGER) lets you activate triggers where this is usually impossible: during menus or loadscreens.

Extra features:
- Not a general thing, you can specify the menu/loadscreen type (eg. “only the main screen of the Paused menu”.)
- Timed trigger (like, “trigger it if the menu has been open for X seconds”), or more: an “organizer”, is possible.
- Key control is available, so you can have custom key commands under menus now.

Issues:
- Some triggers of this plugin is needed instead of the usual triggers if you want to detect loadscreens properly: F592 for Finish to detect leveljump loadscreens or F594 (instead of trng.dll F98) for loading a backup savegame to detect its loadscreen.
- F591 of this plugin is needed to print custom texts during menus, trng.dll printing triggers are useless now.
- Parameters= PARAM_SPRITE_DISPLAY is needed to draw sprites during menus, Parameters= PARAM_SHOW_SPRITE of trng.dll is useless now.
- Drawing other objects during menus, not only the inventory – will be added only later, in another plugin of mine.
- Trng.dll “Image” Flipeffects are useless now, but a new Flipeffect for drawing images during menus is something I cannot do now. Maybe much later I’ll try again. Plus, that is why this menu trigger feature is useless, while you have a TRNG savegame panel (=an image) in that menu! (On the other hand, CUST_BACKGROUND doesn’t seem problematic.)
- Many other features (including playing audios or sounds) of trng.dll can be surely executed as menu triggers.


CAMERA FEATURES

- To check many parameters (actual room properties, position etc.) of the actual camera (C112, for Parameters= PARAM_ACTUAL_CAM).
- See F598 to fix the bug of missing things during static/flyby camera screens.


TRIGGER TRIGGERER FEATURE

A similar thing when you activate/deactivate Trigger_Triggerer objects to enable/disable triggers. F599 works like the trigger to activate/deactivate it, while C111 works like that Trigger_Triggerer object.
Use F599+C111 when a Trigger_Triggerer seems complicated or unuseable:

- If the trigger to enable/disable has more than one square – so, with this plugin setup, you don’t need to place one Trigger_Triggerer object on each of those squares.
- If the trigger to enable/disable is in the script, so C111 will be an exported condition in the script.


SWITCH SEQUENCE FEATURE

When the switch order is important, like in the TRLR level of “Underneath the Sphinx”, in Parameters= PARAM_SWITCH_SEQUENCE:

F600: to establish a sequence.
F601: to reset the switches. (Also possible in some other ways, without this trigger, anyway.)
C110: check the actual order of the sequence.

With some customizable parameters – but for the time being successfully tested only with Lever_Switches.

Last edited by AkyV; 27-12-18 at 09:42.
AkyV is online now   Reply With Quote