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?
Page 1 of 1
Another projectile problem
#1 Posted 17 May 2016 - 10:47 AM
#2 Posted 17 May 2016 - 01:02 PM
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:
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
This post has been edited by Trooper Dan: 17 May 2016 - 01:09 PM
#3 Posted 17 May 2016 - 02:56 PM
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).
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).
#4 Posted 17 May 2016 - 06:59 PM
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.
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.
#5 Posted 17 May 2016 - 09:01 PM
In classic there is no real perspective iirc. It's overdraw and a skewed projection/image.
#6 Posted 18 May 2016 - 03:47 PM
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.
This post has been edited by Perro Seco: 18 May 2016 - 03:53 PM
#8 Posted 18 May 2016 - 08:56 PM
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.
#9 Posted 19 May 2016 - 07:51 AM
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.
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.
#10 Posted 19 May 2016 - 01:34 PM
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...
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.
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.
#11 Posted 19 May 2016 - 02:39 PM
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.
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.
Share this topic:
Page 1 of 1