DRD Team

drdteam.org forum
https://forum.drdteam.org/

Model definition format

https://forum.drdteam.org/viewtopic.php?t=552

Page 4 of 6

Posted: Sat Nov 19, 2005 15:21
by TheDarkArchon
Do weapons count? If so, I have a monster of a weapon.

[spoiler]

Code: Select all

ACTOR Minigun : Weapon 20022
{
	Inventory.PickupMessage "You got the XA-532 Minigun"
	Inventory.PickupSound "misc/w_pkup"
	Weapon.SelectionOrder 400
	Weapon.Kickback 90
	Weapon.AmmoType1 "Cell"
	Weapon.AmmoType2 "MinigunHeat"
	Weapon.AmmoGive 75
	Weapon.AmmoUse 1
	AttackSound "weapons/minigun"
	Obituary "%k turned %o into swiss cheese using %p XA-532 minigun"
	States
	{
   	Spawn:
   	  MINI A -1
   	  LOOP
   	Ready:
   	  MING A 1 A_WeaponReady
	  MING A 0 A_TakeInventory("MinigunHeat",1)
   	  Loop
   	Deselect: 
	  MING A 0 A_TakeInventory("MinigunHeat",100)
   	  MING A 1 A_Lower
   	  LOOP
   	Select: 
   	  MING A 1 A_Raise
     	  LOOP
        Fire:
          MING A 0 A_JumpIfInventory("IsUp",1,3)
          MING A 0 A_GiveInventory("IsUp",1)
          MING A 0 A_PlaySound("weapons/minigunup")
          MING A 0 A_JumpIfInventory("SpinLevel",5,40)
          MING A 0 A_JumpIfInventory("SpinLevel",4,31)
          MING A 0 A_JumpIfInventory("SpinLevel",3,23)
          MING A 0 A_JumpIfInventory("SpinLevel",2,13)
          MING A 0 A_JumpIfInventory("SpinLevel",1,6)
          MING BCD 2 A_TakeInventory("MinigunHeat",1)
          MING D 0 A_GiveInventory("SpinLevel",1)
          MING D 0 A_Refire
          Goto Fire+63
          MING EFGH 2 A_TakeInventory("MinigunHeat",1)
          MING H 0 A_GiveInventory("SpinLevel",1)
          MING H 0 A_Refire 
          Goto Fire+63
          MING A 1 A_TakeInventory("MinigunHeat",1)
          MING B 1
	    MING C 1 A_TakeInventory("MinigunHeat",1)
          MING D 1
	    MING E 1 A_TakeInventory("MinigunHeat",1)
          MING F 1
	    MING G 1 A_TakeInventory("MinigunHeat",1)
          MING H 1 A_GiveInventory("SpinLevel",1)
          MING H 0 A_Refire //Fire+28
          Goto Fire+63
	    MING B 1 A_TakeInventory("MinigunHeat",1)
          MING C 1
	    MING D 1 A_TakeInventory("MinigunHeat",1)
          MING E 1
	    MING F 1 A_TakeInventory("MinigunHeat",1)
          MING G 1 A_GiveInventory("SpinLevel",1)
          MING H 0 A_Refire
          Goto Fire+63
	    MING H 1 A_TakeInventory("MinigunHeat",1) //Fire+36
          MING A 1 
          MING H 0
	    MING C 1 A_TakeInventory("MinigunHeat",1) 
	    MING E 1
	    MING G 1 A_TakeInventory("MinigunHeat",1)
	    MING G 0 A_GiveInventory("SpinLevel",1)
          MING H 0 A_Refire
          Goto Fire+63
          MINF A 0 A_PlaySound("weapons/minigunhold")
          MINF A 0 A_GunFlash
          MINF A 0 BRIGHT A_FireCustomMissile("5.56mmcasing",45+random(-8,8),0,1,4)
	    MINF A 0 BRIGHT A_Jump(48,2)
	    MINF A 0 BRIGHT A_FireCustomMissile("MinigunSmoke",0,0,3,2)
          MINF A 1 BRIGHT A_FireBullets(15,15,1,7,0,1,10240)
	    MINF A 0 A_GiveInventory("MinigunHeat",2)
	    MINF A 0 A_JumpIfInventory("MinigunHeat",100,50)  //Fire+50
          MINF B 0 BRIGHT A_FireCustomMissile("5.56mmcasing",45+random(-8,8),0,1,4)
	    MINF B 0 BRIGHT A_Jump(48,2)
	    MINF B 0 BRIGHT A_FireCustomMissile("MinigunSmoke",0,0,3,2)
          MINF B 1 BRIGHT A_FireBullets(15,15,1,7,0,1,10240)
	    MINF B 0 A_JumpIfInventory("MinigunHeat",100,45)
          MINF C 0 BRIGHT A_FireCustomMissile("5.56mmcasing",45+random(-8,8),0,1,4)
	    MINF C 0 BRIGHT A_Jump(48,2)
	    MINF C 0 BRIGHT A_FireCustomMissile("MinigunSmoke",0,0,3,2)
          MINF C 1 BRIGHT A_FireBullets(15,15,1,7,0,1,10240)
	    MINF C 0 A_JumpIfInventory("MinigunHeat",100,40)
	    MING A 0
          MING A 0 A_ReFire
          MING A 0 A_JumpIfInventory("IsUp",1,1)
   	    Goto Fire+66
          MING A 0 A_PlaySound("weapons/minigundown")
          MING A 0 A_TakeInventory("IsUp",1)
          MING A 0 A_JumpIfInventory("SpinLevel",5,6) //Here by mistake and taking it out would mean recalculating
          MING A 0 A_JumpIfInventory("SpinLevel",4,10) //state jumps, which is a royal pain in the arse with this monster
          MING A 0 A_JumpIfInventory("SpinLevel",3,14)
          MING A 0 A_JumpIfInventory("SpinLevel",2,19)
          MING A 0 A_JumpIfInventory("SpinLevel",1,25)
          Goto Ready
          MING A 1
	    MING C 1 A_TakeInventory("MinigunHeat",1)
	    MING E 1
	    MING G 1 A_TakeInventory("MinigunHeat",1)
          MING A 1 A_TakeInventory("SpinLevel",1)
          MING A 0 A_Refire
          Goto Fire+66
	    MING B 1 A_TakeInventory("MinigunHeat",1)
          MING C 1
	    MING D 1 A_TakeInventory("MinigunHeat",1)
          MING E 1 A_TakeInventory("SpinLevel",1)
          MING A 0 A_Refire
          Goto Fire+66
	    MING F 1 A_TakeInventory("MinigunHeat",1)
          MING G 1
	    MING H 2 A_TakeInventory("MinigunHeat",1)
          MING A 2 A_TakeInventory("MinigunHeat",1)
          MING A 0 A_TakeInventory("SpinLevel",1)
          MING A 0 A_Refire
          Goto Fire+66
          MING BCDE 2 A_TakeInventory("MinigunHeat",1)
          MING A 0 A_TakeInventory("SpinLevel",1)
          MING A 0 A_Refire
          Goto Fire+66
	    MING FGH 2 A_TakeInventory("MinigunHeat",1)
          MING A 0 A_TakeInventory("SpinLevel",1)
          MING A 0 A_Refire
          Goto Ready
	    MING DGADG 1
	    MING A 0 A_TakeInventory("MinigunHeat",2)
	    MING A 0 A_Refire
	    Goto Fire+63    
        Flash:
          MINF Z 1 A_Light2
          MINF Z 1 A_Light1
          MINF Z 0 A_Light0
          Stop
        }
}
[/spoiler]

Posted: Sat Nov 19, 2005 16:13
by Chilvence
Heh, thats a bit more like it. But anyway I was just trying to make a point that even if it gets really complicated to make the model def, its still no more complicated than coding the actual decorate actor itself.

Also, Use tabs properly you evil meanie :P

Re: Model definition format

Posted: Fri Dec 02, 2005 13:57
by Graf Zahl
Update:

Since I need to get started somewhere and the state based model assignment is obviously causing some problems I will add an alternate means to specify models: by sprite frame. This is more interesting for simple decorations and much easier to implement. The state based format or something else can still be added later but at least this allows to define non-animated model-based decorations (or such with simple animations) in a decent way.

Code: Select all

MODEL  SomeDecoration
{
	Path "Models/Deco/Stuff"
	Model 0, "crapstuff.md2"
	Scale 0, 1.4, 1.2, 1.4

	Sprite DECOA Frame "0"
	Sprite DECOB Frame "1"
	Sprite DECOC Frame "2"
}

Posted: Fri Dec 02, 2005 14:51
by Cutmanmike
What program(s) can edit md2 models?

Posted: Fri Dec 02, 2005 15:09
by Graf Zahl
I have no idea. It's just that the only models I have are MD2s so this format has to be supported in any case. I don't consider it the ultimate solution though.

Posted: Fri Dec 02, 2005 15:14
by justin023
I will post the quake 1 and half-life models if there is any possibility of adding support for them.

Posted: Fri Dec 02, 2005 15:23
by Apothem
justin023 wrote:I will post the quake 1 and half-life models if there is any possibility of adding support for them.
That would be friggin awesome if support could be added for that. 8)

Posted: Fri Dec 02, 2005 22:45
by BlazingPhoenix
heh, Quake1 monsters recreated in decorate with models....:)

Posted: Sat Dec 03, 2005 2:10
by justin023
There probably wouldn't be a great way to recreate something like quake 1's ogre, but that thing could still have a killer melee attack

Posted: Mon Dec 05, 2005 6:02
by chaoscentral
o please add HL model support... that would be great, ill put some on my server if you need some.

Posted: Mon Dec 05, 2005 10:37
by Graf Zahl
Do you have any format specs?

Re: Model definition format

Posted: Thu Dec 15, 2005 0:48
by Chilvence
Graf Zahl wrote:Update:

Since I need to get started somewhere and the state based model assignment is obviously causing some problems I will add an alternate means to specify models: by sprite frame.
Actually yes, this is another method that is much more desirable to Doomsday's. It does lose a lot of flexibilty, but its perfectly adequate for defining models that rigidly match the doom sprites.

I would suggest a small tweak though, it would be nice to be able to specify several model frames per sprite name, that would be 'autostretched' across the duration of the frame. This would be a nice, simple way to add a bit of extra fluidity to most animated objects. No need for it to get overcomplicated, just simply dividing the frame duration by the number of extra frames would do the trick.

Also, another simplification you could implement would be to also allow bypassing the sprite animation completely and just define a set of frames for an object. For things like the soulsphere, torches etc which only have a single loop this would be very handy, but it would also let you go to town making writhing animations for the impaled twitchers :).

Re: Model definition format

Posted: Thu Dec 15, 2005 1:54
by Graf Zahl
Chilvence wrote:
Graf Zahl wrote:Update:

Since I need to get started somewhere and the state based model assignment is obviously causing some problems I will add an alternate means to specify models: by sprite frame.
Actually yes, this is another method that is much more desirable to Doomsday's. It does lose a lot of flexibilty, but its perfectly adequate for defining models that rigidly match the doom sprites.
I think for custom actors assignment by sprite is as good as assignment by state. Since it is rather unlikely that you'd want to use models and spprites at the sametime you can lay out ypur sprite frames to match the model. But it makes defining the model much easier as opposed to assign each and every state a model.
I would suggest a small tweak though, it would be nice to be able to specify several model frames per sprite name, that would be 'autostretched' across the duration of the frame. This would be a nice, simple way to add a bit of extra fluidity to most animated objects. No need for it to get overcomplicated, just simply dividing the frame duration by the number of extra frames would do the trick.
For that I have to tweak the internal handling somewhat. It can become a little tricky if the same sprite is being used in several consecutive states.
Also, another simplification you could implement would be to also allow bypassing the sprite animation completely and just define a set of frames for an object. For things like the soulsphere, torches etc which only have a single loop this would be very handy, but it would also let you go to town making writhing animations for the impaled twitchers :).
Same as above. Unfortunately I won't be able to invest time in this in the next few weeks. I am rather busy at work and that won't change until the end of January. Until then it's only bug fixes.

Posted: Thu Dec 15, 2005 2:45
by Chilvence
Of course, theres no mandate for you to do any of this, I'm just suggesting these things since the thread said :)

I still think the ideal method would be my first suggestion though, ie just assigning cycles/loops to key states. It could even be worthwhile in the long run to add that sort of thing to the fstate thingy. One extra field would be all thats needed, a string that says which animation to run. Then you have a system where you can not only define an entire actor that just uses model animation, but you also have no problems keeping it glued together.

Posted: Thu Dec 15, 2005 9:59
by Graf Zahl
Generally I agree with you. But that is something that has to wait until custom state labels exist. Then I would enforce something much stricter for actors that are to be replaced with models.
All times are UTC+01:00
Page 4 of 6

Powered by phpBB® Forum Software © phpBB Limited