Using "random(,)" in a table?
Would using "random()" in a table under an integer or real column work? I couldn't get a number to change by using random(tablecellvalue,tablecellvalue) and the only result is 0. Which means I messed up the nesting or it's too long? It's the last wall standing between me and a working inventory. {Aside from table values showing improperly.}
Would putting random, and the two numbers I want, within a table cell integer/real work?
EDIT:
Here is a screen of the method I'm using now:
The table referenced is this:
I should reduce the column numbers and just have the two min max values be in a single cell using random(), yes?
If you are really good in GS, and want to help streamline my project, PM me. You can probably make whatever I made, more efficiently.
The only things left are the IAP implementation and making a boss with moving individual parts.
EDIT:
I've put a random(0.1,10) in place to see if it was the data not communicating, and instead, it actually worked! The value of the stats changed! And the display text showing the values in question finally changed from 0 to numbers!
So the problem is the way I wrote that table expression that I posted above?
Before:
When in red, that means the gem is use, which means the AG values, the modifiers for attack and defense, should increase/decrease the stats in the middle, yet they remained 0.
Now it's working, showing the changing values. The final thing to do is to get the actual gem's attributes to work as the modifiers, and then I'll have everything game mechanic wise, implemented. O _0 I just have to figure out what and how I'm writing this wrong or if it's actually returning a value of 0 despite the written table values.
Comments
Something I noticed immediately is that you are trying to choose random numbers using decimal values. The random() function only takes integers as arguments. If you plan to use decimals, you'll need to convert them to integers. For example, to choose a random number from 1 to 1.8, you would do random(10,18)/10.
Also, it's hard to read your expression. Can you click in the expression editor, select all (cmd+A), copy, and then paste it into a post here? That will be a lot clearer. But generally, this is how you would choose a random number between two table cell values:
Change attribute self.random to random(tableCellValue(tableName,1,3),tableCellValue(tableName,1,4))
I have experienced problems where embedded functions don't calculate at the correct time when inside of other functions. If you have it set up that way already, try separating out the steps like this:
Change attribute self.min to tableCellValue(tableName,1,3)
Change attribute self.max to tableCellValue(tableName,1,4)
Change attribute self.random to random(self.min,self.max)
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
@tatiang Thank you for the info, I never knew about the decimal problem with random().
I took the screen from windowsm, as it can't copy+paste externally, although it can accept pastes from outside programs, but I have access to a mac too, copied, here was the value, pasted:
game.AttackGem +( game.AttackGem *(random(tableCellValue( game.InventoryTable , self.ItemType , 3),tableCellValue( game.InventoryTable , self.ItemType , 4))))
The reason for game.attackgem adding to itself, is because the modifier default is 1, to represent 100%, and 1.1 would be 110% and so on. Using this also prevents the number from ever being 0 as it will just default to game.attackgem's base value.
Self.itemtype helps identify the row based on the item's type. So as to not write 15 separate instances of the rule.
I see, so that means using this method would only work in non-action sequences due to the timing errors?
Yeah, it looks like I will have to separate the steps out even more.
Thanks again for your insight, @Tatiang , I would have liked changing the table values to whole numbers, then dividing by ten in the expression, sounded more dynamic to use.
Removing the addition and multiplication, your expression looks like this:
I'd say that's correct usage of the function and the tableCellValue expressions.
I wouldn't describe it that way. It's just that if you think about a random() function, it's looking for two integer values. I'm guessing it will evaluate any expressions in a timely fashion but if you're having trouble with it, try the other method.
I would agree with that.
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
@Tatiang I think it's random that just won't work. Whole numbers didn' t go though, and display text for AG just showed 0. However, the table can still be read as I was doing a test with random removed, and the numbers go through and display, both integers and real. It looks like seperating it into steps might be the best deal after all.
It might also be because I'm using 13.40, as I read recently that they fixed tables in html5, and I use html5 preview mostly for testing. I forgot to check on the mac 13.44 when I was on it(I use it mostly for publishing in GS), I guess I'll do a final test on the mac preview tomorrow before giving up and going with the reliable method.
Thanks again.
As for stuttering caused on hit, I think I might have finally figured it out and just set up a new system that handles the damage calculations with less demand on the system{by only changing values at the points when they are actually neccessary, rather than every time a hit occurs.}, thus the values will usually be static and be able to act the way arbitrary numbers did, in theory, I should have things as processor light as before, but still have a a system where damage can be modified and manipulated externally. I guess I didn't need somebody to take over that aspect of the game afterall.
EDIT: YES, IT'S FIXED, FINALLY! I have smooth gameplay again! And within the new system that was responsible for all the lag to begin with. No more violent stuttering! The framerate is very slick and fast!
Now I also finally fixed the gem system as well, random values work, stats reset to default after gem use, and everything now. Thanks for letting me know about the random function not being able to randomize decimal numbers. {I'll guess it's because a random number between say 1.5 and 1.8 would be nearly infinite due to there being no limit to the amount of digits in decimal values towards the right. e.g. {0.999999999999999..}.
Good theory, never thought of it like that, makes sense too.
You can of course generate random numbers with decimal places, you just need to push the maths outside of the random number generation process (which only deals with whole numbers).
So, if you wanted a random value between 1.5 and 1.8 . . .
random(1500,1800)/1000
. . . which would give you values such as 1.673 and 1.521 (and so on).
@Socks Thanks. I see, and you would have to multiply those values enough that the very last digit to the right of the decimal is past the left of it. I wonder if random was given two very extreme values, such as random(1, 1892234348344345645), would it take longer to compute the final value?
For a game that values higher numbers, but generates decimals numbers, something like the precision function would have worked. That would at least limit how many decimal digits appear, then multiply by a value that takes it into whole number territory.
Value: 130.56978
prec(130.56978, 2) = 130.56*100 = 13056
Hmm, I got carried away, your example was about getting random decimal values.
Yeah, I did something like that, but I got carried away as can be seen in the screenshot.
And to be safe, the new table looks like this, lol:
With the end result being multiplied by 0.1 to get the final value.
I haven't got a clue what that means ! Not sure why you'd have to multiply anything, if the goal was to generate a random between 1.5 and 1.8 to (for example) three decimal places then you could use: random(1500,1800)/1000
I couldn't answer definitively (because I don't know) but in practical terms I doubt the range of values has an effect on the length of time it takes to generate the random value - but that probably depends on the method used to generate the random value.
For example imagine this is the routine used to constrain the random value to the range:
1) Generate random value (however this happens)
2) Check whether random value is higher or equal to lowest value.
3) Check whether random value is lower or equal to highest value.
4) If random value meets 2 and 3 then return the value.
In the above scenario it wouldn't matter whether the range was random(1, 1892234348344345645) or random(1,7), both would go through the same process and need to meet the same rules.
But . . . even if larger ranges produced larger calculation times (for whatever reason) then with modern computing we are talking the difference between X billionths of a second vs X billionths of a second + 0.00001 seconds.
There is a recommendation to avoid the prec function, as it converts numbers into text, to carry out its manipulations, then converts the text back into numbers, this process is slow. The recommendation is to use roundTo instead.
The range between low and high shouldn't make any difference. Generally, only one random number is generated, scaled to the appropriate range, then added to low and returned.
@Socks My apologies. I was a bit incoherent, I meant using a value to turn the decimals into whole numbers for equation purposes.
Eep, I didn't know the prec function was a computation turtle. How unfortunate. Thanks for informing me. I'll stick to roundTo.
@GeorgeGS Thanks for clarifying that. On a semi-unrelated note, Is there any list showing what functions are universally supported in all platforms, or was % operator the only one to watch out for?{as it was recommended that the mod function should be used in it's place instead. }