lynx

These are engine hacks, so it would require a lot of work to reimplement them atop EE. And then again for everytime the binary changes.

the missing descriptions are a mod problem. My guess would be you installed an EE-only or a badly ported mod, but that's just speculation.

Err, well that would be something completely else, just like khelban12 said. You described lag as everyone understands it, so this doesn't fit. I just blame windows. The speed adjustments in that config are also just for low end machines and most of these degradations have not been reimplemented in gemrb. But yes, walking speed externalisation is a live todo item, but of course it requires programming and I believe you don't have a development setup.

You asked for something completely different in that thread. But let's leave it at that, there is no point in continuing the subthread. Interactivity is a thing of hot contention in package management.

1 *is* technically possible, that's what my initial mention of Expect was about. Good point about answer preservation for READLN, but I see that as a missing weidu feature, not something unsurmountable or something the mod author should save manually. Simple choice problems are easily solved, but we're talking about the hard one — arbitrary input.

You ignored the verification problem. Or are you suggesting user choice should be ignored in case of mistakes?

Not if mod install tool have a nice "Mod Config" button which will open such ini for the player and can save edits. Not everyone can use your install tool ... and different people might use different install tools. Mods are designed for the game, not for the install tool. Replace 'can' with 'willing to' All of my proposed solution (even 3 with custom ini/json) are not dependent from the install tool type and can be implemented via any install tool. Solution 1 and 2 already exist. For solution 2, you can even display additional info during console installation: "The config.ini file not detected, read config-default.ini to change default configuration" - player will be aware how to use ini files even if he won't use any install tool at all. It's all about removing ACTION_READLN by any means necessary, not to exclusively support preferred install tool. That's a useless argument if such tools don't exist. Make my life worse and claim someone can make it better? That's still a regression. What subtledoctor was probably aiming at is that this (nonexisting?) tool likely doesn't work on non-windows systems (mobile hw, linux, macs, bsds ...). I mentioned verification for the free-form entry use case, of course it's not much of a problem when you only have a discreet list of options. The install will have to be aborted and the tool probably can't know that beforehand, as the code needs to be executed first (Halting problem).

Well, having to use inis is a pain for users, though of course it hampers automation. Expect was invented for a reason though. I only used it once, for a 1-10 choice in the 10 pc party mod, but while absurd, could easily be converted to subcomponents. There is a more serious problem — input verification. If you just read it from an ini, what do you do about typos? READLN can handle it nicely: ACTION_READLN ~newmax~ OUTER_WHILE NOT(IS_AN_INT %newmax% && %newmax% > 0 && %newmax% <= 10) BEGIN PRINT ~Enter a whole number between 1 and 10 silly. What should the new maximum party size be? [1-10]~ ACTION_READLN ~newmax~ END

the 10pp mod takes care of fixing the scripts and dialogs, that's why it exists. There are very few occurrences that can't be handled automatically (like level scaling in the final soa fight).

I very much doubt it, you said it's just a vanilla install.

The log looks fine, so I'm out of ideas, sorry. It's in the realm of profiling now, which is not easy at all.

No, that's not the way FPS works. We have a limit of 30 just so it doesn't bog down your computer, as there is no benefit to rendering more often. The original tied it to scripting speed, otherwise nobody would even touch it. output like tons of errors, especially if they are repeating.

In gemrb ai update speed is not tied to FPS, so you wouldn't see a difference. Waste of time, especially if you haven't compiled anything before. If you have, it would be interesting for various debugging purposes. Lag is quite bizarre for a desktop machine, are you getting any interesting output?

To get back on track: good job with all the updates! Long live g3!

I forgot, the diffing only works on non-windows, you just don't have the right tool. Nevermind. that dialog file is like the original, so still too short for the error message you got. Out of ideas, I'd have to try SOS myself.

I don't use SCS. Framerate can only be increased by changing a hardcoded value and recompiling. Generalized biffing: never had a problem, but also gemrb doesn't usually need it, since it has better file management code. What problem did you hit that you say it doesn't work?

Well it if it works with a different game install on the same machine and same gemrb, then it can't be a gemrb problem. What's the first error you get? I also doubt you have a 32-bit system, so it's pretty amazing if the setup works with 32-bit python.

Disregard his tobex comment, since he doesn't know gemrb. It is true though we don't support all tobex features yet, so if any of the mods uses for example "eval", that won't be executed correctly. Don't know any user, so it remains a code stub. baldur.bcs: yes, that's what I was talking about. It runs each tick, so if you overdo it (or it is done poorly), it can cause lagging. If you say SOS was the major culprit, just play without that. I don't think ambient music causes any problems in gemrb — never seen anything like that.

First, here is the latest version of SOS: https://github.com/weigo87/SoS-EE/releases looking at that file, it doesn't even have as many lines as the error is reported on: https://github.com/weigo87/SoS-EE/blob/master/SOS/D/CBGONOBL.D Please copy its content in a spoiler (you can open it with notepad), the whole version history isn't available, so I don't know if this changed in 1.14 or if some other mod enlarged that dialog. Also, once you install successfully, please zip up the "diffs" folder that was created and upload it or send it via email. I'm interested in the content, since you have so many mods installed. I can read and see if any of the changes are problematic and which mods can be added to the tested/supported list for 10pp.

Tobex and that SOS component should have no effect, at least in the exe patching way, since it's not used.

New hardware won't help. Is any of that mods heavily modding baldur.bcs? That's what usually caused lag in the original. People have played with BGT successfully, but I don't know about SCS — never tried it myself.

Looks like a mod problem, can you check which mod has a file named CBGONOBL.d or .dlg?

Still sounds like needless proliferation. With a fixed name it's also always obvious what's inside (and less chances for misspelling/miscasing). What problem does it actually solve? If the metadata is stored with the source, one always has to download it to check if it changed.

Hmm, that's a build problem. Last release added EAX support and something is wrong in the created file for windows. Do you get the same thing with a more recent build: https://ci.appveyor.com/project/lynxlynxlynx/gemrb/build/build-334/artifacts

In what case would a mod want to include more than one metadata file? Sounds like an unnecessary complication. Since you're already parsing weidu — why not store all of it there, just like author?