View Revisions: Issue #340

Summary 0000340: About the behavior of : pool...
Revision 2021-11-11 14:29 by ponapalt
Description The pool modifiers are excellent, and I'm very grateful to you and steve for working on them. There is just one thing that I'm wondering if we could improve.

My hope with the pool modifier was that devs would be able to write naturally, and have the probabilities of dialogues be reasonable. Right now, when there is a -- in a pool, *all* of the possible outputs are available in the pool with equal probability, which skews probabilities massively towards dialogues that use a --. It also means that nonoverlap_pool may be less effective. Here's an example set of dialogue:

```
RandomTalk : pool
{
    "Other dialogue"
    {
        "Dialogue about the color "
        --
        "blue"
        "green"
        "red"
    }
}
```

in this example, "Other dialogue" will have a 25% chance of appearing, and there'll be a 75% chance for one of the color dialogues to appear. In addition, if you use nonoverlap_pool, you'll have to go through each color option before it starts over again.

But, outputting *all* possibilities makes sense for array_pool! I've already found that to be very useful.

In the test versions steve made, the pool modifiers (except array_pool) were adjusted so that if a -- was present, the set of brackets it was in was treated as one output candidate. This made it very natural to write, but I worry that having array_pool behave differently from the rest could be confusing...

It is possible to separate dialogues with a -- into their own functions, and I will accept this as a compromise if need be, but it is definitely a hassle. Example...

```
RandomTalk : pool
{
    "Other dialogue"
    ColorDialogues
}

ColorDialogues
{
    "Dialogue about the color "
    --
    "blue"
    "green"
    "red"
}
```

So that's why I'm opening this issue. I wonder if there is a better solution to this problem? But I'm not sure what it would be, other than making dialogues with -- be treated as a single candidate as I mentioned above.

(Also, I will note that while you can use ANY('blue','green','red') for the examples above, this is not a good solution for all dialogues. I often put much longer text than what I have here.)

Thank you for your time, as I said I do have a workaround, so if you think the current implementation is best then this can be closed.
Revision 2021-11-02 10:08 by guest
Description The pool modifiers are excellent, and I'm very grateful to you and steve for working on them. There is just one thing that I'm wondering if we could improve.

My hope with the pool modifier was that devs would be able to write naturally, and have the probabilities of dialogues be reasonable. Right now, when there is a -- in a pool, *all* of the possible outputs are available in the pool with equal probability, which skews probabilities massively towards dialogues that use a --. It also means that nonoverlap_pool may be less effective. Here's an example set of dialogue:

RandomTalk : pool
{
    "Other dialogue"
    {
        "Dialogue about the color "
        --
        "blue"
        "green"
        "red"
    }
}

in this example, "Other dialogue" will have a 25% chance of appearing, and there'll be a 75% chance for one of the color dialogues to appear. In addition, if you use nonoverlap_pool, you'll have to go through each color option before it starts over again.

But, outputting *all* possibilities makes sense for array_pool! I've already found that to be very useful.

In the test versions steve made, the pool modifiers (except array_pool) were adjusted so that if a -- was present, the set of brackets it was in was treated as one output candidate. This made it very natural to write, but I worry that having array_pool behave differently from the rest could be confusing...

It is possible to separate dialogues with a -- into their own functions, and I will accept this as a compromise if need be, but it is definitely a hassle. Example...

RandomTalk : pool
{
    "Other dialogue"
    ColorDialogues
}

ColorDialogues
{
    "Dialogue about the color "
    --
    "blue"
    "green"
    "red"
}

So that's why I'm opening this issue. I wonder if there is a better solution to this problem? But I'm not sure what it would be, other than making dialogues with -- be treated as a single candidate as I mentioned above.

(Also, I will note that while you can use ANY('blue','green','red') for the examples above, this is not a good solution for all dialogues. I often put much longer text than what I have here.)

Thank you for your time, as I said I do have a workaround, so if you think the current implementation is best then this can be closed.