[sedition]

Hendricks266, on 23 March 2013 - 02:15 AM, said:

Try "addvar RETURN 16384" to the bottom of your event. IIRC it should disable the "LOADING" text completely.

onevent EVENT_GETLOADTILE
  ifvare VOLUME 0
  {
    ifvare LEVEL 0
      setvar RETURN <e1l1>
    ifvare LEVEL 1
      setvar RETURN <e1l2>
  }
  ifvare VOLUME 1
  {
    ifvare LEVEL 0
      setvar RETURN <e2l1>
    ifvare LEVEL 1
      setvar RETURN <e2l2>
  }

  addvar RETURN 16384
endevent

As for more complicated replacement of the loading screen, I have thought about using the variables LOTAG and HITAG to store the current and total textures values so modders could completely make their own screen using EVENT_GETLOADTILE or an EVENT_DISPLAYLOADING. edit: The variable TEXTURE might be acceptable to change the loading bar texture.


Would "eshoot FOOBAR" followed by "changespritestat RETURN 1" work?

Thank zou Hendricks and Fox,
I tried this, but all I get is a black background. And the loading text is also there.
Did I do something wrong with it?

Here´s the con code:

//Thanks to Fox and Hendricks266

onevent EVENT_GETLOADTILE
  ifvare VOLUME 1
  {
    ifvare LEVEL 0
      setvar RETURN 4030	// replace <xxxx> with the tile no. to display
    ifvare LEVEL 1
      setvar RETURN 4031
  }

  addvar RETURN 16384	// deletes the loading text
endevent

/* OLD ONE - NOT NECESSARY
// Background on Map´s load

onevent EVENT_GETLOADTILE
 setvar RETURN 3281
endevent
*/

And the lines in my textures.def:

dummytilerange 4030 4031 128 96
texture 4030 {
   pal 0 { file "highres/textures/bf/bf4030.jpg" }
}
texture 4031 {
   pal 0 { file "highres/textures/bf/bf4031.jpg" }
}

Maybe I did it wrong, but I can´t figure out what.

[Hendricks266]

It looks like the "add 16384" functionality was removed. Since no one has noticed until now, it should stay removed. There is code to compensate if the tile number is over MAXTILES (which has since been increased to 30720) but nothing to disable the loading screen text. (For the feature to be safe we would need to expose the value MAXTILES to CON as is done in M32script but it would still be hackish.)

If anything it should be done with other variables like TEXTURE. If the idea is approved I will add a way to disable the parts.

Try removing the "addvar RETURN 16384" for now. At least your custom tile should be displayed correctly.

Another thing, to cover the whole screen your dummytilerange should use the values 320 200 instead of 128 96.

[Mblackwell]

Hendricks266, on 25 March 2013 - 07:25 PM, said:

It looks like the "add 16384" functionality was removed. Since no one has noticed until now, it should stay removed. There is code to compensate if the tile number is over MAXTILES (which has since been increased to 30720) but nothing to disable the loading screen text. (For the feature to be safe we would need to expose the value MAXTILES to CON as is done in M32script but it would still be hackish.)

If anything it should be done with other variables like TEXTURE. If the idea is approved I will add a way to disable the parts.

Try removing the "addvar RETURN 16384" for now. At least your custom tile should be displayed correctly.

Another thing, to cover the whole screen your dummytilerange should use the values 320 200 instead of 128 96.

Actually I've noticed there seems to be an off-by-one error when using 320x200. You'll get a thin line on (I believe) the top and left of uncovered screen.

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