AkyV’s released plugins

[AkyV]

Plugin_AkyVMix01 plugin pack has been updated!

Only a readme update!

What is new?

TRG file update:
- For „Trigger’s Help” of F539 trigger (Moveable. Change the look of <&> the object slot for its MIP slot, in bigger distance from Lara than the required one):
Info added to notes:

Probably I am more exact if I say the distance is counted from the actual camera, not Lara.

- For „Trigger’s Help” of F555 trigger (Moveable. Customize <&> Falling Block time to shiver before the crash):
Info added to notes:

See a video for a custom shivering time here: …

- For „Trigger’s Help” of F559 trigger (Trap. Force the required tick frames of pause between two extensions of <&> Teeth Spikes):
Info added to notes:

See a video for a custom pause here: …

- For „Trigger’s Help” of F564 trigger (Effect. (E) Start/stop <&> customized Sprinkler):
Info added to notes:

See a video for a sprinkler which can be used as Lara’s well-controlled shower in her bathroom: …

- For „Trigger’s Help” of F584 trigger (Inventory-Item. Set <&> parameters for (E) inventory item):
Info added to notes:

Never activate it by a prompt trigger, only by some continuous way, i.e. a continuous TriggerGroup or a GlobalTrigger. Here is an example: …
It is probably not compatible at all with JMN's ring inventory.

SCRIPT file update:
- For PARAM_SPEED_PARAMETER:
Info added to root:

See videos for pulsing/moving sun here: …

- For PARAM_INVENTORY_ITEM:
Info added to ItemName field notes:

Probably you should use only the string fields which are also used originally for item names. Other fields seem useless.

[AkyV]

Plugin_AkyVMix02 plugin pack has been updated!

Only a readme update!
(Except: see parameters below.)

What is new?

TRG file update:
- For „Trigger’s Help” of F593 trigger (TriggerGroup. Perform trigger in menu mode with <&> parameter):
Info added to notes:

A video for two examples of the menu trigger here: …

- For „Trigger’s Help” of F595 trigger (Sprite. (E) Show/hide sprite with <&> parameters):
Info added to notes:

See a video here about a transparent sprite fading in then out: …
See a video here to see that variable-based position of the sprite is how useful eg. if you want to move it (also sharing the exact script for it): …

- For „Trigger’s Help” of F596 trigger (Sprite. (E) Enable/disable "raindrops on lens" effect with <&> parameters):
Info added to notes:

See an example image about this feature here: …

SCRIPT file update:
- For PARAM_VAR_MASTER:
In root:
„Global/Local Short Alfa/Beta/Delta: from 0 to 255” – that is apparently not short but Byte.

- For PARAM_PRINT_VAR:
Correction at „PositionX and PositionY fields”: textbox coordinates are for not „upper left” but „bottom left”.

- For PARAM_MENU_TRIGGER:
Correction at „Timer field”:
„If the timer requires, the linked second event will be executed” – that is naturally not „requires” but „expires”.

Correction at „TriggerID field” and „LinkID field”:
Told that the highest TriggerGroup ID here is 255.

Parameters update:
PARAM_SWITCH_SEQUENCE maximum feature ID is not 100 but 30.

[Alisa97]

Thank you for updating.
By the way, I found my post in previous page. (#109)
I completely forgot about what I said.

[loch]

Hi AkyV, I'm hoping you can help me with the fantastic lens drop effect you've implemented. I love it!


I've managed to get it working in a nice subtle way when shes in a rain room / walking through a waterfall and even when she lands in water and it splashes the screen.
They all work well however I'm finding the area of effect around the waterfall object to be fairly inconsistent with the WFallDistance1 field.

When I have it set at 1024 It's working well and will realistically stop adding the droplets when Lara is not within that range - however it feels a bit too narrow of a margin and I would like the range to be wider to 2048 from the object. Though when I set it to this amount there are instances (though not all) where the droplets continue being added for what seems like 4 times that amount away from the waterfall object that is there. So I'm either creating to small a range or a way too big one.

I must be doing something wrong, maybe you can help me by looking at my setup:
Parameters= PARAM_RAINDROP, 3, FRDROP_SPRITE+FRDROP_WFALL, 34, 2048, IGNORE, DEFAULT_SPRITES, 34, 37, 55, 0, 0, 0, 1000, 1000, 10, 100, 0, 30, 10, 2, IGNORE, IGNORE

The waterfall object is just a single vertice transparent static with no collision.

I guess I can always use the FRDROP_TRIGGER to disengage it I guess but it's a bit more work and not as elegant right

[AkyV]

Hello!
I have looked through your setup, and it looks nice.

My notices:

1. Perhaps is this your problem? (See trigger's help file.)

---------- Note for cameras: ------

There can be a bit annoying, but not serious bug: unwanted raindrops on the screen. For example, if a static camera is in a rainy room, Lara's camera in a dry (= not rainy) room, then there will be raindrops on Lara's camera (more or less time - it depends on your setup values), after the screen swaps from the static camerafor Lara's camera.
To fix that bug:

- In the case of flyby cameras in rainy rooms: if Lara's camera in a dry room, then the flyby sequence should both start and end in a dry room.
- In the case of static cameras in rainy rooms: if Lara's camera in a dry room, then the static camera should not shoot at Lara, but only a Target object. If you want to shoot at Lara in the dry room, then the Target object should be between the static camera and Lara, so it looks as if it shooted at Lara, not the Target.

-----------------------------------

2. What if you use two different setups, at different times, with different parameters:
- Rain setup is used in rainy rooms. Disabled when Lara leaves them, re-enabled when she returns.
- Waterfall setup is used in their rooms. Disabled when Lara leaves them, re-enabled when she returns.
(Naturally rainy rooms have no waterfalls in this case.)

3. See WFallObject field. I wrote there that each panel controls the setup, and they can work against each other, being (or not) Lara in their action radius.

4. Not only crucial values (like 1024, 2048 etc.) can be used for the distance limit. What if you try something different between them?

And my notes:
- The code of this setup is huge, so really fragile, I was working on it for months. So I am afraid very much that this house of cards will collapse if I touch it again. So I give advices willingly, but I wouldn't like to change the code of this feature. (Perhaps only later, those Extra fields in the end, which are still unused now.) I don't know if you want to ask an update for this now or later, but please not.
- I see that you cannot use drips for this setup. But I recommend this, a dripping Lara seems more natural in rainy rooms/close to waterfalls. (Naturally you can say "she is not wet enough for this". )
I not recommend it only with special effects, like "a passing car splashes mud drips on the camera".

[loch]

Just want to thank you again for how much work you have obviously put in to make this work. My minor issues are just that and really negligible, I am very happy overall with how it works I just was wondering more really If I had done it correctly

There can be a bit annoying, but not serious bug: unwanted raindrops on the screen. For example, if a static camera is in a rainy room, Lara's camera in a dry (= not rainy) room, then there will be raindrops on Lara's camera (more or less time - it depends on your setup values), after the screen swaps from the static camerafor Lara's camera.
To fix that bug:

- In the case of flyby cameras in rainy rooms: if Lara's camera in a dry room, then the flyby sequence should both start and end in a dry room.
- In the case of static cameras in rainy rooms: if Lara's camera in a dry room, then the static camera should not shoot at Lara, but only a Target object. If you want to shoot at Lara in the dry room, then the Target object should be between the static camera and Lara, so it looks as if it shooted at Lara, not the Target.

The issue has been with only the chase cam in this case as I'm not triggering a static or flyby at this point.

2. What if you use two different setups, at different times, with different parameters:
- Rain setup is used in rainy rooms. Disabled when Lara leaves them, re-enabled when she returns.
- Waterfall setup is used in their rooms. Disabled when Lara leaves them, re-enabled when she returns.
(Naturally rainy rooms have no waterfalls in this case.)

Yes, I'm useing 3 seperate setups- one for for rainrooms another for waterfalls and one for the splash when landing in water.

3. See WFallObject field. I wrote there that each panel controls the setup, and they can work against each other, being (or not) Lara in their action radius.

Not sure if it's partly this reason, as It's actually occurring when after passing through a single wfall object and there are no others relatively near by (say within 8 blocks).

4. Not only crucial values (like 1024, 2048 etc.) can be used for the distance limit. What if you try something different between them?

Thank you, I tried a few variations between the 1-2 blocks and It seemed anything above 1200 the issue would appear.

And my notes:
- The code of this setup is huge, so really fragile, I was working on it for months. So I am afraid very much that this house of cards will collapse if I touch it again. So I give advices willingly, but I wouldn't like to change the code of this feature. (Perhaps only later, those Extra fields in the end, which are still unused now.) I don't know if you want to ask an update for this now or later, but please not.
- I see that you cannot use drips for this setup. But I recommend this, a dripping Lara seems more natural in rainy rooms/close to waterfalls. (Naturally you can say "she is not wet enough for this". )
I not recommend it only with special effects, like "a passing car splashes mud drips on the camera".

No please don't do any extra work for me, as like I said it is such a minor issue I'm having overall, I am content to just keep the range at around 1024 and stick with that as it is still a rather satisfying effect

I had previously been using the drips effect - CUST_RAIN, FR_ADD_DRIPS_TO_LARA- for that and simply had a trigger in the areas it was needed. Its been working great so i didnt feel the need to switch it over to this instead. And my rain rooms are very lightly raining (its more like a cave dripping) so it wasnt neccessary to have Lara dripping with the amount coming down

Your the best AkyV, TY!

[AkyV]

Originally Posted by loch

Thank you, I tried a few variations between the 1-2 blocks and It seemed anything above 1200 the issue would appear.

I am pretty sure I tested even really big distances for this successfully.
So it should be a specific issue, caused by the specific setup values and/or the actual game circumstances. (Perhaps it will disappear again if it is really more than 2000.) So feel free to try bigger distances in other levels/games.

-----
Thank you for the kind words, anyway.

[loch]

Hello again AkyV! I'm wondering if you can help me with one of your conditional triggers here?

Im trying to detect when the Torch is in a water room so I can remove a flame effect from it. The condition trigger I'm using is:
C212:Moveable. The object (including Lara) is in <#> room

I'm using this as the Object Additional Syntax:
Parameters= PARAM_OBJECT_ADDITIONAL, 1, 247, IGNORE, IGNORE, 28
> 247 being the Torch slot ID ( In the reference information there isn't a specified value for C212 to use in the Object Index field so I've taken a guess as to use the objects slot ID - I'm hoping its this anyway)
> 28 is the water room I'm throwing the torch into.

Whenever I activate this condition the game crashes with this explanation:

Last diagnostic mexage:ERROR: not found my PARAMETERS of PARAM_ type 2 with (further) ID = 28

--&--

At moment of crash the program was managing:
(Item Structure of ngle Index=1044 (slot=0 room=31))

So it looks to be conflicting with the Lara (1044) in the room above this (31)?

Is there something obvious I'm missing or a mistake I'm making here?

[AkyV]

Hello!
The reference doesn't say it is a specified value, true.
But it also says:

Type here the index of the required object, what you can see in ngle.

So it must be and object ID now, not slot ID.

EDIT:
Important! One more thing.
The last field is not for the room ID. It is for a Parameters=PARAM_NUMBER_RELATION Script command ID, where you can check if the condition value is bigger/smaller/equal than the required value.

EDIT2:
Another important thing!
The torch dropped is an engine-created item. So its object ID isn't initial.
You can discover the object ID like this in a GlobalTrigger type of GT_CREATED_NEW_ITEM, which puts the item ID in "found item".
Then that can be called in a TGROUP_USE_FOUND_ITEM_INDEX, for an exported trigger.

But C212 condition trigger cannot use exported triggers, so, sorry I cannot help you now.

Later I will try to expand this feature for slots, to host engine-created items as well.

I suggest asking Titak, she made different fancy setups for the torch.

[loch]

TY for the info AkyV, I missed that number relation part but yeh I see the problem with not being able to compute the Object ID.

I've been experimenting with getting the torch to keep its flame after dropping. (Maybe there is a script for this already somewhere but I couldn't find anything?)
It works pretty well overall, its just now when I throw it into water the flame effect I'm using remains (even though the torch itself gets extinguished), so it looks a bit weird.
Ideally I would like to add a smoke effect here instead so when its in the water you could see it easier.

I'm wondering now if the torch has a different state ID when it is floating in the water that I could use this to detect it instead of checking for the environment? I see it uses state ID's form 0-3 for throwing and lighting the torch... more experimenting I guess!

If anyone wants to play with this here is the script I've been using:

GlobalTrigger= 48, FGT_SINGLE_SHOT_RESUMED, GT_CONDITION_GROUP, IGNORE, 900, 901, IGNORE
TriggerGroup= 900, $8000,9,$0023, $2000,244,$1450, $8000,80,$12B, $8000+TGROUP_OR,80,$22B, $5000+TGROUP_USE_FOUND_ITEM_INDEX,102,$2830
TriggerGroup= 901, $8000,9,$0023
AddEffect= 40, ADD_FLAME, FADD_CONTINUE_EMIT, JOINT_SINGLE_MESH, IGNORE, IGNORE, IGNORE, IGNORE, IGNORE, IGNORE

It's not working 100% right but I'm hopeing it can be refined to be better.

Interestingly the phantom flame bug doesn't occur anymore when using this - which was my whole goal for doing this - Its strange because the lit torch isn't getting put out when dropped ( a flame effect is just being added) so in theory the bug should still happen, but from what I can tell it doesn't anymore!