[Mark]

I'm a little confused with those links. Does this mean I don't replace the 3Drealms screen the same way I did the other 2 screens? Or should I be using those links to accomplish what I need instead of how I did it already?

[Diaz]

Mblackwell, on 23 April 2013 - 07:54 PM, said:

What happens if you

onevent EVENT_JUMP
    setplayer[THISACTOR].poszv -2048 // or some other value
    setvar RETURN -1
endevent

This destroys any ifp pjumping code however.

That does what I want, however it has side effects:

- As you have mentioned, ifp pjumping code is destroyed, though I think I can safely replace all instances of "ifp pjumping" with a check for the player's z velocity.
- The player can now bunnyhop like crazy if keeping the jump key depressed (no idea how to fix this).
- Jumping to get out of water messes up.

So, not worth it

[Fox]

Mark., on 23 April 2013 - 07:59 PM, said:

Yet another in a long line of questions.

onevent EVENT_GETLOADTILE
setvar RETURN 7119
endevent

onevent EVENT_GETMENUTILE
setvar RETURN 7119
endevent

I replaced the load and menu screens with my own but I can't figure out the name for the DREALMS tile 2492 so I can replace it. I tried a few variations of the word DREALMS between "GET" and "TILE" but no luck.

There is no such a thing as a event that control the 3DRealms screen. You need to replace the tile.

[Mblackwell]

Diaz, on 23 April 2013 - 10:28 PM, said:

That does what I want, however it has side effects:

- As you have mentioned, ifp pjumping code is destroyed, though I think I can safely replace all instances of "ifp pjumping" with a check for the player's z velocity.
- The player can now bunnyhop like crazy if keeping the jump key depressed (no idea how to fix this).
- Jumping to get out of water messes up.

So, not worth it

gamevar P_JUMP 0 1

onevent EVENT_JUMP
    ifvare P_JUMP 0
        setplayer[THISACTOR].poszv -2048
    setvar RETURN -1
    setvar P_JUMP 3
enda

actor APLAYER
    ifvarg P_JUMP 0
        subvar P_JUMP 1
    ifvarn P_JUMP 0
        action PJUMPING
enda

For example.

If necessary you can add a condition for when you're in water.

[pmw]

I need to make my monsters non-sinkable. When there are water where player can dive, monsters will also sink there.. I tried to find something related to that from con-codes, but with zero results. Any advice?

[Fox]

It depends on what you are aiming to. Do you want them to walk above the water, or not enter water sectors (like some monsters)?

[pmw]

Just walk above the water. Just not going underwater.

[Fox]

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

[Danukem]

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

[zazo]

A common problem when converting images to the Duke3D palette in editart is the existance of fullbright colors in the image, indexed as colors 240-254 in the palette.
Is a way to spot them and correct them ?

[Hendricks266]

When converting stuff, I usually use an edit of the palette that has all the fullbrights blacked out.

[zazo]

Hendricks266, on 27 April 2013 - 10:08 AM, said:

When converting stuff, I usually use an edit of the palette that has all the fullbrights blacked out.

interesting, a link to download this palette ?

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