[Fox]

You should mention that ifhitweapons, despite being an if condition command, triggers some special effects related to the damage inflicted to the actor. For example, using ifhitweapon a second time during the same tic won't work.

[Helixhorned]

Fox, on 28 March 2013 - 02:28 AM, said:

You should mention that ifhitweapons, despite being an if condition command, triggers some special effects related to the damage inflicted to the actor. For example, using ifhitweapon a second time during the same tic won't work.

Yup, some condition checks are side-effecting. In this case, ifhitweapon unconditionally runs the routine that incurs the damage on the actor, so there won't be any left for the second and following times. CON is full of strange corners like this.

[Fox]

I am having some trouble using hitscan command. It seems to be returning false to sprites or walls regardless of the case, while it at least is working for sectors.

    sin SIN player[THISACTOR].ang
    cos COS player[THISACTOR].ang
    setvar HORIZ 100
    subvarvar HORIZ player[THISACTOR].horiz
    subvarvar HORIZ player[THISACTOR].horizoff
    mulvar HORIZ 32
    hitscan player[THISACTOR].posx player[THISACTOR].posy player[THISACTOR].posz player[THISACTOR].cursectnum COS SIN HORIZ HITSECT HITWALL HITSPRITE HITX HITY HITZ CLIPMASK1

[Mblackwell]

Offset the player z by at least -8192 (-10698 is probably more accurate), and instead if mulvar HORIZ 32 do shiftvarl HORIZ 11. Add the player z to pyoff if you want to account for view bobbing. Also CLIPMASK1 will only catch things with the hitscan bit set, rather than all blocking items.

[Fox]

I am using the player posz, not the actor z, so it is not necessary to offset it. And I am reverse engineering something in the source code, so I am quite sure I should multiply the horiz by 32 instead of 2¹¹.

[Danukem]

I use 4294901808 as my clipmask value. I don't know whether that is different from CLIPMASK1 but I have been using it for a long time and it works (on walls and everything) for me.

If this is your first time using hitscan I suggest spawning a little fullbright sprite at the hitx hity hitz coords as a test. Make it an actor that lasts only one tic. Then you will have visual confirmation of where you are actually hitscanning.

[Mikko]

Is there an event or something that could cancel the episode-ending animation? So, it'd be endofgame-->automatically skip the animation-->the ending screen (Duke looking at the monitor, for example)-->bonusscreen. The wiki's event list did not seem to have anything useful.

[Helixhorned]

Fox, on 29 March 2013 - 04:09 AM, said:

I am having some trouble using hitscan command. It seems to be returning false to sprites or walls regardless of the case, while it at least is working for sectors.

    sin SIN player[THISACTOR].ang
    (...)

Well, apparently the inline player[THISACTOR].somemember accesses don't work as expected in C-CON. This is similar to what you reported here. Thanks for the test case, I'll add it to our lot.
[Note: I haven't actually checked the results of the inline struct accesses, but in LunaCON, the code works correctly.]

[Fox]

Thanks, that solve my problem.

Mikko_Sandt, on 29 March 2013 - 07:23 AM, said:

Is there an event or something that could cancel the episode-ending animation? So, it'd be endofgame-->automatically skip the animation-->the ending screen (Duke looking at the monitor, for example)-->bonusscreen. The wiki's event list did not seem to have anything useful.

Not really, cutscenes are super hard-coded.

[Mikko]

So, supplying an empty animation with the same name or something would get around that problem in a way?

[OpenMaw]

Mikko_Sandt, on 29 March 2013 - 07:52 AM, said:

So, supplying an empty animation with the same name or something would get around that problem in a way?

That's how older TCs did it. Blank one frame .ANM files, or blank images for the still images that are housed in the ART files.

You still have to deal with sound effects that are hard-coded with cinematics like for the Battle-lord, though.

[Mikko]

According to the Wiki, orientation parameter's bit 128 is "deprecated". Is there a replacement that works in both Polymost and Software? At the moment using bit 128 works - i.e., a sprite gets drawn on top of a weapon, for example - in Polymost but in Software the weapon takes precedence.

[Hendricks266]

Use a different display event. Weapons should display in EVENT_DISPLAYWEAPON; other specific stuff like the crosshair or statusbar should go in the appropriate event. Otherwise, use EVENT_DISPLAYREST for the highest-priority stuff.

[Mikko]

Cool, thanks. DISPLAYWEAPON actually didn't work either (the weapon was still drawn on top of the sprite in Software mode) but DISPLAYREST is fine. I guess it makes sense since the sprite is not technically a weapon, only a part of it.

[zazo]

I am looking for a piece of code to change weapons depending episodes: for example in episode 2, the shotgun is replaced by another shotgun with a different behavior ... for example the episode 1 is melee weapons, and episode 2 is fire arms...
How to modify the tiles num of weapons in the con code, to change their appearance ?

[Mikko]

I'm saying this as a con n00b, but all you probably have to do is use rotatesprite in the appropriate event (see the discussion above). Variable VOLUME contains the episode number so you can probably use that as a condition for episode-specific weapons.

[Diaz]

Use the code in weapons.con.sample as a base; just duplicate the weapon drawing states, change them according to what you want, then make your new states conditional based on the VOLUME var, in EVENT_DISPLAYWEAPON (which is also in weapons.con.sample).

[zazo]

more trickey... is some code (easy ?) to add extra animations to weapons: make a reloadable ripper for example with reloading frames as the pistol ?

[Diaz]

Not easy. You have to understand how the weapon drawing code works, then modify it accordingly. There's not a "way" to do it.

[Mikko]

How do I change the point of origin of a projectile? We have an actor that fires from both hands so it should appear as if the projectiles originate from these rather than the center of the sprite. Initially I simply changed the offset of the projectile when it's being fired (setactor[RETURN].xoffset, etc.) and, as far as I can tell, no one (of a whopping sample of two) noticed, but obviously this is just smoke and mirrors. Then I tried to change the projectile's x position based on its owner's position but this changed the entire trajectory, not merely the point of origin.

Edit: The projectiles are RPG-like.

[Diaz]

I'm rather interested in that too.

[Fox]

You must change the x-y coordinates and adjust the angle of the projectile accordingly.

[Biturbo]

Hello,

can someone help me with this problem
Im using transport elevator (SE 17) and I have done everything correctly...
but there is in 0:02 a little lag and I dont know why...

It seems, this is problem even in original maps(Episode 3 level 4 example L.A Rumble)...i tried few things but problem is still there.
This "lag" appears only when elevator is going up, when you are going down its OK...

any suggestions? maybe its a old problem, but is there some solution for this?
thanks,

[Fox]

That's a classic engine problem of the "teleport" elevators. It seems that basically the teleportation is as smooth as it should, spoiling the trick.

[Biturbo]

Fox, on 16 April 2013 - 08:39 AM, said:

That's a classic engine problem of the "teleport" elevators. It seems that basically the teleportation is as smooth as it should, spoiling the trick.

thanks for reply, so there isnt some way how to solve it? Trough CON, or maybe write my own teleport elevators...

[Diaz]

Fox, on 16 April 2013 - 06:53 AM, said:

You must change the x-y coordinates and adjust the angle of the projectile accordingly.

So I guess that means it's time to dig up the trigonometry book...

[Fox]

Biturbo, on 16 April 2013 - 08:46 AM, said:

thanks for reply, so there isnt some way how to solve it? Trough CON, or maybe write my own teleport elevators...

if it's any consolation, you also notice this glitch in the original game.

[Helixhorned]

Mikko_Sandt, on 16 April 2013 - 05:35 AM, said:

How do I change the point of origin of a projectile? We have an actor that fires from both hands so it should appear as if the projectiles originate from these rather than the center of the sprite. (...)

Edit: The projectiles are RPG-like.

Would declaring these projectiles as DEVISTATOR-like (sic) do the trick? Here's what happens, from player.c:A_ShootWithZvel(), irrelevant parts omitted.

            else if (PWEAPON(0, g_player[p].ps->curr_weapon, WorksLike) == DEVISTATOR_WEAPON)
            {
                // (...)

                if (g_player[p].ps->hbomb_hold_delay)
                {
                    sprite[j].x -= sintable[sa&2047]/644;
                    sprite[j].y -= sintable[(sa+1024+512)&2047]/644;
                }
                else
                {
                    sprite[j].x += sintable[sa&2047]>>8;
                    sprite[j].y += sintable[(sa+1024+512)&2047]>>8;
                }

                // (...)
            }

The thing to note here is that the offset in the two directions is not the same even if symmetry around the center is to be achieved.

[Mikko]

Well basically it's still more RPG-like because the "hands" shoot different projectiles as opposed to the Devastator, and the firing sequences have nothing to do with one another.

[Diaz]

Is there an easy way to make a player die like he was killed by a hitscan weapon? I mean, for example, if stepping into lava (not the hardcoded lava, but one I've coded myself depending on floor texture), he doesn't explode and play the jibbed sound (which is the standard behavior for addphealth and the like).

Thanks!

EDIT: Nevermind, it looks like everything is in the APLAYER actor. Perhaps it's not even standard behavior, I've just been working with my old Fusion CONs as a base ever since I finished it...