[RPD Guy]

Hy guys!
My name is Daniel. After bothering my partner Daniel (DeeperThought) <- saying to me all the time to use this forum, I finally decided to use it.
By the way, I would like to thank you Deep, you helped me a lot, and you was a very good friend to me, and still is!

Now, focus in the point.

My first question is:
I creat a actor, a simple actor, and in his code I always try to make this: when the player comes close (about 4096 units) get its XYZ position of the actor, and set the XYZ position of the camera (like that flying camera that records scenes only when you are recording a demo)
but, I'm still failing.

HOW I FIX THIS?

[Micky C]

If you say your code isn't working, and want help with fixing the code, why not post the code so we can have a look at it? Otherwise we can't tell you why it's not working.

[CruX]

Having created this very effect, my advice is NOT to bother with distance checks. Instead, check the sector of the actor versus the sector of the player, and change the stats of the camera to the stats of the actor ONLY if the the player's occupying the same sector as the actor. You can change the camera's values using these constantly updated gamevars, then manipulating them in this game event.

[RPD Guy]

well ... as I not had success in this code, I decided delete of the CON, but I decided to bring back.
but I remember a piece of code:

gamevar XVAR 0 1
gamevar YVAR 0 1
gamevar ZVAR 0 1

actor CAMERACHANGER 0 0
ifpdistl 4096 { getactor[THISACTOR].x XVAR setvar camerax XVAR
                    getactor[THISACTOR].y YVAR setvar camerax YVAR
                    getactor[THISACTOR].z ZVAR setvar camerax ZVAR
} else { nullop }

is more or less something like this, not totally remember the code, I think this example isn't very much logic

[CruX]

You can't change those variables in actor code. It has to be in EVENT_DISPLAYROOMS.

[RPD Guy]

ok, searching in eduke wiki I find it:

  
onevent EVENT_DISPLAYROOMS
  ifvarn camerasprite -1
  {
    getactor[camerasprite].x camerax
    getactor[camerasprite].y cameray
    getactor[camerasprite].z cameraz
    getactor[camerasprite].ang cameraang
    getactor[camerasprite].extra camerahoriz
    getactor[camerasprite].sectnum camerasect
  }
  endevent

 

instead of "camerasprite" I could use another actor?
I understand a piece of the code, but nothing is being used as the trigger of this action.

the camera needs to be styled "resident evil"
surely I could not use codes that use the argument that "if" the player is in the same sector of the actor, because the player can be seem by the actor in others sectors.
because of that I used "ifpdistl"


EDIT: ifvarn is a trigger ¬¬ how I not figured it out? =P

[CruX]

Dk2, on 10 November 2011 - 03:02 AM, said:

instead of "camerasprite" I could use another actor?
I understand a piece of the code, but nothing is being used as the trigger of this action.

You've already created your "trigger" with the CAMERACHANGER actor, you just need to flip some of the variables around, and create another var to let the game know that the player is within viewing distance of the camera actor. Since the XVAR (etc.) variables are perplayer, just change the actor's code to this...

gamevar XVAR 0 1
gamevar YVAR 0 1
gamevar ZVAR 0 1
gamevar CANSEE 0 0 // new var

actor CAMERACHANGER 0 0
ifpdistl 4096 { 
setvar CANSEE 1 
getactor[THISACTOR].x XVAR 
getactor[THISACTOR].y YVAR 
getactor[THISACTOR].z ZVAR 
} else { setvar CANSEE 0 nullop }

then jump to EVENT_DISPLAYROOMS...

  onevent EVENT_DISPLAYROOMS
  ifvare CANSEE 1
  {
   setvarvar camerax XVAR
   setvarvar cameray YVAR
   setvarvar cameraz ZVAR
  }
  endevent

...of course, there's all kinds of stuff with this code that's still messed up (you're not taking the camera's horiz value into consideration, for starters), but this'll produce the basic effect you're looking for. And then there's this...

Dk2, on 10 November 2011 - 03:02 AM, said:

surely I could not use codes that use the argument that "if" the player is in the same sector of the actor, because the player can be seem by the actor in others sectors.
because of that I used "ifpdistl"

What you stated is the exact reason using distance checks gets really, really messy the more the cameras are used. What if the player's within distance of two, or even more, different cameras? There's no workaround you can code in at that point that'll make sure the right camera's being used. What I did was create two different actors...

1 - An actor that actually changes the camera's x,y,z values (like what you have in your code)
2 - An actor that serves as a 'tag', and has a hitag value equal to one (and only one) of the 'camera' actors in the map. When the player enters the same sector as this 'tag' actor, it puts its hitag value into a global gamevar, and the camera actor ONLY changes the camerax, y, z vars if its hitag value is equal to the value of that global variable.

This system pretty much worked flawlessly, and I could put camera actors as close together as I wanted as long as I made sure they each had a unique tag that occupied a different sector. Either way, distance checks ain't the way to go. Trust me.

[RPD Guy]

I tested your code, what you did now, I took two or three months to "try" to do, and I had no success.
tanks for the help, I'll try to improve the code, and soon I will post here again.

[High Treason]

Hmm... I've been trying to do this kind of thing as well, and I got it working (Also thanks to DeeperThought)... You can have the code I am using to help you understand,, but it may need tweaking, and I'd be inclined to say that EmericaSkater is on the right track, in fact I might have to... err... borrow some of that, because my code doesn't have a way to determine which is the right camera, I was going to work around it by making a delay, but Emerica's solution sounds better.

gamevar CAMX 0 0
gamevar CAMY 0 0
gamevar CAMZ 0 0
gamevar CAMA 0 0
gamevar CAMZD 0 2
gamevar CAMON 0 0
gamevar CAMH 0 0
gamevar x 0 0
gamevar posx 0 0
gamevar y 0 0
gamevar z 0 0
gamevar ang 0 0

// Fixed Camera
define FIXIECAM 555
action NOWT 1 1 1 1 0
move DONTMOVE 0 0
ai LOOKIEHERE NOWT DONTMOVE faceplayerslow  // you can use faceplayer and faceplayersmart too.

actor FIXIECAM
cstat 32768
  getactor[THISACTOR].lotag CAMH // will get the hitag of the camera and change horizontal angle of camera.

ifpdistl 8192 // change this to desired distance
  ifcanseetarget // make sure it has a line of sight to the player
{
	ai LOOKIEHERE
	setvar CAMON 1
	getactor[THISACTOR].ang CAMA
	getactor[THISACTOR].x CAMX
	getactor[THISACTOR].y CAMY
	getactor[THISACTOR].z CAMZ
 }
else
ifpdistg 20000
{
   setvar CAMON 0
}
else nullop
enda

You will need to enter some code in EVENT_DISPLAYROOMS

onevent EVENT_DISPLAYROOMS
ifvare CAMON 0
{
   setplayer[THISACTOR].over_shoulder_on 0
   getplayer[THISACTOR].ang CAMA
   getplayer[THISACTOR].posx CAMX
   getplayer[THISACTOR].posy CAMY
   getplayer[THISACTOR].posz CAMZ
   setvarvar camerax CAMX
   setvarvar cameray CAMY
   setvarvar cameraz CAMZ
   setvarvar cameraang CAMA
}


ifvare CAMON 1
 {
	setplayer[THISACTOR].over_shoulder_on 1
	setvarvar camerax CAMX
	setvarvar cameray CAMY
	setvarvar cameraz CAMZ
	setvarvar cameraang CAMA
	setvarvar camerahoriz CAMH
 }

// and remember to have any other code you need in this event written before the endevent.
endevent

Edit: Now changes to player view when out of range

[CruX]

...Hitags are okay, but it's really best that you not mess around with lotags. Determining the horiz through something like the camera's xvel,yvel,zvel and even 'extra' members works better. Need to dig that old camera mod up so I can post the code here. I got it working pretty much exactly the way it needed to. Always meant to post what I'd done of the mod when I started working on CrackDown, but just never got around to it.

[High Treason]

Indeed, I intend to either make the game do some math on it's own or just use the extra value. I did have it hooked up to YVEL but I can't remember why I got rid of that.

Either way, hopefully the code is of some help to Dk2, I know that when I am trying to code something I like to have as many examples as possible lying around.

[RPD Guy]

changing the lotag of the camera's sprite make the camera don't work.
why?


EDIT: I've changed lotag to "hitag" in the srting "getactor[THISACTOR].lotag CAMH // will get the hitag of the camera and change horizontal angle of camera."
now is working =)

[CruX]

Dk2, on 10 November 2011 - 04:28 AM, said:

changing the lotag of the camera's sprite make the camera don't work.
why?

Some kind of hardcoded crap to do with the lotag IIRC. It's best that you just avoid use of the lotag completely. Change that structmember to something like 'extra' or 'xvel'.

[RPD Guy]

New question:
i've maked my own JIBS (defined as a projectiles)
I'm using zshoot to make they shoot to the sky, but they are too fast, and aways shoot to + - 45º degrees ahead.
DeeperT have talked about the state "randtraj", but it's falling.
what I do to make they shoot properly and don't fall in the same position?

[rasmus thorup]

You could change the zvel after an amount of time with setactor[THISACTOR].zvel. Make sure that the time it should fall will be random, so every jib will look more different.

[RichardStorm]

You can set both xvel and zvel of the projectile , with " ezshoot (your ZVEL) (your proj.)" and then "setactor[RETURN].xvel (your XVEL)".
You can also modify xvel and zvel directly in EVENT_GAME (where randtraj state should be set), or combining two methods.
Xvel and zvel should be properly set with your own formula, maybe involving trigonometry or something similar. I'm sure you are coding a gore improvement like mine, in this case the first method is better because variables can be calculate within the actor which shoots out jibs projectiles. Then you can use randtraj (you have to write it before) in EVENT_GAME.
Feel free to ask better explanations.

[RichardStorm]

Damn... i meant you need EVENT_EGS, which triggers when sprites spawn...

[RPD Guy]

Soon I'll post some screens of OUR mod here.

My goal is to do a Resident Evil 2 TC, following exactly the original story of the game (not so original)
Currently my job is programming (Cobol in Net Express)
but in the language CON still have some difficulties.
I would like everyone's help, who knows how to make textures, modellers, programmers ... (I don't know nothing about modeling)
everyone will be in the credits of OUR mod.
add my msn angel.bnu@hotmail.com if any of you are interested in helping me hard

Edit: NEED THE MODEL OF LEON SOON AS POSSIBLE!!!!!!!!

[RPD Guy]

well, my trouble now is with models.
I've made a "wall barricade model"



here the DEF lines:

// Barricade (415)
model "highres/sprites/props/barricade.md2" {
   scale 1 shade 0
   detail { file "highres/detail/wood.png" detailscale 0.3 }
   skin { pal 0 file "highres/sprites/props/barricade.png" }
   frame { name "frame" tile 415 }

and here the CON code:

define BARRICADE 415
actor BARRICADE 0 0
ifpdistl 512
	ifhitspace
	quote 134
enda

("cstat" and "sizeat" is defined by the user in mapster)

don't works. what is wrong? CON is ok, but the model don't spawn at the game, only the default sprite.

EDIT: there is no errors or warnings on "eduke32.log".

[The Commander]

   frame { name "frame" tile 415 }

Are you quite sure that the frame name is called "frame"
If this is not correct it will not show up in game.

[RPD Guy]

Quote

Are you quite sure that the frame name is called "frame"

yep.



in "FRAMES" always remain 0.
even if I change the value to 9999, it go back to 0 again.

[Danukem]

Dude, you are missing the larger point of Commander's post. We can't tell if it's a code problem until you establish that the model is capable of showing up in game. Can you see the model when you place the tile in a map using mapster?

[RPD Guy]

Quote

Can you see the model when you place the tile in a map using mapster?

No. The model don't works in mapster and eduke32.
when I put the actor on mapster, only show the default sprite of the game (sign that says "USA")

[chicken]

If you zip your model and upload it here, I'll have a look at it when i get back home.

[RPD Guy]

Ok, I will post it.

[RPD Guy]

here is it.

Attached File(s)

•  Barricade.rar (187.27K)
  Number of downloads: 274

[chicken]

Your model is pretty much ok, except that it is rotated by 90 degrees.

Your defs had mistakes in them.

These were the ones you posted:
// Barricade (415)
model "highres/sprites/props/barricade.md2" {
scale 1 shade 0
detail { file "highres/detail/wood.png" detailscale 0.3 }
skin { pal 0 file "highres/sprites/props/barricade.png" }
frame { name "frame" tile 415 }

These are the new ones that should work:
// Barricade (415)
model "highres/sprites/props/barricade.md2" {
scale 1 shade 0
detail { file "highres/detail/wood.png" detailscale 0.3 }
skin { pal 0 file "highres/sprites/props/barricade.png" }
frame { name "frame000" tile 0415 }
}

A } was missing at the end, your framename was wrong and the tilenumber.

[The Commander]

Incorrect frame name as I first thought.
You dont need the zero in front of 415 though.

[Mblackwell]

For third person cameras (a bit late to the party I know) the best way I've found to control them is to map them to some kind of trigger within a sector (easiest is giving the sector a hitag). Then plot out your map so that you can guarantee the player will cross sectors in a way that lets you change the camera angle.

Example

gamevar TEMP 0 2
gamevar camera_HITAG 0 2
gamevar cur_CAMERA 0 1
gamevar cur_CAMERA_id -1 1

eventloadactor CAMERASPRITE
    getactor[THISACTOR].hitag camera_HITAG
    setactor[THISACTOR].hitag 0
enda

useractor notenemy CAMERASPRITE
    ifvarvare cur_CAMERA camera_HITAG
        setvarvar cur_CAMERA_id THISACTOR
enda


state changecamera // This would go in the APLAYER code
    getsector[THISACTOR].hitag TEMP
    ifvarg TEMP 2304 // to avoid doing anything with the HITAG unless it's outside of a normal range
        setvarvar cur_CAMERA TEMP
ends

event EVENT_DISPLAYROOMS
    
    ifvarn cur_CAMERA_id -1
    {
        getactor[cur_CAMERA_id].x camerax
        getactor[cur_CAMERA_id].y cameray
        getactor[cur_CAMERA_id].z cameraz        
        // Easiest to use EXTRA or SHADE for horiz. EXTRA being the easier of the two.
        // Personally I do some fancy math to make the camera's angle always face the
        // player horizontally and vertically.
        getactor[cur_CAMERA_id].ang cameraang        
        getactor[cur_CAMERA_id].extra camerahoriz        
        getactor[cur_CAMERA_id].sectnum camerasect
    }

endevent

Sure you need extra sectors to handle switching back and forth between cameras but you get a very controllable experience.

[RPD Guy]

tanks my friends! I'll test it.