[Fox]

I have a question about the precache command:

Quote

0 - Precaches <tile0>-<tile1> only if <tile0> is in the map
1 - Precaches <tile0>-<tile1> always

How can I make it so that tile 0020 is loaded if 0010 is in the map, but not include tiles 0011-0019?

[Hendricks266]

The precache command isn't set up for instructions of that complexity. Search for CON_PRECACHE in gamedef.c and tiledata_t (the type that g_tile[] is) in actors.h.

Is it really necessary? Either bite the bullet and load #20 always, or ignore it and let the game takes its chances with automatic loading (which ideally should make this a non-issue).

[Fox]

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.

[Hendricks266]

It would hurt to add it, in the implementation details.

On the other hand, anything related to weapons the player uses should always be precached, so your use case is moot. In fact, the precache extension as you intend might not actually kick in because none of the projectiles might be in the map in the first place.

[Fox]

But isn't that how the source code works? I looked at it and the projectiles frames are precached if they are spawned. It is odd for precache command to not work in the same way.

(And to think about it now, the source code includes the frames from the RPG angles, or FREEZEBLAST animation, etc. Shouldn't it automatically check for animations in the .art files (or using animtilerange), and for all frames of the <action> from actor or useractor commands?)

[Hendricks266]

Fox, on 27 March 2013 - 12:07 AM, said:

Shouldn't it automatically check for animations in the .art files (or using animtilerange), and for all frames of the <action> from actor or useractor commands?

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

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.

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