Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: The Imp
« on: July 29, 2016, 05:57:49 AM »

Sorry to semi-necro, but I just read about GAME_INCLUDES in the Weidu readme and it seems custom-made for game expansions like SoD. Why not have "GAME_IS ~bgee~" return true whether SoD is present or not, and distinguish between the two cases by using "GAME_INCLUDES ~sod~" ...?
Can you guarantee that that logic works 100% of the times... and not just 99% ?
PS, if you remember, the SoD is an expansion... so there are versions of it that are independent from the BGEE main game, as they are gotten from direct-(BeamDog) while the others from indirect-sources(Steam/GoG), and so the SoD is in a DLC folder.
Posted by: subtledoctor
« on: July 28, 2016, 08:42:49 PM »

Sorry to semi-necro, but I just read about GAME_INCLUDES in the Weidu readme and it seems custom-made for game expansions like SoD. Why not have "GAME_IS ~bgee~" return true whether SoD is present or not, and distinguish between the two cases by using "GAME_INCLUDES ~sod~" ...?
Posted by: subtledoctor
« on: May 19, 2016, 11:21:35 AM »

Well you could always fall back on the old-fashioned method of checking for some file from one game or the other.

Code: [Select]
ACTION_IF (GAME_IS ~bgee~) AND NOT (FILE_EXISTS_IN_GAME ~sodcltxt.2da~) BEGIN...would install on BGEE but not SoD.

Code: [Select]
ACTION_IF (FILE_EXISTS_IN_GAME ~sodcltxt.2da~) BEGIN...would install on SoD but not BGEE.

Code: [Select]
ACTION_IF (GAME_IS ~bgee~) BEGIN...would install on both. This likely encompasses the VAST majority of use cases, so IMHO it makes sense to require the least effort from modders for this.

EDIT - or use bd1000.are as Camdawg said earlier in the thread.
Posted by: Argent77
« on: May 19, 2016, 07:24:38 AM »

This is just an example. Actually I agree with you that in this instance it doesn't make much sense to bar out SoD installations.

However, you're also addressing my main concern about the proposed change. How can we easily check for SoD existence within the tp2 code? Since GAME_IS ~sod~ wouldn't work we'd have to find other methods. I wouldn't rely on simple file existence checks since there is always a chance of a false positive. Another foolproof check for SoD is probably by examining the SOD entry in the campaign.2da, but that would amount in a lot of boilerplate code that is much more complicated than a simple "ACTION_IF GAME_IS ~sod~ BEGIN /* do your SoD stuff... */ END".
Posted by: jastey
« on: May 19, 2016, 06:35:40 AM »

Argent77, your suggestion is based on the assumption that mods that do get updated could get an updated tp2 check?

Still, I have a serious question:
Quote
~This mod requires BG:EE without SoD to be installed.~
Why would a mod require BG:EE without SoD to be installed? If there are no engine differences, I see no reason for this check.

I see it like this:

I have bg1 mods that currently install fine on SoD, too. I want to update my mods with SoD content. And I want to achieve this with the littlest necessary update work possible. Thus, all I would need is a check for SoD to add my SoD content, while all the bg1 content gets installed as it does currently. Feel free to correct me if you see a hole in my logic.

Argent77's approach would work, but it includes more tp2 changes than I think would be necessary.
Posted by: Argent77
« on: May 18, 2016, 02:02:02 PM »

Both options have their own advantages and disadvantages.

1. Continuing to use GAME_IS as intended (i.e. using GAME_IS ~sod~ returns true for SoD-only) requires modders to add additional checks to their mods, but it also provides an easy way to distinguish between BG1:EE and BG1:SOD in their code. Many BG1:EE compatible mods are still being actively developed or maintained, so I don't think this option should be discarded right away.

2. Making an exception by allowing GAME_IS ~bgee~ to return true even for SoD allows current BG1:EE compatible mods to be installed on BG1:SOD installations without modifications, but it also requires modders to find a new approach if they want to distinguish between BG1:EE and BG1:SOD in their code.

However, there may be a third solution which combines the advantages of both options by using a global flag that defines how GAME_IS ~bgee~ or similar expressions are evaluated. Let's call it "STRICT".

This example refuses to install on a BG:SoD installation when using GAME_IS ~bgee~:
Code: [Select]
BACKUP ~TestMod/backup~
AUTHOR ~Myself~
VERSION ~1.0~
STRICT    // indicates that GAME_IS uses stricter checks for IE game variants

BEGIN ~Mod component for BG:EE only~
  REQUIRE_PREDICATE GAME_IS ~bgee~ ~This mod requires BG:EE without SoD to be installed.~
  // ...

BEGIN ~Mod component for BG:EE and BG:SoD~
  REQUIRE_PREDICATE GAME_IS ~bgee sod~ ~This mod requires BG:EE with or without SoD to be installed.~
  // ...

While this example installs correctly on a BG:SoD installation when using GAME_IS ~bgee~:
Code: [Select]
BACKUP ~TestMod/backup~
AUTHOR ~Myself~
VERSION ~1.0~

BEGIN ~Mod component for BG:EE and BG:SoD~
  REQUIRE_PREDICATE GAME_IS ~bgee~ ~This mod requires BG:EE with or without SoD to be installed.~
  // ...

Of course, it is ultimately up to Wisp to decide whether it is feasible to implement such a feature. (It doesn't necessarily have to be limited to GAME_IS.)
Posted by: subtledoctor
« on: May 18, 2016, 01:08:08 PM »

But the way, just a quick explanation of exactly why this will cause trouble: it's a logistical matter, thanks to Weidu automatic self-updating mechanism.

Right now, a bunch of mods have been updated to Weidu 239 and the use "GAME_IS ~bgee~" and the mod functions when installed on SoD. Once Weidu 240 is released, I will have to take two steps:
1) Ship Weidu 240 with my mod
2) Update all of the GAME_IS mentions to include ~sod~

Problem is, if I do that, and another mod does not do step 2 for whatever reason (we all have real lives that take up our time), when the player installs this second mod it will update its Weidu installer to v240, and now that mod, which heretofore worked perfectly well on SoD, will no longer work. In a sense, my update to my mod will break the 2nd mod... which leaves a bad taste in my mouth.

Allowing "GAME_IS ~bgee~" to return true for SoD would avoid that.
Posted by: CamDawg
« on: May 08, 2016, 06:37:23 PM »

I'm fine with eschewing a GAME_IS definition for SoD. Despite all of the forward use warnings, everyone (including me) uses it as a very lazy OR check instead of repeated stacks of ugly F_E_I_G checks. I'd love to get the same functionality without the backwards compatibility issues; I'll ponder and write up a feature request for a scheme that might work.
Posted by: subtledoctor
« on: May 08, 2016, 12:01:25 PM »

Either way the next update requires a number of mods to be updated if they should work with BGEE and its SoD expansion.

My point is, this is actually false.  The only reason tons of mods will need to be updated is that Weidu will change - fixing a "bug," to be sure, but I'm suggesting that we consider the bug to be a feature and keep it.  Because fixing the "bug" doesn't actually gain us anything, and it creates a ton of work for a ton of people.  The only thing is gains is consistency of usage... consistency with usage that nobody uses anymore.  So what is really the point?  If we can't explain what the point is, why make the change?

I understand the premise of GAME_INCLUDES, but 1) that will require just as much extra work, and ultimately provide no added benefit; and 2) then we have GAME_IS, ENGINE_IS, AND GAME_INCLUDES... but the first two are indistinguishable, so those three functions are only giving us the same functionality as we could get by using just two functions.  In which case, again, why do it?

I think it's worth discussing, because Jastey made a good point about BG1/TotSC and BG2/TOB... in each case, the game with the expansion installed amounted to a new and different engine.  Whereas, SoD is simply BGEE plus a .ZIP file with some extra game assets in it.  It literally *is* the game BGEE... so it would be reasonable for GAME_IS ~bgee~ to return true. 
Posted by: Wisp
« on: May 08, 2016, 05:36:16 AM »

With backwards comp I meant that currently, BG:EE content in SoD is detected by ~bgee~, which will change after the WeiDU update.
Formally, bgee returning true on a SoD game is a bug. GAME_IS is not performing as documented=bug. There was an analogous issue back when BG: EE was new and GAME_IS ~totsc~ would return true. The documentation of GAME_IS implies it is not forward compatible. The value which does promise forward compatibility is GAME_INCLUDES.

Quote
One question for discussion, though: For bg1 and totsc, it was a must that the two games were detected individually, because the engine was different. Thus, a mod with bg1 content had to be coded differently if it was to be installed on a BG:TotSC game.

For the EE games constantly developped, though, do I see it correctly that the engines of BG:EE and SoD are updated at the same time with the same changes? Meaning, do we need a possibility to detect the different games or do we only need a way to detect whether the extended content is present.
Which is why not implementing SoD for GAME_IS is the least intrusive change, as well as the one that makes the most sense. The differences between BG: EE before and after patch are much larger than the differences between BG: EE with and without SoD. If you want to detect SoD content, you can use GAME_INCLUDES, which is much better suited for the purpose.
Posted by: Argent77
« on: May 08, 2016, 05:15:21 AM »

Redefining the way GAME_IS or ENGINE_IS should be working is probably a very bad idea. There are countless mods that are not updated anymore which would likely break. Some of them are using game checks in ways nobody would do anymore, mainly because WeiDU evolved in time and made game detection more reliable. And installing these mods with older WeiDU versions doesn't work because of WeiDU's auto-update mechanism.

From the description of ENGINE_IS it wouldn't make much sense to implement SoD in the way you're suggesting. ENGINE_IS should be based on engine features. I'd rather see ENGINE_IS supporting ~ee~ for all the Enhanced Edition games since Beamdog aims to unify all of their games under the same engine. It already works for BG:EE and BG2:EE. You can easily substitute the BG2EE executable with the BGEE executable and the game will still work perfectly fine. IWD:EE will most likely follow in time.

The original idea to add SoD support to GAME_IS is probably the most logical choice since it already discriminates between game expansions such as BG:TotSC or IWD:HoW. Combined with the new behavior of unknown game types not triggering errors anymore it should be sufficiently future-proof in case Beamdog or someone else comes up with another Infinity Engine game or expansion.

Either way the next update requires a number of mods to be updated if they should work with BGEE and its SoD expansion.
Posted by: subtledoctor
« on: May 07, 2016, 11:19:37 PM »

GAME/ENGINE_IS will not include SoD. Problem solved.

I think Jastey's point is that, from his perspective at least, "GAME_IS will not include SoD" does not solve the problem.  In fact it actually creates a problem.  I think the most elegant solution is to have GAME_IS ~bgee~ return true in SoD, but have ENGINE_IS ~bgee~ return false in SoD. 

I think that makes a lot of sense, because every SoD game also contains BGEE within it.  So any mod targeting BGEE or edit BGEE assets/resources/etc. will reasonably want to work the same in SoD.  So they can simply use GAME_IS ~bgee~.  Meanwhile, any mod that for some reason *does* want to exclude SoD can use ENGINE_IS.  That way all bases are covered and all of the many many modders that put in time and effort to make their stuff work on SoD won't have to do it all over again when Weidu 240 comes out.  Fewer things breaking = better.  And, what's the point of having both GAME_IS and ENGINE_IS if they don't let modders do different things?

Now, I know that this is not how it worked for BG/TotSC or for SoA/TOB.  But honestly, nobody mods for those distinctions anymore.  BGT requires TOB, ToBEx requires TOB, you can't buy the old game anymore except with TOB attached.  And BG/TotSC isn't even worth discussing.

So here's my immodest proposal: break from past usage in this update.  In fact - change the way GAME_IS and ENGINE_IS work on those old games.  Allow GAME_IS to return true for both the game and the expansion in all cases, and let ENGINE_IS distinguish between them... in all cases.  This would actually break fewer things and require less work from modders to deal with, than the current method that's in beta 239.01.
Posted by: Wisp
« on: May 06, 2016, 02:16:43 PM »

GAME/ENGINE_IS will not include SoD. Problem solved.
Posted by: Andrea C.
« on: May 06, 2016, 10:47:01 AM »

Not sure that would work. This is from my SoD directory's engine.lua:

Code: [Select]
engine_name = "Baldur's Gate - Enhanced Edition"
engine_mode = 0 -- 0 = BGEE, 1 = BG2EE, 2 = IWDEE

If ENGINE_IS checks for that, ~bgee~ will return true with or without SoD (but I don't know what ENGINE_IS checks for, so I'm merely guessing.)
Posted by: subtledoctor
« on: May 04, 2016, 09:42:51 PM »

Can I achieve this with GAME_INCLUDES? If I change my current use of GAME_IS ~bgee~ to GAME_INCLUDES ~bgee~, will the mods install on SoD? Or is there an even better way?[/quote]

That would be nice... but it won't change the fact that a lot of mods that currently use GAME_IS ~bgee~ will have to be updated to work with SoD.  Breakage will happen either way.  And some of those mods might no longer be actively maintained/bug-fixed... :(

On the other hand I'm not sure what an alternative could be.  Continue to make ~bgee~ return true for SoD games?

Actually - that is something worth considering.  If GAME_IS ~bgee~ returns true for both BGEE and SoD, many mods will go on working without trouble.  If a modder wants to specifically target BGEE but not BGEE/SoD (...why? would this ever really happen?) then let them use ENGINE_IS ~bgee~ for that, which should presumably exclude the SoD engine.

If it was up to me, I would choose this as the best method.  Bonus: it would give ENGINE_IS one more reason to exist! :)