Duke4.net Forums: EDuke32 Scripting - Duke4.net Forums

Jump to content

  • 93 Pages +
  • « First
  • 39
  • 40
  • 41
  • 42
  • 43
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

EDuke32 Scripting  "CON coding help"

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#1201

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.

This post has been edited by Fox: 28 March 2013 - 04:20 AM

0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#1202

View PostFox, 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.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#1203

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


This post has been edited by Fox: 29 March 2013 - 04:10 AM

0

User is offline   Mblackwell 

  • Evil Overlord

#1204

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

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#1205

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

This post has been edited by Fox: 29 March 2013 - 06:10 AM

0

User is online   Danukem 

  • Duke Plus Developer

#1206

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

User is offline   Mikko 

  • Honored Donor

#1207

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

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#1208

View PostFox, 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.]
1

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#1209

Thanks, that solve my problem.

View PostMikko_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.
1

User is offline   Mikko 

  • Honored Donor

#1210

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

User is offline   OpenMaw 

  • Judge Mental

#1211

View PostMikko_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.

This post has been edited by Commando Nukem: 29 March 2013 - 08:00 AM

0

User is offline   Mikko 

  • Honored Donor

#1212

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

User is offline   Hendricks266 

  • Weaponized Autism

  #1213

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

User is offline   Mikko 

  • Honored Donor

#1214

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.

This post has been edited by Mikko_Sandt: 31 March 2013 - 12:40 PM

0

User is offline   zazo 

#1215

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 ?
0

User is offline   Mikko 

  • Honored Donor

#1216

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

User is offline   Diaz 

#1217

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).
0

User is offline   zazo 

#1218

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

User is offline   Diaz 

#1219

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

User is offline   Mikko 

  • Honored Donor

#1220

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.

This post has been edited by Mikko_Sandt: 16 April 2013 - 05:35 AM

0

User is offline   Diaz 

#1221

I'm rather interested in that too.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#1222

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

User is offline   Biturbo 

#1223

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,
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#1224

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

User is offline   Biturbo 

#1225

View PostFox, 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...:)
0

User is offline   Diaz 

#1226

View PostFox, 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...
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#1227

View PostBiturbo, 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.
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#1228

View PostMikko_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.
0

User is offline   Mikko 

  • Honored Donor

#1229

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

User is offline   Diaz 

#1230

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

This post has been edited by Diaz: 17 April 2013 - 02:20 PM

0

Share this topic:


  • 93 Pages +
  • « First
  • 39
  • 40
  • 41
  • 42
  • 43
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options