(Solved!) Choicescript Math: Will This Work?


#1

I’m designing combat for my work, Imminent Threat. For my damage calculation, I have an equation worked out that I am happy with. However, I cannot test it until a lot more options, variables, and such are written out which will take more time. So, my question for y’all awesome choicers, will this code function? Or are there supposed to be more spaces somewhere, or different symbols, or what would make this function? All of the variables for this specific snippet exist.

*fake_choice
  *if e1dist = 0 *selectable_if eweapslot = 3 #Strike at the ${e1name} with my ${eweapname}.
    *set dmg = mweapdmg x 30 - (edef x 33)

#2

I assume, that #Strike at the… choice has the *set dmg as its nested code.

There’s nothing wrong with that, except for the fact that your choice option is locked under *if e1dist = 0 conditional check.

I mean, if [e1dist] indeed has the value of 0, thus enabling the option to be selected, doesn’t the value of [damage] will be going #DIV/0?


#3

Yes, that assumption is correct.

That’s a good notice on the distance thing with the zero. Thank you, I’ll find a way to modify!
And my goal for that is basically to have the option not appear at all if the enemy’s distance (e1dist) is more than 0, but if the enemy is close enough for a melee attack (e1dist = 0), then I want the option only grayed out, so that the player will know to draw their melee weapon if they want to make that choice. Will it work that way the way it is written?


#4

So long as you’re not firing magic missiles at the darkness you should be good.

But kidding aside, when do you a *set like your *set dmg you don’t use *set dmg =
You would just do a *set dmg (equation)

Example: *set dmg (150 / 3)
Your dmg variable would be 50.

Example 2: *set dmg (150 / 4)
Your dmg variable here would be 37.5

If you don’t want a decimal in your future equations, you can use ChoiceScript’s round function, like so:

Example 3:

*set dmg round(150/4)

Here, your damage variable would register as 38, instead of 37.5, because the system rounded the number.


#5

Ah, I got your point. But… yeah. The problem’s there, though.

I’m not sure why you’d want to decide distance [e1dist] as your damage factor, tho. When you think about it, there’s this basic rule of spear > sword > dagger length, thus distance.


Either way, back to the topic.[quote=“CowboyHooah, post:3, topic:27243”]
but if the enemy is close enough for a melee attack (e1dist = 0), then I want the option only grayed out, so that the player will know to draw their melee weapon if they want to make that choice.
[/quote]
For graying out option, you’ll need *selectable_if command. Using *if will cause the option to be disappears instead of grayed out.


Now, back to the off topic.
So, you wanted for the player to draw their weapon first before being able to strike the enemy?
IMO, that’s redundant. I mean, if you’re going into battle, you’ll definitely want to keep your weapon on your hand, don’t you?

However, if your point is about “the advantage of the first move,” which in this case is who draws their weapon first, I think there’s a better way to do it.

I hope this clears things up.

P.S. Use the </> button to pre-format your code, allowing multiple spaces to be shown instead of shrinked into 1 space.


#6

My point was, say the player has a pistol or rifle drawn, they may wish to quickly pull out a knife if their gun is empty and the enemy is that close.

Also, realized my damage calculation was really dumb and I edited it. Thank you! I think the way I edited it up top makes more sense now.


#7

Didn’t know I could round! Thank you lots!


#8

Yep! This also works for variables into variables. What I mean by that is…

*temp dmg 0
*temp var1 250
*temp var2 39

TEST

*set dmg round(var1 / var2)

dmg = ${dmg}

The dmg variable here registers at 6 using round, instead of 6.410256410256411


#9

Hmm, makes sense, now.
So, the scenario is our PC are holding a ranged weapon, and the enemy is managed to get into melee-range. We can only use the knife, because the gun option is grayed out, am I right?

Well then, there you go.


#10

Thank y’all @Szaal and @Carlos.R!

Quick addon question, is there a way to make a percentage chance of something happening based on an equation? (In this case a melee attack)
Here is the code I thought up:

  *if e1dist = 0 *selectable_if eweapslot = 3 #Strike at the ${e1name} with my ${eweapname}.
    *set cover 0
    *set dmg (mweapdmg * (20) - (edef * 15))
    *set hit (melee / 3 * mweapman * (1.2 ^ conshot))

Focusing on the “*set hit”, man means manuvering and conshot means how many consecutive hits.

I want that [hit] variable to be the chance of hitting.


#11

Well, chance ,or RNG, can be done with *rand command.
The basic use of *rand should be like this:

*rand hit 1 8

The [hit] variable will be assigned a value between 1 as its minimum value, and 8 as its max. The script will automatically roll a dice between 1-8 (the min and max value are included)


#12

What I meant was, say the equation I put sets [hit] to, say, 80.
Can I make that mean an 80% chance that the attack hits?


#13

Hmmm…
Then have a *rand between 1-100, and set the [hit] as part of the conditional checks.

*rand yay 1 100
*if yay =< hit
  You hit the enemy like a pro!
*f yay > hit
  You miss the enemy, noob.

#14

That’s a great idea! Thanks!


#15

Watch for the “bigger than” and “lower than” symbols, tho.
With that 80, is it 80% to hit or 80% to miss. Just got mistaken on that example of mine :sweat_smile:


#16

I would caution against using any random values to determine the outcome of a fight.
The powers that be don’t seem to like that sort of thing.

However, if it’s a predictable mathematical equation that will work the same way every time (of course, this concept allows for the variables and values to be different, they just have to be consistent and not rely on randomization to achieve success), then I think it should be fine.

Are you testing your code as you go, by the way?
In your ChoiceScript folder --> web --> mygame, there’s an index.html file that opens up in Firefox.

You can use that to test as you go to see if the system will give you any specific errors, like for example, if you’ve got too many or too few parentheses in an equation.

To directly address the problem you’re bringing up about hit chance, I would also think about the opponent’s defense chance. This way we eliminate “chance” altogether and use specific values.

To illustrate:

Let’s say your “chance” to hit turns out to be a value of 18 based on choices you made earlier such as preparedness, situational awareness, etc. So 18 is your hit value.

Normally, the defense value of an opponent is 15, but they caught you off guard (plot reasons) so their defense value gets bumped up to 19.

Their defense is higher than your attack, so you miss.

If their defense is the same as your attack, perhaps they get hit for partial damage?
It’s just a matter of figuring out the design.