Jump to content

Which IR should I download


Arthas

Recommended Posts

57 minutes ago, Gwendolyne said:

It is nonsense to ask modders or maintainers to make their mods compatible with a mod being installed after.

Eh, I rather think it is nonsense to ask mods that are not being maintained to add compatibility for mods that are being maintained. ;) Install order is meaningless in this case.

12 hours ago, Bartimaeus said:

It is only because of exactly one particular user's repeated prodding of me to in someway resolve this situation over the years that this subject even keeps coming up

Uh, if you are referring to this current thread and

19 hours ago, Bartimaeus said:

Anyways, I hope this is the last time we ever have this particular discussion again, because I believe it has been well and truly played out

Then, uh, nobody prodded you. I necro'd a years-old thread for the sole purpose of giving a link to some bug-fixes, and then you jumped in and started talking about 1PP and posting visual comparisons and shit. In no way did I invite "this particular discussion." That said, as long as IR-1PP compatibility is perceived as an issue that needs to be solved (and it is), this discussion will keep happening regardless of what we want. I agree with you in that I would prefer this discussion go away; I think that taking a stab at fixing the problem might be an expedient way to make that happen.

12 hours ago, Bartimaeus said:

yet another complaint and argument on how you don't see why IRR or SRR exist in the first place or how you can't even see why someone might prefer them

I did not say anything like that...? I mean, go read your SRR and IRR threads - I have often participated there, constructively, because I think the discussion of changes is relevant and interesting and can inspire good ideas. And you have good ideas! Not sure where you get the idea that differences of opinion about install methods equals  "they shouldn't exist."  I have also offered advice and code to help you with them... why would I do that if I wanted them to not exist?

12 hours ago, Bartimaeus said:

And you are happy with IR and SR as they are right now - isn't that enough?

I don't want these mods to be gimped. More, I don't want them to be perceived to be gimped. And I think there is some of that perception, and you have a habit of contributing to it. If IR has bugs or problems, I would like to see them fixed, not crow about it. I am not maintaining it, I am just a fan who can contribute some very limited amount of time and expertise (if you can call it that) to tune up the mod and solve some perceived problems. If Cahir thinks the item descriptions are a problem because they were written before the currently-most-popular version of the games were released, maybe I can help solve that! You and others often loudly complain that IR's use of 1PP resources and interaction with 1PP is a BIG PROBLEM. And frankly I credit that, because I have seen similar posts going back five, seven, ten years saying the same thing, even from Demi himself, back when 1PPv3 was released. And since the EE games incorporated some of 1PPv3, that problem is worse now because it affects even non-1PP games. And so I would like to see that problem solved, and help if I can.

Get the chip off your shoulder, stop assuming I am unreasonably hostile, and read this fucking thread again. Everything I have posted comes from a place of humility, has been me seeking guidance from people like you and DavidW who have greater knowledge and understanding than I do.

What I want, the end goal I would love to see, is a pristine, problem-free version of IRv4 that can be an official release, which does not have these 1PP-derived problems on the EE games, and is in very good condition... and next to it, IRR, similarly problem-free and tailored to your liking - icons, colors, stats, whatever. It's all good.

To that end,

10 hours ago, Bartimaeus said:

I have my own custom-selected colors for probably close to two hundred items(?) that do not match either 1pp or the EEs in addition to a number of custom icons that I myself made (and tweaks to existing icons) as well as other design choices/selections that I personally made.

Thanks, that is good to know. In that case this makes perfect sense:

10 hours ago, Bartimaeus said:

it would probably make the most sense to instead run DavidW's handy little comparison code there from the current official version of IR to the vanilla state of BG2:EE,  ... if your concern is mainly the EEs to begin with, then you can just make it an EE-only patch

I was going to write something myself, and needed guidance on what aspects of the .ITM files I should target. But in the meantime DavidW posted that and while I haven't looked at it yet, I have no doubt anything he writes in his sleep will be more effective and comprehensive than what I could do.  I'll check it out. 

(I don't suppose this would be a real fix; regardless of the incorporation of 1PP resources, I assume that like you, Demi made a number of editorial choices that differ from what is in the EE games. So this would probably not be a path to a "fixed" version of IR on the EEs... maybe that ship really has sailed. But maybe it is enough to add an optional component (or .ini setting) for players who prefer things to be in that mode.)

Edited by subtledoctor
Link to comment
1 hour ago, subtledoctor said:

Then, uh, nobody prodded you. I necro'd a years-old thread for the sole purpose of giving a link to some bug-fixes, and then you jumped in and started talking about 1PP and posting visual comparisons and shit. In no way did I invite "this particular discussion." That said, as long as IR-1PP compatibility is perceived as an issue that needs to be solved (and it is), this discussion will keep happening regardless of what we want. I agree with you in that I would prefer this discussion go away; I think that taking a stab at fixing the problem might be an expedient way to make that happen.

Didn't realize the thread was ancient until you just mentioned now. Would explain why Arthas posted it, since I was pretty sure he'd posted stuff in the IRR thread before. I was providing context for one specific thing IRR offers over IR. Of all places, wouldn't a thread specifically asking about IR vs. IRR make perfect sense for that?

1 hour ago, subtledoctor said:

Uh, if you are referring to this current thread and

[...]

Get the chip off your shoulder, stop assuming I am unreasonably hostile, and read this fucking thread again. Everything I have posted comes from a place of humility, has been me seeking guidance from people like you and DavidW who have greater knowledge and understanding than I do.

What I want, the end goal I would love to see, is a pristine, problem-free version of IRv4 that can be an official release, which does not have these 1PP-derived problems on the EE games, and is in very good condition... and next to it, IRR, similarly problem-free and tailored to your liking - icons, colors, stats, whatever. It's all good.

Am I having deja vu? It feels like about the fourth or fifth time we've had large discussions on this subject. I originally wanted exactly what you wanted - to make the official versions be the best they can be. But I was told no - Demi's not currently around, there's an issue of authorial intent and creative design decisions that simply, you know, can't really be worked around. Can do simple bugfixes (assuming they can be reviewed and confirmed by...someone or someones, I'm not exactly sure whom, there hasn't exactly been much of a concrete process to get stuff fixed over the years with a number of PRs sitting open in e.g. SR for literally years), which I compiled a huge amount for the official versions to get fixed which they mostly eventually did after...some time, but anything else is pretty much off-limits: do IRR/SRR for anything else outside of that very narrow scope. Okay, I get it, that's perfectly fair and I'm happy to work with that.

Now SR (and for the time being, only SR), very recently, has been opened for some creative decisions to be made by you, grodrigues, and myself, pursuant to some kind of consensus on those decisions. So this entire discussion in regards to making the official version of IR, you know, solve these problems is kind of irrelevant anyways, because right now, we've only received permission for SR, so anything you do, as far as I know, would have to be an after-the-fact patch anyways. Even considering just SR, it is difficult to bring over a number of fixes in anything approaching an easy manner from SRR - I've already been contemplating and mentally groaning trying to back-port my AoE Spell Deflection component fixes, which will require going back and working with the original .spl files and re-implementing a number of workarounds with those files and it's all just very time costly, and for...what benefit? It's already done. Same thing with the recent EE invisibility/breaking issue that recently came up: I've already fixed all that for both IRR and SRR items/spells via my own patches. I don't know if you'd like how I coded it, because you have a tendency to code stuff in a different manner than I do, but it's already done and already working from what I can tell. We could use it for the official version of SR...or we could keep doing what we've already been doing anyways, which is repeating a lot of work and time spent.

And for the request of @Cahir, it's something he and I already corresponded a number of times back and forth on trying to fix it (unfortunately, trying to figure out the sub-AC types and how to dynamically patch item descriptions when you don't know what the AC will already be and when the values can be anywhere between like 8 and -5 and your patching function has to be able to read that value no matter what it is was beyond me). I have a prototype of literally the exact idea you had (alternative item_descriptions.tra file in the EE style)...but what can be done with it outside of IRR, right? It's the same story as always. It's beyond frustrating to me to be asked to help fix things when I've already put so much time and effort into own, 99% of the time already working implementations of these things, and nobody can even point to any specific faults with the way I did anything, or even really complaints about the specific creative decisions I made. Why don't we just use my already working, already implemented files and solutions and then just revert the creative decisions that you or others find questionable? Wouldn't that be so much easier? Maybe I'm crazy... Well, obviously I am, but I mean in this specific regard, :).

1 hour ago, subtledoctor said:

(I don't suppose this would be a real fix; regardless of the incorporation of 1PP resources, I assume that like you, Demi made a number of editorial choices that differ from what is in the EE games. So this would probably not be a path to a "fixed" version of IR on the EEs... maybe that ship really has sailed. But maybe it is enough to add an optional component (or .ini setting) for players who prefer things to be in that mode.)

Yep - and lots of stuff looks different between the version of 1pp that IR is built on and the latest version on top of that, so trying to determine what would simply be a "fix" vs. a "change" is very murky indeed, and is why it'll likely have to be an after-the-fact patch.

@Gwendolyne I totally get it, I do, which is why I was willing to change my approach to how I handled everything (...well, that and and I had no choice if I wanted things to keep working, :p). Would've been a crazy amount of work for you to do on a mod you're not even familiar with - it makes sense. That's why I went with the "I'll just detect what the user selected and patch stuff how I like them from there".

Edited by Bartimaeus
Link to comment

Yeah, my intent in necroing the thread was not to say "here's a version people can use instead of IRR" - it was to say "here's a version people can use instead of the official IR repo."

1 hour ago, Bartimaeus said:

but what can be done with it outside of IRR, right?

 Sure it can. As I suggested to UMNiK in that other thread (not too kindly, but whatever), I tend to operate by the "Field of Dreams" model: if you build it, they will come. I built a modified version of IR with my own fixes just for me; then I figured I would upload it and make pull requests from it, to help the main branch. Those changes are very much not coded the way Demi or Mike would code them, and so maybe those pull requests will never be accepted. But then again who knows? The stuff kreso added to SR was very much not coded the way others would have ("drunken indentation" and all that) but it got blessed, and the mod is much better for it. So I'm going to keep plugging along until Mike or someone else says "hey, stop doing that!"

1 hour ago, Bartimaeus said:

But I was told no - Demi's not currently around, there's an issue of authorial intent and creative design decisions that simply, you know, can't really be worked around

But this goes a bit further - my recollection is that there were particular editorial changes that you asserted were inextricably intertwined with other improvements, and that is the reason your work could not be more integrated. Generalizing, those editorial changes seem to boil down to two categories: visual changes, and mechanical changes. You know me, I don't mind the visual stuff, I would happily accept IRR's visuals if it could have maintained IR's mechanics... but Demi was not like me, he seemed to have very strong preferences about the visuals, and that is basically the last word on the subject.

1 hour ago, Bartimaeus said:

It's beyond frustrating to me to be asked to help fix things when I've already put so much time and effort into own, 99% of the time already working implementations of these things

If you recall, and to clarify, any objections I had about your projects (proposed projects, at that time) were very specifically at their beginning, because I knew you were going to put a ton of time and work into them, and that you would be layering all that time and work over a starting product that, because of the editorial differences, could never be integrated and would be difficult to back-port. If there was ever a time to try to disentangle things, that was it. I am under no illusion and have not suggested that you should try to do so now, after having done even more work that distinguishes your versions even more from the originals. But I still don't want to just give up on the originals. So here we are, at a relative disadvantageous position, and it can't be helped. And so I need assistance. But I'm not like UMNiK, demanding some ridiculous form of delegated "collaboration." I'm out here doing this shit. I don't want anyone to do anything for me. And anything I do is always available for use and enjoyment by everyone else. But I'm also a rank amateur so I might very often need information or advice to guide what I do myself.

1 hour ago, Bartimaeus said:

Same thing with the recent EE invisibility/breaking issue that recently came up: I've already fixed all that for both IRR and SRR items/spells via my own patches. I don't know if you'd like how I coded it

Can you really not put yourself in someone else's shoes and see how frustrating this kind of thing is? It's clearly something that affects SR, and for sure if it is fixed in SR those fixes will immediately flow into SRR - just like every other improvement or fix we have added to SR. So you take it upon yourself to put some time into it... but you sequester that work in your own personal project, which means now I have to start from scratch and do it myself, which means ultimately we've both wasted time and effort. It's such a fucking one-way street, and for no benefit that I can see.  You don't know if I'd like how you coded it because I don't know how you coded, or even that you did.  Several people were discussing it and then you disappeared.

(FWIW, I could care less how something is coded, as long as it works. Again kreso's stuff is an example. I don't mind if a mod ends up with a bit of mish-mash in it. Best if the code is marked as by this person or that person, but at the end of the day all I really care about is that it ends up achieving the desired in-game effect.)

1 hour ago, Bartimaeus said:

AoE Spell Deflection component fixes

I was not even aware there is a problem with that component. Seems to work fine for me in my current game...

1 hour ago, Bartimaeus said:

Why don't we just use my already working, already implemented files and solutions and then just revert the creative decisions that you or others find questionable? Wouldn't that be so much easier?

Because I don't even know what all the creative decisions are, and a long time ago when I asked you not to change any of them, but to simply give me a list of them, so that I could do the work of changing them, you said you were unable to even list them. So my understanding is that it would not be easier.  Even above when I had the idea to use a tool like DavidW's to read parts of the .ITM characteristics from IRR to be compatible with 1PP, while retaining the mechanical characteristics that are well-established in what people think of as "Item Revisions," you shooed me away from the idea.

So my current idea is much more quixotic: add a power-user .ini option to use DavidW's tool to read the cosmetic characteristics of items as they are before IR's main component is installed; and then install IR; and then optionally patch the items' cosmetic characteristics to match the pre-existing state. To be sure, this would destroy Demi's aesthetic design decisions, so it should at best be tucked away in the settings.ini file. But, very theoretically, it could make the mod visually compatible with any underlying conditions, whether they be an EE game and any subset of 1PP installation options.

It probably won't work.

And Mike probably won't like it to be part of the official mod.

But... maybe? :undecided:

If you build it, they will come. Maybe! But if you don't build it, they definitely won't come (as UMNiK demonstrates).

Edited by subtledoctor
Link to comment
3 hours ago, subtledoctor said:

'm not exactly sure what you mean by this. But if you meant something like, you can rewrite /item_rev/languages/%lang%/ITEM_DESCRIPTIONS.TRA to better accord with the EE description style, and call the new version of the file "ITEM_DESCRIPTIONS_EE.TRA" (or whatever), then I think we can add an .ini option to let power users like yourself choose those descriptions at install time. I think this would not be against the spirit of the base mod, since the original descriptions would be default behavior.

I could certainly add it to my fork to test it out.

Yes, I was thinking exactly like that. Well, I thought rather that EE descriptions could be installed as an optional component, if you don't want it to be default for EE games, but an .ini option would be fine too (providing the instructions how to change it will be simple enough for me to understand :D)

Anyway, here is an example of what I've had in mind:

IR(R) description

Quote

@1341 = ~This is the personal armor of Drizzt, the famous dark elf ranger. It was forged for him by his friend Bruenor. Mithral is a very rare silvery, glistening metal that is lighter than iron but just as hard. This chain mail does not encumber more than a leather armor and is treated as a light armor for purposes of movement and other limitations. In addition, this suit of chain mail is highly enchanted and gives additional bonuses to the wearer's armor class.

STATISTICS:

Equipped Abilities:
 Mithral: +1 bonus to AC

Armor Class: 2
Weight: 20
Requires: 6 Strength
Not Usable By:
 Druid
 Mage
 Monk
 Thief
 Archer
 Beast Master
 Kensai
 Stalker~

EE-stylised IR(R) description

Quote

@1341 = ~This is the personal armor of Drizzt, the famous dark elf ranger. It was forged for him by his friend Bruenor. Mithral is a very rare silvery, glistening metal that is lighter than iron but just as hard. This chain mail does not encumber more than a leather armor and is treated as a light armor for purposes of movement and other limitations. In addition, this suit of chain mail is highly enchanted and gives additional bonuses to the wearer's armor class.

STATISTICS:

Equipped abilities:
– Mithral: +1 bonus to Armor Class

Armor Class: 2 (3 vs. crushing, 1 vs. piercing and missile, 0 vs. slashing)
Requires: 
 6 Strength

Weight: 20~

What I like in IR descriptions are the small flavour touches, like the name of the ability, i.e:

Mithral: +1 bonus to Armor Class

instead of simply

+1 bonus to Armor Class

I very much like to preserve those little things.

 

As I've said, I can prepare EE style descriptions, the only concern for me is IR correctly patch these descriptions for Revised armors and weapons components.

 

Quote

And for the request of @Cahir, it's something he and I already corresponded a number of times back and forth on trying to fix it (unfortunately, trying to figure out the sub-AC types and how to dynamically patch item descriptions when you don't know what the AC will already be and when the values can be anywhere between like 8 and -5 and your patching function has to be able to read that value no matter what it is was beyond me). I have a prototype of literally the exact idea you had (alternative item_descriptions.tra file in the EE style)...but what can be done with it outside of IRR, right?

Obviously I don't know a thing about WeiDU coding or regexp, but I just feel the original IR code can be adjusted to catch also EE descriptions, it just needs someone who actually understands it to expand its boundaries.

Link to comment
1 hour ago, subtledoctor said:

I was not even aware there is a problem with that component. Seems to work fine for me in my current game...

A few spells are missing from it entirely, others' get some functionality bugged/broken (think Wail of the Banshee never being able to play its signature sound effect anymore - that's because the AoE Spell Deflection component breaks the targeting of that sound, and so it needs a workaround). I think some spells are missing because stuff would break if you tried to add them...it's a little bit of a pain. And then there's also IR/R resources to add as well...

1 hour ago, subtledoctor said:

Sure it can. As I suggested to UMNiK in that other thread (not too kindly, but whatever), I tend to operate by the "Field of Dreams" model: if you build it, they will come. I built a modified version of IR with my own fixes just for me; then I figured I would upload it and make pull requests from it, to help the main branch. Those changes are very much not coded the way Demi or Mike would code them, and so maybe those pull requests will never be accepted. But then again who knows? The stuff kreso added to SR was very much not coded the way others would have ("drunken indentation" and all that) but it got blessed, and the mod is much better for it. So I'm going to keep plugging along until Mike or someone else says "hey, stop doing that!"

Yeah, I guess. I suppose I really dislike the idea of what happened with grodrigues, which is that he submitted a pile of fixes to the main branch of SR, I reviewed and gave feedback on said fixes, we weeded a few of the more questionable ones out and figured out a few more, and then...they were untouched for nearly two years after that, he decided to take a different approach in coding up that insanely exhaustive "fix SR after it's installed" mod so it wouldn't be reliant on the base mod getting fixed, then had to try to backport those changes to the base .spls after that. I would probably have given up modding entirely if that had happened to me. So yeah, no kidding I enjoy dictatorial power - I see an issue (either one that I find or one that someone else finds), I immediately fix it, do some basic testing to try to make sure it doesn't break anything, and out into the wild it goes for other people to use and provide feedback on.

1 hour ago, subtledoctor said:

Can you really not put yourself in someone else's shoes and see how frustrating this kind of thing is? It's clearly something that affects SR, and for sure if it is fixed in SR those fixes will immediately flow into SRR - just like every other improvement or fix we have added to SR. So you take it upon yourself to put some time into it... but you sequester that work in your own personal project, which means now I have to start from scratch and do it myself, which means ultimately we've both wasted time and effort. It's such a fucking one-way street, and for no benefit that I can see.  You don't know if I'd like how you coded it because I don't know how you coded, or even that you did.  Several people were discussing it and then you disappeared.

(FWIW, I could care less how something is coded, as long as it works. Again kreso's stuff is an example. I don't mind if a mod ends up with a bit of mish-mash in it. Best if the code is marked as by this person or that person, but at the end of the day all I really care about is that it ends up achieving the desired in-game effect.)

Yes...and no. You don't want to keep up with SRR or any changes that might benefit SR that I make, but I should keep up and do everything in service of the original mod that I have not meaningfully touched in years. A comparison between main_component.tpa looking like this is about enough to send me into a state of catatonia (yellow different, white same, grey missing...):

WinMergeU_pN3s0ZJyet.png

If someone downloads SRR, installs it, and finds something broken, yes, my greatest concern is fixing SRR first, not SR, whose development had all but halted for years at a time. That's just...like, how it's always worked. Hard for me to change that when SRR is my baby that I know inside and out while SR, well, I just don't.

1 hour ago, subtledoctor said:

But this goes a bit further - my recollection is that there were particular editorial changes that you asserted were inextricably intertwined with other improvements, and that is the reason your work could not be more integrated. Generalizing, those editorial changes seem to boil down to two categories: visual changes, and mechanical changes. You know me, I don't mind the visual stuff, I would happily accept IRR's visuals if it could have maintained IR's mechanics... but Demi was not like me, he seemed to have very strong preferences about the visuals, and that is basically the last word on the subject.

Yes...worse, it's been so long since I played the original mod I don't even remember all the changes I've made over the years. But again, in regards to IR, it doesn't even matter, since it's neither here nor there currently.

1 hour ago, subtledoctor said:

If you recall, and to clarify, any objections I had about your projects (proposed projects, at that time) were very specifically at their beginning, because I knew you were going to put a ton of time and work into them, and that you would be layering all that time and work over a starting product that, because of the editorial differences, could never be integrated and would be difficult to back-port. If there was ever a time to try to disentangle things, that was it. I am under no illusion and have not suggested that you should try to do so now, after having done even more work that distinguishes your versions even more from the originals. But I still don't want to just give up on the originals. So here we are, at a relative disadvantageous position, and it can't be helped. And so I need assistance. But I'm not like UMNiK, demanding some ridiculous form of delegated "collaboration." I'm out here doing this shit. I don't want anyone to do anything for me. And anything I do is always available for use and enjoyment by everyone else. But I'm also a rank amateur so I might very often need information or advice to guide what I do myself.

Wasn't really much of a choice in either of them at the time, though, at least not from my perspective. As for building it, I did build it...but maybe I built a little too much.

47 minutes ago, Cahir said:

Obviously I don't know a thing about WeiDU coding or regexp, but I just feel the original IR code can be adjusted to catch also EE descriptions, it just needs someone who actually understands it to expand its boundaries.

There should be, and I've figured out (I think) everything with the other components that isn't Revised Armor, but a field like this...

"Armor Class: 2 (3 vs. crushing, 1 vs. piercing and missile, 0 vs. slashing)"

...is a little beyond my skill to dynamically patch when those values can be positive, negative, be missing, can go from positive to negative (or the reverse) depending on what Revised Armors does with them...

Edited by Bartimaeus
Link to comment

Just to close brackets on my own involvement here:

1) It would certainly be straightforward to generate an ini that would, e.g., describe IR's changes relative to vanilla BG2EE, or IRR's changes relative to IR. There are other functions in the library that can do that (and that I used to generate the IRR ini) - happy to talk people through them. 

2) I got far enough into building a prototype that I'm confident it would be straightforward enough to build a tool to auto-generate WEIDU that applies the non-cosmetic changes between two versions of a resource. So one could autogenerate code to apply the mechanical changes from IR to IRR, for instance.

3) However, I don't use IR myself and I don't really understand either the technical or the intellectual-property issues (I was doing this mostly as a technical challenge and out of curiosity). So I've paused doing any of it for now. If at some point someone decides tools like this would be really useful for something, let me know and I'll look into finishing them off.

Link to comment
35 minutes ago, DavidW said:

Just to close brackets on my own involvement here:

1) It would certainly be straightforward to generate an ini that would, e.g., describe IR's changes relative to vanilla BG2EE, or IRR's changes relative to IR. There are other functions in the library that can do that (and that I used to generate the IRR ini) - happy to talk people through them. 

2) I got far enough into building a prototype that I'm confident it would be straightforward enough to build a tool to auto-generate WEIDU that applies the non-cosmetic changes between two versions of a resource. So one could autogenerate code to apply the mechanical changes from IR to IRR, for instance.

3) However, I don't use IR myself and I don't really understand either the technical or the intellectual-property issues (I was doing this mostly as a technical challenge and out of curiosity). So I've paused doing any of it for now. If at some point someone decides tools like this would be really useful for something, let me know and I'll look into finishing them off.

That'd be pretty wild. At this time, updating IR is not currently on the table (only SR), so it's kind of moot, but what was previously set in stone for years (that SR could not have creative changes) is no longer true today, so... I could possibly see a situation where the two branches are ultimately reconciled with something like that, where I would just keep using my current IRR install base for working on it (because lord knows I'm not switching over to trying to modify items purely through patches!), but then could use your tool to automatically generate the differences between the main version and my version and then just stick everything that it generates as an optional component to base IR that people could install directly after the main component. Neither here nor there right now, but it's possible that it could be in the future, so definitely hold on to it!

(e): Also, I presume that this could be adapted for...say, spells?

Edited by Bartimaeus
Link to comment
5 hours ago, Bartimaeus said:

(e): Also, I presume that this could be adapted for...say, spells?

In theory, yes.

In practice, spells are a lot more complicated - partly because a lot of the action is in subspells, partly because they have large numbers of closely-related headers.

Link to comment
19 hours ago, Bartimaeus said:

You don't want to keep up with SRR or any changes that might benefit SR that I make, but I should keep up and do everything in service of the original mod

Not at all what I said. Staying on the example of the 2.6 update, the invisibility-breaking stuff actually does not affect anything SRR-specific at all. It affects SR - and therefore affects SRR only in a derivative sense. The fix is not complicated, and the difference in effort to apply it to one or the other repo is zero. Literally zero extra effort, to fix it for two groups of players instead of one. And yet you choose not to. That seems pathological to me. I mean admittedly I am extremely utilitarian-minded, to the point of it being a personality fault. But... it’s like the classic runaway trolley problem, but a really stupid version of the trolley problem where saving the people in front of the trolley does not involve any kind of trade-off, it’s just free. What am I missing?

It's like, as I've been tinkering with the electrical systems in my home, I've been learning about how to effectively use GFCI outlets. A single GFCI outlet can provide ground-fault protection for all outlets that are "downstream" from it. You keep putting GFCI outlets in the downstream receptacle, when the same amount of work, placed in a different location, would provide twice the protection.

18 hours ago, DavidW said:

It would certainly be straightforward to generate an ini that would, e.g., describe IR's changes relative to vanilla BG2EE,

Based on what Bartimeus said, I’m fairly convinced that a comparo between IR and IRR would not be fruitful. But I haven’t heard anyone suggest this wouldn’t be worth trying. I didn’t have time to really tinker with it, just added it to IR as a new, initial component. But running it didn’t have any effect. Does it assume SCS is present? I saw what seemed to be some undefined variables, like %data_loc% and %workspace%. Maybe I didn’t feed it a necessary variable? 

For clarification, I think what I would like to try is 1) generate a list of files that IR copies over (easy enough, I can do that); 2) run this function to record the cosmetic data of the unmodded versions of those files; 3) install IR; and then 4) patch the new versions of that list of files with the data from step 2. 

Edited by subtledoctor
Link to comment
10 hours ago, Bartimaeus said:

There should be, and I've figured out (I think) everything with the other components that isn't Revised Armor, but a field like this...

"Armor Class: 2 (3 vs. crushing, 1 vs. piercing and missile, 0 vs. slashing)"

...is a little beyond my skill to dynamically patch when those values can be positive, negative, be missing, can go from positive to negative (or the reverse) depending on what Revised Armors does with them...

Yes, my partial success with updating this on my own ended also here. This is above my skills too. But I'm fairly sure it can be done, just preferably with someone that has deep understanding of regexp.

Link to comment
6 hours ago, subtledoctor said:

Whoops, also:

What are you talking about?? It’s the whole reason people are on this thread right now.

Sorry, I meant "updating the official version of IR in anything that isn't a simple bug-fix" is currently not on the table.

6 hours ago, subtledoctor said:

Not at all what I said. Staying on the example of the 2.6 update, the invisibility-breaking stuff actually does not affect anything SRR-specific at all. It affects SR - and therefore affects SRR only in a derivative sense. The fix is not complicated, and the difference in effort to apply it to one or the other repo is zero. Literally zero extra effort, to fix it for two groups of players instead of one. And yet you choose not to. That seems pathological to me. I mean admittedly I am extremely utilitarian-minded, to the point of it being a personality fault. But... it’s like the classic runaway trolley problem, but a really stupid version of the trolley problem where saving the people in front of the trolley does not involve any kind of trade-off, it’s just free. What am I missing?

You're welcome to review the PR I made yesterday, :). I didn't bring that one up specifically for no reason, after all.

Link to comment
6 hours ago, subtledoctor said:

Based on what Bartimeus said, I’m fairly convinced that a comparo between IR and IRR would not be fruitful. But I haven’t heard anyone suggest this wouldn’t be worth trying. I didn’t have time to really tinker with it, just added it to IR as a new, initial component. But running it didn’t have any effect. Does it assume SCS is present? I saw what seemed to be some undefined variables, like %data_loc% and %workspace%. Maybe I didn’t feed it a necessary variable? 

It doesn't assume SCS is present, but it does need you to tell it the locations of the 'workspace' and 'data_loc' directories - weidu_external/workspace and weidu_external/data/[mod name] are my usual defaults.

Here's the TP2 I was using:

BACKUP ~test/backup~
AUTHOR ~blah~
VERSION ~v1~
AUTO_EVAL_STRINGS
MODDER setup_tra none area_variables none missing_extern none missing_resref none ict2_actions none missing_eval none overwriting_file none fun_args warn


ALWAYS

	SILENT
	OUTER_SPRINT workspace "weidu_external/workspace"
	OUTER_SPRINT data_loc "weidu_external/data/dw_itemrev"
	MKDIR "%workspace%"
	MKDIR "%data_loc%"
	INCLUDE "%MOD_FOLDER%/lib/alter_effect.tpa"
	VERBOSE
END



BEGIN "move all made items" DESIGNATED 1000 NO_LOG_RECORD

MKDIR "%data_loc%/item_copy"
ACTION_BASH_FOR "item_rev/itm" ".*\.itm" BEGIN
	COPY_EXISTING "%BASH_FOR_FILE%" "%data_loc%/item_copy" IF_EXISTS
END

BEGIN "compare items" DESIGNATED 2000 NO_LOG_RECORD

INCLUDE "%MOD_FOLDER%/lib/lib_cosmetic.tph"

LAM cosmetic_data
LAF cosmetic_document_changes STR_VAR loc="%data_loc%/item_copy" RET change_count END
PRINT "%change_count% itm files changed"

BEGIN "implement changes" DESIGNATED 3000

INCLUDE "%MOD_FOLDER%/lib/lib_cosmetic.tph"
INCLUDE "%MOD_FOLDER%/lib/alter_effect.tpa"
LAM cosmetic_data
LAF cosmetic_implement_changes STR_VAR ini="%data_loc%/cosmetic_changes.ini" END

 

Link to comment
20 hours ago, Cahir said:

Mithral: +1 bonus to Armor Class

Huh... just occurres to me that YARAS does not see and respect this.  I can probably account for it.  But it will need an opt-in list of all armors categorized as mithral. Will put it on the to-do list...

9 hours ago, Cahir said:

Yes, my partial success with updating this on my own ended also here. This is above my skills too. But I'm fairly sure it can be done, just preferably with someone that has deep understanding of regexp.

Briefly, only because I clearly haven't looked into this as much as you, what is the issue here? My first thought, trailing Bartimaeus, is to simply LOAD_TRA a different .tra file according to your preferences (in an .ini setting, a subcomponent, whatever). So, questions for you off the top of my head:

  1. shouldn't that work fine for the main component?
  2. If so, then can I suppose that the problem you ran into is that a later component tries to run regexp-based replacements on the item descriptions, and fails on your modified versions? To which my first response would be, "try to leave alone the part of the description that is subject to the later regexp."
  3. But I suppose that is unacceptable because that is part of what you don't like about the IR/pre-EE description style? So the regexp itself needs to be amended?

Seems... probably solvable. I'm just not entirely clear on what precisely needs solving. (I note, for instance, that the revised .tra file Bartimaeus linked to earlier does not even specify any variant AC adjustments for different damage types...)

4 hours ago, Bartimaeus said:

You're welcome to review the PR I made yesterday

I saw no PR at the time of writing, and ended up duplicating the work myself. Oh well.

3 hours ago, DavidW said:

Here's the TP2 I was using:

Got it, thanks. I'll play around with it. If I can get it to do something useful, it might want testing from non-EE players, if any readers of this thread are of a mind. I'll post here if/when I have something ready.

Edited by subtledoctor
Link to comment
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...