• Join Us |
  • |
  • Sign in with:

Quake3 v116i Release

by Steve Gibson, Feb 19, 2000 12:43am PST
Related Topics – E3, id software, Quake 3 Arena

Just when you thought you had the latest pre-beta alpha patch of Quake3 another one comes out. Here is the .plan update from Robert Duffy over at id Software on the release:

Q3A 1.16i Beta is now on our ftp site. This is a small executable only patch that enhances security. It is available in three flavors, Win32 ( a .zip file ), Linux ( a .gz ) and Macintosh ( a self extracting archive ).
Make sure you have the 116h release as well. Then grab the 116i release here: Win32, Linux, or Mac. Thanks to PlanetQuake for the initial heads up.




Comments

253 Threads | 253 Comments














  • Heheheh...

    Here\'s a bit of a follow up to that link I posted earlier on the 64MB GeForce from Dell. Sharkey got a preview of the things:

    \"Apparently, Dell will have a window of at least a month before joined by the competition (Guillemot, ASUS, LeadTek et al) in offering the enhanced board. Dell representatives told Sharky Extreme that their board will carry the \'reference design\' tag usually reserved for NVIDIA\'s designs. On a final note, Dell is not only aware of the immanent release of NV15 but is already working with NVIDIA on a similar NV15 \"plus\" card. Scary.\"

  • I\'ve been thinking on this whole issue about the way sv_pure is supposed to be working now and I think there are several paths that could provide a balance in the ability to provide model and skin choice that would both preserve pure functionality and ease the burden on players who use custom models and/or skins.

    The first idea, would be to retain the functionality introduced with the previous point release: If your model/skin is not on the pure server, then you are forced back to the default model/skin, unless that too is not on the server, then you would get kicked.

    Second, would be to give the user the ability to define a \"pure\" player model or skin, in addition to the \"standard\" one, so a player could connect to a pure server without having to reconfigure each time AND have the benefit of choosing an alternate configuration.

    Third, would be to allow the client to display whatever personal model/skin the player chose, while sending the default model/skin information to the server, if the specific model/skin is not installed on the server. I can\'t think of a way that this could be used to violate the intent of the pure server, since the personal skin choice, at best, give the individual player only a psychological advantage. The only other factor that would need to be considered would be to make sure that if the default model/skin was not on the server, that play would still be disallowed.

    Finally, in regard to HUD modifications, such as SHUD. I\'m afraid my knowledge of how the HUD interacts with the rest of the game engine is a bit limited, so I may not make any sense... My thought is to force a HUD to be developed within a specific scope within the game engine environment. This scope would eliminate the ability to \"see\" any variable that was not \"safe\" for the client to have access to. In object-oriented design, this would be akin to making the \"dangerous\" global variables private to the main game object, while exposing the \"safe\" variables to the scope of the HUD.

    By restricting the scope of what a HUD could have access to, this would open up the development of a HUD as a purely client-side change that would have no chance of allowing any cheats to occur, much like you can change game settings for screen size and gamma (though some might consider the alteration of gamma on dark maps cheating... <sigh>) without being blocked from a pure server. Any HUD that was developed outside of the provided API would obviously be disallowed on a pure server, unless the HUD was also installed. This would allow developments of HUDs like SHUD, which display accuracy statistics and award accumulation both during game play and on the score board. Or, it would allow the development of HUDs that use different fonts, different placements of information, or provide a different style of score board altogether, all without impacting the protection from cheating.

    Right now, it seems that all the emphasis is on stopping the cheaters, with little on easing the burden to players who enjoy using non-cheating client-side mods like alternate models or skins.

    Id has put a lot of effort into making Q3A accessible to the mod community and in providing information and advice to mod authors. By easing the burden of using custom, non-cheat mods, it will make the fruits of the efforts of those whom Id has fostered and spent a great deal of time to provide assistance to, more easily used by the very players who are supposed to benefit from them.

    I cannot see how effort made in this regard will be anything but a benefit to the popularity of Quake 3 Arena.




  • [BC]Ominous, this goes back to #159, you can tell someone has a skin/model that you don\'t have when they show up as a blank gray square on the level load. Once in the game, they show up as the default model.

    I\'ve never used forcemodel, so I have no idea how they would show at map load time.

    I can\'t really say that load time or hitching really effect my score at all. I\'m inconsistant at best and no where near your claimed skill level.

    The beauty of the game and the variety of models and skins is one of the things that I find enjoyable, aside from the fun of the competition.