DECORATE spritenames longer than 8 possible?

As described here, sprite names must follow a specific format consisting of a 4 letter prefix and 2 or 4 letter suffix, otherwise they won't be recognized as sprites. Sorry.

Don't think that's possible ATM, If the sprite prefix is longer than 4 characters g/zdoom errors out saying "Sprite names must be exactly 4 characters"

Just now, dmg_64 said:

Don't think that's possible ATM, If the sprite prefix is longer than 4 characters g/zdoom automatically errors out saying "Sprite names must be exactly 4 characters"

so if DECORATE doesn't support sprites that are not 4-8 lettered filenamed. What can be used instead? DECORATE does work with soundfiles with names longer than 8 letters when you quote them along with the file directory.

Just now, Gabenslair said:

What can be used instead?

Nothing.

dag-nammit. I was looking forward towards animating a live tv showcasing the entire broadcast fox news channel record that lasts at least 4 hours as an enemy. Are there any work-arounds possible to get around the problem? 

Well you can use Advanced Renamer. this will save you some time.

No, there are no workarounds. This simply cannot be done because you not only need to rename all your images properly, you also need to define a separate state for each single frame. And if you want to make this an enemy, you either have to duplicate each animation sequence for different phases of the source data.

1 hour ago, Jerry.C said:

you also need to define a separate state for each single frame.

Huh?

8 hours ago, dmg_64 said:

Huh?

Got confused on the terminology Doom uses?

A 'frame' is a single image in an animation, (i.e. POSSA? is a frame.)

A 'state' is what you define in DECORATE to display a frame (i.e. the line "POSS A 3" defines a state with a duration of 3.)

7 hours ago, Jerry.C said:

A 'state' is what you define in DECORATE to display a frame (i.e. the line "POSS A 3" defines a state with a duration of 3.)

And why would you need to define a separate state for each single frame, It's a simple TV so all of it's frames would be played through only 2 or 3 states.

TVS1 ABCDEFGHIJKLMNOPQRSTUVWXYZ( ....... etc) TicsPerFrame

If you want lots of frames, you could use (using dmg_64's example) TVS1 A...Z and then TVS2 A...Z and so on, putting in letters if you need to continue past 9, like TVSA A...Z, TVSB A...Z, and so on. All those frames, even with different 4-character sprite names, can be in the same actor.

10 hours ago, dmg_64 said:

And why would you need to define a separate state for each single frame, It's a simple TV so all of it's frames would be played through only 2 or 3 states.

 

TVS1 ABCDEFGHIJKLMNOPQRSTUVWXYZ( ....... etc) TicsPerFrame

That is 26 ( ... etc ) states, so you're kinda undermining your point of not needing individual states.

^ Those are frames though? By state I'm referring to things like See state and missile state.

No, those are states.

The See state is the state directly after the See: state label. An actor can only have one See state, and no more.

It is possible, however, for an actor to have several states in the See state sequence. Those are the states accessible through the goto instruction, via See+1, See+2, etc., but this is a property unique to goto - A_Jump's brethren can only jump to properly labeled states, and you cannot ResolveState( "See+1" ) in ZScript.

Frames do exist in the context of states, but they're entirely in the realm of the state's appearance. Effectively, the "SPRT F 1" line defines a state by its sprite, frame, and duration, and a "SPRT FR 1" defines two states by that share a sprite and duration ( and action function and state flags if you include them ) but not a frame. They're still two states, not one with two frames.

Here's a quick example:

  See:
    POSS AABBCCDD 4 A_Chase
    Loop

Here we have eight states and four frames. The frames are A, B, C, D; the states are See, See+1, See+2, See+3, etc. until See+7.

See and See+1 are using the A frame, See+2 and See+3 are using the B frame, and so on.