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: AL|EN
« on: August 08, 2017, 01:01:27 PM »

Guys, I'm going on vacation. To summarize, let the GUID/LABEL serve the same role as marker files ( added to weidu.log ) and a new role for mod to search GUID/LABEL inside a tp2 which is present(extracted) inside game directory, so it could be possible to check a components which might be installed in the future. Let the same GUID/LABEL be allowed for more than one component and be called <ModderPrefix>something for now, to not making this more complicated.

EDIT: Removed requirements for GUID, conversation continue here: http://forums.pocketplane.net/index.php/topic,29787.0.html
Posted by: GeN1e
« on: August 06, 2017, 07:29:56 PM »

But we have a few people participating here. Everyone, why are you not using LABEL and is there anything that could be changed about it that would make you start using it?
DESIGNATED and markers seemed to suffice just fine...

Question: Can someone explain to me why DawidW prefer to use:
Code: [Select]
REQUIRE_PREDICATE FILE_EXISTS ~override/dw#setup.mrk~ @8 // ~This component requires the core "initialise" component to be installed~instead of
Code: [Select]
REQUIRE_PREDICATE MOD_IS_INSTALLED "STRATAGEMS" "1000" @8 // ~This component requires the core "initialise" component to be installed~Does using file to check if component is installed have any advantages over checking weidu.log?
The best answer I can think of atm is that log check doesn't have any particular advantage over the marker either.
Captain Obvious, duh :D

Looking at IR's compatibility setup, it also favors markers a few times, for some reason. One specific case is SR v3, which serves as a version check as well. I could swear I heard about it being possible to retrieve installed mods' versions, but I can't seem to find it in the readme?

Regarding the difficulty of getting markers outside of FILE_EXISTS_IN_GAME, yes, I most definitely agree it is their biggest (and only?) downside.
As I mentioned, the best solution imo would be to have CONTENT_MARKER tp2 component flag, which can include one or more strings that are stored in log or somewhere, and ADD_CONTENT_MARKER tp2 action to append the list manually, e.g. if specific ACTION_IF conditions are met or something. MARKER_EXISTS ~string~ value would return 0 or 1 if such marker exists.
Both the unique string generation and mandatory part can be applied to it as well, though I continue to question the necessity of both specifications - it's more likely that only a handful of mods with complex structure really need a careful assessment of compatibility, and that can realistically be resolved by hand and a bit of nagging. Heck, you can even print a warning (without failing the install process otherwise) that a recommended bit of component information is missing - e.g. if tp2 contains ASK_EVERY_COMPONENT amount of them.

PS Do note that I don't consider myself an active modder any longer, though, more like old geezer dwelling on past accomplishments and sharing wisdom with the young, so take whatever I say with a grain of salt.
Posted by: AL|EN
« on: August 06, 2017, 04:26:20 PM »

Yep, that is a nice feature set of marker files. The worst thing is that many mods are using them and weidu cannot present/use them as a component logic dependence ( they serve such purpose) I won't even ask about it. The depper we dig, the worse it look :'(


Maybe, in order to give GUID/UUID same sort of portability as marker files, i think that they need to be placed into weidu.log when the component is installed. So other functions like MOD_IS_INSTALLED/other can check for it. And the warring about multiple components using the same LABELS should be removed. GUID/UUID_GROUP seems to be unnecessary.
Posted by: subtledoctor
« on: August 06, 2017, 03:53:00 PM »

Marker files have all of the benefits of GUID/UUID that you talked about.  Among other things, they are portable, moving with a component no matter what mod installs it.  And multiple components can install the same marker file, allowing detection of whatever quality you want to represent by it. 

For example, the first install option for Faiths & Powers, which lets you choose a deity through a dialogue, adds d5_deity.d5.  The second install method puts all of the kit choices in menus, but it also installs the deity dialogue as a backup option for NPCs and dual-classing.  So this component installs both d5_menus.d5 and d5_deity.d5.  So another mod can check whether a particular component is installed, but it can also broadly check whether that particular part of the mod is present, regardless of which component did it.
Posted by: AL|EN
« on: August 06, 2017, 03:38:43 PM »

Question: Can someone explain to me why DawidW prefer to use:
Code: [Select]
REQUIRE_PREDICATE FILE_EXISTS ~override/dw#setup.mrk~ @8 // ~This component requires the core "initialise" component to be installed~instead of
Code: [Select]
REQUIRE_PREDICATE MOD_IS_INSTALLED "STRATAGEMS" "1000" @8 // ~This component requires the core "initialise" component to be installed~Does using file to check if component is installed have any advantages over checking weidu.log?

Maybe LABEL must be added to weidu.log so MOD_IS_INSTALLED can check LABEL instead of DESIGNATED?
Posted by: subtledoctor
« on: August 06, 2017, 02:53:13 PM »

I'm open to suggestions. I think it's already been suggested you could probably add a set of predicates that take a label directly and transparently resolve it into a component number. Maybe you could even adapt some or all of the existing predicates.

But I would be entirely unsurprised if the low to non-existent usage of LABEL was less due to its properties and more due to one or more of the following:
1. The usage of marker files is too ingrained.
2. The majority of mods predate LABEL.
3. Low awareness of LABEL and "new" features in general. Many modders probably do not code their mods ab initio, drawing upon all available features (or the subset best suited for the task). Instead they do like they did in the past and/or draw more or less heavily upon example code. So in effect, established patterns stay established and new features are underutilised.

But we have a few people participating here. Everyone, why are you not using LABEL and is there anything that could be changed about it that would make you start using it?

I'm not using LABEL because I didn't know it existed.   :P  Also I don't know what it gets me.  DESIGNATED is important because it can be used as predicates.  If LABEL could be used with the same usage, interchangeably I would probably switch to LABEL.

But, of course, there are many mods that won't switch, because they are not being updated.  That's why I suggest labels and component numbers be used interchangeably - so there is a fallback that doesn't require the use of two different systems.
Posted by: subtledoctor
« on: August 06, 2017, 02:48:07 PM »

Yes, markers are so far the most flexible. The ideal solution, as I see it, would be content type register as a component flag, and also as an action to append the list manually - so that if you comment out a section of code or uninclude a tph, you'll also automatically disable the marker/register associated with that section. Basically, the exactly same thing as markers, but somewhat more robust if we assume the component flag to be mandatory (while the tp2 action remains optional).
I also don't think it would need a real GUID, just using author's nickname as prefix should be enough, even if it migrates across tp2s, from mod to mod. While there's already some other "Ardanis" registered here on PPG, and we have two Avengers, I'm rather confident such things will resolve themselves before it comes to mod publishing.

The downside to marker files - and, I think, what we are considering here - is that I don't think a GUI Weidu app could read marker file dependencies and forbiddances and translate them into visual conflicts in the GUI.  Whereas, it's seems straightforward (kind of? maybe?) to read component numbers and labels and utilize or display such stuff.
Posted by: Wisp
« on: August 06, 2017, 01:29:26 PM »

First experiments with LABEL:

- in the current state, it is keyword/feature which nobody uses. Proof: I've checked more than 600 mods https://pastebin.com/raw/TKBBsRw0 and noone is using LABEL component keyword.

Can we at lest agree that in order to make it useful, something need s to be changed/improved and there is no problem of "breaking old mods" ?
I'm open to suggestions. I think it's already been suggested you could probably add a set of predicates that take a label directly and transparently resolve it into a component number. Maybe you could even adapt some or all of the existing predicates.

But I would be entirely unsurprised if the low to non-existent usage of LABEL was less due to its properties and more due to one or more of the following:
1. The usage of marker files is too ingrained.
2. The majority of mods predate LABEL.
3. Low awareness of LABEL and "new" features in general. Many modders probably do not code their mods ab initio, drawing upon all available features (or the subset best suited for the task). Instead they do like they did in the past and/or draw more or less heavily upon example code. So in effect, established patterns stay established and new features are underutilised.

But we have a few people participating here. Everyone, why are you not using LABEL and is there anything that could be changed about it that would make you start using it?
Posted by: AL|EN
« on: August 06, 2017, 12:19:34 PM »

First experiments with LABEL:

- in the current state, it is keyword/feature which nobody uses. Proof: I've checked more than 600 mods https://pastebin.com/raw/TKBBsRw0 and noone is using LABEL component keyword.

Can we at lest agree that in order to make it useful, something need s to be changed/improved and there is no problem of "breaking old mods" ?
Posted by: GeN1e
« on: August 06, 2017, 09:42:28 AM »

I also don't think it would need a real GUID, just using author's nickname as prefix should be enough, even if it migrates across tp2s, from mod to mod. While there's already some other "Ardanis" registered here on PPG, and we have two Avengers, I'm rather confident such things will resolve themselves before it comes to mod publishing.
And then we will see "Ardanis" flag inside "Avenger" mod. Misleading and complete mess.
There's already some "Ardanis"-labeled content inside SCS, plus it helps with tracking original coder and is human-readable. Much like variables, you can generate unique names or you can use self-descriptive ones whose function is immediately recognizable, and is easier to maintain.
I predict there'd be higher rate of human error with randomly generated IDs you'd have to look up every time you need to work with compatibility, than with descriptive labels that may on a rare occasion jump between mods. Even ctrl-c/v is not a salvation here. Might as well switch to machine code.
If you get a dupe label, it can be easily checked by simply reading the code and fixed. If you accidentally mess up with GUID in some way, it'll take effort to figure out just where the error came from in the first place.
Posted by: Wisp
« on: August 06, 2017, 07:41:30 AM »

You need to use an intermediate variable.
That's not really helpful for someone who never write tp2 mod except playing with weidu commandline/components etc
Code: [Select]
BEGIN ~6~
DESIGNATED 6
LABEL ~CwEHCw0IBQk~
OUTER_SET num = ID_OF_LABEL ~setup-GUIDExample.tp2~ ~CwEHCw0IBQk~
PRINT "%num%"
Posted by: Wisp
« on: August 06, 2017, 07:40:00 AM »

The amount of work involved in loading and parsing all TP2 files in order to find some particular UUID would be stupidly large. This would especially be an issue in BWP contexts, where you can have a large number of TP2 files in the same game. On the whole, I think the number of times where it's useful to be free of the TP2 file (so far, pretty much only when a component migrates from one TP2 to another) is by far outweighed by the number of times it would be useful to limit the scope of the search (pretty much every time).

DESIGNATED assigns component numbers. These must be numbers.

Similarly, UUIDs would need to be resolved into component numbers before they could be used by predicates.
Posted by: AL|EN
« on: August 06, 2017, 07:13:02 AM »

You need to use an intermediate variable.
That's not really helpful for someone who never write tp2 mod except playing with weidu commandline/components etc

I also don't think it would need a real GUID, just using author's nickname as prefix should be enough, even if it migrates across tp2s, from mod to mod. While there's already some other "Ardanis" registered here on PPG, and we have two Avengers, I'm rather confident such things will resolve themselves before it comes to mod publishing.
And then we will see "Ardanis" flag inside "Avenger" mod. Misleading and complete mess.
Posted by: GeN1e
« on: August 06, 2017, 07:10:03 AM »

As I think about this, there's no reason multiple components couldn't share a GUID or a LABEL, right?  And CONFLICT/FORBID/REQUIRE could work on all of them.  And by the same token, there's no particular reason a single component couldn't have multiple LABELs or GUIDs.  So maybe this problem I presented is solvable.  But, again, as I think about ways to solve it, it looks a LOT like it's just replicating what I already do with marker files.
Yes, markers are so far the most flexible. The ideal solution, as I see it, would be content type register as a component flag, and also as an action to append the list manually - so that if you comment out a section of code or uninclude a tph, you'll also automatically disable the marker/register associated with that section. Basically, the exactly same thing as markers, but somewhat more robust if we assume the component flag to be mandatory (while the tp2 action remains optional).
I also don't think it would need a real GUID, just using author's nickname as prefix should be enough, even if it migrates across tp2s, from mod to mod. While there's already some other "Ardanis" registered here on PPG, and we have two Avengers, I'm rather confident such things will resolve themselves before it comes to mod publishing.
Posted by: Wisp
« on: August 06, 2017, 06:35:06 AM »

You need to use an intermediate variable.