[Fox]

If we are going to talk about projectiles, there is a lot more that is needed right now. There should have an EVENT_SHOT that would run at the moment the shoot command is called, which is the same as the "void shoot" section from the source code. And EVENT_SHOTHIT which RETURN would be the sprite, wall or sector that was hit by a projectile (including bouncing). If you are using the Shotgun, these events would be called 7 times.

[Mblackwell]

There's already quite a few functions that allow you to control projectile behavior in pretty much any way you would like, unless you have a use case that doesn't let you account for it in hittype, getprojectile, eshoot, event_game, event_pregame, etc.

[Fox]

Projectile control is one of the best reasons to include new events. There are plenty of cases of use, besides that's would be in the same way the source code handles it. None of these events gives you proper control over the histcan projectiles, and they are called after the player fired the entire set of Shotgun bullets. Right now you can't control what a non-hitscan type projectile or radius explosion hit. Furthermore none of these events return the picnum of a hitscan projectile, they assume it is always SHOTSPARK1. And you can't properly make a sprite immune to certain projectiles, since checking the .htpicnum won't work if the sprite was hit by more than one type of projectile during same tic.

===//===//===

About the tint for 8-bit tiles flag, I just realized that it would also require a flag for nofullbright (which is another reason why I defined all tiles as highres textures).

[Hendricks266]

Fox, on 14 April 2013 - 11:42 AM, said:

There should have an EVENT_SHOT that would run at the moment the shoot command is called [...]. And EVENT_SHOTHIT which RETURN would be the sprite, wall or sector that was hit by a projectile (including bouncing). If you are using the Shotgun, these events would be called 7 times.

These sound plausible. How would you propose distinguishing between sprites, walls, and sectors for your EVENT_SHOTHIT? I can only see having separate events for each.

Fox, on 14 April 2013 - 11:42 AM, said:

which is the same as the "void shoot" section from the source code

It's more helpful to refer to the current EDuke32 source than the original source. This function has been renamed to A_Shoot and is now merely a stub for A_ShootWithZvel. I had to go out of my way to track this down.

Fox, on 14 April 2013 - 03:07 PM, said:

About the tint for 8-bit tiles flag, I just realized that it would also require a flag for nofullbright (which is another reason why I defined all tiles as highres textures).

Would this be per-tile or per-tint? We have the "nofullbrightrange" def command (only for OpenGL modes), used internally so we don't display the nasty fullbrights in #3281. A per-tint and lookup flag might be useful too, to apply on top of fullbrights and glowmaps.

[Fox]

Hendricks266, on 14 April 2013 - 05:05 PM, said:

These sound plausible. How would you propose distinguishing between sprites, walls, and sectors for your EVENT_SHOTHIT? I can only see having separate events for each.

What I can think of is RETURN holds the ID in the same way of .htmovflag. However there is the problem of distinguishing beetween the floor and ceiling of a sector, which is already a problem for .htmovflag anyway.

Hendricks266, on 14 April 2013 - 05:05 PM, said:

Would this be per-tile or per-tint? We have the "nofullbrightrange" def command (only for OpenGL modes), used internally so we don't display the nasty fullbrights in #3281. A per-tint and lookup flag might be useful too, to apply on top of fullbrights and glowmaps.

It would be per-tint, since the whole point is that you suggested it so I don't need to define a highres texture for every tile...

[Jblade]

having an EVENT_SHOTHIT would be very very useful to me too, so I'd definitly very much like something like that too.

[Helixhorned]

I disagree with adding new weapon/projectile-related CON functionality without at least having analyzed the existing one for possibilities of implementing the desired behavior.

First, how does the game handle damage? Basically, any code that wishes to damage an actor (the "target") sets its appropriate actor[] members (known as .ht* from CON): .htextra for the amount of damage and .htpicnum for the type, given by a tile number. This damage is not processed immediately. Rather, a particular actor's code checks whether it suffered damage using the A_IncurDamage() function when it is run. Normally, this function subtracts the damager's .htextra from the target's sprite[].extra and returns the damage type (.htpicnum). The code that called this function may then do whatever it pleases as a consequence of this damage, such as spawning guts. In certain cases, A_IncurDamage() may nullify the damage in the first place, such as when the player was hit on God mode. It returns -1 then.

One thing to note here is that there is no such thing as a "damage processing event"; both the intention of damage infliction and the subsequent "suffering" may happen from anywhere in either C or user code.

So, now to the CON side. The only point of accessing A_IncurDamage() from CON is the ifhitweapon condition, which takes the "true" branch iff a then-issued A_IncurDamage() call returns >= 0. For example, replacing the second ifhitweapon in the vanilla GAME.CON's APLAYER code by an always-false check (e.g. ifvare 0 1) will effectively make the player immune to almost any kind of damage. (Falling damage is handled from somewhere else.)
The above description implies a natural way to hook into the process of incurring damage: .htextra is backed up into a variable (say, damageamnt), and if a subsequent ifhitweapon takes the "true" branch, you know that the target's .extra has just been diminished by damageamnt. The projectile type, .htpicnum, is never changed by an A_IncurDamage() call.
Yes, there are probably some impediments to scripting such as hitscan weapons being lumped into SHOTSPARK1, but these would unlikely be solved by introducing even more complexity into the weapon/projectile code.

Just as an example, let's assume that a new EVENT_SHOOT is added that runs directly on top of the A_ShootWithZvel() function. While in this particular case it would not be a performance issue (shooting stuff is a rare event on a CPU-time scale), it would expose a superset of what was really intended originally: that function is for example used to "shoot" blood, or from the shooter SE.

So, Fox, can you reformat your use cases in bullet list form? Then we'll see how they may be implemented for a start.

[Fox]

Not really sure what you meant. But basically the picnum used in defineprojectile for hitscan doesn't return in any event, but instead they are all SHOTSPARK1. This is also true for other default hitscan projectiles (SHOTGUN, CHAINGUN) except for the GROWSPARK which htg_t seems to be inaccessible in events.

Now about projectile damage... one case which would cause trouble is shooting different types of projectiles with the same speed. You can't make the player immune to one of them, because they will hit the target at the same tic, and htpicnum returns the value of the latest hit.

[LeoD]

r3679 has introduced a bug that makes certain static sprites move around. At least in this map the red doors and the trunks of nearby palm trees are going wild right after map start.

[Helixhorned]

Oops, haha! That should not have happened. Fixed in r3685, thx. It doesn't help that these cleanup sprees (and there's a LOT to do if you're dealing with code descended from the original Duke3D source) mostly happen when I'm already somewhat tired and not in the state of doing anything significant.

[Helixhorned]

Fox: if you had read the EDuke32 source, you'd know that both getting the weapon that spawned a shotspark as well as the hit sector/wall/sprite is already possible from CON. The latter is even listed on the wiki. Take a look at the following code, usable as add-on module (-mx):

define Q 1000
definequote Q ----
definequote 1001 shotspark %d: %d from weap %d [sect %d wall %d sprite %d]

gamevar sparkcounter 0 2

// Override GAME.CON's shot spark.
actor SHOTSPARK1 PISTOL_WEAPON_STRENGTH WEAP2FRAMES
  qsprintf Q 1001 /*fmt:*/ THISACTOR sparkcounter
    sprite[THISACTOR].yvel  // See player.c:Proj_InsertShotspark()
    sprite[THISACTOR].htg_t 7
    sprite[THISACTOR].htg_t 6
    sprite[THISACTOR].htg_t 8

  addvar sparkcounter 1
  userquote Q

  // This is a stripped version of the vanilla code:
  ifdead
    killit
  ifactioncount 4  // note this
    killit
enda

Curiously, this will print the message eight times per shotspark. The reason is that the SHOTSPARK1 actor code is run additionally to the main actors loop in G_MoveWeapons() at the end, and this since Duke3D.

Arguably, using these members is horribly unreadable (in addition, .yvel should not be assigned to; it may stay read-only in LunaCON), but at this point it's unlikely to change, so it can be considered official API.

As for the other issues, again, please format them each on a single line -- I can't follow all of your feature requests / questions because there are so many!

EDIT: Just to clarify, I do not encourage reading the source to find out what's possible in CON. There should be a clear seperation of implementation and interface, the latter preferably being clearly documented (both what is, and just as importantly, what is not allowed).

[Fox]

I wasn't aware of the .yvel for projectiles. However I know of htg_t (though apparently still unavaiable for non-hitscan type projectiles?).

Recon not working in latest svn. It simply explode and spawn the Pig Cop in mid-air instead of falling to the ground.

[Mblackwell]

Yvel has different actions for different types of actors/projectiles. However they aren't really documented.

[Helixhorned]

Fox, on 14 April 2013 - 05:47 PM, said:

What I can think of is RETURN holds the ID in the same way of .htmovflag. However there is the problem of distinguishing beetween the floor and ceiling of a sector, which is already a problem for .htmovflag anyway.

A reasonable way to check whether the ceiling or floor was hit is to see if the z coordinate is <= or > than the midpoint between them at a given (x, y) position.

Fox, on 15 April 2013 - 10:53 PM, said:

However I know of htg_t (though apparently still unavaiable for non-hitscan type projectiles?).

Ah, I see, by "not available" you mean that they're not set for anything other than hitscan projectiles (well, and KNEE). Adding it to the others sounds like a sensible idea, but it's really more a question of making hitradius/A_RadiusDamage() more scriptable then.

Fox, on 15 April 2013 - 06:55 AM, said:

Now about projectile damage... one case which would cause trouble is shooting different types of projectiles with the same speed. You can't make the player immune to one of them, because they will hit the target at the same tic, and htpicnum returns the value of the latest hit.

I'm still having problems to parse this. Making a player immune to certain damage could be achieved by hooking into ifhitweapon as described above and reverting the damage for that particular weapon.

[Helixhorned]

Fox, on 15 April 2013 - 10:53 PM, said:

Recon not working in latest svn. It simply explode and spawn the Pig Cop in mid-air instead of falling to the ground.

Oh, that was another oversight. Fixed in r3686. Keep up the quick pointing-at-what-you-broke .

[Fox]

Helixhorned, on 16 April 2013 - 11:04 AM, said:

I'm still having problems to parse this. Making a player immune to certain damage could be achieved by hooking into ifhitweapon as described above and reverting the damage for that particular weapon.

For example, let's the player has been hit by RPG and FREEZEBLAST during the same tic, I can't revert only the damage suffered by the RPG, because .htpicnum will return only one of the projectiles (probably the one which ID is higher).

[Mblackwell]

But does ifwasweapon return both as true in that case?

[Fox]

No, because ifwasweapon only checks for the value of .htpicnum, which cannot store more than one value.

===//===//===

Is it just me or .htflags is inaccessible in CON? Because I would like to have the "badguy" value stored somewhere, however htflags return false for it.

[Helixhorned]

Fox, on 16 April 2013 - 09:57 PM, said:

Is it just me or .htflags is inaccessible in CON? Because I would like to have the "badguy" value stored somewhere, however htflags return false for it.

BADGUY is set per-tile, not per-actor. Alas, there's no access for the respective structure array in CON.

[Helixhorned]

Fox, on 16 April 2013 - 12:33 PM, said:

For example, let's the player has been hit by RPG and FREEZEBLAST during the same tic, I can't revert only the damage suffered by the RPG, because .htpicnum will return only one of the projectiles (probably the one which ID is higher).

Let's review how damage is handled once more.

What's on the scene?

• A particular actor's current health: sprite[].extra in C and CON.
  
• For this actor, a potential damage: actor[].extra in C, sprite[].htextra in CON.

What operations are possible?

• Anything/anyone can request that a particular actor i shall be inflicted damage by a certain amount. Thus, an actor can be in the state of pending damage infliction. In C-like pseudocode, this amounts roughly to
  

  actor[i].extra = damage_amount;  // (r1)
  // OR
  actor[i].extra += damage_amount;  // (r2, see below for discussion)
  
  actor[i].picnum = damage_type;  // given by tile number
  

  
  Other members like .owner or .ang also have a meaning with damage handling, but are irrelevant here.
  
  
• The suffering actor can have (usually in CON code via ifhitweapon) its pending damage accounted/incurred. This is done via A_IncurDamage() in C, around which CON's ifhitweapon is simply a wrapper. Roughly,
  

  /* Maybe nullify damage (e.g. if on God mode). Return early then. */
  
  // If we have pending damage, process it.
  if (actor[i].extra > 0)
      sprite[i].extra -= actor[i].extra;
  
  actor[i].extra = -1;  // We don't have pending damage now.
  
  /* If damage was inflicted, actor[i].picnum can be used to handle it in a
   * specific way, for example tinting the screen. */
  

What do we have after a series of damage infliction requests R₁, R₂, ... R_n, in between which there may be anything except damage incurring?
Well... actor[i].extra is a positive value and actor[i].picnum is the damage type of the last request, R_n. Depending on whether (r1) or (r2) was taken in the requests, the pending damage may either be overwritten or accumulated to an existing one, but in the end, you don't know, and no effect happened conditional on it (well, unless you specifically coded it).

[Fox]

Helixhorned, on 18 April 2013 - 09:33 AM, said:

BADGUY is set per-tile, not per-actor. Alas, there's no access for the respective structure array in CON.

Is it possible to add a command to return the value of badguy, nvg, nopal, noshade and etc for a specific picnum?

I need to do some reverse engineering of the tspr shade and pal, and it would be very helpfull if I had access to those values, otherwise I am forced to use some rought interpretation of the source code.

[Forge]

r3688

i don't know what was done to "fix" the water, but it broke an old effect

example used is billyboy's clearwater map

old style transparent water now acts like an ordinary untagged floor, it is walked across like a non-water surface and can't be dove in

coming from another direction to get under the water - while surfacing duke keeps going up past the actual floor height of the water quite a bit before the under water effect is ceased
doing this also causes everything to have the underwater blue tint afterwards

Attached thumbnail(s)

• 
• 

[LeoD]

Forge, on 20 April 2013 - 07:17 AM, said:

i don't know what was done to "fix" the water, but it broke an old effect

That's a rather old problem I think.

[Forge]

nope.

this map worked fine prior to r3684

edit: went back and used some older snapshots and i couldn't get it to work like the original. Whatever I did or whatever happened when i was using r3676 to make it act like it was originally designed was a fluke and i can't reproduce it

[Fox]

BUMP

Fox, on 11 April 2013 - 11:07 PM, said:

It seems that now that the problem with horizontally flipped sprites offset is fixed, the same thing happens with vertically fliped sprites in OpenGL modes:

Also in Polymer mode the same problem occur with center-aligned sprites (cstat 128). Which reminds me of that old problem with the hanging babe HRP model requiring maphacks for a similar reason.

[Player Lin]

Forgot did I reported something like this, just can't remember at all...or maybe not on here...(Lazy to find the threads on 3DRealms. )

Noticed some renderer glitches at polymost when playing DNWoA (1.50 beta) mod in the one of DukeDC levels, recently.
Just minor renderer glitches and I won't surprise if it won't be fix due it's on polymost...

The duke0004 one is on classic renderer, and on the same position with the duke0006 one taken, all screenshots on the attachments taken with r3705 snapshot.

Attached thumbnail(s)

• 
• 
• 
• 
• 

[High Treason]

The TARGET sprite has reversed it's operation in recent builds, check E4L4, the combo is shoot target 2 and 4 but in newer builds of EDuke32, the pattern is 1, 3, 5.

I can try running back through the builds to track it down if you want, but it seems to be between r3555 and r3693 so that could take a while.

[necroslut]

Hasn't anyone noticed fire spawns spawning a few feet above the floor? For example in E1L3. It's been like that for years.

[Mblackwell]

It's supposed to get cstat 128.

[High Treason]

You might have found it already, but just in case it is at all useful, I tracked down the problem I am having to r3684. This is the first one to have broken targets, it also has shooters that don't work (projectiles seem to hit something that isn't there) and the frame-rate is awful. The last two bugs disappear by the latest build though, so it's just the targets that are broken from my perspective.