ZEQ2 Lite

Thursday, July 25, 2013

On the same note, re-added team deathmatch as an option when creating a server.

I'm opened to suggestion.

Thursday, July 25, 2013

SAMCROSS wrote : On the same note, re-added team deathmatch as an option when creating a server.

I'm opened to suggestion.

good work

Thursday, July 25, 2013

wow,death match server.. I like that when I play call of duty

Thursday, July 25, 2013

GREAT UPDATES!! Wink

Technically they are reverts, not updates. Samcross hasn't coding anything new (yet). He's simply copy/pasting things from the newer revisions.

Friday, July 26, 2013

Zeth wrote :

GREAT UPDATES!! Wink

Technically they are reverts, not updates. Samcross hasn't coding anything new (yet). He's simply copy/pasting things from the newer revisions.

you are right..even if these reverts to me are more like updates for the stable revision with the best things of the latest build..

Friday, July 26, 2013

True that, but Zeth is right. I'll see if I can pull off something new sometime

Either way, I'm upload a video right now for those intersted :

http://youtu.be/_lG7D9V93vM

Friday, July 26, 2013

SAMCROSS wrote : True that, but Zeth is right. I'll see if I can pull off something new sometime

Either way, I'm upload a video right now for those intersted :

http://youtu.be/_lG7D9V93vM

keep it up brother

Friday, July 26, 2013

brother just add mêlée system of revision 1536 (with some changes if you can) in latest revision 1885. then revision 1885 can be pretty playable if you are able to fix some bugs (many are fixed already) too then may be it will be announced as new stable/playable revision. only you can do this work. I was think to do this but I can't download all 3 folder. but keep it up remember my thinking you can create a new revision.

Friday, July 26, 2013

SparkingVegito wrote : brother just add mêlée system of revision 1536 (with some changes if you can) in latest revision 1885. then revision 1885 can be pretty playable if you are able to fix some bugs (many are fixed already) too then may be it will be announced as new stable/playable revision. only you can do this work. I was think to do this but I can't download all 3 folder. but keep it up remember my thinking you can create a new revision.

also can anybody make a gameplay vid of the revision?because my pc can't run ZEQ2

Saturday, July 27, 2013

SAMCROSS wrote :

ivanhoeGT wrote :

You mean, when locking on ?

I don't know how to explain exactly..

And I don't know how to understand it X)

Anyways, in the current state of things, locking on only zooms out the camera of 50%

Here is how it looks with default camera settings.

You're on to something. I never understood why lock-on kept the camera so close to the player.

Locking on in revision 1536 can sometimes feel like a double edged sword. If I fight/ lock-on with my camera set "Locked behind player" it is almost improbable to get a view of my surroundings.

Then when my camera is set to "Delay behind player" I can see everything around me just fine because the camera zooms out, but then when I fight/ lock-on, the camera can come off my opponent when I move to anywhere but forward.

Maybe you could look into a compromise between the two? Or better yet, could you show me a thing or two?

Saturday, July 27, 2013

You're on to something. I never understood why lock-on kept the camera so close to the player.

To highlight the mêlée itself. It's still not as robust or as close as it should be in reflection to how the series handled the camera, however.

Locking on in revision 1536 can sometimes feel like a double edged sword. If I fight/ lock-on with my camera set "Locked behind player" it is almost improbable to get a view of my surroundings.

That was intentional. When focused (locked on) to a single target, you become susceptible to outside factors.

Then when my camera is set to "Delay behind player" I can see everything around me just fine because the camera zooms out, but then when I fight/ lock-on, the camera can come off my opponent when I move to anywhere but forward.

The "Delay behind camera" mode was a copy/paste Dave did from another mod. It always was extremely jerky and highly unusable.

Saturday, July 27, 2013

Zeth wrote :

You're on to something. I never understood why lock-on kept the camera so close to the player.

To highlight the mêlée itself. It's still not as robust or as close as it should be in reflection to how the series handled the camera, however.

Locking on in revision 1536 can sometimes feel like a double edged sword. If I fight/ lock-on with my camera set "Locked behind player" it is almost improbable to get a view of my surroundings.

That was intentional. When focused (locked on) to a single target, you become susceptible to outside factors.

Then when my camera is set to "Delay behind player" I can see everything around me just fine because the camera zooms out, but then when I fight/ lock-on, the camera can come off my opponent when I move to anywhere but forward.

The "Delay behind camera" mode was a copy/paste Dave did from another mod. It always was extremely jerky and highly unusable.

I can't think of gaming without "Delay behind camera"...
its good that its there.by the way why doesn t revision 1885 have "Delay behind camera"?

Saturday, July 27, 2013

I can't think of gaming without "Delay behind camera"...
its good that its there.by the way why doesn t revision 1885 have "Delay behind camera"?

Camera system was gutted pending a rewrite with proper camera modes. Dave finished a tag-based camera, but the other modes were not started.

Saturday, July 27, 2013

To highlight the mêlée itself. It's still not as robust or as close as it should be in reflection to how the series handled the camera, however.

By this, are you referring to the dynamic camera angles that are seen in the anime or does this refer to the nature of the actual skirmishes themselves?

That was intentional. When focused (locked on) to a single target, you become susceptible to outside factors.

Yes, I had a feeling that this is what you guys aimed to achieve when the code was written for the camera, however even if less susceptible to oncoming attacks, a zoomed out camera may provide a more appealing view of the battle.

The "Delay behind camera" mode was a copy/paste Dave did from another mod. It always was extremely jerky and highly unusable.

So is Dave currently the only one (besides you of course) who possesses the knowledge on how to edit camera specified codes?

Saturday, July 27, 2013

By this, are you referring to the dynamic camera angles that are seen in the anime or does this refer to the nature of the actual skirmishes themselves?

Both. The angles used in the series during sequence and speed mêlée portions were almost exclusively up-close with both characters fully filling the screen (sometimes only their torsos visible).

Yes, I had a feeling that this is what you guys aimed to achieve when the code was written for the camera, however even if less susceptible to oncoming attacks, a zoomed out camera may provide a more appealing view of the battle.

How would a zoomed out camera be more appealing? You'd see next to nothing of the encounter. You won't be able to see the impact expressions from punches/kicks, the subtlety of motion lines, nor even be able to ascertain your opponents actions very clearly based on their animation state. More zoomed out may give you more strategic awareness of your scene on a whole, but it'd be MUCH less detail/information concerning your present exchange (and much less accurate to boot).

So is Dave currently the only one (besides you of course) who possesses the knowledge on how to edit camera specified codes?

Of the developers that have contributed to ZEQ2-lite so far? Yes, Dave and I have the most knowledge in dealing with those systems. Some game source code was done by ScifiSpirit if I'm not mistaken and SonGolias had done some bigger scope input/engine systems relating to additional features, but of the few involved even fewer muddled about in the client game (cgame) code.

Sunday, July 28, 2013

How would a zoomed out camera be more appealing? You'd see next to nothing of the encounter. You won't be able to see the impact expressions from punches/kicks, the subtlety of motion lines, nor even be able to ascertain your opponents actions very clearly based on their animation state. More zoomed out may give you more strategic awareness of your scene on a whole, but it'd be MUCH less detail/information concerning your present exchange (and much less accurate to boot).

My reply was hasty. What I meant to say was a free flowing camera rather than zoomed out view. To be more specific, a camera that shows various views of the fight (which include some zoomed out views) whether or not at the player's command. I really have no grievances with the camera being as close as it is, but rather the fact that when fixed upon my character's back the fights feel slow paced and static.

I've taken a look at the latest revision and I see the difference between it and Rev 1536 when ki boosting or soaring but during a fight all of this fades.

Of the developers that have contributed to ZEQ2-lite so far? Yes, Dave and I have the most knowledge in dealing with those systems. Some game source code was done by ScifiSpirit if I'm not mistaken and SonGolias had done some bigger scope input/engine systems relating to additional features, but of the few involved even fewer muddled about in the client game (cgame) code.

Well I guess I'll head to the learning forum then. The reason I asked in the first place is solely for expanding my knowledge and possibly contributing something worth wile to the project. I greatly improved upon my capabilities in 3DS max in my few years using these forums and I'd like to take it a step further and learn to code.

Sunday, July 28, 2013

My reply was hasty. What I meant to say was a free flowing camera rather than zoomed out view. To be more specific, a camera that shows various views of the fight (which include some zoomed out views) whether or not at the player's command. I really have no grievances with the camera being as close as it is, but rather the fact that when fixed upon my character's back the fights feel slow paced and static.

Yes. The camera was intended to move and not remain static. It was simply never fully implemented. Technically, if setup correctly, Dave's tag-based camera could allow for this (partially) by adjusting view differences between speed mêlée and different mêlée attacks.

I've taken a look at the latest revision and I see the difference between it and Rev 1536 when ki boosting or soaring but during a fight all of this fades.

I believe cg_view.c is where you'll want to look. This is where most of the camera functionality is at.

Well I guess I'll head to the learning forum then. The reason I asked in the first place is solely for expanding my knowledge and possibly contributing something worth wile to the project. I greatly improved upon my capabilities in 3DS max in my few years using these forums and I'd like to take it a step further and learn to code.

The problem most people have with coding is that, unlike doing other kinds of development, there is no step by step process. Unless you are copying an existing design, it's not a mechanical process and you cannot just repeat a series of instructions to achieve a result. Every bit of fresh code you write will require understanding of C language types/capabilities and Quake 3 game/engine functions. It's a creative endevor where result isn't as important as the process of getting there.

There are a thousand ways to write code that does the exact same thing in the end. Your only reference is your imagination.

Monday, July 29, 2013

The problem most people have with coding is that, unlike doing other kinds of development, there is no step by step process. Unless you are copying an existing design, it's not a mechanical process and you cannot just repeat a series of instructions to achieve a result. Every bit of fresh code you write will require understanding of C language types/capabilities and Quake 3 game/engine functions. It's a creative endevor where result isn't as important as the process of getting there.

There are a thousand ways to write code that does the exact same thing in the end. Your only reference is your imagination.

I see that I have a longer way to go then I initially perceived. If I do manage to better my understanding you can bet that you will see great contributions to ZEQ2-lite from me.