I found the deescription confusing (mostly because of inconsistent use of terms), so I edited it accordingly. I tried not to allow any of my changes to provide spoilers, but only clearer communications about the requirements.

Finally a YurichBRO kata that even I can solve :-) Thanks for the fun.

I hope you can indeed create more installments in this series without duplication of existing kata. I would look forward to that.

I prepared for this kata by reading about the Postfix Mail Transfer Agent. Only after doing that did I read the kata description :P

Really enjoyed this, but I think the instructions should clarify the following:

• Can a "hit" ever occur at the same location more than once?
• And if so, how should the solution handle that? In other words, can we assume that the first hit at this location already caused as much damage as possible, or should the new hit cause further damage to the ship?

I was ashamed of the hard-coding in my first solution, so I came back and changed my medved function to iterate over (and test) all possibilities.

Fair enough. Sounds like it would have been good to present the idea in the Discord discussion before creating the kata.

I liked it. This is definitely a situation where I would usually try to convert to string first, so I had to think differently. I didn't even try to get around the restrictions, but went along with the spirit of the kata. Thanks for the challenge!

(If people are going to downvote this kata, it would be helpful if they'd at least come on here and tell us why. Is it a duplicate? Is it too easy? Are the restrictions too easy to circumvent?) Help the kata author by providing some feedback.

This "solution" is horrendous. The approach I was originally taking only worked for n values up through about 170. So I thought that for higher values, I could possibly call the next-lower n value recursively and then apply a kind of reducing factor to its result. While I tried to fine-tune that factor, I gradually added more and more hard-coding. It's an ugly mess.

Thanks for the clarification!

What exactly constitutes moving "away from" an enemy? This needs to be defined more precisely. For example: If an enemy is in position to attack me (i.e., above, below, left, or right of me), and I move to a new position, so that this enemy is no longer above/below/left/right of me, can that enemy still attack me?

This made me think hard about how to avoid my usual slow brute-force frontal assault. I got oh-so-close with a few different approaches, and then finally shocked myself with a one-liner. That never happens! Thanks for the fun challenge!

Thanks for the fun kata. Brings back memories of looking at hex dumps of RPG programs and wondering what in the world they meant.

The description isn't clear. I needed to study the example pretty carefully to figure out what needed to be done. For one thing, it should be clarified that the prime divisor is never added to the element at index 0, despite the fact that 0 % [prime] equals 0.

Here's an example of input whose expected output does not follow the "one vowel per line" rule:
"oGweQFMoJNk KnJLHOtimUtRTu GirCkKZBLIzXtOfTfNvfI h"

If the test conformed to the description, the last line of expected output would be "fTfNvfI h". But the expected output instead puts a newline after the I and leaves h on the last line by itself.

In testing and modifying my code to handle cases like this, I found that it was the space following the I that was triggering the newline. If that space were not there, the last line of the expected output would be "fTfNvfIh". This is not explained in the description.

You should really not mark issues as "Resolved" until they have been resolved. I think you first need to reach a clear understanding in your own mind about the rules for the expected output. Then these rules will be easier to express accurately in the description.

OK, but I saw at least one case where the test did require a new line after the final vowel if there was a space after that final vowel. That should be explained.

Danke gleichfalls!