lynx

Look at the CRE to see which soundset slots are set — perhaps the damage one is as well. Search the scripts for any manual firing.

Set Bored Timeout in the ini to something super high. I think 0 works for disabling too. The NPC thing sounds like a mod bug.

You always want the boom to display, so why not set that up in the projectile? You can have the secondary/aoe then apply the spell.

Since I mentioned it, here's some more testing data for horizontal paths with the "set to" mode of the opcode. Testing with boots of speed setting movement rate, values are speed in px/s, plus delta: 5: 75 6: 90 (matching default), +15 7: 105, +15 8: 120, +15 9: 120, +0 10: 120, +0 11: 235 (item default), +115 12: crash 13: crash 14: crash Utter madness. It's like 8 was the max at some point and then they bolted on 11 just for boots of speed. The 15s could be 16s (one horizontal foot), but data is data.

It does and Wait is an action, not a trigger.

Updated upstream: add more of these details, merged bg1 with a warning, softly redirected iwd version and added iwd2 research todo. Thanks!

In case anyone still cares about bg1/totsc: while trying to figure out the speed discrepancy* between haste and the boots of speed (they don't double as in bg2), testing showed that incrementing works as setting. In other words, trying to increase the rate by 3 will actually slow you down (6 being the base bg1 rate). IESDP updated to match. * somehow they make you effectively faster by setting your rate to 11 than haste doubling it to 6*2 = 12 !? The only explanation I currently have is that speed doesn't scale linearly with rate, but that would be quite silly.

I don't work for BD. But sure, added it to GemRB.

subtledoctor: you just want to change the CRE bits modifying what was the previous class in a dualclass combo? That's trivial to add, considering there are similar actions for other bits in the same set.

The extender introduced an extra bit value to fix effect stacking behaviour (eg. for regeneration and poison). EEs reused the bits for something else. Do you know of any mods relying on TobEx effect stacking? So far I know only about one on BGForge.

Moving to 64-bit will slightly increase memory use, but that isn't really the motivation — it would be if the games needed more than 4G at once, which would be a terrible regression (eg. original bg1 required 16M ).

I'd say you're very welcome to do it here, but it's not my call.

You mean SPBURN / SPFIRIMP or something else?

Interesting, so it doesn't trigger on inaccessibility (eg. a door being shut or other actors getting in the way) in bg2? Most uses are in the iwds, but I didn't expect this. Come to think of it, I've seen the uses before and thought it was just bad coding: IF Allegiance(Myself,ENEMY) ActionListEmpty() !TargetUnreachable([PC]) THEN RESPONSE #100 MoveToObject([PC]) END ... since it currently causes them to move to pcs hiding in shadows etc. I should test the original more before dismissing it, heh.

Thought it might be a synonym, but no indication, so I just fixed the example — thanks. btw, actions are now even easier to edit, since there's one per file and any variants are separated: https://github.com/Gibberlings3/iesdp/blob/master/_data/actions/162.yml

Never tried it jastey, but perhaps it would — actors, containers and area triggers do share underlying code.

Technically any line with an object would do in place of CutSceneID, the engine doesn't care. It takes the object, makes it the cutscene runner and discards the action. So it's a good idea to use a noop like CutSceneID.

Thanks, included.

Thanks everyone, IESDP now reflects this.

Conditions are trigger blocks, yes. An example script wouldn't hurt, especially since it's not clear why the parameter is needed — are some cutscenes ran with and without it?

Maybe ask in the raspbian communities, but the best bet is to compile it yourself. btw, you don't need to choose gemrb mode in the mod.

did you compile weidu yourself? I don't remember it having arm binaries.

Didn't remember The Hidden, so after some googling came upon this quote from the original writer.

Forgot to mention caillean7 did some detailed testing of the rect stuff and it appears it was gimped (doesn't work if the first point isn't [0.0]): https://github.com/gemrb/gemrb/issues/548

The process complete, here are the results: https://gemrb.github.io/2020/06/11/unexpected-new-use-case-of-gemrb.html