| | Zdaemon passe en 1.10b01! | |
| | Auteur | Message |
---|
Invité Invité
| Sujet: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 14:10 | |
| Zdaemon passe en 1.10b01 en tant que cadeau de noel! Certes, c'est une bêta et une rushed release, mais pas mal de choses ont été updated, avec des nouvelles features! /!\ Voir en bas du thread pour fixer les 2 problèmes les plus courants de cette build /!\ /!\ LES DEMOS NE FONCTIONNENT PLUS DU COTE DU CLIENT, en attendant la 1.10 finale!! /!\ Voici le changelog complet: - Changelog:
- Code:
-
1. Implemented server-side demos (SSD). The server can automatically generate and publish demos of all games. The recording of demos is controlled via the "ssd_record" CVAR (0=off, 1=record when one player joins the game, 2=record when one player connects to the server); the demos are saved in the directory "server_demos" directly underneath the server directory. The server can also "publish" the demos via an embedded mini web server. This is controlled via the "ssd_publish" CVAR (1=on, 0=off). When it's enabled, one can browse/fetch the demos by pointing a web browser to the URL: http://SERVER_IP:PORT/demos/
The server can automatically cleanup the directory by removing demos older than a given number of days; this is controlled from the "ssd_keepdays" CVAR: it defaults to 7 (one week); a value of zero disables this cleanup, but you better have another way of removing them as they will consume more and more of your disk space.
There is also an "ssd_minsecs" CVAR that determines the minimum number of seconds for a demo's duration. If a demo is shorter than that minimum, then it will not be stored at all. The default value is 30 (seconds).
There are cases where the server admin may prefer to avoid the above described publishing and process the demos in some other way (for example, move them to other directories, send them to other hosts, etc). In that case, he can use the "ssd_process" CVAR; it's a string containing a command will be issued when the demo is ready. If that command is non-empty, then the zserv will issue that command and will NOT do anything more regarding the demo (ie., it will not move it, delete it, or touch it in any way); from that point on, the demo becomes the responsibility of the specified command.
When the server admin decides to process the demos in some other way, he may want to publish them at some other URL, which he can specify by using the "ssd_url" CVAR. It's a simple string and it overrides the above described default URL. There are 2 special escape sequences that can be used in the URL: $a will be replaced by the IP address of the server and $p will be replaced by the listening port.
Furthermore, the server admin may wish to specify some unique name to be displayed in the demo download page. This is done via the "http_title" CVAR.
Finally there is an "ssd_voice" CVAR (1=on, 0=off) that determines whether voice data will be stored in demos or not. Defaults to ON.
2. Implemented WAD downloads directly from the server. It's controlled from the "wad_downloads" CVAR (1=on, 0=off). When the downloads are enabled, the launcher will be notified about it and it will use the server's download page: http://SERVER_IP:PORT/wads/ to fetch any missing WADs. The WADs are auto-compressed into ZIP files and they're cached in the "cache" directory for the life of the server (ie., once a given WAD has been compressed into ZIP, it will never be re-compressed while the server is still running).
3. Implemented throttling of WAD and demo downloads; it's controlled via the "max_download_kbps" CVAR. A positive value indicates the maximum download rate in kilo-bits per second; zero or negative values disable the throttling. Defaults to zero. There is also a related CVAR called "max_transfers" which controls the maximum number of concurrent downloads allowed; requests that will result in exceeding that limit are ignored. Defaults to 10.
4. Extension of the sv_voice_chat server CVAR to recognize a value of "3" which will stand for "commentary mode". This mode works as follows:
Team modes ---------- Chat is in-team as usual, but there is also a "commentators" CVAR that contains a space-delimited list of nicks allowed to speak *from the non-playing teams*. If the list is empty, then everyone can speak; if not, only the specified nick(s) can talk. Suppose for example that maxteams=2; in that case 2 teams are non-playing. Spectators would get into the non-playing teams; one or more of those spectators would be designated as a commentator and that person would be heard only by whoever is on his team. In this way you could even have 2 commentary channels (green and white): imagine for example english commentary on one channel, spanish on the other.
Non-team modes -------------- Commentary mode results in a "spectator-separated chat". If the mode is coop/survival, then the players talk only to each other (and that's one conceptual channel) and spectators talk only to each other (that's a second channel). If it's DM, then there is no player channel (unless it's a private server). There is also a "commentators" CVAR containing a space-delimited list of nicks allowed to speak from the spectator channel. If the list is empty, it means that anyone can talk.
No changes are needed to the "voice_chat" CVAR on the client. People will be able to hear the commentators simply by joining the proper team (in team modes) and remaining a spectator.
There are also 3 new server commands to facilitate the mani- pulation of the "commentators" CVAR: commentators_clear commentators_add nick [nick ...] commentators_remove nick [nick ...]
5. Added a "refreshbans" server command that asks the server to reload the master and server-provider ban lists.
6. Added new SetActivator and SetActivatorToTarget acs functions.
7. Fixed a crash on e2m9 intermission.
8. Added some spectator CCMDs that are useful for video recording. spec_togglenoclip: allows specs to enable noclip (it is needed in some maps that teleport players only when they use a switch). spec_warp: warp the spec to location x, y, z and set pitch and angle (the input values are on the same scale as the idmypos output). spec_follow: make the spectator view follow a player. spec_follow_params: TODO spec_stopfollow: stop following a player.
9. Fixed a client crash when using combinations of higher resolutions, SSAA and zooming.
10. Resolved a weapon/ammo desync in demos from the recorder's POV.
11. Added a new dmflag (DF_MULTIKEYBINDS = 536870912) and an associated CVAR (sv_multikeybinds). It determines whether aliases/bindings can trigger more than one key at the same time (typically used for SR50 automation).
12. The dmflag2 "DF2_OS_JUMP" (262144) is not needed any more. The classic movement it implies will be always used except when when mlook + jump + no OS_BLAST is set (rjump physics).
13. Implemented UT-style double jumping: activates when you jump a second time near the apex of the first jump and gives you an extra boost. It's activated via a new dmflag (DF_DBL_JUMP = 536870912), or an associated CVAR (sv_dbljump).
14. Implemented true widescreen (16:9) support; when enabled, it expands the field of view to 106 (rather than 90) degrees in the horizontal direction and is suitable for most of today's monitors. Fullscreen (4:3) as opposed to Widescreen (16:9) view is controlled via a dmflag2 (DF2_FULLSCREEN = 262144) or an associated CVAR (sv_fullscreen). There are also very flexible arrangements for using widescreen on a fullscreen video mode: you can select between letterboxing vs. stretching and you can also select the desired amount of letterboxing/stretching.
15. Added a client CVAR called "demo_ar". It controls the desired aspect ratio while playing back demos. It can assume a value of zero (in which case the demo plays back at the "native" aspect ratio), one (in that case the demo plays back as widescreen), or two (in that case the demo plays back as fullscreen).
16. In some instances, missiles that exploded on the server would appear as live on the client: fixed.
17. Fixed a case where doors could move below their initial height in sectors that also had a lift in them (See liftdoortest2.wad). thx to rhinoduck, Krawa and Evolution for reporting and testing work.
18. Added the StrParam ACS function. It allows creating temporary ACS strings on the fly.
19. Added lineid arguments to Polyobj_StartLine and Polyobj_ExplicitLine line specials.
20. Protocol improvements to help the hosting of home servers when port forwarding or upnp are not properly configured.
21. Added Support for the "map00 lobby convention" in WADs. It's controlled via the "lobby" CVAR. When that CVAR is 1, it activates the "lobby mode": 1. The server auto-switches to map00 when both players leave. 2. The server auto-switches to map00 when a map ends. 3. All maps will always be available for voting, no matter the value of sv_vote_map_skip. 4. There will be no time limit on map00. 5. Dynamic bots (minplayers) are excluded from map00.
For this mode to get activated, you need to: a. Set the "lobby" CVAR to a value of 1. b. map00 should exist in the loaded WADs. c. Define a maplist on the server. d. Include map00 into the maplist.
22. Multiple fixes for client and server crashes.
23. Fixed monster railgun shots not being visible online.
24. Added two new command line parameters -rand_color and -rand_voice to randomize the player's color/voice.
25. Enabled loading of font lumps that have kerning specified.
26. Remember the value of the idmypos CVAR on the client.
27. Make color representation of health depend on dehacked start health.
28. Allow maxplayers=1 in coop/survival.
29. Proper tid=0 handling for Thing_Damage special.
30. Fixed the spectator teleports and improved the player teleports as recorded in demos. 31. Transfer TID when morphing an actor.
32. Fixed nightmare monster respawns; they should not spawn into players any longer.
33. New server CVAR sv_acs_world_exit. When enabled then ASC OPEN scripts can exit a map even when sv_noexit is set. Beware that the activator in other scripts that use a delay can become NULL before exit is called, thus resulting in a mistaken 'world' exit (e.g., see DeathBall).
34. Fixed a problem with split demos and inventory/ammo/weapons in coop/survival.
35. Fixed a crash related to long cvar names in cvar overrides.
36. Restored vanilla barrel height.
37. Added new client CVAR cl_showeventmsg. When disabled the event messages (flag taken, etc.) will not be printed to screen. Event sounds will still play.
38. Added new client CVAR cl_showdeadscore. It controls whether the scoreboard is automatically drawn for dead players.
39. Added the following read-only CVARs on the client: get_x, get_y, get_z to get the x, y, z position (fixed-point) of the display- player; get_pitch, get_yaw, to get the pitch and angle (truncated) of the displayplayer; get_consoleplayer, get_displayplayer to get the consoleplayer and displayplayer indices respectively.
40. Allow old thrust method (sv_newthrust) to operate on TIDs. The ACS function declaration is: ThrustThing (angle, force, nolimit, tid) old ThrustThing (angle, force, dummy, tid) Nolimit does nothing when old thrust is enabled for compatibility reasons. 41. Windows client and Linux server crashes will generate a dump file that can help to fix the crash. To make it work in Linux you need to have GDB installed. At any rate, if your server or client crashes, you can submit the dump file so we can fix the bug.
42. Added a new dmflag2 (DF2_BRIGHTSKINS = 1073741824) and an associated CVAR (sv_brightskins). It determines whether player skins are brighter/more visible from a distance than normal.
43. Fixed skin scaling to work online.
44. Fix color overrides to be not applied when spectating a game.
45. Fixed a ZDoom bug that sometimes caused the BFG to misfire right after pickup.
46. New "motd_duration" CVAR controlling how long the MOTD stays on screen. Default value = 15 (seconds). It can range between 1 and 300; a zero value blocks the display of the MOTD completely.
47. Two new commands to re-display / kill the MOTD: "showmotd" and "killmotd".
48. The item selection (heretic/hexen) should be shown while spying or demo viewing.
49. Fixed the Windows 8 problems by replacing DirectDraw framebuffer with Direct3D framebuffer using the D3D device backbuffer. This also means that now 3rd party programs, like Steam Overlay UI, are working. 50. Better multiple monitor support and implementing it as a menu item to the video options.
51. Improved a bit the handling on the server of uneven packet delivery from the clients.
52. Added a new dmflag (DF3_INSTATELE = 1) and an associated CVAR (sv_instatele). When enabled, it removes the half-second freeze, and preserves the player speed and angle on normal (non-silent) teleports.
53. Switched the timestamps in all server logs to the standard ISO format (YYYY-MM-DD HH:MM:SS). Furthermore, the frag and weapon logs will contain timestamps just like all other logs.
54. New "limited" log on the server; it's similar to the general one, but it does not display the IPs of connecting players, rcon commands and non-public messages. It's enabled by the -llog cmd. line switch.
55. Implemented log downloading in the zserv; it's controlled from the "log_publish" CVAR; when it's turned on, logs can be fetched from: http://SERVER_IP:PORT/logs/ Only "non-sensitive" logs are available through this mechanism: CTF, frag, weapon and limited logs. There is also a restriction in the age of logs: current logs are NOT available for download: only older logs are. The max. age of the logs that will be available for download is controlled via the "log_publish_maxage" CVAR; it's an integer that can range from 1 up to 30 (days); defaults to 7.
56. The railgun has been extended to work as a standard weapon in Heretic and Hexen; it uses Hellstaff ammo (lesser and greater runes) in Heretic and blue mana in Hexen. both cases it consumes 2 units of ammo per shot and gives 20 units of ammo (ie., 10 shots) on pickup. The instagib dmflag has also been extended to work properly in Heretic and Hexen.
57. Added the CLIENTSIDE flag to dehacked; objects having that flag move independently on the client (no bandwidth is consumed for their movement).
58. New "joinable_teams" server CVAR; it's a bitmask indicating which teams are allowed to join (1=red, 2=blue, 4=green, 8=white). It is automatically reset whenever maxteams is set; it can assume a value between 1 (only red can join) and 15 (all 4 teams can join). Note that team joining is STILL SUBJECT TO "maxteams"; if for example you want only red and green to join, you will set maxteams to 3 (or 4) and joinable_teams to 1+4 = 5. If you set maxteams to 2 and joinable_teams to 5, then only red will be able to join.
59. New "sv_info_caching" server CVAR: it determines the amount of caching that the zserv will apply to the info sent to browsers. It's an integer value expressed in seconds. Defaults to 3. It can range from 1 (very little caching) to 15 (very large caching).
60. Increased the client limit to 100.
61. Implemented uncapped FPS; it's controlled from the "vid_capped_fps" client CVAR; when the CVAR is on, the client uses 35 FPS (as in classic DOOM); when it's off (the default value), the client uses as many FPS as your computer can handle, SUBJECT TO your monitor's limitations (vsync). If for example you have a strong CPU but a low-end monitor, then you will probably see 60 FPS (the refresh rate of most low-end monitors); if your monitor is fancier, you will see a higher FPS value. The implementation is correct, in that this setting does NOT affect your keyboard or mouse handling in any way.
62. The "limitpainelemental" CVAR is replaced by the "maxlostsouls" CVAR (which defaults to 21); it gives you better control over the amount of lost souls you want spawned.
63. Spectator pitch is now recorded in demos (for the recording player of course).
64. Improved the robustness of the old CTF convention with respect to packet loss.
65. Enabled the demo tool to handle demos over 42MB.
66. Allow passing high CVAR values (eg. 1e+006) with the Puke CCMD. Make it also possible to properly return such high CVAR values.
67. sv_aircontrol changes should get propagated from server to client.
68. A value of 2 for the restartemptymap CVAR will advance to the next map.
69. Fixed a non-switching-out bug in the railgun when running out of ammo.
70. Fixed a problem in using the A_FireCustomRailgun in dehacked patches.
71. Made the ID numbers of Hudmessages serve as priority for the messages. Hudmessages with lower IDs will appear in front of those with higher IDs.
72. More work on hexen has been done; the HUD, as well as most artifacts, armor, weapons, monsters, player classes are *starting* to work; don't assume though that they are "done"; there is still a long road ahead for that.
73. Barrels should be able to activate lines.
74. Fixed the Hexen main menu (it should show minotaurs instead of skulls). 75. Fixed a problem where a weapon appeared to fire while no projectiles were spawned when fire was kept pressed during a weapon pickup and PWO was enabled. -----------------------------------------------------------------------
Pour ma part, une grande part des choses est faite, MAIS! le netcode n'a pas été fixé (les high pingers sont toujours autant intouchables qu'avant malgré quelques optimisations), et le server demorecording est volontairement désactivé. Mais à part ca, tout va bien! (Ah, je regrette que pour Windows, ZSL soit retiré au détriment de Zdaemon Server Wizard...) Niveau serveurs, tous les BaseQ.fr sont désormais en 1.10, avec un changement de politique des serveurs pour favoriser l'équilibrage des joueurs (tous au même niveau)! HOHOHO! Joyeux noel d'ailleurs
Dernière édition par Ch0wW le Mer 25 Déc 2013, 20:15, édité 6 fois |
| | | franckFRAG Modérateur du chaos
Nombre de messages : 8769 Age : 34 Localisation : Orionis - Map11 Clan(s) : ( Aucun )
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 14:41 | |
| Ah je ne m'y attendais pas c'est cool ^^ | |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 14:45 | |
| J'ai appris que la commande ssd_record est intentionnellement mise à 0.
POURQUOI DANS CE CAS, ils le marquent pas dans leur changelog que ca a été intentionnellement supprimé? Ca aurait rendu ma nuit (blanche) plus tranquille face à ce problème! |
| | | franckFRAG Modérateur du chaos
Nombre de messages : 8769 Age : 34 Localisation : Orionis - Map11 Clan(s) : ( Aucun )
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 14:51 | |
| - Sur le blog de Zdaemon:
Demo recording is not supported in the 1.10 beta release because of potential netcode protocol changes.
| |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 14:53 | |
| Ils ne l'ont pas mis cette nuit (c'est une rushed release, la ils ajoutent des nouveaux trucs au fur et à mesure :/). Au moins ils auraient pu le mettre dans le changelog... |
| | | [WH]-Wilou84 Rêveur perpétuel
Nombre de messages : 30876 Age : 39 Localisation : Paris, France
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 15:08 | |
| Merci pour l'info !
Ca passe en section News. _________________ Un peuple qui élit des corrompus, des renégats, des imposteurs, des voleurs et des traîtres n'est pas victime ! Il est complice. George Orwell
| |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 17:51 | |
| Très mauvaise nouvelle: Zdaemon ne SUPPORTE PLUS DU TOUT les démos, que ca soit du côté du client, ou du serveur. (en attendant la 1.10 finale)
Je rajoute ca au premier post. |
| | | franckFRAG Modérateur du chaos
Nombre de messages : 8769 Age : 34 Localisation : Orionis - Map11 Clan(s) : ( Aucun )
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 18:02 | |
| Ils vont bien finir par trouver une solution | |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 18:04 | |
| C'est surtout à cause d'une possibilité de changement de protocole... - Talk a écrit:
14:17 <[BaseQ]Ch0wW> seems like demorecording is broken too, serverside 14:17 demo recording is not broken 14:17 <[XV]Evolution> demo recording is disabled during beta phase 14:17 this is a beta, it is disabled currently 14:17 you otherwise are left with aload of non-functional demos when the protocol changes 14:17 <[BaseQ]Ch0wW> aswell as log_publishing? 14:17 pre-110 demos do function EDIT: Pour ceux qui aiment pas l'écran en 16:9 super petit, pensez à ajouter ca dans la console: # pour remettre les FPS à 35 - Code:
-
vid_capped_fps "1" pour remettre l'écran à 100% en 4:3 . - Code:
-
r_letterbox_percent "0" |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 20:15 | |
| vid_capped_fps "0"
Enfin <3 |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 20:17 | |
| - Datacore85 a écrit:
- vid_capped_fps "0"
Enfin <3 Tu repasseras vite à 1 quand tu verras que la souris déconne bien au niveau de horizontale - Zdaemon changelog a écrit:
- 61. Implemented uncapped FPS; it's controlled from the "vid_capped_fps"
client CVAR; when the CVAR is on, the client uses 35 FPS (as in classic DOOM); when it's off (the default value), the client uses as many FPS as your computer can handle, SUBJECT TO your monitor's limitations (vsync). If for example you have a strong CPU but a low-end monitor, then you will probably see 60 FPS (the refresh rate of most low-end monitors); if your monitor is fancier, you will see a higher FPS value. The implementation is correct, in that this setting does NOT affect your keyboard or mouse handling in any way. En gros, ils "clament" le fait que la souris est parfaitement implémentée dans ce mode ; or, beaucoup se plaignent du problème de la souris qui freeze pendant 1/2 frames. |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Mer 25 Déc 2013, 21:06 | |
| Ils fixeront surement ça, c'est bien de partir dans cette direction en tout cas on a un peu plus de choix entre OS et NS |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Jeu 26 Déc 2013, 00:58 | |
| - Datacore85 a écrit:
- Ils fixeront surement ça, c'est bien de partir dans cette direction en tout cas on a un peu plus de choix entre OS et NS
Exact, mais bon, le fait d'avoir eu le 16:9 à cassé pas mal de joueurs, et les developpeurs ne veulent pas réagir "positivement" façe à ca... Donc Wait & See |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Jeu 26 Déc 2013, 14:42 | |
| Une nouvelle update a eu lieu, et à fixé pas mal de bugs, notamment le railgun ! |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Jeu 26 Déc 2013, 17:39 | |
| Bah tant qu'a faire ils nous permettraient d'avoir le choix via un switch dans les différents rendu, "Doomsday", "ZDoom" et "PrBoom" ainsi que la possibilité d'adapter les servers pour du Doom2.Exe via les options (avec des noms différents pour les modes quand même ) tout le monde seraient content on aura enfin un port qui satisfera tout le monde et 4x plus servers peuplés. Mais dans ce cas la guerre des ports n'aura plus lieu d'être :/ . |
| | | Invité Invité
| Sujet: Re: Zdaemon passe en 1.10b01! Jeu 26 Déc 2013, 18:12 | |
| - Serana, qui a supprimé juste ensuite a écrit:
Et sinon, c'est pour quand la M.A.J qui fixera la communauté? Quand ce genre de remarques pertinentes et de troll inutile disparaitront. |
| | | Contenu sponsorisé
| Sujet: Re: Zdaemon passe en 1.10b01! | |
| |
| | | | Zdaemon passe en 1.10b01! | |
|
Sujets similaires | |
|
| Permission de ce forum: | Vous ne pouvez pas répondre aux sujets dans ce forum
| |
| |
| |