lynx

There's a bot linking the two, so everyone is happy.

Feel free to join us on IRC/Discord to talk things through — starts are always daunting.

Thanks, added.

You caught us at a bit unstable time, as there are several regressions and bold changes, but that also means testing is even more welcome (just check the tracker before reporting). Eg. you'll probably see missing text in the demo (#1508). As far as playtesting efficiency, I'm not sure what you mean, but any game is game.

The demo needs all these optional plugins, so install development files and rebuild.

cat > demo.cfg <<KUKU GameType=demo GamePath=../demo GemRBPath=../gemrb PluginsPath=./gemrb/plugins/ Width=800 Height=600 KUKU You can generate a minimal config with that and then pass demo.cfg to gemrb.

I see you tried latest git. It works for me now, but there have been hundreds of changes in the past few days, so I suggest you first update to the latest code. At minimum you'll have to bump the resolution. I also see a bug in one way to run it, investigating.

You can restore the single space if the warnings bother you.

Yeah, whatever reformatter the mod used broke the signature by aligning the version with the first column. No biggie, just not standard.

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