Why is input not showing up in this context?

[Leeg]

 

I've written these few lines and I've found out that "input" is not working. But I can't understand why. The script just stops right before the input should be showing up and nothing happens. No errors. No warnings. Nothing. Where is the problem? Thank you very much.

	.@loop1 = 1;
	while(.@loop1){
	
		mes "Choose an option";
		next;
			switch(select("One:Two:Three")) {
			case 1:
			mes "Write a number between 0 and 6.";
			while(1){
				input .@TdayofWeek;
				if ((.@TdayofWeek >= 0) && (.@TdayofWeek <= 6))
					break;
			}

 

Edited March 8, 2017 by Leeg

[Leeg]

Found out the bug!

The input works with this npc declaration: -    script    wisp    -1,{

 

The input doesn't work with this npc declaration: prontera,143,185,1    script    wisp    -1,{

 

Is that normal?

Edited March 8, 2017 by Leeg

[Skorm]

4 hours ago, Leeg said:

Found out the bug!

The input works with this npc declaration: -    script    wisp    -1,{

The input doesn't work with this npc declaration: prontera,143,185,1    script    wisp    -1,{

Is that normal?

I was able to reproduce this... Although I'm not sure if I'd call it a bug. It's got something to do with the way npcs are loaded.
If you're within the range of the npc ~21 squares or something like that it will act fine.

A few other side notes:

			while(1){
				input .@TdayofWeek;		//Script stops working right here. Input doesn't show up.
				if ((.@TdayofWeek >= 0) && (.@TdayofWeek <= 6))
					break;
            }

Can be replaced with...

while( input( .@TdayofWeek, 0, 6 ) ){}

 

Also I don't recommend using -1 as the sprite on an npc that is approachable by players. It's caused problems for me in the past with specific clients.
I instead recommend using 104.

Sprite 104 = Invisible, Unclickable.
Sprite 111 = Invisible, Clickable.
Sprite 844 = Shadow, Clickable.

[Akkarin]

"In this context" no one can really help you, you're using a while loop with a predetermined value that doesn't change. Remove the while clause before input and validate the data properly. 

[Leeg]

The while loop value is changed properly when needed. If that was the issue, the script would be bugged way before the input. What do you mean by validate the data properly? And how would that have any effect on the input box showing up?

If more context is needed, this is the whole thing:

OnWhisperGlobal:
if(getgmlevel() > 50){
  
	.@loop1 = 1;
	while(.@loop1){
	
		mes "Choose an option";
		next;
			switch(select("Option1:Option2:Option3")) {
			case 1:
			mes "Write a number between 0 and 6.";
			while(1){
				input .@TdayofWeek;		//Script stops working right here. Input doesn't show up.
				if ((.@TdayofWeek >= 0) && (.@TdayofWeek <= 6))
					break;
			}
			setarray $dayofWeek[getarraysize($dayofWeek)], .@TdayofWeek;
			break;
			
			case 2:
			//Nothing yet
			break;
			
			case 3:
			.@loop1 = 0;
			break;
			
		}
	}
	close;

}

 

Edited March 8, 2017 by Leeg

[n0tttt]

I tried your script this way:
 

-	script	wisp	-1,{
OnWhisperGlobal:
	if(getgmlevel() > 50){
  
		.@loop1 = 1;
		while(.@loop1){
	
			mes "Choose an option";
			next;
				switch(select("Option1:Option2:Option3")) {
				case 1:
				mes "Write a number between 0 and 6.";
				while(1){
					input .@TdayofWeek;		//Script stops working right here. Input doesn't show up.
					if ((.@TdayofWeek >= 0) && (.@TdayofWeek <= 6))
						break;
				}
				setarray .@dayofWeek[getarraysize(.@dayofWeek)], .@TdayofWeek;
				break;
			
				case 2:
				//Nothing yet
				break;
			
				case 3:
				.@loop1 = 0;
				break;
			
			}
		}
		close;

	}
}

and couldn't reproduce. It worked right.
This test was made with the latest git commit. What version are you using?
A weird issue indeed.

[Daegaladh]

You're right, it doesn't work if you set the NPC in a map, but only with no sprite (-1). It works fine with any sprite, both clicking and whispering.

[Leeg]

If it can't be considered a bug, then I think the problem is solved.

[Daegaladh]

45 minutes ago, Leeg said:

If it can't be considered a bug, then I think the problem is solved.

I'm not sure if this is the intended behaviour though

[Skorm]

6 hours ago, Daegaladh said:

I'm not sure if this is the intended behaviour though

I would agree although it is completely avoidable.