[Danukem]

By the way, setting xvel and zvel on an actor in the code that spawns it generally won't work, because those values don't do anything unless it is a projectile or it has been set in motion with a move command first.

[High Treason]

Well in that case, EVENT_EGS or EVENT_SPAWN are probably early enough to fix that, aren't they? I'm not sure as it's not something I've ever done, instead setting X, Y and Z co-ordinates directly, but if so the code wouldn't be that hard to implement. You'd just need your

ifmove 0 { move YOURMOVE }

in one of the events instead,

I don't know that this would make so much difference by now, though setting the VEL parameters immediately afterwards would certainly take a sprite up to full speed near enough instantly. Keep in mind that those values are in relation to the sprite's location in the map and not the orientation of the sprite - for example, rotating a sprite with a high XVEL will not change the way it moves, it will still move towards positive X on the map.

If you get stuck I'd be willing to take a quick look at what you're trying to do, as well as trying to make it work.

[Danukem]

 High Treason, on 12 May 2017 - 04:09 PM, said:

for example, rotating a sprite with a high XVEL will not change the way it moves, it will still move towards positive X on the map.

That's not true. Sprites with a positive xvel member will move forwards (in the direction they are facing), whether it is on the x-axis of the map or not. I think you might be confusing this with using the internal clipmove function, or the movesprite CON command, which are different.

[High Treason]

This is not at all the behaviour I have found from setting these values. However, I have only really experienced them with the player. I would have to experiment, but I suppose it isn't impossible that the player is a special case.

A cut-down version if you wish to observe this would be;

onevent EVENT_GAME
ifactor APLAYER
{
  setplayer[THISACTOR].xvel 102400 // Should be enough to make you move a little, but not fast enough to instantly smash into a wall.
}
endevent

I understand that the "ifactor" is redundant as I am using setplayer, but I use this "if" in my code because of other code that has to run exclusively in the APLAYER actor. I doubt it has any bearing at all, but it is included for consistency with what I have. Turning the player does not alter the direction in which they are traveling; A positive XVEL set this way serves to move the player towards positive X on the grid, regardless of which way they are facing.

This method is unusual for me anyway and is related to a specific purpose. Usually I just add/subtract X/Y/Z as I can safely assume the player won't be positioned outside of player space at any time the code is used.

[Danukem]

 High Treason, on 12 May 2017 - 05:51 PM, said:

This is not at all the behaviour I have found from setting these values. However, I have only really experienced them with the player.

That's because the player is different. For the player, there are posxv, posyv, and poszv members, all for speeds on the different planes. So yes, the player is the one entity in the game that works as you describe -- but we weren't talking about the player. We were talking about sprites that you can spawn. For regular sprites, positive xvel makes them move forward, negative makes them move backwards, positive zvel makes them move down, negative zvel makes them move up. And the yvel member on sprites is not used for velocity -- it has different purposes for different types of sprites.

[High Treason]

Well, that saves me having to experiment with it and is interesting to know. So, the player actually is a special case then, which is actually very useful to what I'm doing, saving on a lot of math and, as you have described this behaviour, a good chunk of trial and error.

I've noticed that some interesting things can happen if an actor's YVEL is manipulated and I am aware of some effects using it to store information. One such effect I discovered is actually useful in a map I've had shelved for years.

[David B.]

Hi everyone,

I'm trying to create an icon (sprite) with a script behind, its role is playing a sound (determined by the lotag) when the player is close to it and hits space.
But the sprite disappears in the game (I have seen the sprite is "annihilated" in the game because of the script behind, and the sprite has not been set as invisible) and nothing works as usual...

DEF FILE :

dummytile 5970 24 24
   texture 5970 {
   pal 0 { file "fx/icon_sound.jpg" }
   }

DEFS.CON :

define I_SOUND 			5970

GAME.CON :

gamevar snd 0 2

state playsnd

    ifpdistl 1024
      ifhitspace
      {
        getactor[THISACTOR].lotag snd        
        soundoncevar snd
      }

ends

useractor notenemy I_SOUND 
  state playsnd
enda

It's painful to do a single basic CON script that works... Some modders implement within their games new effects with icons (similar to S, M, T...) like in Dark Level. But despite my effort I can't figure out how they're doing this.

May I have some help to fix it ? It would be appreciated

[Hendricks266]

Try removing "getactor[THISACTOR].lotag snd" from state playsnd and adding this to the bottom of your CON:

eventloadactor I_SOUND
    getactor[THISACTOR].lotag snd
    setactor[THISACTOR].lotag 0
enda

Basically, you need to copy the lotag into a gamevar at map load, because otherwise the engine might do something to the sprite based on the number.

[David B.]

 Hendricks266, on 25 May 2017 - 11:01 AM, said:

Try removing "getactor[THISACTOR].lotag snd" from state playsnd and adding this to the bottom of your CON:

eventloadactor I_SOUND
    getactor[THISACTOR].lotag snd
    setactor[THISACTOR].lotag 0
enda

Basically, you need to copy the lotag into a gamevar at map load, because otherwise the engine might do something to the sprite based on the number.

That's weird, I don't understand exactly that behaviour.
But your solution works perfectly, thanks !

[Danukem]

 David B., on 25 May 2017 - 12:12 PM, said:

That's weird, I don't understand exactly that behaviour.

It's because lotag on sprites is used to determine whether they are deleted when the map loads. If the difficulty setting is lower than the tag, they get deleted.

[Mark]

If you want to make sure the player has to face the icon when pressing the key you could use the ifpfacing command.

[David B.]

 Mark., on 25 May 2017 - 01:02 PM, said:

If you want to make sure the player has to face the icon when pressing the key you could use the ifpfacing command.

Yes I need the player faces it to make sense. Many thanks for the info, I could make it works too.

[Mark]

How do I add a delay to the start of an actor's action. It has the usual ifpfacing,ifpdistl,ifcansee then action. So after the first 3 conditions are met how do I insert a 1 second delay before the action starts? If it makes a difference, this actor will be performing it's action only one time in the game.

[Danukem]

 Mark., on 30 May 2017 - 07:09 AM, said:

How do I add a delay to the start of an actor's action. It has the usual ifpfacing,ifpdistl,ifcansee then action. So after the first 3 conditions are met how do I insert a 1 second delay before the action starts? If it makes a difference, this actor will be performing it's action only one time in the game.

You can do it the old fashioned way:

First, define a move that will be used like a var:

move WAIT

Then, in the actor's code, you do something like this (please excuse the shit formatting):

ifmove 0
ifp pfacing
    ifpdistl 1280
        ifcansee
move WAIT

ifmove WAIT
  ifcount 30
  action MYHOTACTION

[Mark]

Thanks. I should be able to handle that. Its for the one and only souldoor I'm using in medEVIL but with my own sound byte. It starts when the player turns a corner and because of the large map, the frame rate may stutter so that the action starts before the player gets close enough for a good look at the effect. So a delay will make sure the player is close and able to see the whole thing play. I normally would adjusted the player distance to a smaller value but the distance between the corner and the door is already quite short.

[Perro Seco]

How can I make a projectile that makes different damage if shot by an enemy than if shot by the player? I've been trying to found a solution for this during months. I know I can duplicate it to have two different projectiles with two different damage amounts, but there has to be a better solution.

[Danukem]

 Perro Seco, on 03 June 2017 - 12:37 PM, said:

How can I make a projectile that makes different damage if shot by an enemy than if shot by the player? I've been trying to found a solution for this during months. I know I can duplicate it to have two different projectiles with two different damage amounts, but there has to be a better solution.

You can either have the player detect the type of projectile hitting him and reduce the damage when the owner of the projectile is not a player, or you can set the extra member on the projectile to a different amount after it is fired. The first option is not quite what you asked for, because the projectile would still do normal damage if an enemy shoots another enemy. So, focusing on the second option:

onevent EVENT_EGS

ifspawnedby APLAYER nullop else
{
   ifactor MYPROJECTILE strength 10
   ifactor MYOTHERPROJECTILE strength 15
   // etc.
}

endevent

If that doesn't work, try using setthisprojectile[].extra instead of strength.

[Perro Seco]

Thanks a lot! Your code works fine, but I had to use negative values to make the projectile less powerful. I thought 'strength' was the total amount of damage inflicted, but it's an addition to the original amount.

[Danukem]

 Perro Seco, on 04 June 2017 - 03:11 PM, said:

Thanks a lot! Your code works fine, but I had to use negative values to make the projectile less powerful. I thought 'strength' was the total amount of damage inflicted, but it's an addition to the original amount.

I think you are confusing "strength" with "addstrength". Using negative values on "strength" should not work that way. In any case, what's going on here is that the .extra member of the projectile sprite, which stores damage, is being modified.

[David B.]

 Drek, on 19 February 2017 - 12:46 PM, said:

I found the old project and copied out the code for reference.

Spoiler

// from duke3d.def
dummytilerange 7250 7251 512 512
// Metal Bar Door Closed
model "structure/bar_door.md3" {
scale 13.2 shade 0
skin { pal 0 surface 0 file "structure/bars.png" }
frame { name "frame1" tile 7250 flags 0 }
}
// Metal Bar Door Open
model "structure/bar_door.md3" {
scale 13.2 shade 0
skin { pal 0 surface 0 file "structure/bars.png" }
anim  { frame0 "frame1" frame1 "frame9" fps 5 flags 1 }
frame { name "frame1" tile 7251 }
}

// from DEFS.CON
define METALBARDOOR_C 7250
define METALBARDOOR_O 7251

// from GAME.CON
// ADDPIC	
state addpic
  ifvare mycount 32	
  {
    setvar mybool YES
	setvar mycount 0
  }	
  ifvare mybool NO 
  {
	addvar mycount 1 
  }	
  else
  ifvare mybool YES
	ifpdistl 4096
	  ifhitspace
      {
	  getactor[THISACTOR].picnum picnum
	  addvar picnum 1
	  setactor[THISACTOR].picnum picnum
	  setvar mybool NO		  
	  }  
ends

// SUBPIC
state subpic
  ifvare mycount 32	
  {
    setvar mybool YES
	setvar mycount 0
  }	
  ifvare mybool NO 
  {
	addvar mycount 1 
  }	
  else
  ifvare mybool YES
	ifpdistl 4096
	  ifhitspace
      {
	  getactor[THISACTOR].picnum picnum
	  subvar picnum 1
	  setactor[THISACTOR].picnum picnum
	  setvar mybool NO		  
	  }
ends

useractor notenemy METALBARDOOR_C // 7250
  state addpic
enda

useractor notenemy METALBARDOOR_O // 7251
  state subpic
enda

Hello
I tried the script to open a door using an animated model. As a reminder, the closed door was a static model ("closed" position) while the next tile was defined as the same model with an animated opening.

The problem is when the model is switching to the next picnum to start the animation, the animation is not played but skips to the very last frame (completely opened).
As a result the door opens roughly anyway.

The behaviour is erratic because when I insisted on the door - opening & closing several times - it happens sometimes the animation is played (fluid opening),
and other times the animation goes "half-way". Is there some explanation or something to do ?

[Danukem]

What happens when you change "flags 1" on the open door to "flags 0"? I'm guessing the door will loop the entire open animation. I had a similar issue with a robot death animation recently, where it would insist on using the endpoint of the flags 1 tile instead of playing the whole thing, even though the animations were on different tiles.

[David B.]

Trooper Dan, on 08 June 2017 - 10:03 AM, said:

What happens when you change "flags 1" on the open door to "flags 0"? I'm guessing the door will loop the entire open animation. I had a similar issue with a robot death animation recently, where it would insist on using the endpoint of the flags 1 tile instead of playing the whole thing, even though the animations were on different tiles.

flags 0 make it loops properly but indefinitely. For now it's the only case I know where animation is executed.

[Danukem]

David B., on 08 June 2017 - 12:09 PM, said:

flags 0 make it loops properly but indefinitely. For now it's the only case I know where animation is executed.

That's what it's supposed to do when flags is set to 0, but I was just asking to confirm you can get the animation to display.

I'm beginning to think we may have an EDuke32 bug here. Like I said, I experienced a similar problem. It seems that in many instances, setting flags 1 on an animation will cause it to immediately skip to the last frame rather than play the whole thing.

[David B.]

So I'm trying to fall back on a animation only with hardcoding, but the sprite still rotates roughly by 90.

(Here is what I wrote for now, but the while loop doesn't allow to looks like an animation. I even tried ifcount and resetcount inside the loop to make it changes the angle "step by step" but it makes the game bugs, thus I know all this is not the right solution) :

state rotate_door

  ifvare mycount 16     			
  {
    setvar mybool 1				
        setvar mycount 0			
  }     
  ifvare mybool 0 				
  {						
        addvar mycount 1 
  }     
  else
  ifvare mybool 1
        	
        ifpdistl 1024 ifhitspace {				
          
          setvar temp 512

             whilevarn temp 0 {

             getactor[THISACTOR].ang angnum
             addvar angnum 1
             
                   setactor[THISACTOR].ang angnum
                   subvar temp 1
                
                }

             }          

          ifvare temp 0 soundonce 412
          setvar mybool 0
                    	
        }  
ends		

useractor notenemy TEST_DOOR
  state rotate_door
enda

I'd like to assign to the sprite a rotating speed ; is it possible at least ?

[Kyanos]

Yes, it should be a simple math trick by manipulating your timing var (temp) and the rotation var (angvar)

Eg setting temp to 256 and adding 2 to angvar each tic would double speed.

Slower you could set temp to 1024 add 1 to angvar each tic then divvar angvar 2 before setting it to the sprite, this would give you half speed rotation.

[David B.]

 Drek, on 11 June 2017 - 08:27 AM, said:

Yes, it should be a simple math trick by manipulating your timing var (temp) and the rotation var (angvar)

Eg setting temp to 256 and adding 2 to angvar each tic would double speed.

Slower you could set temp to 1024 add 1 to angvar each tic then divvar angvar 2 before setting it to the sprite, this would give you half speed rotation.

This is not working precisely, the 512 loop tics (or 1024) are seemingly executed in "no time", what I just see in the game is the door taking suddenly the final position (ang + 512) after hit space ; tuning the speed has changed nothing.

I'd like to know a way to tell "wait a certain time" at the end of the loop. I used "ifcount" for that, but this crashes the game.
Or perhaps giving to the sprite a rotating velocity along the Z-axis, similarly to the linear velocity we may give by using xvel, yvel, zvel.

I can't think it's impossible to rotate a sprite but I need something which is unfortunately beyond my knowledge.

[Kyanos]

I will try to test this code block of yours myself later tonight. For now if I were you I'd try a few things, first I'd set up the sprite classically with actions, then try to work with ifactioncount for timing as it's probably the better route over game tics.

added later:
I reordered some brackets, but the worst offender for you was the while loop, it seemed to play out in 1 tic, I changed it to an ifvarn 0 then it cycles through now once each tic as event game is called, still not perfect it may animate at varying speeds for faster/slower pcs, I still recommend looking into using the actions and ifactioncount.
 test_door.zip (1.68K)
Number of downloads: 640

state rotate_door

  ifvare mycount 16                             
  {
    setvar mybool 1                             
    setvar mycount 0                        
  }     
  
  ifvare mybool 0                               
  {                                             
     addvar mycount 1 
  }    
  
  ifvare mybool 1 
  {
    ifpdistl 1024
    {	
      ifhitspace 
      { 
        setvar temp 512 // the way this is set up set temp here to full rotation you want
        getactor[THISACTOR].ang angnum
        setvar mybool 0
        soundonce 74
      }
    }
  }

  ifvarn temp 0 
  {
    addvar angnum 16 // set speed here 1 is slow, 2 is still slow but faster, use power of 2 nums
    setactor[THISACTOR].ang angnum
    subvar temp 16  // match this to angnum above, 4,8,16 maybe 32 are decent speeds
  }
ends            

useractor notenemy TEST_DOOR 
  state rotate_door
enda

[David B.]

 Drek, on 11 June 2017 - 09:58 AM, said:

I will try to test this code block of yours myself later tonight. For now if I were you I'd try a few things, first I'd set up the sprite classically with actions, then try to work with ifactioncount for timing as it's probably the better route over game tics.

added later:
I reordered some brackets, but the worst offender for you was the while loop, it seemed to play out in 1 tic, I changed it to an ifvarn 0 then it cycles through now once each tic as event game is called, still not perfect it may animate at varying speeds for faster/slower pcs, I still recommend looking into using the actions and ifactioncount.

I think I'm obliged to use the actions then.

[David B.]

Sorry to be a pain but the curse keeps on me... I'm using actions, here again the animation doesn't start neither and the door don't move.

action OPENING 1 9 1 1 4

useractor notenemy TEST_DOOR TOUGH OPENING

     ifpdistl 1024 ifhitspace ifcansee
     {
         soundonce 412
         action OPENING 

     }
 
enda

define TEST_DOOR		5646

and

dummytile 5646 128 128
   texture 5646 { 
   pal 0 { file "fx/door.jpg" }
   }

model "models/test/new test/door.md3" {
   scale 2 shade 4
   skin { pal 0 surface 0 file "models/test/door.jpg" }
   skin { pal 30 surface 0 file "models/test/door_30.jpg" }
   skin { surface 1 file "models/test/metal.jpg" }
   skin { surface 2 file "models/test/glass.png" }
   frame { name "closed1" tile 5646 }
   anim { frame0 "open1" frame1 "open2" fps 10 flags 1 }
   frame { name "open1" tile0 5647 tile1 5648 }
   }

This time I can't get animation even with flags 0. The issue seems to come from the action itself or something is lacking...
The action was supposed to play the 9 next frames, the first frame (closed1) being reserved for the closed door in its initial position (this trick is inspired from the EGG definition).

[Danukem]

The first thing that strikes me when looking at that is that you have an action that goes for 9 frames (from tiles 5647 to 5655) but your model definition only covers 2 of them.