Zugg Software :: View topic

Wizard Joined: 26 Mar 2008 Posts: 1547

Obviously something has changed between 3.2x and 2.37 which has caused a script of mine to act in a funky way and I'm unsure of why it does this. I'm not certain if this is a bug or me missing an understanding of a new feature. I've tried several imitations of this in test aliases to try and locate a specific bug with record variables, local variables, or anything that might cause the issue but none of them replicate the error that can be clearly seen in this script.
[ Removed Non-working script, posted updated script below ]

Type: #show "Someone's slash mauls you!"

You should get:

Someone's slash mauls you! (22.5) dmg
22.5: DAMAGE
1: DAMAGE %int

This is WRONG, for some reason, in the function "dam_calc", the $_dam variable's value is getting converted to a 1 by %int. As far as I know, it should NOT be doing this, I don't know why it is.

Posted: Mon Jun 28, 2010 4:47 pm

Actually, I don't get anything because apparently you didn't add the trigger for someone else. Also, no one really wants to wade through 100 lines of code to figure out what's wrong. If you say it's just the damage calculation, only post that. No need for the entire script...

Charneus

Wizard Joined: 26 Mar 2008 Posts: 1547

That's what the bit at the end is for. You'd need the entire script to test it, and everything I posted is all that you'll need for it. But the actual code being concerned with is the bit I posted at the end. Lines 2-5 or so in the "dam_calc" function. What error are you getting when you try to test it? The line "Someone's slash mauls you!" should work exactly as I have it posted.

Posted: Mon Jun 28, 2010 5:02 pm

Ah, the trigger is in there, but it's not firing for whatever reason. Might have something to do with the variable. I'll see what I can possibly do, but by typing:

#SAY {@dam_calc("Charneus","you","22.5","dog")}

It worked well for me. *shrug*

Charneus

Wizard Joined: 26 Mar 2008 Posts: 1547

Yeah, manually inputting into the function seems to work just fine. However, having it fire from the trigger causes the failure. Believe me when I say it's quite odd in that regard. So, the trigger will need to become functional in order for you to see it. I'll try installing what I posted here in a blank session.

Wizard Joined: 26 Mar 2008 Posts: 1547

I tried it out and found it also wasn't working. I re-copied and pasted it into the blank session from the working session and it seems to fire now:

Install the settings first:

Settings

Wizard Joined: 22 Mar 2007 Posts: 2320

Chamenas, it really isn't very reasonable to expect us to find the one bug in two hundred lines of code, without any attempt to cut out the extraneous stuff.

You didn't say what version you are using. I assume it is 3.20. If so, I believe the problem is a bug which has already been reported and fixed for 3.21 in which some parameters were being treated as strings instead of numbers.

Wizard Joined: 26 Mar 2008 Posts: 1547

The bug occurs in 3.21, so it hasn't been fixed. But I don't understand why I keep getting hostile posts about not cutting out the extraneous code when I specifically give you the bits of code that are causing the problem. I gave the whole script because you need to see the whole script in order to see the issue, since I have been unable to replicate the issue outside of the script, so I cannot help but give you the entirety of the script. I do not, however, expect you to look through the entire script to find the problem. In both posts in this thread I have specifically pointed to where you will need to look to find the issue.

I'm very much confused as to why people are not seeing that.

Wizard Joined: 26 Mar 2008 Posts: 1547

I'm not sure how to better pull out the proper code snippet than I've already done. Every other test I've tried to do to replicate it has failed, which is why I shared the entire script, but, as I've said in all the posts, it's just lines 2-4 of the dam_calc function which I posted a second time, with just the snippet and the entire function in case you want to look at surrounding context, that should concern this. Maybe I'm just being silly, but it feels like a bug, since there's no reason it should exhibit this behavior.

Posted: Tue Jun 29, 2010 5:03 pm

I just tried this snippet:

Wizard Joined: 26 Mar 2008 Posts: 1547

Edit: Oops

Wizard Joined: 26 Mar 2008 Posts: 1547

Is there any reason it would work in 2.37 but not 3.20? I've been trying to track it down myself for awhile now and have been unable to do personally find a way to isolate the issue. Tried replacing $_dam with $dam, but that didn't work. This is very frustrating. *sighs*

Edit: Nevermind. When I changed ALL of my variables, to no longer have a preceding _ sign it worked.

Edit 2: And suddenly it's failing again. And %int() is returning 1 instead of the number, so it has nothing to do with the preceding _

Wizard Joined: 26 Mar 2008 Posts: 1547

I've tried reducing the script down as much as possible, so here we have it:

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

%int would return 1 if you were feeding it a string and not a number. So somewhere, one of your variable types is wrong.

Wizard Joined: 26 Mar 2008 Posts: 1547

That's what I thought. It's getting the number from a database variable value, but all of those values are numbers and there's no way for me to tell it it's type is %int. So, instead, I have to manually convert it to an int with %int. In 2.37 %int() would return the number AS an integer if it was a string. Does it no longer do this? How am I going to explicitly define my database record values as integers?

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

Here, this might highlight the issue:

Wizard Joined: 22 Mar 2007 Posts: 2320

You are misunderstanding the purpose of %int(). It does _not_ convert a string into an integer. Rather, it returns the integer part of a floating point value. Using %int() on a string will return 1.

Posted: Wed Jun 30, 2010 1:07 pm

Rahab, I think he knows that. What he's saying that for some reason the automatic type conversion of the string "22.5" to the floating point 22.5 is failing for some reason and that's why his code is failing. The conversion only seems to fail when the result is from the %db. His example really highlights this. I even added the following lines to get a better sense of it.

Posted: Wed Jun 30, 2010 4:09 pm

Yep, General has the test to reproduce this bug. Thanks for pinning this down. It's on the bug list and should be fixed in this week's release.

Wizard Joined: 26 Mar 2008 Posts: 1547

Thanks for figuring it out, guys. I was close when I narrowed it down but missed it and so I didn't think to go further in that direction. I'm glad there's others with a bit more "know" ;)