Ardanis

The color scheme for "has new posts" and "no new posts" is counter-intuitive, actually. Seriously.

Even [old user] has a right to be forgotten at some point.

Nah, the "right to be forgotten" is a violation of free speech and has to be outlawed. **** the all governments that endorse it

I wish you'd get rid of the living cancer that IPB calls "message formatting"...

I suppose then, depending on a mod, it boils down to the existence of two kinds of config options - one the players are actively encouraged to tweak, and another is unsupported and only exists for expert users who really know what they're doing. If so, then it could be as simple as formatting the former to be BWS-compatible on the modder's side and include it in case-by-case manner on BWS's side, rather than uniformly trying to read all settings files.

That is assuming I understand Alien's intent correctly, obviously.

... no it doesn't, it's a text file called (item_rev/)settings.ini

 

Yes it does, in the lib folder. It's not called "settings", but technically it's the same thing. My point is that while the ini file is more obvious, it's not the only place where users can fine tune mod's parameters before installing it. And neither is really meant to be tweaked by a casual user anyway.

So, when it comes to BWS, the question is whether it's really a good idea to allow ini tweaks in the first place. Like, if it lets users to customize their setup beyond what the tp2 structure offers, then shouldn't it grant access to even more obscure settings, if the main concept is to not deprive users of any customization options they might have had with traditional install process. If it is, then it might just defeat the purpose of being a lightweight solution for those who simply want to play the damn game instead of messing with technicalities. If it's not, then why include inis at all.

Just a thought - custom settings were specifically put into config file because modder (probably) didn't want to officially support them via tp2 subcomponents, but left a door open for advanced users who know what they're doing. So, I may by now be well behind the train when it comes to mod installation, but isn't BWS supposed to make the installation process easy for normal people, who don't know how to unpack a mod archive or edit a tp2 in notepad? Taking it a step further, IR has its weapon/armor overhaul data stored in easily accessible txt table in the mod's subfolder - done so both for the maintenance ease as well as to allow said advanced players to easily adjust the values. Would it also need to be presented by BWS to the user? Probably not, but I guess you see the direction I'm being a little skeptical of.

Oh, I believe you're missing the laziest option of all--a tpa masquerading as an ini file.

ALWAYS
  OUTER_PATCH ~~ BEGIN
    PATCH_INCLUDE ~item_rev/settings.ini~
  END

 

It is same DS, if you mean SCS one.

Operative question is, does SR need to be fixed for the 2.5 patch? I.e. (I think) does it need this:

SORT_ARRAY_INDICES auxil NUMERICALLY

?

 

It's identical to

  SPRINT sort_array auxil
  LPM sort_array

present in v3.95

If you're concerned whether it's better to just use internal WeiDU function, then technically that's what I would've wanted back then. However, if memory serves me well, my macro had a bit of edge over Wisp's implementation either in being able to sort both numerically and lexically in one sweep or somehow else, so I'd rather preserve my macro somewhere in case anybody would ever need its functionality. For the purpose of fixing the v2.5 bug it makes no difference which one is used.

So it was an old, already fixed bug, at that. I would expect the macro to sort just as well.

This bug was actually the very reason I asked for WeiDU macro http://forums.pocketplane.net/index.php/topic,28279.msg331141.html#msg331141

author of the commits is David.Wallace, not myself

 

Github says "DS v3.95 from RR, with one minor change" is commited by "dawidw", but searching for users only shows one such person from Poland, Poznan. Did David change his name, or github is playing tricks on me?

Turns out, SCS was choking on those files for several people, but they had been corrupted by an earlier mod - RR. I can't find the thread where the problem was finally diagnosed... it might have been on SHS, which is currently down. But Wisp figured out that something in DS was failing when it tried to read the information in the 'resource' field in effects in the 2.5 Spell Deflection spells. And he updated RR. I think it's in 4.93? But I only see 4.92 on the RR Github page. The 4.92 readme says "Updated detectable spells" as of May 19th... but I don't know if that was to fix this problem. I thought this issue only popped up in the last couple weeks.

Ah. If what he has fixed is what has been causing issues, then it should be already fixed in the version I linked above. I knew about the potential issue, but figured it wouldn't normally happen.

I may be stupid or missing something very obvious, but what exactly is broken with DS? I've seen Kjeron's post over there, but I'm not observing anything like that in the builds I have.

Yeah, I'm only talking about the DS update that stops it corrupting .SPL files for the EE 2.5 versions of Spell Deflection et al.

Is RR's implementation the most recent, or should I look to lift code from elsewhere?

That has the K4thos's stat wants for EET.

 

That's easy, but be advised it can't automatically update RR, aTweaks, SCS and Big Picture code to actually use spellstates instead of stats in EE. Someone's gonna bite the bullet and provide platform-sensitive dual triggers to EVAL in their scripts.

Also, all AI mods will need to be updated, otherwise if at least one of them installs stats instead of spellstates, then it'll screw whatever Kathos wants regardless.

Wisp has already updated RR so maybe se what he changed there.

 

Unless I'm mistaken, it's still pre-EE version there, without spellstate support. The latest one is https://github.com/Gibberlings3/SpellRevisions/blob/master/spell_rev/lib/ds.tph though I may be unaware if any further issues have been discovered with it.

Of course just because the EE devs have moved over to checking the associated spellstates, doesn't mean various AI mods don't still use the DS stats.

Exactly. Updating DS to use spellstates in EE games would be very easy and simple, as a matter of fact. However it's up to SCS, aTweaks and RR (and iirc Big Picture too) to use spellstate checks in AI scripts instead of stats - DS can't possibly handle this, as those mods compile their scripts after DS is installed/checked.

If the fleeing character happens to be near a transition (door, gate, etc.) he uses it and the cutscene comes to a halt without having the option to terminate it

 

I assume the CutsceneID() was that party member? I developed a habit of running all cutscenes by player1 or a dedicated spy actor to avoid potential troubles that may befall the director.

Make c#brxxxx cast c#brxxxy via 146 effect, make your NPC immune to c#brxxxy (via 206), and have it set a global variable you can check in scripts.

Pretty sure HasDLC("SOD") is supposed to do what it says on the tin.

Pretty sure he was heavily involved, at least three years ago when the project was first announced.

Btw they've quite improved the graphics since then, character models look rather decent now.

"Ah! I see a few loopholes I can exploit in those terms and get away unscathed."

 

Yes, it's nice seeing you back

It's just a stupid video game. Chill out.

It's a long story spanning into the second decade by now.

And I see someone's been logging in and tampering with it already, so I figured I might as well discard it.

Oh, I see. Thought it was you logging in.

You actually recognized me right away over on the SHS thread

 

I wasn't quite certain, considering how many years have passed, until I saw recent account activity here

(and yes, this is -me-)

 

Shouldn't that've been posted by your real account... That would at least add more credibility to your claim.

Miranel: Sorry for my whiny post I didn't mean to turn this thread into a "let's give jastey a pep talk" topic.

*Checks the pic* You don't look like Jastey to me...

Vanilla is original aka non-EE for me.

Can't see too many people flocking to mod it. BG and NWN stood out because there were few other games to compete with. Today, when games are dime a dozen, it's gotta take a lot more than nostalgia factor for a player to get heavily invested into a rather niche title. So, I think just not putting effort into obfuscating the game's architecture is enough to keep it open for a casual modder.

Congrats... competitors