[Fox]

Hendricks266, on 27 March 2013 - 12:42 AM, said:

In fact it should, and I am adding this to my to-do list.

Being more careful, I would say to check the action of an actor during the first tic (event_spawn?) and return false if the cstat is not 32768.

Hendricks266, on 27 March 2013 - 12:42 AM, said:

BTW, if you still want CON access to the four members of the picanm[] array we should have a conversation with Helix. Me adding tilesizx[] and y[] gave him extra trouble in Lua.

Yes, I totally want. The game uses the size and offset to check the enemy hitboxes and where the projectiles aim at.

Can you at least make a command like getsizx <tilenum> <gamevar>?

[Danukem]

Fox, on 26 March 2013 - 11:28 PM, said:

Is it necessary? Not really, I don't care much about precache. But since it's there, it wouldn't hurt to also add it.

To be more specific, this is the projectile of the Grenade Launcher from Duke Nukem 64 I am talking about. There is about 200 tiles beetween some frames of the projectile.

If there are 200 tiles between frames, then the art isn't well organized. That's not something that the pre-caching code should have to worry about.

[Fox]

It's not my fault. But it is also like that with some of the original sprites (i.e. the player swimming frames are in another art file).

[Jblade]

If I remember right, there's an odd quirk with htextra and ifhitweapon - I can't remember what it was, but htextra is always returning -1 for me even if I'm clearly hitting the actor and doing damage. Anybody know what's up with that? I can't see any info on the wiki.

[Fox]

I believe that you should get the htextra before ifhitweapon command is used.

[Jblade]

Alright, thanks - I should add something to the wiki about this at some point since after searching a few others had the same problems.

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