[Hendricks266]

I'll leave it as an exercise to the reader. You can get the palette into Paint Shop Pro format (a human-readable text file) by opening an extracted art tile in IrfanView or by using bsuite. From there, it is simple to change 15 of the last 16 colors to black. That would be best to use for conversions. During this time, the tools you use should both input and output images in PNG format so that transparency is an actual alpha channel. Then, you can use the finished product directly with tilefromtexture or flatten using the transparent color (index 255) with another tool.

[Diaz]

So I've made a hack to make models that occupy more than one sector not disappear when the player is not looking at the sector the actual sprite is placed in....

First I used the hitscan code that is on the wiki:

gamevar MY_X 0 1
gamevar MY_Y 0 1
gamevar MY_Z 0 1
gamevar MY_SECTOR 0 1
gamevar MY_ANGLE 0 1
gamevar MY_ZDIST 0 1
gamevar MY_COS 0 1
gamevar MY_SIN 0 1
gamevar HITSECTOR 0 1
gamevar HITWALL 0 1
gamevar HITSPRITE 0 1
gamevar HITX 0 1
gamevar HITY 0 1
gamevar HITZ 0 1


state checkhitscan
	getplayer[THISACTOR].posx MY_X
	getplayer[THISACTOR].posy MY_Y
	getplayer[THISACTOR].posz MY_Z
	getplayer[THISACTOR].cursectnum MY_SECTOR
	getplayer[THISACTOR].ang MY_ANGLE
	getplayer[THISACTOR].horiz MY_ZDIST
	subvar MY_ZDIST 100
	mulvar MY_ZDIST -2048
	cos MY_COS MY_ANGLE
	sin MY_SIN MY_ANGLE

	hitscan MY_X MY_Y MY_Z MY_SECTOR MY_COS MY_SIN MY_ZDIST HITSECTOR HITWALL HITSPRITE HITX HITY HITZ CLIPMASK1 
ends

State checkhitscan is called constantly from within the APLAYER actor. Then I create an actor for the models:

spritenoshade 4577

eventloadactor 4577
    getactor[THISACTOR].cstat TEMP5

    ifvarand TEMP5 16
    {
        getactor[THISACTOR].sectnum TEMP
        getsector[TEMP].floorpal TEMP7
        setactor[THISACTOR].pal TEMP7
        getactor[THISACTOR].shade ACTORFLOORSHADE
        getactor[THISACTOR].x TEMP2
        getactor[THISACTOR].y TEMP3
        getactor[THISACTOR].z TEMP4
    }

    else
    {
        getactor[THISACTOR].sectnum TEMP
        getsector[TEMP].floorshade ACTORFLOORSHADE
        setactor[THISACTOR].shade ACTORFLOORSHADE
        getsector[TEMP].floorpal TEMP7
        setactor[THISACTOR].pal TEMP7
        getactor[THISACTOR].x TEMP2
        getactor[THISACTOR].y TEMP3
        getactor[THISACTOR].z TEMP4
    }
enda

useractor notenemy 4577 // Stone column
ldist TEMP6 THISACTOR player[THISACTOR].i 

ifvarl TEMP6 24000
{
        ifvarn HITSECTOR -1
            ifvarn sector[HITSECTOR].lotag 2
                changespritesect THISACTOR HITSECTOR    

        setactor[THISACTOR].shade ACTORFLOORSHADE
        setactor[THISACTOR].pal TEMP7

        setactor[THISACTOR].x TEMP2
        setactor[THISACTOR].y TEMP3
        setactor[THISACTOR].z TEMP4
}

enda

So the sprite's sectnum is always the sector the player is looking at, and thus it won't disappear. I have to save and restore x,y,z, pal and shade or weird things will happen.

Let me know what you think - this hack may not be optimal but I've noticed no slowdowns or undesirable effects so far....

EDIT: There is indeed slowdown with a large number of actors running this code. So I have to limit the distance, and I think I will make the "fix" toggleable with some gamevar, so it can be turned off if flickering/disappearing models don't bother you.

[Fox]

I am not sure if the hitscan sector is necessarily visible, have you tried setting it to camerasect instead?

Besides you should never change the actor sectnum (risk of map corruption), use the tsprsectnum instead.

[Diaz]

tsprsectnum doesn't seem to work (yea, I did set mdflags to 16 and put the code in EVENT_ANIMATESPRITES). However, I can use changespritesect, which is suppossed to prevent map corruption. Thanks for the warning!
And using camerasect caused the actors to completely disappear from the map for some reason

The HITSECTOR value seems to be very reliable, and I was already using the hitscan state for other things anyways. The clipmask is set to blockable sprites though, might want to change that to sectors only for this case.

[Mblackwell]

Changing sectnum always does changespritesect now. has for ages. it just happens in the back end.

Also camerasect is the current view point's sector. So from first person it's the player's current sector generally... so not what you want.

[Diaz]

meeeeeeeeeeeeeeeeeeeh, the code is almost worthless. I thought clipshape collision wasn't affected, but now that I have all models running this code, I found out it is. Sprites become non-blocking when their sectnum is different from the original. Too bad.

It's useful for big models that don't need collision.

[Mark]

It would probably be a good compromise to trace the outside shape of the model on the floor with sectors using blocking walls as a substitue clipshape.

[Diaz]

Yeah, that's why I said *almost* worthless. Some of the models I use actually have no clipshapes and use a combination of manually placed walls and clip sprites for collision - the code works safely on those.

[Fox]

 Diaz, on 29 April 2013 - 02:38 PM, said:

Sprites become non-blocking when their sectnum is different from the original. Too bad.

So you are actually changing the sectors and not setting it back? That's some massive fuckery since many functions depends on the sectnum.

[Diaz]

Oh yeah, now that you mention it, when the player is outside the effective distance range, I should set the sectnum back to the original value - whooops.

But it would make no sense to reset the sectnum right after changing it - that would cause the code to have no effect at all.

[Fox]

Change it during DISPLAYROOMS and set it back in DISPLAYREST by making a loop through all sprites in the level.

[Diaz]

Great, thanks.

[Diaz]

Making a loop for all sprites with all the conditions, etc. for an event that is being processed constantly, caused the game to hang.

I think I'm reverting to changing sectnums in actor code - after all, these are just static decoration models with no collision. I doubt changing their sectnum will do any harm.

[Mblackwell]

 Diaz, on 30 April 2013 - 01:28 AM, said:

Making a loop for all sprites with all the conditions, etc. for an event that is being processed constantly, caused the game to hang.

I think I'm reverting to changing sectnums in actor code - after all, these are just static decoration models with no collision. I doubt changing their sectnum will do any harm.

You should give them a unique statnum and do it in a loop that runs every few frames from the player code. Not turning those sprites into actors will save you fps.

[Fox]

 Diaz, on 30 April 2013 - 01:28 AM, said:

Making a loop for all sprites with all the conditions, etc. for an event that is being processed constantly, caused the game to hang.

I think I'm reverting to changing sectnums in actor code - after all, these are just static decoration models with no collision. I doubt changing their sectnum will do any harm.

You may be making the hitscan check for each sprite?

[Diaz]

Nope... just checking for picnum on each sprite and changing sectnum accordingly. If I do it every few tics there's potential for flickering so this all would have no sense, really - but I have to look into that different statnum thing.

Still, any loop is not really the most fps-effective solution - any reason I really shouldn't use the actor's code to change sectnums? It only happens within a range of 16000 units (original sectnum is restored outside that range), the actors are just static models with no collision or any other form of code, and the mod is Polymer only. I've noticed no side effects whatsoever, even after running the game for a long time, saving, reloading games, etc.

[Mblackwell]

If they have code running they aren't static models and take up additional processor time. I have a loop that runs every tic and only updates objects with a specific statnum (by using headspritestat/nextspritestat) and there's no effect on performance, other than the improvement of not having them as actors (which is much slower). You can process a few thousand objects this way much faster than if they were individual actors. This doesn't work for a good number of things, but for anything static it's great.

[Diaz]

Done. Performance does seem good, but the amount of models usable for this code (those with no collision) isn't that high.
So I guess it's working in an optimal way now. Thanks guys!

[Helixhorned]

 Fox, on 26 April 2013 - 03:59 PM, said:

Hmm, that's a trick one. Try this:

include this line somewhere before your actor code...

gamevar TEMP 0 2

Where you see the command "fall" in your actor, replace with:

  ifvare sector[THISACTOR].lotag 1
  {
    iffloordistl 8
      setactor[THISACTOR].zvel 0
    getsector[THISACTOR].lotag TEMP
    setsector[THISACTOR].lotag 0
    fall
    setsector[THISACTOR].lotag TEMP
  }
  else
    fall

The proposed hack is pretty good, but the advice to copy-paste a dozen of lines of code is not. One should always aim at reducing redundancy. In this particular case, it's easy: just put these lines into a CON state.

 Trooper Dan, on 26 April 2013 - 10:58 PM, said:

^That's an interesting idea for a solution, but it would be much simpler (and probably more reliable) to simply use "ifonwater spriteflags 16" which should prevent the sprite from teleporting into the underwater sector.

These two refer to different aspects of water: Fox's hack would prevent wading in water and your proposal would stop teleporting the actor. I haven't tested either of them, though.

[Dr. Kylstein]

This doesn't work:

onevent EVENT_GAME
    setprojectile[KNEE].extra 100
endevent

Why?

[Fox]

Because the KNEE is not defined with defineprojectile, it is hard-coded.

[Danukem]

 Fox, on 01 May 2013 - 06:56 PM, said:

Because the KNEE is not defined with defineprojectile, it is hard-coded.

Correct, but he can mod it the old fashioned way.

In USER.CON, find:

define KNEE_WEAPON_STRENGTH             10

and change the value to 100

[Dr. Kylstein]

 Trooper Dan, on 01 May 2013 - 09:45 PM, said:

Correct, but he can mod it the old fashioned way.

In USER.CON, find:

define KNEE_WEAPON_STRENGTH             10

and change the value to 100

That isn't desirable because my mod is a collection of mutators. In the end, I just defined a new projectile.

[Fox]

If you are using a mutator, you could add this:

actor KNEE <strength> enda

Of course an alternative is to redefine the KNEE using defineprojectile, but that way it would loose some hard-coded features, such as increasing the strength if you are using Steroids.

[Jblade]

Just a silly question, but I want to make sure it's accurate before I go ahead - if I want to remove a percentage of a number, there's no command to do that I have to work it out manually right? So for instance say TEMP8 is equal to 25:

	ifvare PERSONEL_RESEARCH[8] 2 // player has thermal weaving? reduce damage by 20%
		{
		setvarvar TEMP7 TEMP8
		mulvar TEMP7 10
		subvarvar TEMP7 TEMP8
		subvarvar TEMP7 TEMP8
		divvar TEMP7 10
		setvarvar TEMP8 TEMP7
		}

That should reduce it by 20% right?

[Fox]

What an ugly code, you should simply multiply it by 4 and divide by 5.

[Jblade]

Yeah ok so there is a better way to do it then, please don't call my code 'ugly' when I'm asking for help.

[Fox]

Yo code so fat when you get on top of her your ears pop!

[Mblackwell]

Btw for percentages in general, if you wanted 20% of 5 then X = (5 * 20) / 100.

So to add 20% you'd do X = (5 * 120) / 100

[Helixhorned]

For gamevars, two practically undocumented but used in-the-wild flags are 1024 (NODEFAULT) and 131072 (NORESET). This post is about the former.

What bit 1024 is likely supposed to do is to prevent resetting the gamevar's value to the default/initial one on various occasions such as starting a new game. For global and per-player gamevars, it could be e.g. used to hold information about gained mod-wide achievements.^[1] However, currently, the value of such gamevars would still be (always) restored by savegames or (if NORESET is clear) when restoring mapstates.
While I'm not sure whether to call it a bug (there was never a specification), I still think it's not the desired behavior. Suppose you kill the final boss and win $ 10⁶ as an award, but because you liked the final fight so much, you load up the last savegame and attempt to beat it once more. This time, you fail though, and all your money is lost .

What I intend to do in LunaCON is to make NODEFAULT gamevars persist during the entire duration of a session, with the only option of restoring it being via readgamevar. (I'm not yet sure how the interaction with NORESET should be.) Because this is an externally visible change to gamevar behavior, I'll probably also backport it to C-CON. Are there any objections to this plan? It should be noted that in all the mods that I'm batch-testing CON-compilation on, there are only a total of four uses of that bit.

----------
^[1]For per-actor gamevars, it has a somewhat technical use, the original one being rather meaningless. It can be set to prevent actor variables being reset on spawn (this includes the initial one from premap), so that they can be manipulated before: e.g. from eventloadactor code.