[Kyanos]

It just slammed shut. It was wip.

The count is in there to prevent a glitch where the door would open and close quickly with just a quick tap of the key. The count and Boolean vars unlock the check for ifhitspace.

[David B.]

Drek, on 21 February 2017 - 11:23 PM, said:

It just slammed shut. It was wip.

The count is in there to prevent a glitch where the door would open and close quickly with just a quick tap of the key. The count and Boolean vars unlock the check for ifhitspace.

Otherwise is it possible to make directly rotate a sprite by 90° only with a script ?
(therefore animation frames would not even be required)

[Kyanos]

David B., on 23 February 2017 - 04:55 AM, said:

Otherwise is it possible to make directly rotate a sprite by 90° only with a script ?
(therefore animation frames would not even be required)

I think it is, I think it will rotate at center. Look at the top of the page for angle info.

[Zaxtor]

Found an extremely simple trick to make some sprites go "through TROR" when normally they would stop at the "top" of a TROR. I talk about TROR with no ceiling.
Normally they would just goto the ceiling of the TROR and not go up further.
For the mod I am finishing, sparks coming through the hole in the floor "somewhere" in the mod.

We know mobs, projectile will go through TROR limits that doesn't block.

first scene is it stops at the end of the TROR top and slides sideways.
second scene I added "fall" in its code and it goes beyond the TROR "top" instead of sliding sideways.
fall wont make the thing go up "fall down".
here is a test vid (not a level of my mod)

[Mark]

Is there a way to preset the x,y,or zvel in an actor's code so that when it spawns it will have that value set?

[Kyanos]

Yes a few ways and different places to do it depending on what it is you're trying to accomplish.

xvel yvel & zvel are set in mapster sometimes for custom mods, or maybe you want real velocity immediately upon map load.

Event loadactor is probably where you would set it, just setvar[THISACTOR].*vel ###

[High Treason]

espawn MYACTOR
ifvarn RETURN -1
{
  setactor[RETURN].xvel YOUR_VAR_OR_NUMBER
  // YVEL, ZVEL or whatever other structs.
}

Or else you might have to catch it in EVENT_EGS, getting the RETURN to there should be trivial, but depending on what you're trying to do, a simple ifactor might be enough if you want every actor of that type to be affected when it spawns into the map.

[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.