Allow *input script command to support negative input

[AnnieRuru]

Pull Request Prelude

• I have followed proper Hercules code styling.
• I have read and understood the contribution guidelines before making this PR.
• I am aware that this PR will be closed if the above-mentioned criteria are not fulfilled.

Issues addressed

prontera,155,185,5	script	kljhdsfskjh	1_F_MARIA,{
	.@b = input(.@a, -1000,100);
	dispbottom .@a +" "+ .@b;
	end;
}

input -100, always gets 0

Changes Proposed

blame clif.c, now allow negative input

Affected Branches

• Master

Known Issues and TODO List

rathena also allow it, why hercules don't ?

[HerculesWSAPI]

This change is 

[4144]

for avoid exploits, probably need check limit inside clif_parse_NpcAmountInput
because by default negative values may create some issues

[AnnieRuru]

yeah, no idea who so clever wants to avoid it in the source code
because input_min_value was commented out ... thanks for pointing it out

[4144]

@MishimaHaruna from what i see it can be unsafe as is. because it allow negative value stored in npc variable and after other code will use it as it

[MishimaHaruna]

But as far as I'm aware it's already possible to store negative values in NPC variables (through direct assignment), am I missing anything?

The default setting that this PR uses, provides the same behavior as before, in scripts that used to rely on input() using a minimum limit of 0 when not otherwise specified (see BUILDIN(input)). This will only affect scripts that specifically request a different minimum limit, or servers that alter the default configuration

[4144]

For now npc_amount used only in BUILDIN(input) and here it checked, but if some other code will use npc_amount it can be negative. I suggest add validation inside clif_parse_NpcAmountInput after this all other code will be safe in same way as before current pr commit

[4144]

better not allow unsafe values at first place and not check it every time before it can be used

[MishimaHaruna]

Oh I see, this is a good point. Let's move this to the next release then.

[AnnieRuru]

I'm sorry, I'm too dump to understand your point
can you provide a patch to prove your point ?
this should be pretty simple and straight forward, I guess

[4144]

it short into sd need add also variables npc_amount_min and npc_amount_max
this vars should be set in buildin input before actual input happend. Next input value should be checked in clif_parse_NpcAmountInput for this new limits. Current check inside input buildin can stand as is

[AnnieRuru]

you mean like this ?
so its not adding 2 variables, it should be 3 variables because the documentation ask for it

Hercules/doc/script_commands.txt

Lines 1677 to 1683 in a3a1e36

	The command has two optional arguments and a return value.
	The default value of 'min' and 'max' can be set with 'input_min_value' and
	'input_max_value' in conf/map/script.conf.
	For numeric inputs the value is capped to the range [min, max]. Returns 1
	if the value was higher than 'max', -1 if lower than 'min' and 0 otherwise.
	For string inputs it returns 1 if the string was longer than 'max', -1 is
	shorter than 'min' and 0 otherwise.

in fact, I always do checks like this in my npc script
https://github.com/AnnieRuru/Release/blob/master/scripts/Games%20%26%20Events/Guess%20the%20password/hangman_0.1.txt#L57-L60

[4144]

variables optional only for scripts, inside buildin you always have limits from parameters or some default one. default i think 0 to INT_MAX

[AnnieRuru]

I'm kinda give up, you can take over
because I totally don't understand what you are talking about

the 0 to INT_MAX has been double check by input_min_value and input_max_value
or maybe I misunderstood your meaning