Commenting that: http://collective.valve-erc.com/index.php?faq=source_mod_faq&printable=yes
>> Ask: What is the maximum map size for Half-Life 2? >> >> >> Valve: The maximum map size is currently set at +/-16384 units (16x >> the horizontal area of Half-Life 1, 64x overall volume). >> >> Mods can choose their own unit scale for the world. For example, 1 >> unit could be made to be equal to 1 foot, or to 1/10 of an inch. >> Physics will be adjusted accordingly, but collisions are only >> guaranteed to be accurate to 1/32nd of a unit. >> Oh... everything is scaled down/up? cool. But resolution will be the same... as ever?. >> Ask: Would it be possible to make a mod similar to Battlefield 1942 >> with Source? >> >> Valve: First, BF1942 has pretty large maps, so you'd probably want to >> scale your units down to allow for a multiple mile x mile playing >> field. Close fighting at BF1932 suck, maybe because have very low resolution. I suspect. With worldscale you will have something similar. Mods with big maps and ugly worldscale factors will have ugly clipping.. I suspect. This look like a hack: http://collective.valve-erc.com/images/hl2/faq/area_hl1_vs_hl2.gif >> >> Ask:What is the networking system like and how flexible is it? >> >> >> Valve First, you have total control over what entity data is >> transmitted for a particular entity. In other words, no more set >> "entity_t" where you had to wedge in fields and override fields. >> Reflection alike network! cool. >> Second, you can write custom data proxy code to massage data values >> into more networkable values on the fly. ...??? >> >> Third, you have all of the low level prediction code exposed to you in >> the client .DLL and you have all of the server-side lag compensation >> code exposed to you in the game .DLL. >> humm... >> Fourth, there are a bunch of useful new diagnostic modes to show you >> when things mis-predict and help you track down inconsistencies >> between the client and server versions of things. >> Interesting. >> One of the cool things we've added to the multiplayer engine is the >> ability to predict the creation of additional entities, such as >> projectiles... so you can do a predicted rocket, have it simulate on >> the client and even do a non-lagged rocket jump in your mod if you >> wanted to. >> Cool. Instagib mods :D >> Also, entities that go out of the PVS on the client are no longer >> destroyed and recreated upon re-entry to the PVS. The entities live >> continuously on the client. In fact, you can create additional purely >> client side entities and have them simulate completely locally, too. >> To save reflected data? Humm... >> If you're familiar with the Half-Life 1 SDK code, there's now a >> C_BaseEntity on the client that matches the CBaseEntity on the server >> in almost all ways. Hee.. not, I dont know the SDK. >> >> On the performance of the networking code, it's as compressible and >> much more flexible than the Half-Life 1 code. Reflection will kick-ass. >> >> Ask: How do physics behaviors work in multiplayer? >> >> >> Valve: The simple answer is that there are client-side and server-side >> physics behaviors. You use client-side when maintaining cross-client >> coherence isn't important. This cuts down the network traffic while >> maintaining the appearance of physical simulation throughout the >> world. >> >> It's definable per-object, so exactly what is client-side and what is >> server-side is tunable by the designer. - - - About Netcode: I think this design is very interesting. Reflection is new for me, but is think is somewhat already common here, at the hl scene. I have read something about "scale", that sound me that the engine send a scale, and compress the coord with this scale. This will generate less resolution for big resolutions. But he!.. if the renderer is better now, you will be able to use outdoors anyway, maybe the problem is more r_speeds than network protocol. I guess the code will look like this: Server: void MSG_WriteCoord (sizebuf_t *sb, float f) { MSG_WriteShort (sb, (int)(f / sv.worldscale ); } Client: float MSG_WriteCoord (sizebuf_t *sb, float f) { return ( MSG_ReadShort(sb) * cl.worldscale ); } And reflection will work like that: Server: void CTurret::Reflection() { self->QueueReflection(); self->NoOfRockets()->Reflection(); self->Origin->Reflection(); self->Angle->Reflection(); self->EndQueuReflection(); } Client (render): void CTurret::Render() { ApplyAngle(self->angle); for (t=0;t<self->NoFoRockets;t++) MyRockets(t)->Render(); } I can be wrong. But this is what I have understand from Valve "source-faq man". _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
