Forums General Discussion Peace n Protection Script + mIRC 6.31

does this work now since it didnt work in 6.3?

If it didn't work in 6.3, it probably won't work in 6.31 until they change whatever it is in their script that makes it not work in 6.3. You'd be better off asking them to update their script.

i did that for 6.3 and they said they contacted Khaled and its a known thing i guess. the guy who made the script said tis cause something changed in mirc between 6.2 and 6.3. just was wondering if what was changed maybe was reversed or something.

It remains to be an issue you need to take up with the script's author(s). The original author of PnP is, afaik, inactive nowadays but someone else took up the job of modernising it to work with current versions.

Surely the quicker way to get an answer is to test out the script with 6.31?

true but i was looking to see before doing the trial and error method

Scripts break all of the time when new versions of mIRC come out. It's just the way it is. It's not mIRC's fault (unless it's a bug) and it isn't mIRC's job to fix the issue. It's the script author's responsibility or else other people who want to edit the script themselves.

If the PnP people know what the problem is (ie. what was changed that broke PnP), then they shouldn't have any problem fixing the issue. If they are claiming it's a "known issue" that is a bug in mIRC rather than a valid change in mIRC, then they (or you) should explain what the problem is and I am sure someone here can offer a fix and/or a workaround to the problem.

found this on the, i guess, homepage of PnP:

Latest News:
mIRC v6.31 are reported to work with PnP.

It should say "PnP reported to work with mIRC v6.31"

How can you possibly not say mIRC and it's author are not at least partially responible? The langauge is horribly incosistant...

Scrips will check to see if the client version is of a high enough version before loading often. But you don't see scripts checking if the client is NEWER than expected. That's because the langauge isn't expected to change.

If the PnP people know what the problem is (ie. what was changed that broke PnP), then they shouldn't have any problem fixing the issue. If they are claiming it's a "known issue" that is a bug in mIRC rather than a valid change in mIRC, then they (or you) should explain what the problem is and I am sure someone here can offer a fix and/or a workaround to the problem. [/quote]

*sigh*... I have the last version of PnP released, though it's not loaded and I don't use it. I just kept it because I remember how long MissPai devoloped it... and when she said she was moving on I decided too keep the final installment..

Anyhow, so far the errors I get are the result of basically $mircdir returning a different value. I can fix this by incorperating some stuff I use and such... though I'm gonna have to write a parser (using a seperate language to do the work...)

Honestly though... maybe it's time to leave PnP to rest. I always thought it over complicated things w/ it's interface and

Inconsistent in what way? In terms of fluxuation of functions from version to version? That's technically not inconsistent.

A new version of mIRC is indeed a new version of mIRC. It's implied with any software, specifically with major releases (6.1, 6.2, 6.3 in mIRC's cycle) that there will be major changes to the software system. This also means that there will be inherent implications about incompatibilities for everything besides completely new features. This is a tautology, and is universally true for any system that makes changes.

For example: Apple's operating system introduces serious upgrades every ~2 years which implicate major incompatibilities for software using certain components: the software systems must be upgraded to be compatible with every new version. This is true for Leopard, just released last month.

This is also true for Windows Vista, a much slower release cycle than Apple's operating system, but still important. The changes for Vista are much larger than that of Leopard's (due to the slower development cycle). In fact, mIRC 6.3's changes to $mircdir that you're fussing about were done specifically to be compatible with changes made in Vista-- so mIRC is not the real culprit here, it's sort of Vista's fault too-- but the again, this change was necessary to implement the new security system, which was inevitably a request by the userbase of Vista. Therefore, if we continue all the way up the responsibility chain, it's your fault that mIRC changed the way $mircdir works.

mIRC releases a major update roughly every year. This is close to the development cycle of Apple's OS, and given that mIRC is a much smaller component than an entire OS, this is more than fair- we'd therefore expect many things to change. And indeed, things change in mIRC. Sometimes due to dependencies like the OS changing, sometimes to fix bugs. Not every release will affect all scripts, but at some point there will be a change that migh affect you. What am I getting at?

Change is inevitable. It is always the third party developer's responsibility in all of the environments I mentioned above to maintain their application to be compatible with the underlying system-- the same way mIRC's 6.3 release addressed compatibility issues with Vista. While the developers of the underlying system are still somewhat responsible, it depends completely on the system.

I may not have mentioned that both Apple and Microsoft release betas ahead of time to developers so they can predict such incompatibilities-- but I don't think this maps to mIRC. Why? I'll be blunt now: mIRC is an IRC client with no commercial market for third party developers. If a script comes out a few weeks after release, that developer doesn't lose anything out of it... an IRC client is not a critical system like an OS powering million dollar businesses. Face it, what's the worst that happens? You hold out on downloading an upgrade for a few weeks?

We already agreed that changes occur in every software system. Windows, Mac OSX, and mIRC is no different. I'm sorry that your script used a function that underwent such a change, but really, the scripter should be the ones to fix it- Khaled shouldn't be the one to stop the inevitable just for you. There is clearly nothing inconsistent about change.


I wasted my quota on the previous topic so I'll keep this one short: says who? You? The hundreds of users making feature requests on this forum every week seem to think otherwise. You seem to be alone in the school of thought that mIRC's scripting language is not meant to change. If that were the case, a lot of the great advancements of the language would never have come. Remember that mIRC's language *evolved*. It was not designed. The entire functionality of the language is based on change. $dll, $com, $regex, /noop, $qt, SSL support.. these are all heavily used features that came into mIRC within the last few years at most. Unicode support only came around a year ago! Where would we be without change?

The change of $mircdir applicability is documentated (complained and explained) quite well in these forums - just set out a search on $mircdir

Well, scripts don't break "all the time". In general, what's working in older versions will work with more recent releases, too. In general, mIRC is downward compatible.

But, of course, there are changes that might break a specific script.
As far as I know, these cases are never due to a "horribly inconsistent" language, but to changes that remove/correct some ambiguous/inconsistent syntax. Thus, these changes in fact make the language more consistent.

Please keep in mind that the MSL is no designed langauage but one that grew organically over the years out of feature requests and users suggestions - and it keeps growing to this day.
To keep the status quo ante none the less, just to avoid some breaking of some script, would mean to preserve anbiguous syntax possibilities, and would freeze the entire language...

One of the most popular examples of using "ambiguous/undocumentated/wrong syntax" might be the use of $() for $eval() outside of the text match section of an event definition - I am using $() all the time as well. But, if Khaled would decide to remove this "syntax shortcut" one day, no one could officially blame him for breaking thousands of scripts... We just got used to the $() and he will most likely keep the $() valid forever.

I've got scripts here that were written back in the mIRC 5.x days, and they still work without fault on mIRC 6.31.

The scripts I currently run were written in 2003 and haven't ever had to be changed due to updates to mIRC.

I'd almost be willing to bet thst those scripts use $scriptdir rather than $mircdir, in which case there's been no changes (in this regard) to where the information the script is getting information from.

Yup. It always made sense to me to use $scriptdir rather than $mircdir, as things were supposed to be relative to where the *SCRIPT* is, not the mIRC installation..

But *shrug*..

I never even thought of that-- you can then argue that Peace and Protection was bugged anyway, since it wasn't supposed to be using $mircdir. Most scripting sites require scripters to use $scriptdir when referencing their scriptfiles these days as well, otherwise the submissions are usually refused.