Post reply

Warning - while you were reading a new reply has been posted. You may wish to review your post.
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: AL|EN
« on: January 28, 2019, 06:41:23 PM »

I know that requesting the same items won't make it happen but I would like to request a limited version of this feature:

@wisp, can you please include "Component Flag" keywords (like MOD_IS_INSTALLED, REQUIRE_COMPONENT, FORBID_COMPONENT, REQUIRE_PREDICATE etc) and their values into --list-components-json? Let me access this information and try to deal with it accordingly.
Posted by: AL|EN
« on: July 18, 2017, 04:09:22 AM »

So we need new KEYWORD/FUNCTION: LANGUAGE_IS for modders to have pre-defined way to mark components as language-dependent and in order to export this extra-logic data from components into JSON.
Posted by: Wisp
« on: July 14, 2017, 10:49:58 AM »

What about such code:
Quote
BEGIN ~Extended Epilogues for Beamdog NPCs by shawne~ DESIGNATED 105
REQUIRE_PREDICATE GAME_IS ~bg2ee eet~ ~This component is for BG2:EE or EET only~
REQUIRE_PREDICATE ("%LANGUAGE%" STRING_COMPARE_CASE "american" = 0) ~This component is currently only available in english language~
COPY_EXISTING ~sw1h01.itm~ ~override/asc_shawnesEE.flag~ //Creates install "flag"
Is this is some sort of custom code or can be included inside component logical json data?
This is run-time state and not something that can be exported.
Posted by: AL|EN
« on: July 01, 2017, 04:52:07 AM »

What about such code:
Quote
BEGIN ~Extended Epilogues for Beamdog NPCs by shawne~ DESIGNATED 105
REQUIRE_PREDICATE GAME_IS ~bg2ee eet~ ~This component is for BG2:EE or EET only~
REQUIRE_PREDICATE ("%LANGUAGE%" STRING_COMPARE_CASE "american" = 0) ~This component is currently only available in english language~
COPY_EXISTING ~sw1h01.itm~ ~override/asc_shawnesEE.flag~ //Creates install "flag"
Is this is some sort of custom code or can be included inside component logical json data?

Posted by: AL|EN
« on: June 30, 2017, 07:04:03 AM »

Fantastic work, I've played a bit and we are getting closer and closer to revolutionary improvements. Now, proposed improvements which comes after I put my hands on what's you posted:

1. Allow more data to be present inside mod's tp2 
2. Rename --list-components-json to something like --list-mod-data-json and introduce all data from tp2 KEYWORDS + name of the tp2 file as a top-level
3. Put the data of the component requirements inside "requirements", rename "name" > "componentname" for components to have difference for properties of the mod/component

Proposed theoretical JSON data, I'm not sure if .tp2 is really necessary here:


1. Data from IE mod manifest file ( new keywords for mod description ):
Quote
{
   "mod":
   {
      "author": "argent77",
      "fullname":"Disable Enhanced Edition NPCs"
      "description": "allows you to make the new Enhanced Edition NPCs less intrusive or disable them completely.",
      "homepage": "http://www.shsforums.net/topic/58322-mod-disable-enhanced-edition-npcs/",
      "version": "v3.3",
      "semanticversion": "3.3.0.0",
      "download":"http://lynxlynx.info/ie/modhub.php?Argent77/A7-NoEENPCs"
   }
2. Data from --list-language-json comaindline

Quote
   "languageList":
   [
      {
         "languageIndex":0,
         "languageName": "English",


         "languageDescription": "English"
      },
      {
         "languageIndex":1,
         "languageName": "Deutsch",


         "languageDescription": "Deutsch"
      },
      {
         "languageIndex":2,
         "languageName": "Polish",


         "languageDescription": "Polski (tłumaczenie: Cahir)"
      }
   ]
3. Data from --list-components-json command line ( new keywords for components ), bold logic is taken from LANGUAGE_IS:
Quote
   "component":
   [
   {
      "index":12,
      "languageIndex":0,
      "number":301,
      "forced":false,
      "componentname":"Make NPC-specific items available for everyone",
      "group":[],
      "image":"",
      "category":"NPC-Related"
      "tags":"BG1EE, BG2EE"
      "requirements":[
                  {

                  "and":
                        {
                        "languageIndex": "0"
                        }

                  },
                  {
                  "or":
                     [
                        {"game": "bgee"},
                        {"game": "bg2ee"},
                        {"game": "eet"}
                     ]
                  },
                  {
                  "or":
                     [
                        {"mod": {"name": "A7NoEENPCs.tp2", "number": 1}},
                        {"mod": {"name": "A7NoEENPCs.tp2", "number": 101}},
                        {"mod": {"name": "A7NoEENPCs.tp2", "number": 102}},
                        {"mod": {"name": "A7NoEENPCs.tp2", "number": 103}},
                        {"mod": {"name": "A7NoEENPCs.tp2", "number": 104}},
                        {"mod": {"name": "A7NoEENPCs.tp2", "number": 105}}
                     ]
                  },
                  {
                  "not":
                     {"or":
                        [
                           {
                           "mod":
                              {"name": "EE_content_tweaks.tp2", "number": 0}
                           },
                           {
                              "mod": {"name": "EE_content_tweaks.tp2", "number": 1}
                           }
                        ]
                     }
                  }
                  ]
   }
   ]
}

Now, if you could provide a new weidu beta version, I can play around and test my solutions for 300+ mods.

EDIT: JSON data should also contain data from --list-languages so I've updated my proposed example.
EDIT2: language requirements could be defined for every component
Posted by: AL|EN
« on: June 27, 2017, 12:40:24 PM »

Excellent work, from the first look. I intend to do some stuff with this and give more feedback but now, just to know if we at the same track:

1. The ToB-is-true-on-BGT won't be a problem. BGT requires ToB so components with "GAME_IS contains only tob" will be show. Besides, the bg2 as a SoA-only game (limited in terms of it's content and engine features ), without ToB is no use for today's modding. Classic BG2 should be always treated as SoA + ToB + last patch. So ToB can be true before we are dealing with "BGT or not BGT" because we execute outside checks of the data/file version.

2. Because some people will never buy SoD, all components which has GAME_INCLUDES sod will be removed from mod selection after determining BG1EE state. Since EET requires SoD, the BG1EE without SoD is treated as "standalone game".

3. Such check can be preformed outside and compared to the ENGINE_IS requirements + the state of BGT/EET (enabled/disabled, extra requirements will apply).

4.  If the mod/component require BGT/EET then it might be show at the mod list as grayed until user enable BGT/EET, then other requirements are activated and mod list is processed accordingly, for eg: mods which doesn't support EET are purged from mod list.
Posted by: Wisp
« on: June 27, 2017, 07:18:47 AM »

Yeah, I haven't gotten much done lately. After barking up a couple of wrong trees, I think I have mostly settled on an output format:

Code: [Select]
"and": []
"or": []
"not": {}
"game": ""
"engine": ""
"mod": {"name": "", "number": int}

To take one of your examples:
Code: [Select]
[{"or":
  [{"game": "bgee"},
   {"game": "bg2ee"},
   {"game": "eet"}]},
 {"or":
   [{"mod": {"name": "A7NoEENPCs.tp2", "number": 1}},
    {"mod": {"name": "A7NoEENPCs.tp2", "number": 101}},
    {"mod": {"name": "A7NoEENPCs.tp2", "number": 102}},
    {"mod": {"name": "A7NoEENPCs.tp2", "number": 103}},
    {"mod": {"name": "A7NoEENPCs.tp2", "number": 104}},
    {"mod": {"name": "A7NoEENPCs.tp2", "number": 105}}]},
 {"not":
   {"or":
     [{"mod": {"name": "EE_content_tweaks.tp2", "number": 0}},
      {"mod": {"name": "EE_content_tweaks.tp2", "number": 1}}]}}]
Each object in the top-level array corresponds to a component flag.

A few issues I have yet to resolve to my satisfaction:
  • To express current semantics, these games and engines must also be mutually exclusive. You simultaneously have to propagate the ToB-is-true-on-BGT exception.
  • What about GAME_INCLUDES? Particularly, SOD? To date, all GAME_INCLUDES games except SOD can be expressed in terms of GAME_IS. But the GAME_IS semantics are not applicable to SOD. I suppose if you resolve the BGT-ToB thing, the same solution can be applied to a hypothetical BGEE-is-true-on-SOD.
  • game and engine can only be determined by examining the key file/override. Having WeiDU performing the check wouldn't work (or at least, very suboptimally) because BGT and EET are WeiDU mods, can be part of an as-of-yet unprocessed installation queue and are relevant to the installation predicates of other mods. It would also be slow as hell.
  • What about BGT and EET? I'm not keen on making hardcoded exceptions for these mods. If-hacks are among the lowest of the low.
Posted by: AL|EN
« on: June 26, 2017, 10:38:47 AM »

Because this feature is a fundamental of the progress in terms of automated mod/component installation, I would like to know more about it's status/problems when the time is right. If the current design of the weidu component dependency is a limiting factor or it prevents creating such feature because of how unpredictable tp2 code/data could be, it is yet another reason to consider breaking compatibility and do what is need to be done.
Posted by: AL|EN
« on: June 04, 2017, 03:24:05 PM »

It was only examples using my new, simplified conflict//dependency syntax for BWS. JSON + Polish notation might be even better. What was the problems?
I can live with extra weidu-based function which will execute weidu and check if file exist.
Posted by: Wisp
« on: June 03, 2017, 06:13:03 PM »

I tried for something thoughtful, but it's not working out, so I just write this:

I would like to avoid homebrewed output formats because they require each client to implement code for parsing/string comprehension. It would be preferable to use a standard format for which there are off-the-shelf parsers available. Since it's already close at hand, I've been looking at JSON. Probably something built around Polish notation, because it works well with JSON and other systems seem to lack required expressiveness.

Another problem is that I'd like to avoid needing for every client to have to implement code for determining if some biffed file exists within the game, but I don't really see a way around that.
Posted by: AL|EN
« on: June 01, 2017, 10:54:17 AM »

I've modify examples: we don't need 'C:' if we use '>' for conflict description. I still have no idea how things looks from the weidu-internal code or what idea is on you mind. Recently, I was thinking about this a lot so if you need some 4-eyes look, count me in.
Posted by: AL|EN
« on: February 14, 2017, 04:28:13 AM »

My previous request didn't include any kind of logic processing. I'm glad that you already take it into consideration.
Posted by: Wisp
« on: February 13, 2017, 03:56:50 PM »

Requesting something multiple times does not make it happen faster. Unless it does. I'm fickle that way. 1-0 to you. But I'm not doing it now, so 1-1.
Posted by: AL|EN
« on: February 13, 2017, 05:21:11 AM »

Hi wisp,
many mods already have used code using MOD_IS_INSTALLED/REQUIRE_COMPONENT ("one component needs another, not the way around") and FORBID_COMPONENT ("can't install this component because other is present").
I need to access those data somehow so how about --list-dependence ?

Syntax:
tp2nameWithoutSetup(componentNumber):tp2nameWithoutSetup(componentNumber)

Example 1 internal dependence : https://github.com/subtledoctor/NPC_EE/blob/9f5272c2190ee8506e2d1ddc97d477269b99746e/npc_ee/npc_ee.tp2#L752
Code: [Select]
BEGIN @3000
DESIGNATED 3000
REQUIRE_COMPONENT ~npc_ee.tp2~ ~2000~ @1
//GROUP @6

Proposed output:
Code: [Select]
npc_ee(3000):npc_ee(2000)


tp2 name it's the same (it's internal dependence ) but external dependence like this: https://github.com/vbigiani/refinements/blob/a587dd5e8675f13817b40f6a6ba09c57f0c56c57/setup-refinements.tp2#L293

Code: [Select]
BEGIN @702
SUBCOMPONENT @700
FORBID_COMPONENT ~bg2fixpack.tp2~ 0 ~Already included in BG2 Fixpack~


have tp2 name for another mod/component.


Proposed output:
Code: [Select]
refinements(702)>bg2fixpack(0)

The ">" stands for "conflict", you can use anything else with will distinct REQUIRE_COMPONENT from FORBID_COMPONENT

EDIT: one more example with "MOD_IS_INSTALLED" : https://github.com/Argent77/A7-NoEENPCs/blob/master/A7NoEENPCs/setup-A7NoEENPCs.tp2#L56
Code: [Select]


BEGIN @301  // Make NPC-specific items available for everyone
  REQUIRE_PREDICATE (GAME_IS ~bgee bg2ee eet~) @1000      // This component requires either BG:EE, BG2:EE or EET to be installed.
  REQUIRE_PREDICATE ((MOD_IS_INSTALLED ~setup-A7NoEENPCs.tp2~ 1) OR
                     (MOD_IS_INSTALLED ~setup-A7NoEENPCs.tp2~ 101) OR
                     (MOD_IS_INSTALLED ~setup-A7NoEENPCs.tp2~ 102) OR
                     (MOD_IS_INSTALLED ~setup-A7NoEENPCs.tp2~ 103) OR
                     (MOD_IS_INSTALLED ~setup-A7NoEENPCs.tp2~ 104) OR
                     (MOD_IS_INSTALLED ~setup-A7NoEENPCs.tp2~ 105)) @1005   // This component is only available if one or more NPCs have been disabled.
  REQUIRE_PREDICATE (NOT ((MOD_IS_INSTALLED ~EE_content_tweaks.tp2~ 0) OR
                          (MOD_IS_INSTALLED ~EE_content_tweaks.tp2~ 1)))  @1006   // This mod is not compatible with Pecca's EE_content_tweaks.
  DESIGNATED 301


Proposed output:
Quote
A7NoEENPCs(301):A7NoEENPCs(1)
A7NoEENPCs(301):A7NoEENPCs(101)
A7NoEENPCs(301):A7NoEENPCs(102)
A7NoEENPCs(301):A7NoEENPCs(104)
A7NoEENPCs(301):A7NoEENPCs(105)
A7NoEENPCs(301)>EE_content_tweaks(0)
A7NoEENPCs(301)>EE_content_tweaks(1)

// Output for the rest of the weidu code
Quote
A7NoEENPCs(101):A7NoEENPCs(3)
A7NoEENPCs(102):A7NoEENPCs(3)
A7NoEENPCs(103):A7NoEENPCs(3)
A7NoEENPCs(104):A7NoEENPCs(3)
A7NoEENPCs(105):A7NoEENPCs(3)
A7NoEENPCs(201):A7NoEENPCs(3)
A7NoEENPCs(203):A7NoEENPCs(3)
A7NoEENPCs(204):A7NoEENPCs(3)
A7NoEENPCs(205):A7NoEENPCs(3)

A7NoEENPCs(101)>A7NoEENPCs(1)
A7NoEENPCs(102)>A7NoEENPCs(1)
A7NoEENPCs(103)>A7NoEENPCs(1)
A7NoEENPCs(104)>A7NoEENPCs(1)
A7NoEENPCs(105)>A7NoEENPCs(1)
A7NoEENPCs(201)>A7NoEENPCs(1)
A7NoEENPCs(203)>A7NoEENPCs(1)
A7NoEENPCs(204)>A7NoEENPCs(1)
A7NoEENPCs(205)>A7NoEENPCs(1)

A7NoEENPCs(101)>A7NoEENPCs(2)
A7NoEENPCs(102)>A7NoEENPCs(2)
A7NoEENPCs(103)>A7NoEENPCs(2)
A7NoEENPCs(104)>A7NoEENPCs(2)
A7NoEENPCs(105)>A7NoEENPCs(2)
A7NoEENPCs(201)>A7NoEENPCs(2)
A7NoEENPCs(203)>A7NoEENPCs(2)
A7NoEENPCs(204)>A7NoEENPCs(2)
A7NoEENPCs(205)>A7NoEENPCs(2)


assuming that the "|" character means "OR", the above output can be simplified to:

Quote
A7NoEENPCs(301):A7NoEENPCs(1|101|102|103|104|105)
A7NoEENPCs(301)>EE_content_tweaks(0|1)
and for the rest of the weidu code:

Quote
A7NoEENPCs(101|102|103|104|105|201|203|204|205):A7NoEENPCs(3)
A7NoEENPCs(101|102|103|104|105|201|203|204|205)>A7NoEENPCs(1|2)

The logic behind this exist inside weidu, I'm just asking about a way to get easy access to this data.