[Perro Seco]

Looks like it's not an Eduke32 problem because it also happens in the original DOS game and in other Build Engine based games like Tekwar. I think a video is the best way to explain it:



From that angle, the projectile only hit if I aim to her feet. Is there a way to fix it via CON code or something?

[Danukem]

I think I've gotten so used to it that I automatically don't even try that angle when I'm shooting. I'm not sure of a good solution that doesn't have unwanted side-effects. This will sound weird but it might work: have actors spawn an invisible, non-blocking but hittable floor aligned sprite (cstat 33056). Then, when a projectile his the floor behind them (or in front of them), it will actually hit that sprite instead -- make that sprite transfer to the damage to the actor who spawned it.

Rough draft of code:

// in def file if you don't use .art
dummytile 6000 64 64
//variables

gamevar myspawner -1 2
define HITGROUNDSPRITE 6000 // or whatever number you want

useractor notenemy HITGROUNDSPRITE 0

ifaction 0
{
  action ANULLACTION
  cstat 33056
  sizeat 40 40 // or whatever seems right
}
ife myspawner -1 killit
ifl sprite[myspawner].extra 1 killit
ifg sprite[myspawner].statnum 2 killit

setsprite THISACTOR sprite[myspawner].x sprite[mypawner].y sprite[myspawner].z
ifhitweapon
{
   ifwasweapon SHOTSPARK1 nullop // we don't want this to work with bullets!
   else ifwasweapon RADIUSEXPLOSION nullop // or splash damage...
   else
   {
   seta[myspawner].htextra sprite[].htextra
   seta[myspawner].htpicnum sprite[].htpicnum
   seta[myspawner].htowner sprite[].htowner
   seta[myspawner].htang sprite[].htang
   }
   strength 0
}
enda

// example of spawning this thing in an actor's code

state femcode

ife myspawner -1
{
  espawn HITGROUNDSPRITE 
  setav[RETURN].myspawner THISACTOR
  set myspawner RETURN
}
// regular code after this

// you can also add another line of code where the actor dies: setav[myspawner].myspawner -1 to make sure it clears, but it should do that anyway

[ToiletDuck64]

This is a rendering-method-specific issue.
Classic-style renderers in general (such as what DOS Duke used) don't properly apply perspective vertically, so the area where the sprite is drawn doesn't quite match up with its actual location when you're looking at it from certain angles.
By the way, this happens in the classic renderer in eDuke as well; Polymost, for instance, doesn't seem to suffer from this problem (at least not nearly as bad).

[Danukem]

ToiletDuck64, on 17 May 2016 - 02:56 PM, said:

This is a rendering-method-specific issue.
Classic-style renderers in general (such as what DOS Duke used) don't properly apply perspective vertically, so the area where the sprite is drawn doesn't quite match up with its actual location when you're looking at it from certain angles.

I just re-watched the video after reading your reply, and I gotta say, if it's a perspective issue then some renderers would have to be WAY off. He was aiming up and down almost the entire length of the sprite.

[Mblackwell]

In classic there is no real perspective iirc. It's overdraw and a skewed projection/image.

[Perro Seco]

Trooper Dan, on 17 May 2016 - 01:02 PM, said:

Rough draft of code

Thanks a lot for your help! I understand your idea, but I tried to implement your code to the game to see how it works and nothing happened. Maybe I'm doing something wrong?

gamevar myspawner -1 2
define HITGROUNDSPRITE 216

actor HITGROUNDSPRITE 0
  ifaction 0
  {
    action ANULLACTION
    cstat 33056
    sizeat 64 64
  }
  ifvare myspawner -1 killit
  ifvarl sprite[myspawner].extra 1 killit
  ifvarg sprite[myspawner].statnum 2 killit

  setsprite THISACTOR sprite[myspawner].x sprite[myspawner].y sprite[myspawner].z
  ifhitweapon
  {
    ifwasweapon SHOTSPARK1 nullop
    else ifwasweapon RADIUSEXPLOSION nullop
    else
    {
      setactor[myspawner].htextra sprite[FEM3].htextra   //I don't know if it's correct to put "FEM3" here,
      setactor[myspawner].htpicnum sprite[FEM3].htpicnum //but with empty brackets it doesn't work.
      setactor[myspawner].htowner sprite[FEM3].htowner
      setactor[myspawner].htang sprite[FEM3].htang
    }
    strength 0
  }
enda


//In femcode:

ifvare myspawner -1
{
  espawn HITGROUNDSPRITE 
  setactorvar[RETURN].myspawner THISACTOR
  setvar myspawner RETURN
}

If I make it work I would try to implement it with moving enemies.

By the way, I found that slowing the projectile's velocity makes it more accurate.

[Hendricks266]

Update EDuke32 or put THISACTOR inside sprite[].

[Danukem]

Perro Seco, on 18 May 2016 - 03:47 PM, said:

Thanks a lot for your help! I understand your idea, but I tried to implement your code to the game to see how it works and nothing happened. Maybe I'm doing something wrong?

Yes, you did something wrong. The inside of the empty brackets [] is supposed to refer to the actor that is running the code. This is normally expressed by THISACTOR, but I omitted that because you are allowed to do that in recent builds as a shortcut. If you look at the code I posted, anywhere I write [] you can substitute [THISACTOR]. Substituting [FEM3] will not work, because that is the number of the tile, not the ID of that specific copy of the sprite.

Also, to start with, I would make the hit squares visible, so you can see that they are spawning, how big they are, and whether they are absorbing the shots. So, subtract 32768 from their cstat (i.e. give them cstat 288). There's a lot of things that could go wrong. For example, since the squares are flat against the ground, they may be too low and may need to be moved up slightly in order for projectiles to hit them instead of the ground.

[Perro Seco]

Thanks for your help again. I didn't know this also works with moving enemies!

But now I have another problem; projectiles go across sprites with cstat 288 without hit them! And with 289 the square begins to elevate the enemy...

I changed the cstat to 256 only for test, and now it can be hit, but it doesn't hurt the enemy.

Sorry for bother, but I'm a bit lame in this and I can't figure how to make it work.

[Danukem]

Perro Seco, on 19 May 2016 - 07:51 AM, said:

Thanks for your help again. I didn't know this also works with moving enemies!

But now I have another problem; projectiles go across sprites with cstat 288 without hit them! And with 289 the square begins to elevate the enemy...

The setsprite command constantly sets the square to the position of the sprite which spawned it. Notice that the setsprite coordinates are the coordinates of that spawning actor. Any odd-numbered cstat has the blocking bit set. Blocking of course makes a sprite solid, and yes that will make other sprites stand on it like a sprite bridge which could elevate them.

Perro Seco, on 19 May 2016 - 07:51 AM, said:

I changed the cstat to 256 only for test, and now it can be hit, but it doesn't hurt the enemy.

Sorry for bother, but I'm a bit lame in this and I can't figure how to make it work.

Don't take this the wrong way, but when you first posted and wondered about code that might fix the problem, I thought you had more experience with the scripting system and would be able to adapt the draft I posted. Unfortunately, I have other priorities right now and I'm not going to take the time to develop this any further myself. I think the concept has some merit, but getting it to work correctly would likely take someone with more knowledge and experience of the engine and scripting system than you have.

[Perro Seco]

No problem, you have helped me alot with your code. I'll try to find the way to make it work.

I'm not very good with CON coding, but I'm getting better slowly. Eduke32 Wiki have helped me lot of times, but sometimes I wish there was something similar in Spanish.

I'm also working on a TC for Eduke32 since 2009. I'm going to put a link in my signature now that I just reached the 50 posts.

[Jblade]

Blacklist looks really damn cool, good luck with it