Slime Salad

I like leaving Cursor Follows Mouse enabled, but I did also run into the same issue. I would position the cursor over a tile on the map to display the x,y coordinates. Then I would move the mouse over to my script window to type those coordinates in, but the cursor would have moved when I moved the mouse.

The workaround I used was to switch between Custom and the script window using ALT+TAB instead of the mouse. That kept the cursor where I left it, and it would not move again until I clicked on custom. Took me a couple hours to get used to, but feels comfortable now.

The settings menu is new in Etheldreme.

RedMaverickZero wrote:I'd still like to disable it altogether

Why's that? Because you click on the map accidentally? If so, why?

Also, isn't it contradictory to say to you don't like using the mouse, but you use the mouse to change focus to another window? :) Alt-tab is one of the most useful keyboard shortcuts to get into the habit of using

I always forget about CTRL+Tab. I'll give that a shot, thanks. Your exact scenario James, is how I do scenes too.

You know for "set NPC direction"? Does it take relative values (based on current direction) rather than absolute ones?
Like clockwise/ccw turning?

Virtuous Sword wrote:You know for "set NPC direction"? Does it take relative values (based on current direction) rather than absolute ones?
Like clockwise/ccw turning?

I'm pretty sure there's no built in way to turn CW/CCW, just absolute directions. That would be a nice feature though. Depending how what you're using this for it shouldn't be too difficult to script.

Oh! That reminds me of something you just suggested on the wiki:

for 'walk NPC' can we have the npc's direction as the default direction?

I was thinking that this could be achieved by adding a special direction called 'forward' (or should it be 'forwards'? Probably have both as synonyms). Could have 'backward' too. But what to call turning clockwise or anticlockwise? 'clockwise' to mean clockwise 90 degrees? 'turn right'? 'CW 90'?
(Aside: Some day, we might also have 8 directional movement, so that's something to consider. I think the easiest way to accomplish it would be to set up=0, up right=0.5, right=1, down right=1.5, etc)

Try these:
I use variants of those scripts pretty often. I wouldn't mind having these as standard commands.

--Hiding the level & experience on the stat screen.

For the command "wait for key", how can you make it wait for a specified amount of time (e.g. to receive a keypress)?

James has already done a lot of work on allowing customisation of the status menu, so hopefully it's not far off.

Virtuous Sword wrote:For the command "wait for key", how can you make it wait for a specified amount of time (e.g. to receive a keypress)?

This is the script you want: skippable wait

I've run into a weird issue with the mouse -- not in the map editor, but in the sprite editors.

In windowed mode it works fine, moving the mouse outside of the editing area means it stays there... but when I'm in fullscreen mode, the mouse cursor likes to jump into the editing area every time I switch from one sprite/frame to another, which causes the (keyboard) cursor to jerk to the same position as the mouse rather than carrying over the same x/y position within the editing area from the previous sprite/frame. I mostly notice this in the hero sprite editor since that's the one where I go back and forth that much, but I believe it happens with the walkabouts too; probably every other sprite editor too (and maybe maptiles as well?) if I had to guess.

This makes it a bit harder to do something like... mark/clone tool copying a sprite or piece of a sprite onto others, and things like that. It's still doable (just have to make a note of the x/y position the copied pixels need to go) but it does slow things down a bit when the mouse is throwing off my aim and I have to adjust back to the right place every time.

It's especially odd that it only does this in fullscreen... I guess it's trying to make sure the mouse stays inside the "window" when it's not windowed, but instead of putting it in some neutral space where its presence won't cause any issues, it's throwing it into the editing area and dragging the keyboard cursor with it? If that's the case though, it's odd that it doesn't seem to even try to go to the position the keyboard cursor is (or was) at, just some random spot around the edges...

Maybe an idea for a provoking attack, which could be stored in some kind of register. That will cause stupid enemies to only attack the hero, who has provoked them. A bitset must be set in the enemy data, that they will only attack provoking targets, if there are any. This could be used in battles as a defensive strategy to distract enemies from weaker characters.

Would be neat to have something like that as a built in option for those who use the unused "Ctr" stat for something else already, but it's possible to fake the effect -- set the dumb enemies' attacks to target whoever's Ctr stat is highest, and the "provoke" type attack should be set to increase the user's Ctr stat so it would be above the other heroes'.

Bird wrote:Maybe an idea for a provoking attack, which could be stored in some kind of register. That will cause stupid enemies to only attack the hero, who has provoked them. A bitset must be set in the enemy data, that they will only attack provoking targets, if there are any. This could be used in battles as a defensive strategy to distract enemies from weaker characters.

This should actually be possible already.

In the attack editor, go to "Target and Aiming Settings"
Then go to "Target Class"

You can pick "Revenge (last hit to attacker)" or "Revenge(whole battle)"



Be aware that "Revenge" includes anyone who deals damage to the target, so for example, if the enemy has a revenge attack, but the enemy is attacked by another enemy, then that other enemy can get included in the first enemy's revenge list along with the heroes.

(Also, If I remember correctly, HP cost attacks to NOT count for revenge, so an enemy that uses an attack with HP cost does not get included in its own revenge list, but an enemy that damages itself with a self-targetting attack does get included in its own revenge list)

A good advice! Using the unused counter stat worked, but it has more chicanes than expected.
The provoking attack consists of a chain of three attacks. The first part includes the animation of the provoking attack. It also stores the hero, which you want the stupid enemies to rage on.
The second part of the chain resets an unused stat, for example the Ctr stat to 0. This affects all the heros. It must be done, if you want to declare another hero as enemies target for every time you cast the provoking attack.
The third part of the chain automatically raises the unused stat of the stored hero by 1. Now, the stupid enemies will attack this hero the whole battle until he is defeated or another provoking attack was cast on another hero.

But the enemies attack must be prepared too. If you just make an attack for the stupid enemies, which will target the hero with the strongest Ctr stat, the enemies will attack the first hero in the party automatically, when no provoking attack was cast. That's not what they are supposed to do, because the enemies should have random targets like in a normal battle without provoking attacks. Is there a bitset I forgot, so that the enemies didn't attack between heros with the same Ctr stat and just used the first one?

I used tags to tell the stupid enemies, when they should be provoked. The enemies need to cast a harmless and invisible attack on themselves, which will determine in a conditional chain, if they must head for a random target or the provoking hero.

The revenge option is not sufficent for the provoking attack. I think about an attack, that overshadows the revenge target for the whole battle.

Thanks for your ideas, it was worth the effort. But maybe it would be useful to just have a provoked register for that, which would make stupid enemies simply to override their target behaviour for all attacks.