lynx

First, you should definitely use the latest version for the best experience. The master branch has some extra fixes if you want to compile that, but otherwise .7 should be ok. We can't help you if you don't post the whole error.

IESDP, or any research for that matter, should never be trusted blindly. Similarly, I still find forum archives very useful, even if a lot of old research is vague, wrong and/or misleading. Nowadays people almost exclusively only test EEs and more shalowly, so there's a gap. But all the research, the tool updates and IESDP are a result of volunteer work. So any discrepancies are just that, discrepancies from different priorities (and the far past when there was less oversight on quality). There's nobody actively hunting for info and making sure all users have it (the closest thing is @Luke ). This subforum used to be the focal point for research, but the few years in between, when IESDP wasn't updated, hurt the practice. As far as contribution review goes: it's fully open. Sure, there's only a few people that can merge on github, but that's a technicality. Everyone is free to help with review, just like when stuff is shared on the forum. It's unfortunate that more people don't participate in this, but it's sort of boring, so it's understandable. It also makes it harder to grow the pool of people with commit access. I know you don't like git for some reason, but you're projecting a lot. Pull requests can even be marked as draft if you want to explicitly signal that they're not ready yet or that you just want to have a structured discussion before preparing a final proposal. And small incremental changes are just as welcome as big ones — as long as they're incremental improvements, not all around the place. And finally you can make as many changes in a single PR as you want, have it open for months if needed.

Any news on this? It's very annoying.

Thanks, I've updated IESDP for 146, 321, 326 and 333. Should be up in a minute.

Are you saying param2==2 is different from param2==1? We don't have it documented yet, but I don't see how it would differ. In my testing in 2014 also something else was fishy: contingency spells use type 0 yet expect an instant cast. @Grammarsalad: thanks, I'll take a look.

This subforum is low volume enough to host also modding discussions. 206: yes, that's the iwd variant. To use it in bg2, you'd have to add a new entry to an ids file and in this case we'd also have to rename the internal function, since they match in both systems. So trivial stuff. 326: looks like we don't have it yet, but it will need to be added anyway. Do I see correctly it's just an Apply Spell with the same iwd-style targetting? 321: same, but it looks very easy to do, since we do this sort of thing internally all the time. Are there any publicly available files, users of these two opcodes? Is the IESDP description correct (as far as you know)?

Not really; I think it would be best done as another game type in IESDP itself. The way effects and actions have been refactored on the backend means little need for duplication. Sure, we have some extra opcodes and actions, depending from which engine you look from. Also some things that are new to all or are just extra parameter extensions. Or the projectile externalization that I think EEs adopted partially. DLTCEP supports the gemrb-only projectile stuff, but I had no luck preparing a DAT file for it. Things just broke. The reason it's not documented yet is that some things might still change ("not a stable API"), but more practically, you're the first one to ask.

Hmm. Throw the scrollbar files up and I'll take a look.

transparency: make the white pure green (0 255 0) and it should work out of the box. window: if you want to reuse all that code, you'll have to add all the same buttons and make sure they have the same ID. It will be easier if you add the buttons to the existing window though (pst/iwd2-style).

Nice, much better now with the smaller frame. Also now there's no need to move the textarea to prevent overlap with text. The same filename is fine, it was just a placeholder. If you can change the scrollbar images to match the style, that would be even better. The originals for the bam are in demo/data/source/. edit: I've now pushed a font swap that will make the text a bit less horrible.

Thanks for the pic! Yeah, the the contrast was a bit too low on the wooden one, since it was so dark and the main text color is black (can easily be changed though!). It also made the green colouring look less bad. I also like its simpler trimming a bit more, but it's up to you to pick a gui style cave: do you want to use it? It's not in the repo yet indeed, just because it's not wired to anything yet. Options: well, you first need an options window, only then does the button become useful. Since it's a book, it could be used for the spellbook, but the same thing applies.

Override: for that purpose it is fine, but you'll eventually have to move it back if you want the changes to be included upstream. Yes, we don't load windows automatically — that would be silly, there's too many. Area bg: I prefer the current one, since it doesn't look so plastic. There's also a nice image for the interior of the cave, which you can't get into yet. The window styling is much better than what we currently have. The actor looks ok, but it probably shouldn't be pre-shaded (or not so much, now it's clear the direction doesn't match the global light). I'd appreciate if you could share a bigger picture like the second one, so I can include it in a presentation.

Err, the demo ships with its own fonts.2da — edit that, I even gave you the path. Window: do you load the window? Show me your code diff ...

The button font doesn't exist. You either need to add a new line to demo/data/fonts.2da or change ButtonFont in demo/data/gemrb.ini to point to an existing entry.

2) I don't know which timers you mean, but in general they can tick tick by tick. AFAIK the poison opcode does limit it to a second, but as you know haste and slow affect time itself. 3) No, modals are the abilities that need to fire repeatedly and have dedicated buttons.

Please submit a pull request with the proposed wording fix, for whatever you're certain of.

If it was in the area script, you ordered the area to check what it sees and move.

Use ActionOverride?

The next release will have some improvements that will benefit small form-factor platforms, including android. But until someone that cares enough steps up, there won't be new builds, since the upstream API changes require some significant work and the whole port needs some general love.

If you use replacement TTF fonts, Freetype should take care of everything, I think. But if you use window scaling on top, you'll blur everything. The original fonts are bitmap fonts, so there's not much one can do about scaling performance for them.

The ini option for extra feedback is handy here. If lightMod is anything like bg2, then there's a reference light level (23) involved that the current area one is compared to in a pretty convoluted way: ieDword lightness = game->GetCurrentArea()->GetLightLevel(Pos); // seems to be the color overlay at midnight; lightness of a point with rgb (200, 100, 100) ieDword light_diff = int((lightness - ref_lightness) * 100 / (100 - ref_lightness)) / 2; ieDword chance = (100 - light_diff) * skill/100; which is then compared to the roll in other games The light level is from: // returns a lightness level in the range of [0-100] // since the lightmap is much smaller than the area, we need to interpolate unsigned int Map::GetLightLevel(const Point &Pos) const { Color c = LightMap->GetPixel(Pos.x/16, Pos.y/12); // at night/dusk/dawn the lightmap color is adjusted by the color overlay. (Only get's darker.) const Color *tint = core->GetGame()->GetGlobalTint(); if (tint) { return ((c.r - tint->r)*114 + (c.g - tint->g)*587 + (c.b - tint->b)*299)/2550; } return (c.r*114 + c.g*587 + c.b*299)/2550; } I don't know how crelight.2da works, but from the few entries it looks like a percentage and it could be a direct mod of lightness or the whole result.

It just looks like you cranked up the sharpness. Perhaps some would find it nicer, can't say.

I can't think of a way, so I'd leave it to narrative ("this message will self-destruct in x" or something).

Thanks for the proof — lame stuff. It works fine in GemRB, but you can't play past the Ice temple there yet. Since stats were ruled out, it sounds like it would require an exe fix in the original.

Nice! Didn't know about that one. Anyway, I think this mod started at the wrong stage — areas to exclude can be figured out eventually, but without a technical proof-of-concept showing the mod is feasible in the first place, asking for areas is a bit moot.