mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 3 1 2 3
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Rock: I'm curious, what did you need this identifier for?


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Counting the number of times mIRC started would just be

Code:
ON *:START:if (!%numtimes) %numtimes = -1 | inc %numtimes


Or, reworded: it would be "the total - 1", as Riamus indicated. No identifier needed here.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
instead of subtracting by 1, technically you would have the ON START event increment your variable, and the ON LOAD decrement it. The START/LOAD events offset each other whenever the script is loaded, then all that remains is the count of mirc startups.

Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
OnLoad, used to set the script up initally. As stated before.
Code:
on *:LOAD: set %Starts -1


Then the onStart, which handles each time the script is started
Code:
On *:START:inc %Starts



It would appear that this has gone from a feature request to being a tutorial on what each onStart and onLoad are used for.

Last edited by FroggieDaFrog; 04/11/11 03:28 AM.

I am SReject
My Stuff
Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I never said it was needed, I just gave one example, any other example would have its solution as well since it's scriptable, again this is beside the point.

Note: %numtimes in your code will always be 0, == $null should be used.

Last edited by Wims; 04/11/11 03:47 AM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031
Ahhhh you got me there lol. It's been so long I can't even remember. But it's still there in my loaded file full of snippets. I do know it was a part of another something that does not appear to be there any longer.

Edit: Removed lol.

Last edited by RoCk; 04/11/11 03:52 AM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
The "not needed" part is certainly not beside the point[/b]. It absolutely [i]is the point. The point is that you can completely avoid some $isstarting identifier by simply using the events as they are meant to be used.

Moreover, the fact that there has yet to be a real world use case for this shows that the benefit to such an id is really just hypothetical. The examples so far have been purposefully contrived, and that is my point. Of course you can have some arbitrary scenario where you could have ON START used for everything but script load, but where is the value in that? If there is some real value, show it, it matters. Because if not, why should it be added?

It should be reiterated that the original scenario was not actually meant to be done with ON START. That's why it looks super awkward with 2 event handlers. If the goal was to show something ON LOAD, then ON LOAD should be used. I'd question the scenario where "show something except during script load" is needed-- and even if such a case existed, your script probably has some kind of install flag that can be used to detect this already.

Ultimately what it comes down to is that every possible scenario I can think of can either be done with ON LOAD and/or is probably meant to be done with ON LOAD, not ON START. We should encourage users to use events as they are meant to be used. Is there really a consensus around adding bloat to the language just to give users another way to do the exact same thing in a less proper way? I can't get behind that.

If someone (hopefully pball, since this is his thread, so I assume there was a reason why he requested this) can explain what scenario would rely on this feature, and cannot "easily" be implemented with ON LOAD, I'm all ears.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Wims, you can always make up something that would fit what you want it to fit, but that doesn't mean it's really going to be used. Your example, as I stated, is something that is unlikely to be needed because your first load of the script is already showing that mIRC is running. And if you don't want it to show that mIRC is already running, then you can subtract 1 as stated. It just doesn't show any reason to make changes.

Yes, there are things that are added that can be done easily with scripting. HOWEVER, this request, as I've stated before, is FOR a scripting method. If you already have a scripting method that is easy, what is the benefit of adding yet another one? Besides, if you really want an identifier added, it would make more sense considering your example to request a # of times started identifier. That would be used far more often. Not that I think it is needed, but there is more value in that.

RoCk, an identifier would act just like a variable. You'd still need your IF/ELSE. The only difference is unsetting the variable when done.

As argv0 said, there hasn't been a really good example shown that is using on START and on LOAD correctly that doesn't work well because of how the events are designed. You can determine your event easily with a variable if absolutely necessary, though it shouldn't be necessary in the first place if the events are used properly. Instead of hypothetical scenarios, I agree with argv0 that pball should explain (or show code) his situation. It is almost guaranteed that it can be done easily by using the events properly.


Invision Support
#Invision on irc.irchighway.net
Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I was talking about my point, not your, yes what you are saying is beside my point: you repeated in all your post that "it's scriptable, it's not needed" it's ok we get that, there's no need to repeat it again; however I'm saying that it's not because it's not needed that it shouldn't be added, again please answer the question: how many feature has been added that wasn't needed?
Quote:

Moreover, the fact that there has yet to be a real world use case for this shows that the benefit to such an id is really just hypothetical. The examples so far have been purposefully contrived, and that is my point. Of course you can have some arbitrary scenario where you could have ON START used for everything but script load, but where is the value in that? If there is some real value, show it, it matters. Because if not, why should it be added?
The example I gave is a perfect and valid real world use case, again it's not because you can workaround it with scripting that the example isn't valid so I already showed a value there, not sure why this example is contrived for you, it's not for me.

The origianl scenario is irrelevant to the suggestion.

Quote:
We should encourage users to use events as they are meant to be used. Is there really a consensus around adding bloat to the language just to give users another way to do the exact same thing in a less proper way? I can't get behind that.
I agree that we should encourage users to use events as they are meant to be used, but clearly on start isn't meant to be used as an on load, it has been done like that for good reasons, or not, but again, cases where the difference must be made exist, yes it's workaroundable with scripting, but yes we should still be able to tell the difference without storing our own variable, you would end up having tons of variables for every little workaround like that and I clearly prefer having tons of built-in $ident than tons of global variable, which is imo (the global var) the less proper way to handle this

You are not understanding that pball's example is as basic as the one I gave, the same basic workaround exists with scripting.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
How many features have been added that weren't needed? Really? So it's your opinion that we Khaled should add every possible feature regardless if it's needed? Yes, some things that aren't really necessary have been added. That is not a valid reason to add more things that are not needed. If you've noticed, Khaled has been trimming things down in mIRC over the past few versions (instead of adding bloat) by removing things (mainly settings) that are not needed.

The difference of using a variable or an identifier is so minor that it really isn't worth Khaled spending time making that kind of change. I'd much rather see him work on useful things that will benefit everyone. If the events are used correctly, you should not have any need for a variable anyhow. I still say your example isn't a good one. Most people would count the first use of the script as the first use of mIRC in that situation. Almost all of the remainder (besides apparently you) would not care one way or the other. If you can give an example that many people would run into, then please do. If all you can do is give examples that might only affect a handful of people, then there isn't any reason imo to do anything with this suggestion. And before you say it, yes, some things have been added in the past that benefit very few people. But that does not mean Khaled should add every idea that benefits only a few people. Besides, as I said before, if you are really that concerned about your example, you're far better off asking for an identifier for the # of times mIRC has been run instead. That would be far more useful and help far more people and would solve your example.

Asking for something that can be done without scripting even though it's scriptable is one thing. Asking for another way to script something is entirely something else.

And, pball, whenever you get back, please post your script (at least the on LOAD and on START events) so we can see why you think it's necessary.


Invision Support
#Invision on irc.irchighway.net
Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Quote:
So it's your opinion that we Khaled should add every possible feature regardless if it's needed? Yes, some things that aren't really necessary have been added. That is not a valid reason to add more things that are not needed.
I never said that, re-read my post please. Well what I mean is that something that can be scripted doesn't make it pointless to add.

Quote:
The difference of using a variable or an identifier is so minor that it really isn't worth Khaled spending time making that kind of change
Might be true and I would respect his choice, but note that adding this one wouldn't take time.
Quote:
I still say your example isn't a good one
It doesn't matter, it's a valid one, please stop talking about what people would do if they were to implement it, it's pointless.
Quote:
Almost all of the remainder (besides apparently you) would not care one way or the other. If you can give an example that many people would run into, then please do. If all you can do is give examples that might only affect a handful of people, then there isn't any reason imo to do anything with this suggestion
If you read carefully I'm not the only one; it's your opinion and I explained why I disagree, I don't need to give another example.

Last edited by Wims; 04/11/11 07:42 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I cannot speak to language bloat, I can only say that I oppose language bloat in every instance unless it makes scripters lives significantly easier. That means it should take more than one line of code to re-implement.

Khaled might certainly have added features that weren't needed-- and I am saying that I disagree with those choices, and that we shouldn't use mistakes as a guideline for future development. FWIW, there are very few of these mistakes, though... I can only think of a very small set of exceptions.

In other words, if it is not needed, it should not be added. I don't know anybody who would willingly want to bloat the language just because you can.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Feb 2003
Posts: 3,432
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Feb 2003
Posts: 3,432
!!Responce to no one!!

I have noticed that often when someone asking for something to be added to mirc they got the same answer, "It can be scripted", yes it can be scripted, and if not it can be done with a dll, i for one would like to see some new things added to mirc, if only things that cant be scriptet would make it in to mirc, then we would need to wait for ages for a new release, if no new fetures are added "they can be scripted", we only can look forward for bug fixes to be released, and this part of the forum is useless and a waste of space, no point for someone to try come up with new ideas if they only get the answer "it can be scripted or use bla.dll and it can do it".


if ($me != tired) { return } | else { echo -a Get a pot of coffee now $+($me,.) }
Joined: Nov 2009
Posts: 295
P
pball Offline OP
Fjord artisan
OP Offline
Fjord artisan
P
Joined: Nov 2009
Posts: 295
I agree with sparta and whoever else mentioned the over used "it can be scripted" excuse. I also like that someone else mentioned on start is basically two events in one and it'd be nice to tell for which reason it was triggered.

Code:
on *:start:{
  ;%uptimepercent.beginning is the "zero" point on which the script bases the start of measuring uptime
  if (!%uptimepercent.beginning) set %uptimepercent.beginning $ctime
  ;incase the on exit event didn't trigger (crash or something) updates total time
  if (%uptimepercent.temp) set %uptimepercent.up $calc(%uptimepercent.up + (%uptimepercent.temp - %uptimepercent.start)) 
  ;%uptimepercent.start is when mirc was started
  set %uptimepercent.start $ctime
  ;periodically set %uptimepercent.temp in case of crash or something (it happens), this prevents loss of up time
  .timer -o 0 600 set %uptimepercent.temp $!ctime
}
 
on *:exit:{
  ;adds the uptime from mirc start to exit to the total overall uptime
  set %uptimepercent.up $calc(%uptimepercent.up + ($ctime - %uptimepercent.start))
  unset %uptimepercent.temp
}
 
alias uppercent {
  say 7Uptime Percentage: $calc(100* ( %uptimepercent.up + ( $ctime - %uptimepercent.start )) / ( $ctime - %uptimepercent.beginning ) ) $+ % since $asctime(%uptimepercent.beginning)
}


I'm sure everyone and their grandma will try to make a better version and say how crappy mine is. But I made this to do a few things specifically. The initial time is set when you load the script and it should show 100% uptime after you load it. It also keeps a temp variable which tracks time every 10 min in case mirc fails to trigger the on exit. In which case the temp var and start var will be used on the next start up to update the total uptime. What it doesn't do, is not reset the start var when the script is reloaded (what the proposed identifier would fix). I don't care if you just say well don't reload it and it won't have that problem. If I want to change the output format and up reloading the script it'll throw the tracked time off.

If you can make something smaller than what I have and works in the manner I'm looking for great. But I think being able to stick a simple if statement with the identifier I'm suggesting would be perfect.

Like
if ($isstart) set %uptimepercent.start $ctime


http://scripting.pball.win
My personal site with some scripts I've released.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
What's wrong with telling someone that something can already be done? If you say: "mIRC should be able to do X" and I say: "mIRC can do X, here's how: ...", why is that not a good response? Why would your response be "but I don't like that and still want X!"?

To me the problem lies in the fact that people are not asking for functionality, but rather they are asking for the same functionality in a different form. In other words, when you say, "mIRC needs <specific identifier here>" you're not asking for a solution to a problem, you're asking for your own solution to a problem with an existing solution.

This begs the question: why can't the existing solution work? Note that in many cases, the existing solution can be scripted.

The problem of IGNORING existing solutions is that we end up with a scripting language that has hundreds of solutions for the same problem. It's the known problem of software bloat. Bloat is NOT a good thing. We don't need more than one way to do things-- it just makes the language complex, the implementation large, maintenance much harder, and for little benefit.

Lastly I should point out that the "it can be scripted" solution in this case is EASY. It's so easy, in fact, that using "ON *:LOAD:" is actually fewer characters than using an "if ($isstarted)" check if you actually ran into that scenario. And, especially in this case, when the solution is already about *scripting*, telling somebody that it can be scripted seems perfectly apt to me. "I need a way to script X" -- "here is how you script X" ... what is the problem?


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
In your case "$isstarting" is just a matter of checking whether your timer was created. You can also solve any other problems by unsetting %uptimepercent.start when you exit (and when you clean .temp), that way you can also check that .start is not set before setting it (in case only the timer was somehow turned off and script reloaded).

Code:
on *:start:{
  ;%uptimepercent.beginning is the "zero" point on which the script bases the start of measuring uptime
  if (!%uptimepercent.beginning) set %uptimepercent.beginning $ctime
  ;incase the on exit event didn't trigger (crash or something) updates total time
  if (%uptimepercent.temp) upaddtime %uptimepercent.temp
  if (!$timer(UPTIME)) {
    ;periodically set %uptimepercent.temp in case of crash or something (it happens), this prevents loss of up time
    .timerUPTIME -o 0 600 set %uptimepercent.temp $!ctime
    ;%uptimepercent.start is when mirc was started
    if (!%uptimepercent.start) set %uptimepercent.start $ctime
  }
}
 
on *:exit:upaddtime $ctime

alias upaddtime {
  ;adds the uptime from mirc start to exit to the total overall uptime
  set %uptimepercent.up $calc(%uptimepercent.up + ($1 - %uptimepercent.start))
  unset %uptimepercent.temp
  unset %uptimepercent.start
}
 
alias uppercent {
  say 7Uptime Percentage: $calc(100* ( %uptimepercent.up + ( $ctime - %uptimepercent.start )) / $&
    ( $ctime - %uptimepercent.beginning ) ) $+ % since $asctime(%uptimepercent.beginning)
}


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
argv0 pointed out exactly why the answer here is that it can be scripted. The question was for scripting in the first place. Therefore the answer is going to be related to scripting it. Even if a new identifier was created or some other scripting change was made, it would still be "it can be scripted". You can't complain about that answer in this thread because that is exactly what this thread is asking for.

To everyone- In addition to what argv0 said, many feature suggestions are supported. Even suggestions where scripting is possible. That does not mean that people have to support every suggestion. If people think a suggestion is a bad idea or a waste of time, that should be stated. Suggestion forums (here or anywhere else) are not a place to boost your ego by having everyone agree with you. If your suggestion is good, people will agree. If not, they will not. And if they don't, then you shouldn't be so upset and complaining just because they don't agree with you. Everyone has different opinions and there is absolutely nothing wrong with stating your opinions. Don't get bent out of shape when someone disagrees with you ... especially when it isn't even your thread. Everyone here has had some of their own suggestions disregarded or turned down (those who have been here long enough to make more than a few suggestions). There is nothing wrong with that.

Two points here... First, if people disagree with your suggestion, you should listen to their reasons with an open mind. Then, if you still think your idea is worthwhile, use their comments to improve your suggestion so that it can gain support. If you still don't have support after discussing it, then it probably isn't a good idea. Accept that. No one has all good ideas.

And second, don't get upset when someone offers you a scripting solution. Scripting is a vital part of mIRC and is therefore a valid solution to a problem. And don't assume that someone giving you a scripting solution is saying your idea is bad. I've seen many threads where someone offers a scripting solution and certain people get involved and start complaining that "it can be scripted" is some horrible thing to say. And in many of those cases, the person offering the suggestion was offering a workaround until another option was available. There is nothing wrong with that. Simply put, if a scripting solution is available, it should be offered. That doesn't mean another solution can't be created if the scripting solution is not great. It just means the person asking for a feature will have an option in the meantime.

So let's stop complaining about people offering scripting solutions. It's a waste of time and just confuses the threads so that no one knows the real benefits or downsides of the suggestion. That is especially true in a case where the suggestion is asking for a scripting solution in the first place.


Invision Support
#Invision on irc.irchighway.net
Joined: Jun 2003
Posts: 994
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Jun 2003
Posts: 994
Quote:
Everyone here has had some of their own suggestions disregarded or turned down (those who have been here long enough to make more than a few suggestions).


Case in point: my suggestion long ago that Khaled have mIRC make my coffee for me in the morning was shot down and I was told "It can be scripted" grin grin grin


I refuse to engage in a battle of wits with an unarmed person. wink
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
This is actually still on my to-do list - milk and sugar? wink

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
It would probably be useful to have an identifier that indicates whether mIRC is starting up - I think I originally intended for on START to trigger only on startup but eventually changed it to trigger when a script is loaded as well to cater for any on START initializations. mIRC already has an internal variable that returns its startup state, so I will go ahead and add an identifier that returns this value for the next version.

Page 2 of 3 1 2 3

Link Copied to Clipboard