Sauerbraten 2006-04-26 release!

by Aardappel_ on 04/26/2006 08:01, 106 messages, last message: 09/02/2006 04:19, 120859 views, last view: 05/05/2024 23:29

http://sourceforge.net/project/showfiles.php?group_id=102911

# tweaks & fixes to the capture gameplay mode
# added high resolution skyboxes, and some of the g_pack textures to the standard set
# fixed newent sending invalid attributes in coopedit mode
# models with a specularity of 0 now have a specialized shader ("nospecpvmodel") for faster drawing (mainly for vegetation)
# grenadelauncher damage increased to max 75
# multiplayer players & flag models will not be culled no matter how far away they are
# added waterfall effect for water material sides
# added pistol ammo (ent type "cartridges")
# added linearly-interpolated normals for lighting (controlled by "lerpangle", "lerpsubdiv", and "lerpsubdivsize" vars)
# added HW occlusion culling support (requires NV GeForce3-class hardware or better)
# height map mode. will hopefully allow for easier terrain editing.
# reduced overdraw dramatically
# reduced size of vertex data by using short instead of float
# removed ZYX order inconistency from math classes
# fixed lights placed outside the world not casting shadows
# fixed grenades being stopped by clip material and being stuck in walls
# made networking protocol use less bandwidth
# calclight now uses multi-sampling and adaptive sampling
# faster mapmodel ray intersects with spheretrees instead of bsp
# shorter fuse on grenades (2 seconds)
# fixed hudgun light computation related crash

   Board Index   

#78: Re: mapmodel bug found

by shadow,516 on 05/05/2006 01:50, refers to #77

Do you need any models for doors? I'd be happy to make some.

reply to this message

#79: Re: mapmodel bug found

by Aardappel_ on 05/05/2006 02:55, refers to #78

we have plenty for the moment.. have a look when we have the code for it out.

reply to this message

#80: Re: mapmodel bug found

by Aardappel_ on 05/05/2006 02:56, refers to #78

we have plenty for the moment.. have a look when we have the code for it out.

reply to this message

#81: Re: mapmodel bug found

by Pxtl on 05/05/2006 14:21, refers to #80

Aww nuts, doors are gonna be mapmodels instead of mobile Sauer geometry? I can see why that's easier to implement and whatnot, but I miss the heady days of Quake 2 mapping with the Q2-mapped trains, rotators, doors, and crushers.

reply to this message

#82: Re: mapmodel bug found

by CC_machine4 on 05/05/2006 21:59, refers to #81

yes, with only models you will be limited to the models you have rather than mapping it yourself...

reply to this message

#83: Re: Visual artifacts

by absinth on 05/06/2006 01:21, refers to #30

>You can just turn off occlusion with "/oqfrags 0".

isn't there also the possibility that this is an endian-related bug
(i'm just hoping there is a fix that doesn't cost so much performance)

reply to this message

#84: ..

by Max of S2D [Fr] on 05/06/2006 08:21

There are a bugs in the physics (i'll post an image, wait)

reply to this message

#85: ..

by Max of S2D [Fr] on 05/06/2006 08:24

http://www.myfilehut.com/userfiles/49517/physicbug.JPG

Just see :

-> The red arrows is what the game render
-> The green arrows in what you should make.

reply to this message

#86: Re: ..

by kurtis84 on 05/06/2006 17:17, refers to #85

I cannot really tell whats going on in that screenshot, but it is possible to make cube shapes that cannot be rendered properly....don't do that ;)

reply to this message

#87: Re: ..

by CC_machine4 on 05/06/2006 17:25, refers to #86

no he means that if you have a sloped cube and a non-sloped cube and you walk in between them (like this:

stand in there (the v is an arrow):

v
|--| /|
|__|/_|

then move out sideways and you move really fast.. see the arrows in max's pic!

reply to this message

#88: ..

by CC_machine4 on 05/06/2006 17:26

grr i mean like this: (v is an arrow)


|--|v
|--| /|
|__|/_|

reply to this message

#89: Re: ..

by MeatROme on 05/08/2006 11:09, refers to #58

I agree there should be some masterpass command and hope that security will be sufficient with the packet only sent to server (not distributed) unencrypted.

But I'm against the master getting another burden like forcing team-balancing onto his hands.

You'll still have the "I'm no MASTER-player, but I'm MASTER" situations on public servers where you can't masterpass your way to power and at the end of the day I'd rather see the user transparently made aware of all requirements.

I'd vote for a join-team screen - at least for CAPTURE mode.

Sadly the community has quite a broad spectrum of maturity, I've goggled at people joining/leaving teams without any hints to obviously balance teams and have fallen to spontaneous outbursts of Turret-Syndrome in case of players flood-chatting a server in "mastermode 2" because they "Wanna play!".

Maybe we should have the Master see the team setting even for spectators - like he now already sees the clients ID.

reply to this message

#90: Re: ..

by Passa on 05/08/2006 11:56, refers to #89

Maybe allow the master to force team changes?

reply to this message

#91: Re: mapmodel doors

by kurtis84 on 05/13/2006 15:45, refers to #91

I can build a much nicer looking mapmodel & skin, than what I could with geometry. I like the mapmodel doors, and I see no problem with it as long as mappers are free to add new doors as they see the need. I'm already thinking of how many other uses this entity will have, besides just being a door!

I cannot help but wonder though...will these doors block ocllusion culling?

reply to this message

#92: Re: mapmodel doors

by Aardappel_ on 05/13/2006 21:17, refers to #91

currently they won't necessarily, because we draw mapmodels last. I have been arguing with eihrul that we should draw close, large mapmodels earlier, so they can help in occlusion.

animated models will be IT for the moment, in terms of making doors etc. its what we need to make the FPS SP work well. If we need moving geometry for the RPG, maybe we'll add it, but for now there's no plans.

reply to this message

#93: Re: Visual artifacts

by absinth on 05/13/2006 23:13, refers to #30

>It would be kinda lame if we have to entirely disable occlusion for all ATI cards.

somehow the issue seems to be much less severe in CVS head than in the 2006-04-26 release....

reply to this message

#94: Re: mapmodel doors

by praxibetel-(damn_forum) on 05/14/2006 13:14, refers to #91

thats all well and good but im not a moddeller, and to make custom doors id have to model. how would i make a hatch that drops players in through the cealing in an SP map for example? id have to make a animated mapmodel just for that very map for that very purpose! i think that there should be animated mapmodels as doors but also have a system where the door is a material with a number corresponding to a trigger as i would imagine this would not be such a problem code-wise.

reply to this message

#95: Re: mapmodel doors

by kurtis84 on 05/14/2006 17:38, refers to #94

"thats all well and good but im not a moddeller,"

Looks like you have some learning to do.

reply to this message

#96: ..

by Max of S2D [Fr] on 05/14/2006 17:44

1) We can't have getmap/sendmap because some maps can be over 1 mb !
Is it the reason ?

2) Maybe Sauerbraten should have a dynamic menu with a list of all maps installed...

reply to this message

#97: ..

by makkE on 05/14/2006 17:48

Modelling a door is pretty easy and a perfect task to get into modelling.

reply to this message

   Board Index