lynx

GemRB has to support eight different engines, so don't worry about some warnings and errors in the log, they are to be expected just from the game differences.

But it would be interesting to see your tooltip.2da, just as an example. Looks like one mod was lazy when rewriting a lot of your tables.

For the helmet and banter timer thing (sounds like you are getting bg1-style, that is random, banters), please file a bug.

Quote

[EffectQueue/WARNING]: Couldn't assign effect: stat:setstat
[EffectQueue/WARNING]: Couldn't assign effect: usability:itemusability

This is the only truly interesting thing from the log. These two are tobex opcodes and we only implement the first one now, so I'd expect only the second warning. But upon looking at the code, I see we weren't registering the first, which I'll fix promptly. Maybe I'll go implement the other as well, it's early in the day. What you need to know is that this is just the engine talking to itself, the warning is not saying any one item is actually using these effects.

I guess the reputation hacking is there to prevent immediate re-falling.

Plus, I doubt the stated reason for slowdowns. Anyway, you can disable the comments in the options.

It might also be hardcoded to ignore magic weapons in general.

I never tried, but I imagine it would error out immediately due to the different dialog.tlk location. If you solve that, probably no gui will be displayed, as I doubt the old assets were preserved, including their code. And we don't support the new file formats yet any way.

How hard is it to contribute? That depends on your skill, what you want to work on, how well it is understood and sometimes how well you know the games. Some of the needed work does not require programming.

On the opposite front: some of the effects just need to be moved from the iwd-specific list, some effects, triggers and actions are missing (all relatively well self-contained and in that sense easier) and there are a few flag bit differences here and there still to implement, which is also potentially simple. More advanced, but also much more consequential would be things like adding PVRZ support, which is also a nicely self-contained task, as we have "importer" plugins for each file type. All the existing implementations make the task even easier.

Yes, it will definitely load. And you don't need a reinstall, just copy the existing one so you have a quick backup if needed.

Since it only touches scripts and dialogs, installing it mid-game should be fine, since they're not part of the save game.

Until a problem is presented, it's all academic anyway. I doubt anything can beat just throwing everything on a tmpfs though.

Previous changes may affect later changes, so I don't see how batching could be done universally. If it would help with anything at all.

If you have enough memory, an in-memory "disk" would be an interesting test. Copy the game there, install mods there, record timing info and see the difference.

As for test subjects, the squirrel in Easthaven is famously invincible.

If the creatures take care of their own movement, then there's no need to modify many scripts (should be hackable through dplayer*). But this is way simpler than having a full player character.

Technically you could hex edit it to turn it into a web browser, but it's just not feasible.

That's what I'm saying, it's a bad example. I'll just remove the distinction between the versions.

Bubb confirms it for ees here:

This was added 17 years ago, so the info is unrelated to ToBEx. Could be a reverse-engineering mistake.

What I think it refers to is the scripted modal actions, not the GUI triggered ones (though internally I'm pretty sure they share the code). The example given does not make much sense though, since all these actions are blocking and I don't know of any other way to set a modal state. So you'd have to use ActionOverride which then kills the previous action anyway.

IF
  ModalState(BATTLESONG)
THEN
  RESPONSE #100
    NoAction()
END

It doesn't matter.

Yeah, it has the extra param in iwd2, but apparently didn't work in the bg line of games.

The example is not convincing of anything to me, since it could just be a simplification for HoF — two sets of items.

Too bad it doesn't help for your case; I have no other ideas.

Did you try with plain EquipItem?

Anyway, did we just find some bugs in the original — two original scripts still use SLOT_WEAPON0, so unless they added an internal translation, these shouldn't work properly:

3000brsc:

IF
  HasItemInSlot("00swdL02",Myself,SLOT_WEAPON0)
  HasItem("00swdL02",Myself)  // ~Masterwork Longsword~
THEN
  RESPONSE #100
    XEquipItem("00swdL02",Myself,SLOT_WEAPON0,TRUE)
    EquipMostDamagingMelee()
END

41pares1

    ...
    ApplySpell(Player6,2084)
    ActionOverride("OriaEssence",EquipItem("00CWRDE1",0))
    XEquipItem("00CWRDE1","OriaEssence",SLOT_WEAPON0,FALSE)
    ActionOverride("OriaEssence",EquipItem("00AX1H79",1))
    XEquipItem("00AX1H79","OriaEssence",SLOT_WEAPON0,TRUE)
    SetDoorFlag("AR4102_Switch2",HIDDEN,TRUE)
    ...

Why action are you using? Are you doing it on area load or later?

We don't even know what that trigger should be:

https://gibberlings3.github.io/iesdp/scripting/triggers/bgeetriggers.htm

Maybe the newest ee patch introduced extra ones that are not yet included on the page, but that's also a hint for you that you need the latest game.

I know GemRB does, but don't EEs also externalize the shadow, so you can set a separate bam per animation id (eg. not cshd.bam)? Still, something that works in all engines is always preferred.

I don't have access to windows. I think this got fixed already, but the build problems are in the way. Just use 0.8.8 for now, since the gameplay support is actually the same for both.

They're available from the download page ...

Do you have the same problem with the latest windows development build? It's not the latest code, but at least it's newer than the release.

Since none of the regular contributors have any relevant hardware, I'm afraid it's up to other, yet unknown contributors. The stuff in the screenshot makes it look like GLES3 has changes in its shader API/language, so perhaps the fix is easier than it seems. But I'm not a graphics guy at all.

What version are you using ...

I can confirm most of that. Our code also says:

- LeaderOf returns the actor others are following, so I guess the party formation is important

- GroupOf supposedly returns everyone with the same specifics stat

- I think LastSeen can also be set by some movement actions (MoveToObjectUntilSee)

- LastMarked also by AttackedBy, trap triggering and travel regions, CreateCreature actions (easily testable with mounted goblins in iwd2)