Tanks, CDPR, you just made my day

+
thats why there is this specially selected group of people called: you guessed it.... :"Moderators"
stop being so anti-everything... its a great idea!

Believe me, having a direct link to developers is a great idea, but that simply doesn't work if it's not properly organized. The fact that this question has apparently never been read by a dev is a good example of this. I'm not anti-everything, I simply explain how such thing can work. I would be anti everything if I just said "that won't work, stop dreaming". I gave both the problem and what I believe is the solution. I simply believe the modding community need a few guys, and clearly you would me one of my picks along with KNG and Holgan, who can serve as "representative", and have a favoured link with the devs. If I have a question, rather than asking it on your sticky post direct to the dev, I would relay it to KNG, Holgan, and yourself, and you would either answer it, or if you don't have the answer (and that's a relevant question), you could discuss it during the next "Q/A" with the dev. This interface between the representatives & the modders could really well be a sticky post, but the interface with the dev would be via another mean. A moderator, given this moderator is a talented modder, could very well be this medium as well.

That's my opinion, it doesn't serve as being against another great idea, it serves as my attempt for improving it, while using my experience in general to know what works and what doesn't, from other games and similar interface.
 
That would be one of most urgent ones.
In general we need more info on custom classes and global events. Without being able to reliably create custom classes and have them instance automatically (with functioning timers) we're unable to do anything good/complex.

I thought I had proposed a pragmatic workaround for this problem. At least until somebody comes up with a better solution. Only one person bothered to ask for any info. As a result I didn't even attempt to improve it or add more helpful stuff (not to mention port it to 1.12). So I'm not sure if these are the "most urgent" issues. But if we get an official solution I'll certainly welcome it.
 
What channel did you use to ask these questions? E.g. I never heard this before. It may indeed be a five minute answer (alas, I'm not a programmer I dunno) but note that if it was posted on forums then the right dev would have to be at the right time in the right section of forums to read it and not everyone spends time on forums in general (and I mean any forums). Also, sometimes info is proprietary.
What if we had a forum where everyone could create a topic, but only devs could answer? Since devs answer to forum posts in their free time, let's make it easier for us to communicate. Sometimes even simple answers like "it's proprietary" or "we don't know" are enough. :)

I thought I had proposed a pragmatic workaround for this problem. At least until somebody comes up with a better solution. Only one person bothered to ask for any info. As a result I didn't even attempt to improve it or add more helpful stuff (not to mention port it to 1.12). So I'm not sure if these are the "most urgent" issues. But if we get an official solution I'll certainly welcome it.
The problem is that sometimes we need to change how things work and not just add some new stuff. And for the game that was not conceived with modding in mind it creates all sorts of problems. It exists even for Unreal Engine that was referenced several times as a good example of modding-friendly engine. Another problem is code coupling: too often you need to literally hack several classes for one change and this can't be done simply by using timers. BTW, it's probably good that we don't have easy access to timers or mods would quickly turn the game into a slow-mo. :) And the biggest problem: we're not organized as the community. Not because we're bad guys with poor social skills, but rather because all of us have their RL and simply don't have time to discuss things in depth on forums.
 
Last edited:
Believe me, having a direct link to developers is a great idea, but that simply doesn't work if it's not properly organized. The fact that this question has apparently never been read by a dev is a good example of this. I'm not anti-everything, I simply explain how such thing can work. I would be anti everything if I just said "that won't work, stop dreaming". I gave both the problem and what I believe is the solution. I simply believe the modding community need a few guys, and clearly you would me one of my picks along with KNG and Holgan, who can serve as "representative", and have a favoured link with the devs. If I have a question, rather than asking it on your sticky post direct to the dev, I would relay it to KNG, Holgan, and yourself, and you would either answer it, or if you don't have the answer (and that's a relevant question), you could discuss it during the next "Q/A" with the dev. This interface between the representatives & the modders could really well be a sticky post, but the interface with the dev would be via another mean. A moderator, given this moderator is a talented modder, could very well be this medium as well.

That's my opinion, it doesn't serve as being against another great idea, it serves as my attempt for improving it, while using my experience in general to know what works and what doesn't, from other games and similar interface.

I'm flattered but I'd vote for @skacikpl he got a much better understanding of what is going on. or maybe @Sarcen but I think @Sarcen is rarely active anymore. Anyway, anyone but me I barely understand this shit myself and merely hack this stuff together until it kinda works.
 
Believe me, having a direct link to developers is a great idea, but that simply doesn't work if it's not properly organized. The fact that this question has apparently never been read by a dev is a good example of this. I'm not anti-everything, I simply explain how such thing can work. I would be anti everything if I just said "that won't work, stop dreaming". I gave both the problem and what I believe is the solution. I simply believe the modding community need a few guys, and clearly you would me one of my picks along with KNG and Holgan, who can serve as "representative", and have a favoured link with the devs. If I have a question, rather than asking it on your sticky post direct to the dev, I would relay it to KNG, Holgan, and yourself, and you would either answer it, or if you don't have the answer (and that's a relevant question), you could discuss it during the next "Q/A" with the dev. This interface between the representatives & the modders could really well be a sticky post, but the interface with the dev would be via another mean. A moderator, given this moderator is a talented modder, could very well be this medium as well.

That's my opinion, it doesn't serve as being against another great idea, it serves as my attempt for improving it, while using my experience in general to know what works and what doesn't, from other games and similar interface.
i see what you mean. A sticky thread for "Q/A" would still work and have it be managed by the modding veterans as you suggested. people come to post, the usual suspects choose the questions they deem to be worth answering/interresting, and have the person who opened the the thread to put the "good" questions on Opening post, then put the answers of the devs later on there as well once they post them.

easy, simple and effective, and ofcourse our usual moderators will make sure no one gets out of line.
 

Guest 2364765

Guest
I thought I had proposed a pragmatic workaround for this problem. At least until somebody comes up with a better solution. Only one person bothered to ask for any info. As a result I didn't even attempt to improve it or add more helpful stuff (not to mention port it to 1.12). So I'm not sure if these are the "most urgent" issues. But if we get an official solution I'll certainly welcome it.
It is urgent, but that doesn't mean that remainder of active script modders is desperate to rely on (absolutely no offense meant) half-working and limited solution.
There's enough hacking employed in modding wscripts as it is. Adding another hoop is just troublesome and frankly - i don't think anyone would want to bother.
I don't want to detract from the work you did, but i assume that to many it wasn't plainly worth it.

At this point i guess that we expect CDPR to at least give us working timers out of the box (eventually).

It's either that or people will plainly move on, once they're done with B&W or one more NG+.

Being able to do our job within custom classes that would be separate or act as extensions to existing classes would greatly increase both compatibility between patches and comfort of developing script mods. Not to mention compatibility between mods that rely on editing same file - conflicts would be less likely if code was included in separate files extending modified class.

As it is now, i can have separate files and custom classes but i still need to hook something that due to whatever reason will get instanced automatically to kickstart my class as we've no insight into events system.
Not to mention that lacking timers greatly limits our possibilites, unless you wish to mess with statemachines, latent functions (which also is not very intuitive or just pure bonkers to me).
 
Last edited by a moderator:
The problem is that sometimes we need to change how things work and not just add some new stuff.
I'm aware of this and if I remember correctly I wrote a couple of lines addressing this in my linked post. It's not always easy to do but possible.

And for the game that was not conceived with modding int mind it creates all sorts of problems. It exists even for Unreal Engine that was referenced several times as a good example of modding-friendly engine.
Don't know the Unreal Engine but the underlying issue you are referring to is a fundamental problem in software design: how to get it structured so it is "easily" extendable. Since you mention decoupling you know this and you also know: there is no solution to make everybody (who wants to extend) happy. You can provide only some paths safely in advance without compromising your "design" and primary functionality (in this case a performance optimized game). Now combine this with the intended audience of.. well the internet. And you get people who don't think it's easily extendable.

Long story short.. I don't think it's fair to label the game "not conceived with modding in mind". It's extendable only in certain ways. That's it. No more no less. And even if I get crucified for this: I think the scripts already provide a *very* deep insight into the game internals and potential for creating very interesting and different mods (though the code quality won't win any prizes, sorry guys :))

Documentation and support (FAQ, dev contacts, etc.) is a *whole* other issue. And that's actually a measurement where I think it's fair to compare modable games. Because that's where the game studio can show their commitment and shine or fail (please don't take this as a statement for starting a flame war...)

Another problem is code coupling: too often you need to literally hack several classes for one change and this can't be done simply by using timers.
Agreed and I don't think timers are a solution for everything. For decoupling the event system is way more apropriate. Just provided the timer workaround for those who wanted them badly. As for the coupling of the script code... I'd take this as a fact of life: If you want to have it done the way you want it, you have to do it yourself :)
BTW, it's probably good that we don't have easy access to timers or mods would quickly turn the game into a slow-mo. :)
Ack.

And the biggest problem: we're not organized as the community. Not because we're bad guys with poor social skills, but rather because all of us have their RL and simply don't have time to discuss things in depth on forums.
Agreed.

Btw, I think we're on the same page. Just wanted to add my couple of cents.

---------- Updated at 08:05 PM ----------

It is urgent, but that doesn't mean that remainder of active script modders is desperate to rely on (absolutely no offense meant) half-working and limited solution.
There's enough hacking employed in modding wscripts as it is. Adding another hoop is just troublesome and frankly - i don't think anyone would want to bother.
I don't want to detract from the work you did, but i assume that to many it wasn't plainly worth it.
No offense taken. It was meant as one less hoop by hiding a hack, but oh well... :)

At this point i guess that we expect CDPR to at least give us working timers out of the box (eventually).

It's either that or people will plainly move on, once they're done with B&W or one more NG+.
Probably.
 

Guest 2364765

Guest
I remember a year ago that CDPR were going to deliver redkit as soon as possible the game was out. And now they're simply "against" mods?
I don't think they're "against" but i wouldn't classify their stance as "for" either.
RedKit is going to happen sooner or later - given their initial pitch behind engine was to licence it to 3rd parties, meaning they're going to have working RedKit to share with others.

Real question is, whether end-users/consumers like us will ever see RedKit.
I imagine that given enough time and some good will, they will eventually strip down their internal/licensed Redkit for use by simpletons like us.
But another question is, just like in Witcher 2 case - whether there'll be anyone left to use it once it's ready.
 
Last edited by a moderator:
Being able to do our job within custom classes that would be separate or act as extensions to existing classes would greatly increase both compatibility between patches and comfort of developing script mods. Not to mention compatibility between mods that rely on editing same file - conflicts would be less likely if code was included in separate files extending modified class.

As it is now, i can have separate files and custom classes but i still need to hook something that due to whatever reason will get instanced automatically to kickstart my class as we've no insight into events system.
Actually that's something I tried to address, too. If you extend from a base class it gets auto instanced at game start/load and from there you can hook into events/timers from the "hacked" event system. If all "hacked" events are already covered you don't have to extend a single line of gamescripts. For all new events you need you can add a one-liner into a game script which triggers a custom event. Other mods can use these events, too and don't need to change gamescripts. In theory way less lines changed. But mod authors would need to commit to a standard. And that won't happen without agreeing and maintaining one...

But I'm getting off-topic with this.
 

Guest 2364765

Guest
But mod authors would need to commit to a standard. And that won't happen without agreeing and maintaining one...
I assume that reason why nobody so far commited to your hack-standard is simple reason and hope that WScript actually supports all of this and we simply don't know how to achieve this.

I mean - it'd be pretty bad if it actually did not support such core functions out of the box.
 
I'm flattered but I'd vote for @skacikpl he got a much better understanding of what is going on. or maybe @Sarcen but I think @Sarcen is rarely active anymore. Anyway, anyone but me I barely understand this shit myself and merely hack this stuff together until it kinda works.

Sharing information is critical for this kind of initiative. Posts like this one are one of the reasons why I had you in mind. I do not care of anyone's talent if this talent is solely used in his own mod. I also never used any single mods made by @skacikpl, nor would I be able to list any. In this condition, I cannot judge of his talent.

In any case, the names matter less than the idea, and I truly believe representatives of some kind are required for this kind of initiative to work. If we're asking RED to use extra time (and thus money), we better do it an organized way so this time is limited and well used.
 
I'm aware of this and if I remember correctly I wrote a couple of lines addressing this in my linked post. It's not always easy to do but possible.
I've looked through your code. No offense, but that's not a solution, that's a bigger problem.

What you're proposing is a big "mod of all mods", where mods are not actual mods, but just triggers to do things you have coded. You was able to "simplify" No Talk Icon mod by adding a hack into interactions class and "hiding" this hack inside your base mod. But that hack was very situational. For the other part of the same class you'll need another hack, so if I'm to use your approach, I'll need to modify your base first and then write my mod. And the worst part of this is: no one else will probably need this code. So the sentence "modders are not allowed to modify vanilla scripts" is incorrect: modders will need to modify vanilla scripts and will need to maintain common base for all their mods. And then they will all need to use this base to do things they want. This level of coordination is rarely achieved inside modding community.

Know this, been there. If the game is not designed to handle mod calls, you end up adding hacks allover the original code to provide some sort of interface for your mods. If you do this because you have no other choice (I hadn't with XCOM) - it's one thing. But for the game that provides source code and compiler you risk either accepting responsibility for maintaining this monstrous "mother of all mods" or discovering that only a handful of people are agree to follow your rules and that your mods are quickly becoming incompatible with the rest of the world.

IMO, for TW3 this approach is too heavy-weighted. Most of the mods merge just fine. Problems arise when there are variables/calls inserted at the same line of code by different mods: diff programs treat the situation as two subsequent code changes while it should be treated as two independent insertions. And, of course, no matter how good modding support is, there always are mods incompatible by nature.
 
I've looked through your code. No offense, but that's not a solution, that's a bigger problem.
None taken. But let's agree that we see different problems :)

What you're proposing is a big "mod of all mods", where mods are not actual mods, but just triggers to do things you have coded. You was able to "simplify" No Talk Icon mod by adding a hack into interactions class and "hiding" this hack inside your base mod. But that hack was very situational. For the other part of the same class you'll need another hack, so if I'm to use your approach, I'll need to modify your base first and then write my mod. And the worst part of this is: no one else will probably need this code. So the sentence "modders are not allowed to modify vanilla scripts" is incorrect: modders will need to modify vanilla scripts and will need to maintain common base for all their mods. And then they will all need to use this base to do things they want. This level of coordination is rarely achieved inside modding community.

Know this, been there. If the game is not designed to handle mod calls, you end up adding hacks allover the original code to provide some sort of interface for your mods. If you do this because you have no other choice (I hadn't with XCOM) - it's one thing. But for the game that provides source code and compiler you risk either accepting responsibility for maintaining this monstrous "mother of all mods" or discovering that only a handful of people are agree to follow your rules and that your mods are quickly becoming incompatible with the rest of the world.

IMO, for TW3 this approach is too heavy-weighted. Most of the mods merge just fine. Problems arise when there are variables/calls inserted at the same line of code by different mods: diff programs treat the situation as two subsequent code changes while it should be treated as two independent insertions. And, of course, no matter how good modding support is, there always are mods incompatible by nature.

You're right. It's not a good solution. It's a pragmatic one as in: simplified merging because the interface hooks are only few lines at most and can be generic enough to be reuseable. And you could use the stuff (init, timers, events) now without reimplementing it or waiting for some better official interface/docs/?.

Would it need to be a mother of mods: nope. Just provide generic hooks for the top most used/requested methods within the main classes. Because I do not agree with your assessment that merging is not a problem. Merge conflicts are no problem for us but for users who cannot code every one of them is a problem. And if mods really need/want to use timers or just this (required) simple init call then they will put their code inside one of the main vanilla classes and increase the area of merge conflicts. Whereas using a provided solution (even if it's just the init and those timers) and decreasing the imprint on the main classes makes merging easier.

Btw, I never wanted to "push" "my rules" or any "hack-standard". In fact I was never eager to maintain any of the base hooks, just proposed a working proof-of-concept.

But you got me curious: what do you mean by "game [not] designed to handle mod calls"? How would this look like in you opinion?
 
Guys, maybe it was said somewhere before, I don't know.

If I get it right, when a new patch comes out, you update your modified script files with changes that CDPR made. But why not the other way round? I mean just track changes you've done and when there's a new patch, again apply your own changes to original files from new patch. Maybe it's just me, but it seems to be more intuitive. No matter what CDPR changes with the scripts, whether they include comments or not, there's still the same amount of work for you to do. And using some smart application could reduce it to a couple of mouse clicks, just potential conflicts would have to be resolved manually. If there is no such application for detecting and reapplying changes, someone could write it since I guess some of you have programming skills.
 
Guys, maybe it was said somewhere before, I don't know.

If I get it right, when a new patch comes out, you update your modified script files with changes that CDPR made. But why not the other way round? I mean just track changes you've done and when there's a new patch, again apply your own changes to original files from new patch. Maybe it's just me, but it seems to be more intuitive. No matter what CDPR changes with the scripts, whether they include comments or not, there's still the same amount of work for you to do. And using some smart application could reduce it to a couple of mouse clicks, just potential conflicts would have to be resolved manually. If there is no such application for detecting and reapplying changes, someone could write it since I guess some of you have programming skills.

That's how I've always done it since day 1. I just add my stuff to the new scripts that come with the patches, also always make sure you comment your own stuff so that you can, in case of update, always "remember" what the hell you did in the first place.

---------- Updated at 11:07 PM ----------

Guys, maybe it was said somewhere before, I don't know.

If I get it right, when a new patch comes out, you update your modified script files with changes that CDPR made. But why not the other way round? I mean just track changes you've done and when there's a new patch, again apply your own changes to original files from new patch. Maybe it's just me, but it seems to be more intuitive. No matter what CDPR changes with the scripts, whether they include comments or not, there's still the same amount of work for you to do. And using some smart application could reduce it to a couple of mouse clicks, just potential conflicts would have to be resolved manually. If there is no such application for detecting and reapplying changes, someone could write it since I guess some of you have programming skills.

That's how I've always done it since day 1. I just add my stuff to the new scripts that come with the patches, also always make sure you comment your own stuff so that you can, in case of update, always "remember" what the hell you did in the first place.
 
Guys, maybe it was said somewhere before, I don't know.

If I get it right, when a new patch comes out, you update your modified script files with changes that CDPR made. But why not the other way round? I mean just track changes you've done and when there's a new patch, again apply your own changes to original files from new patch. Maybe it's just me, but it seems to be more intuitive. No matter what CDPR changes with the scripts, whether they include comments or not, there's still the same amount of work for you to do. And using some smart application could reduce it to a couple of mouse clicks, just potential conflicts would have to be resolved manually. If there is no such application for detecting and reapplying changes, someone could write it since I guess some of you have programming skills.
I'm guessing it's a little complicated than that, and depend strongly on the type of mod.
Some changes made by the Reds are spread among half a dozen of files and changes the way certain features are handle by the game, if your mod is one of those who tweak that particular feature you'll need to basically rewrite your mod on the new base to fit the change, if you're "just" initializing a script it will be less problematic.
For example if your mod is about an object which have lost some of its objectiness, it'll be harder..
 
Last edited:
None taken. But let's agree that we see different problems :)
You're right. It's not a good solution. It's a pragmatic one as in: simplified merging because the interface hooks are only few lines at most and can be generic enough to be reuseable. And you could use the stuff (init, timers, events) now without reimplementing it or waiting for some better official interface/docs/?.
Would it need to be a mother of mods: nope. Just provide generic hooks for the top most used/requested methods within the main classes. Because I do not agree with your assessment that merging is not a problem. Merge conflicts are no problem for us but for users who cannot code every one of them is a problem. And if mods really need/want to use timers or just this (required) simple init call then they will put their code inside one of the main vanilla classes and increase the area of merge conflicts. Whereas using a provided solution (even if it's just the init and those timers) and decreasing the imprint on the main classes makes merging easier.
Btw, I never wanted to "push" "my rules" or any "hack-standard". In fact I was never eager to maintain any of the base hooks, just proposed a working proof-of-concept.
But you got me curious: what do you mean by "game [not] designed to handle mod calls"? How would this look like in you opinion?
But "just provide generic hooks" phrase essentially means that it have to be the mother of all mods. Because you need to either anticipate which hooks mod makers will potentially need and code them in (which is unrealistic) or maintain it to add new hooks for new mods (which is unrealistic too). Simple mods are simple enough without hooks and create no merging conflicts. Same with timers: I've never have had any problems with merging them, kdiff3 is able to resolve such conflicts on its own. And that's what I mean by easily resolved conflicts - ScriptMerger can do it automatically with no need for user to learn how scripts work. I was using like 15 different mods with 1.11 and ScriptMerger had no problems merging them. Problems arise when modmakers don't care to comment their changes and don't care to think about compatibility problems (refactor the code, move things around, etc). So far the biggest issue is new class variables added by two mods at the same line of the code. :)

As for "game [not] designed to handle mod calls" just compare 1.11 and 1.12 scripts to see what they did to add new oil effect to buffs HUD module. If the game was designed with modding in mind, adding new effects would be as simple as adding new child class and defining it's default properties/xml data. And modifying an existing effect would be as easy as replacing the base class with it's child, using provided replacement mechanism (see Unreal Tournament mutators, for example). Right now to add new effect you need to change several different classes and there's no guarantee it'll even work without applying a bit of dark magic to some other class you never knew you end up editing for the purpose.

Guys, maybe it was said somewhere before, I don't know.
If I get it right, when a new patch comes out, you update your modified script files with changes that CDPR made. But why not the other way round? I mean just track changes you've done and when there's a new patch, again apply your own changes to original files from new patch. Maybe it's just me, but it seems to be more intuitive. No matter what CDPR changes with the scripts, whether they include comments or not, there's still the same amount of work for you to do. And using some smart application could reduce it to a couple of mouse clicks, just potential conflicts would have to be resolved manually. If there is no such application for detecting and reapplying changes, someone could write it since I guess some of you have programming skills.
Re-applying hundreds of changes to dozens of files is not fun. But yes, this is exactly what we do. Doing opposite is easier as sometimes new patch has less changes than a mod and applying patch changes to modded files is actually easier. But thanks to dancing around comments we can't do it with 1.11 mods to update them for 1.12. Yes, I can auto-strip comment from my mods too, but those are my comments and I need them, so that's not the way to go.
 
Last edited:
Wasteland_Ghost, I, once more, like to thank you from the bottom of my heart for all your work. I just installed your Friendly Hud 1.12 version and it was such a pleasure to see all the improvements and all the nice, comfortable features which can be activated from the main menu and all this great stuff.... this is skyrim level of modding without the proper tools. Thank you. :)

:cheers:
 
Last edited:
Attempting to update Better Combat Evolved 2 for 1.12 is proving very difficult... I've resolved all script errors within the modbcevolved2 folder but I'm still getting errors from content0.... These new scripts are... Unpleasant to work with, to say the least.
 
Top Bottom