<ANP and <BOA

So I figured out in more detail what ANP does exactly and how to use it. The tsc listing is a little sketchy about its actual use.

Animate entity X with method Y in direction Z [entity type determines Y values?]

An NPC's actions are handled through code. Each NPC has a variable keeping track of its current state. This variable is sometimes linked to a timer, sometimes to the player's actions, so forth. It will be used by the game to decide which part of the NPC's code to run.

The ANP instruction allows you to set this variable. For instance, I wanted a room where those giant jellyfishes start off "angry" (ie, moving around) right away. This is state 10. I used ANP on them with 10 and wham, they were, indeed, in state 10.

This could also be used to make Mannans fire (state... 2 or 3 I think?) for instance.

I'll eventually try to produce a list of NPCs and their related states if anyone is interested. This will take a while, since I have a few other projects under my belt and I want to complete my Cave Story hack beforehand.

As for BOA? Same thing, but for bosses. A boss means anything not normally placeable on a map, like Heavy Press.

 

I just realized something minor but interesting.

As mentionned in the "NPC" thread, bosses and regular entities are completely seperate in the code. They use a totally different pointer table and, I suspect, a totally different structure to hold their info.

ANP and BOA are largely identical save for the fact they work on a different structure in memory (ie, entity vs. boss) and use a different pointer table to access their members. That's all there is to it.

 

Well there si no Structure how they work, for every enity there is another, if u searched the forums u could had readed this thread:

http://www.cavestory.org/forums/threads/163/

 

Schmitz's guide is most certainly a very useful piece of material. However it is made based on observations from experimenting with Sue's Workshop and only covers ANP, not BOA.

My observations come from reading through the code and tracing values. And I can say that yes, there is a structure to all of this, and no actual duplicate "animations" (states) exist. Often it'll seem that way because they're transitive one into another (for instance, one may set up a state and then switch to another state; in that case it may sound like the two do the same thing but that's not the case.)

In short, ANP and BOA are not commands which trigger animations. They change the current state an entity is executing (which often does have an animation linked to it, but not always.) Knowing this, it's possible to code a multitude of effects by creating new states for an entity (code-wise) and calling them via the script.

I'd say ANP and BOA are the most powerful commands the script engine supports - a clever assembly hacker could create a "State" entity which has states that trigger different things in the code (switch into night mode when state 1 is called, day when state 2 is called, changes the background when state 3 is called...)

In fact, you could create a shop system through this command by managing the shop (an entity) via states, for instance. It's the ultimate expansion command which can allow you to do anything you can code via scripts in-game.

Edit: For some inspiration, have a look at the NPC faq I posted. The pseudocode (which is called every frame) makes mention of a "ScriptState" variable - this is what is set by the command. When ANP/BOA are called, the next time the game enters this code, the variable will be set with the value specified by the command.

 

In short, ANP and BOA are not commands which trigger animations.

Well, is NPC behavior governed by the animation currently running, or is the animation currently running governed by behavior?

Rightly, it doesn't matter, because whenever one changes, so does the other.

Whether <ANP changes the state of an entity's animation by changing making its "AI" jump to a certain routine, or its "AI" jumps to the routine because the animation state changed, the function exists so that one can change both of those.

Whether you say the A stands for "Animate" or for "AI", it's equally true. Because it does trigger a change in the animation, one way or another, and it triggers a change in the AI state, one way or another.

EDIT: Implicit for this statement, but something I ought to say outright is that I'm confident that every routine of entity code execution is linked to a specific animation, if not a specific frame. And while multiple routines may be linked to the same animation, no routine will be linked to multiple animations.

Meaning: while an entity is just sitting somewhere, it could be doing any number of invisible things, but it will never be doing those same invisible things while it's not just sitting there, unless called as a part of something else.

 

Whether you say the A stands for "Animate" or for "AI", it's equally true. Because it does trigger a change in the animation, one way or another, and it triggers a change in the AI state, one way or another.

It's really nothing more (nor less) than a means of sending information to an entity. There is absolutely no link with animations - those are incidental. An example is the mannan projectile, whose acceleration is controlled by which state it's in - there is no impact on its animation as this occures regardless of the state it's in.

On the other hand, many entities can trigger different animations while in the same state. The state of a theoretical wolf enemy could determine wether it moves by dashing about in an enraged or just runs around calmly - its behavior towards a play would be identical in either case and being reduced to 0 hp would still cause it to trigger its death animation. Its standing still animation could easily be picked randomly from a number of animations regardless of the state it's in.

Don't forget this command could be used to manage code completely unrelated to the entity it's intended for. The entity could run code that destroys every enemy entity onscreen (or that simply removes them - kinda like some global DNP.) The state of an entity is just a means of communicating info to it, not necessarily a command sent to it meant to draw an immediate reaction (if any at all.) There are, after all, over 170 bytes reserved per entity structure to determine how it acts.

It's all very structured, code-wise. And it wouldn't be half as powerful as it is if it had to deal with animations all the time. In my hack, I'm working on an invisible entity placed in steam tiles that periodically enters a state where it can damage the player using its internal timer. It can be switched off via ANP and no longer damage the player, which I could use to simulate a "heat suit" to protect the player. There is 0 visual impact on the game, but it still plays a huge role in things.