Author Topic: Chex Quest Standardization Project (working title)  (Read 6140 times)

Offline Nomekop

  • a.k.a. frozenLake
  • Cycloptis
  • **
  • Thank You
  • -Given: 2
  • -Receive: 2
  • Posts: 439
  • Flem Balloon (Flemoidus Hydrogenus)
Re: Chex Quest Standardization Project (working title)
« Reply #30 on: April 08, 2012, 04:57:32 PM »
I know, but I was letting him know that he could put the patch in the wad instead of having it separate.

Chex Quest Fan Forums

Re: Chex Quest Standardization Project (working title)
« Reply #30 on: April 08, 2012, 04:57:32 PM »

Offline Atariangamer

  • Dormant User
  • Snot Lord
  • *****
  • Thank You
  • -Given: 25
  • -Receive: 54
  • Posts: 11777
  • Keelah se'lai
Re: Chex Quest Standardization Project (working title)
« Reply #31 on: April 08, 2012, 08:59:09 PM »
I may or may not, actually.

I know you can put it inside the wad, but for some rare ports that won't work.

But IDK if I made this more clear in my last post (or if I'm contradicting my words in the last post O_o) but I'll be focusing on the Decorate version first.

I was just mentioning that I found dehacked can do the things I'll need. There was a point I was thinking it wouldn't let me do a thing or two.
Don't remember me as I was...I was an idiot.

Offline arch129

  • Drum Set Salesman
  • Fan Projects Coordinator
  • Chex Master
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 3
  • Posts: 3655
Re: Chex Quest Standardization Project (working title)
« Reply #32 on: June 25, 2012, 04:51:49 PM »
I just want to say I really like what your doing Atari, I thought about doing something like this before, but of course I'm way to busy with my other projects.

I hope to see a release soon!

Offline Atariangamer

  • Dormant User
  • Snot Lord
  • *****
  • Thank You
  • -Given: 25
  • -Receive: 54
  • Posts: 11777
  • Keelah se'lai
Re: Chex Quest Standardization Project (working title)
« Reply #33 on: December 06, 2012, 01:27:41 AM »
After quite the time, I've decided to pick this back up.
The ability to do this project as desired is...uncertain to say the least. Alot of ports might not take its structure too well. But who cares, I'm pressing forwards.

I just want to do a refresher of what it's supposed to do for now. The idea is to have a base wad that is nothing but resources. Nothing port or game specific, just what's needed to make a game work. So, Textures, flats, sprites, sounds, music, general Doom engine graphics: all there. Maps, port specific graphics and code bits, and custom game content: not there.

The base wad will fit into the Doom wad architecture as an IWAD, but it doesn't function correctly as one. Every graphic name (except for things that cannot be changed, such as M_DOOM) has been redefined to make it easier for mod makers to understand and add onto the existing structure, which is documented and standardized (hence the project title).

Since the base wad is nothing but resources and no definitions to be found, the structure is two parted: base, and mod. The plan is to create several 'mod wad' templates that give a starting point for the modder. These templates will be port specific, and contain additional graphics, code bits, and other defining pieces that allow the modder to make full use of the ports features without having to piece together the additional resources. For example, a (g)zDoom template would contain DECORATE definitions for all objects, ANIMDEFS for animated textures and switches, SNDINFO modified if necessary, as well as graphics replacements for the supplied .pk3 resources.



The aim here? To be like the Source SDK. You are given a base set of resources and a choice of engine, and then a project is started tailored specifically to the engine type you want. Just add maps, additional scripting and game coding, and your own custom content to go with the provided set, and voilla! You have a mod that runs very quickly and simply without any issues!

So far, I've standardized the naming of the patches and flats, and have recreated all of Chex 3's texture set (well, the ones that were actual textures and not weird doom carryovers) in a new TEXTURES lump. Sprite renaming is going on now, but I'm having issues 'standardizing' the name scheme because of a certain issue:


Lump names can only be 8 characters long (AFAIK). I've operated within that bound regardless, as that's how vanilla DOOM.wad and CHEX.wad work.

A sprite name usually looks like

****$#($#)

* = A four letter descriptor
$ = animation frame as a single, capital letter
# = direction as a number (0 faces player view, 1 faces south, 2 faces SW, 3 faces west, 4 faces NW, 5 faces north, 6 faces NE, 7 faces east, and 8 faces SE)

the parenthesis defines the frame and direction that the image would occupy if mirrored, so POSSA2A8 is the possessed soldier, first frame, facing SW, or SE if flipped...

Static objects with no animation use A0.
Static objects with animation use A-D (depending on how many frames of animation is desired), and 0 as they face the player
Actors use A-D as a normal walk cycle, E-F as an attack cycle, G as a pain frame, and the rest are all death frames.

This sounds pretty straightforwards, yes? Well...flying actors only have 2 frames of 'walk cycle'. Nearly every actor has different length death cycles, and some have explosive deaths, and some use flipped normal deaths as explosive deaths (yeah, that's weird)...

Any object that appears in the first episode of Doom follows the basic standard. everything else does not, really.
Now, I could really just leave it all alone, and just take note of it as I'll be making all the item definition code myself...but wouldn't it be nice if you ever had to use these base sprites again...to know they followed a very easy to remember pattern? I don't think 'compressing' the animations so that every actor has a 4 frame walk, 2 frame attack, 1 frame pain, 4 frame death, and 5 frame explosive death is the way to go. But what else to do? This is a very non-standard part in a standardization project...


Does anyone have a solution for this before I commit to anything crazy?
Don't remember me as I was...I was an idiot.

Offline MajorSlime

  • Self-Proclaimed ACS Grandmaster
  • Multiplayer Team Leader
  • Chex Master
  • *****
  • Thank You
  • -Given: 18
  • -Receive: 29
  • Posts: 4308
  • If life gives you lemons, give its lemons back!
    • Chex Quest: Reflections
Re: Chex Quest Standardization Project (working title)
« Reply #34 on: December 06, 2012, 02:25:23 AM »
Hmmm.... select a range for each section? Like, for the walking, A-D like normal, but those who only have two frames skip C and D; they simply dont have any graphics labelled with C or D. AFAIK, the sprites dont have to come one after the other.
Shh!  I'm taking a break from reality.

John 3:16
For God so loved the world, that he gave his only son, that whoever believes in him shall not perish, but have eternal life!

Give God your life; You won't regret it!

Offline Atariangamer

  • Dormant User
  • Snot Lord
  • *****
  • Thank You
  • -Given: 25
  • -Receive: 54
  • Posts: 11777
  • Keelah se'lai
Re: Chex Quest Standardization Project (working title)
« Reply #35 on: December 06, 2012, 03:44:01 AM »
Hmmm.... select a range for each section? Like, for the walking, A-D like normal, but those who only have two frames skip C and D; they simply dont have any graphics labelled with C or D. AFAIK, the sprites dont have to come one after the other.

Hmm! I'd have to leave space in case someone needed extra frames, but that's an idea...

My only concern would be my desire to have a possible DEHACKED support. My structure is moving further and further away from that being possible, not to mention I've yet to find a good resource on how to fully utilize it. A general guide to its features and functions would suffice. IDK. For the Zports, I think that'd work well.

Comments?


I found Enjay's old DEHACKED reference site. Very insightful. But its basically telling me that gaps in the frame sequence aren't possible. It is, however, helping me figure a few other things out about the sprite naming scheme and what not.

Looks like I'll just be making each frame set unique, and documenting it as such.
At least the coding is possible from all points. A slight hard, but possible nonetheless.
« Last Edit: December 06, 2012, 04:08:17 AM by Atariangamer »
Don't remember me as I was...I was an idiot.

Offline MajorSlime

  • Self-Proclaimed ACS Grandmaster
  • Multiplayer Team Leader
  • Chex Master
  • *****
  • Thank You
  • -Given: 18
  • -Receive: 29
  • Posts: 4308
  • If life gives you lemons, give its lemons back!
    • Chex Quest: Reflections
Re: Chex Quest Standardization Project (working title)
« Reply #36 on: December 06, 2012, 04:27:13 AM »
Is it not possible as in the engine wont accept not having those frames available? Like, can you still put NULL images (all blank/cyan) in for those frames, and simply not use them in the actual definition of the monster?
Shh!  I'm taking a break from reality.

John 3:16
For God so loved the world, that he gave his only son, that whoever believes in him shall not perish, but have eternal life!

Give God your life; You won't regret it!

Offline Atariangamer

  • Dormant User
  • Snot Lord
  • *****
  • Thank You
  • -Given: 25
  • -Receive: 54
  • Posts: 11777
  • Keelah se'lai
Re: Chex Quest Standardization Project (working title)
« Reply #37 on: December 06, 2012, 03:45:34 PM »
As you know, DECORATE doesn't care. The Zport base is going to be cake no matter what I do.

DEHACKED uses sequencing to manage its animations. So once you list em all you, you define it like so:

Init. Frame = POSSV (idk, this is default)
Init. Walk = POSSA
Init. Attack = POSSE
Pain Frame = POSSG
Init. Normal Death = POSSH
Init. Explosive Death = POSSJ (not sure if this is correct, but just for example)

So, the initial frame is the still frame that the object spawns with. The initial walk frame is the first frame of the walk cycle. It will just animate all frames from here till the next definition: attack. So if I had frames ABCDEFG for the walk cycle, and HI for the attack cycle, I just define frame A as the walk, and frame H as attack, and the engine will do the rest (just cycling through the frames between the two definitions).

Unless the extra null frames are at the end of the animation (which is possible), it won't work. Just skipping them (like, having frames ABD but not C) will cause crashes, it seems.

So a standardized definition could be:

A - Walk 1
B - Walk 2
C - Walk 3
D - Walk 4

E - Attack 1
F - Attack 2

G - Pain

H - Normal Death 1
I - Normal Death 2
J -  Normal Death 3
K - Normal Death 4
L - Normal Death 5
M - Normal Death 6

N - Explosive Death 1
O - Explosive Death 2
P - Explosive Death 3
Q - Explosive Death 4
R - Explosive Death 5
S - Explosive Death 6

~
One thing I know for sure is that the Player death cycle is 7 frames, I think. I'm at school and away from my project files, but that seems to be what I remember.
Might be a question for 75, but what does the Skulltag/Zandronum pack skins use for their frame counts?
Don't remember me as I was...I was an idiot.

Offline MajorSlime

  • Self-Proclaimed ACS Grandmaster
  • Multiplayer Team Leader
  • Chex Master
  • *****
  • Thank You
  • -Given: 18
  • -Receive: 29
  • Posts: 4308
  • If life gives you lemons, give its lemons back!
    • Chex Quest: Reflections
Re: Chex Quest Standardization Project (working title)
« Reply #38 on: December 06, 2012, 08:38:20 PM »
Hmm, k. Yeah, might have to design them all separately  :'(


As for the Skulltag/Zandronum actors, i have no idea, that's definitely a 75 question.
Shh!  I'm taking a break from reality.

John 3:16
For God so loved the world, that he gave his only son, that whoever believes in him shall not perish, but have eternal life!

Give God your life; You won't regret it!

Offline 75

  • [IFOC] Server Admin
  • Multiplayer Team Leader
  • Chex Master
  • *****
  • Thank You
  • -Given: 29
  • -Receive: 26
  • Posts: 4241
    • IFOCSERV
Re: Chex Quest Standardization Project (working title)
« Reply #39 on: December 07, 2012, 08:52:58 PM »
Skins are unusual because Zandronum (and every other engine I know of, going back to Legacy) only support skins in games whose player inherits from DoomPlayer or HereticPlayer AND has a colorrange identical to Doomplayer. It's a very old bug.

Basically that means that if your player sprite ISN'T green, "skins" don't work and the only way to implement them is to add them as alternate player classes. This means that I can have every "skin" have as many or as few sprites as I want. Normal skins are restricted to the DoomPlayer exact sprite set.

My skins look like this (frames O,P,Q,R, and S were added for zorch related sprites):

Code: [Select]

actor RadsuitWarrior : ChexPlayer75
{
Player.Displayname "Slimeproof suit"

Player.ColorRange 192, 207


States
{
// Standing
Spawn:
SUIS A -1   
Loop

//Walking
  See:
SUIS ABCD 4   
Loop

// shooting
  Missile:
SUIS E 12  BRIGHT
Goto Spawn
// Melee weapons
  Melee:
SUIS F 6   BRIGHT
Goto Missile


 // Pain state for getting zorched
Pain:
SUIS O 4  bright A_SetBlend("99 20 20", .5, 20)
SUIS O 4  bright A_Pain
Goto Spawn


// Pain state for getting flemmed
Pain.Flem:
SUIS G 0   A_SetBlend("20 99 20", 1, 20)
SUIS G 4   
SUIS G 4   A_Pain
Goto Spawn

// Zorch death state
  Death:
  XDeath:
SUIS P 0  bright A_TakeInventory("sound_play", 1)
SUIS P 15 bright A_SetBlend("99 20 20", 1, 120)
SUIS Q 15 bright A_PlayerScream
SUIS Q 0 bright A_NoBlocking
SUIS R 15 bright
NULL A -1
Stop

// Flem death state
Death.Flem:
XDeath.Flem:
SUIS H 0 A_SetBlend("20 99 20", 1, 120)
SUIS H 10
SUIS I 10 A_PlayerScream
SUIS J 10 A_NoBlocking
SUIS J 0 A_TakeInventory("sound_play", 1)
SUIS KLM 10
SUIS N -1
Stop


}
}

Note also that my skins have added damagetypes for pain and death. This is so that the player can be both slimed and zorched depending on what hits him or her.

EDIT -- oops, the actor code I originally posted doesn't have a flem pain/death.
« Last Edit: December 07, 2012, 08:57:59 PM by 75 »
"Give us those nice bright colors, give us the greens of summer, makes you think all the world's a sunny day."

You can find me on the CQFF discord: https://discord.gg/AgNhjem

 


Web Hosting by InMotion Hosting