ultimate_evil wrote:"Novelty" weapons such as crossbow, long bow, sword, maybe a (medeval) shield (only stops long bow, sword, etc). Maybe a colt .45 and a revolver (and a peper box revolver aswell).

Last time I checked Nexuiz wasn't a medieval game. If those kinds of weapons would exist then think of a mod, not standard Nexuiz. (Unless that's what you meant/suggested)

yeah, and a hairspray can in the right and a firelighter in the left hand, would be a great supplement for Nexuiz rofl wtf lol

I'm more for adding a LART to Nexuiz!

Maybe a flamethrower crylink...

torus wrote:Maybe a flamethrower crylink...

or a plasma fountain crylink

esteel wrote:I'm more for adding a LART to Nexuiz!

thats a nice idea ... a LART whip? But that fits more to the medieval games ...

Urmel... wrote:yeah, and a hairspray can in the right and a firelighter in the left hand, would be a great supplement for Nexuiz rofl wtf lol

hey, that was just a joke, referring to the foregoing post, right?

BusterDBK wrote:I like the ideas with the physics of projectiles launched at high speed (this may need testing and careful balancing to get done just right and not kill the fun)

The RBI servers now run at a mode which has Newtonian projectile speeds, but with an automatic aim adjuster - means, projectiles still go where your crosshair points to, but their speed is right relative to your own speed whenever possible. That is, if you fall down fast (bluesky for example), you can STILL shoot rockets downwards - but even if you move sideways, a rocket still goes in the direction of your crosshair and does not take over the direction you move to. So basically, you play as usual, from a player's perspective not much changes - except that rockets are now "faster" when you shoot them in your walking direction and "slower" when you walk backwards while shooting a rocket.

As it did not change the weapon balance significantly (the RL improved a bit and is now on one level with the Nex, which I consider a good thing), this change has good chances to go into Nexuiz 2.3. For fun, I also coded other projectile physics modes (including true Newtonian as Tribes uses, which however is very hard to play with, and for fun two buggy suggestions of simple formulas to include your own speed in the projectile speed). But see for yourself on the RBI servers. The difference should not be that large, but in CTF you can now chase the enemy flag carrier with a RL too.

Items (not brushes) that mappers could put into their maps would be a very big improvement. Things like trees of various types and sizes, vegitation, chairs and decorations for walls, "light boxes" (look like light going through fog). One map had modled trees, if this is opensource and can be made into an object that would be good.

Removal of vis and t-junction restrictions would also be good. You might have to work with the q3map2 developers to add a command line switch to send the new correct limit.

linuxkangaroo wrote:Items (not brushes) that mappers could put into their maps would be a very big improvement. Things like trees of various types and sizes, vegitation, chairs and decorations for walls, "light boxes" (look like light going through fog). One map had modled trees, if this is opensource and can be made into an object that would be good.

you mean models? I'd like to see maybe a zip of some models, but I'm not quite sure what you mean.

I mean like for commercial game editors you can just pick say plants, monsters, trees, chairs, other entities from the item menu (gtkradiant and the like) and place them in the map. That would be good for nexuiz (ease of use).

How does ingame map models work anyway? As we all know player models and weapons already eats fps. I never actually understood how models taking no space are done, for instance I remember in CS where models where introduced and Morfar explained that those things you can walk through were models, but never understood how they didn't drain fps.
If I knew how it worked I would have done such things long ago.

They drain fps. But they can be more detailed.

Something I was thinking about after watching some Quake demos.

Right now, the player is always vertical, and the weapon seems to move in a horizontal plane. If I remember correctly, when aiming up, a persron standing next to you cannot tell. Also, when the player is "in flight," he/she is also verticle- imo it would be cool if the models had an "in flight" animation, ala Quake 3, where the model leans into or away from the path of movement, which would look very cool at high speed (and more realistic). It would also help to judge where the enemy is attacking you, and how you should move to avoid it.

New animations would need to be made, which could come with updated models. Other than that I dont know what it would take.

Well as far as i understand it new animations are hard to do as the current models would require an closed source expensive program that noone of the current devs does have. Thats why we want to switch the model format in the future which would allow this. either like in quake3 with segmented models or by doing bone animation in CSCQ (client side quakeC) which will still take time and would require to redo the models or exchange them completly..

Which program?

ai wrote:How does ingame map models work anyway? As we all know player models and weapons already eats fps. I never actually understood how models taking no space are done, for instance I remember in CS where models where introduced and Morfar explained that those things you can walk through were models, but never understood how they didn't drain fps.
If I knew how it worked I would have done such things long ago.

Kinda depends on the mapper. In the most common use, decorative, its simply a pile of tris with a texture or two slaped on thats dumped into the BSP file at compiletime. The fps drain is usualy not noticable unless the model is very complexs/big or used extreamly many times in the same area. If one part of this kinda model is considers visible for a playre the whole thing is drawn (thats teh drawback). This kinda model is also vert lit.

A model can also be used teh same way "detail brushes" are used. That is its broken down into its indifidual faces, players and gunfire colide with its sufraces its faces can be light-mapped and only the visible ones are drawn.

Do note that is unlikely to the the poly count of player models that pull the framerate down. (try impule 13 or 14 with sv_cheats on, you can spawn a army of copies before the framerate takes a big hit in many cases)

Well it took over 30 "impulse 14" copies to half the fps on silvercity.. nice for midair mortar training

Only 30? hmm its a very open map =)

Anyways A Nicer HUD would go a long way towards making nexuiz better imo. Again CSQC needed to realise it, lets hope it arrives soon

On the vein of a better hud, I think that some kind of compass/minimap would be very usefull, especially for maze maps. In the hullabaloo of battle, I have on occasion wandered back into the enemy base (on one of the 70mm13 maps), because I didnt know where the hell I was going.

how can darsana be close source when it is based on a gpl'd engine??

It may be distributed as module or plugin. Separate from the engine. Then they could even sale darsana.

If they integrate the Engine direct into the darsana-files they would lose the right to use the DP engine, if they wouldn't release it under GPL too.

So: what way did they choose?

divVerent wrote:I'm against true Newtonian physics for weapons because it's just too hard to control. A major element is shooting while strafing - which would get pratically lost then.

However, jumping should use inertia (does it already? Need to try that on space-fun).

As for weapons, I had the idea of making weapon speed relative to the player, but adding an "auto adjustment" that makes the rocket still fly to the crosshair (so basically the speed is relative to the player, but the direction is absolute). However, that's not always possible to do, so in extreme cases, I'd give priority to the direction and use a wrong speed then. But it would certainly fix shooting rockets downwards while on the bluesky jump pad, or shooting rockets while running around fast on greatwall.

If you want to try "more realistic" projectile inertial, try playing Tribes 2. It's a bit less severe there because Tribes 2 has much slower players relative to the projectiles.

for the mortar it would be nice to simply add the player's current direction vector to the mortar projectile, it looks ugly if you boost forward, then shoot, and the shot falls behind you :S
for rockets too, but well, if rockets depend on the player's speed there's no way to boost off the ground with 2 rockets. Now you can fall off a building, shoot at the start, then shoot again when you pass your rocket, then wait for the light, and that second, laserjump, the rockets will give you a DAMN hard additional boost.

But well, boosting forward, and shooting `boosted' rockets would be cool enough too

I dunno.

Rockets now actually get part of the player's speed - it is now true Newtonian physics, but with adjusted aim direction. A bit complicated is the formula, but it works great - you almost don't notice it while playing, but rockets now just "work" when you are fast.

This has been really noticable on GreatWall, where the rockets used to lag behind you. Nice!

Yeah i already kinda miss that feature when playing CTF on older servers.. But it requires to relearn the rockettiming to a certain degree as you have to adjust your aiming for the new speed.

Voice chat = Teamspeak? Free to non commercial users......

Imo, all the graphics additives would be eye candy, but wouldn't really add a whole lot to gameplay. Alternate gravities would be ok, would allow fo rmore varied maps. A more accurate physics model would be nice. Nex needs one more weapon. I'm not sure what it is yet, but the crylink doesn't cut it. I think it has been upped it power, but its still a light hitter. The twin crosshair would be nice, but there is would not be easy to show where you should have shot to hit an enemy depending upon the weapon. The only way I could see that being effective is if the targeted played was within a certain are in the center of the screen (primary crosshair) , then the scondary crosshair would be placed along a vector from the true screen center along the angle of the targeted vector with a magnitude calculated from a ray cast from the center of the screen to the targeted player. So, you have a constant scan over an area and getting the magnitude of a player moving through said area. It wouldn't work well targeting groups of players, and the secondary crosshair also would have to take into account the weapon type.
On another topic, the Open Dyanics Engine piqued my interest on "ragdoll" physics, as did verlet integration. However, either way would alter the collision detection as it stands now.
Personally, I feel the best thing to do to make nex better, is improving and better balancing the maps. Some need no tweaking, others need overhauls. The DM maps are good, but some CTF maps could use some work. I don't like when I hit my head on a brush that's being used for a light. Let me pass through them so I can keep my speed instead of just running side to side while I get pelted with a machine gun. Making large open expanses is cool, but stuffing nexguns into that map gives the advantage to the nexgun carrier. Anyways, before I rant more, thanks for the forum.