Xash3D Engine Update! Created 9 years ago2014-04-28 01:42:11 UTC by Alberto309

A new update for the custom Goldsource build "Xash3D" has been released!

Both Xash3D Engine and XashXT have been significantly updated, including different bug fixes, improvements and new features. Please, note that these uploaded versions of the engine and the mod/toolkit are still not in the final state, and they can be updated in the nearest future after some additional testing and minor bug fixing.

[b]Xash3D Engine, build 2636 (stable) changelog:[/b]

Engine: added internal loader for deluxemap data (*.dlit files producing by VHLT)
Engine: msurfmesh_t was reorganized to complex vertex data instead of single arrays (VBO-ready)
Engine: decal_t now contain msurfmesh_t with all vertices and texcoords
Render: RenderAPI interface updated to version 35
Render: get support for float textures format (GL_ARB_texture_float is required)
Render: implementation of image program preprocessor, like in Doom 3, syntax: AddNormals( texture1.tga, texture2.tga );
Render: implemented an access to an internal tesselator through RenderAPI
Server: a little update for PhysicInterface: added a support for custom decal save/restore
Client: separate levelshots for wide-screen and normal screen modes
Client: restored a parametric rocket implementation (it was broken somehow two builds ago)
Client: fixed a potential crash with calling of function IsSpectateOnly
Client: pressing the ESC button while playing a video now causes a jump to a next video in a list (instead of complete playback stopping)
Client: fixed a bug with a completion of demos' playback (Connection Problem)
Client: a compensating of screenshots' gamma is toggleable now (cvar "gl_compensate_gamma_screenshots")
Render: optimized a decal code, removed some unused functions
Render: now all the lightmaps are storing into 1024x1024 texture
Render: added cvar "gl_detailscale" for customizing of *_detail.txt automatic generation
Render: fixed some errors with studiomodels lighting
Sound: increased a maximum count of words in sentence up to 64 (from 29)
Engine: fixed a broken recursion in Cmd_CheckMapLis_R (potentially could cause a crash)
Client: passed keyup event through HUD_KeyEvent callback
Network: changed delta params for skycolor_* variables (in some cases color value can be recieved incorrectly)
Network: fixed TIMEWINDOW_BIG mode
Engine: added engine build number into console log

[b]Xash3D Engine, build 2463 (intermediate testing build) changelog:[/b]

Engine: reorganized data in texture_t. Released one variable for mod-makers
Engine: changed decal_t structure to get a compatibility with GoldSrc
Engine: expanded mextrasurf_t reserved fields up to 32
Engine: updated player_info_t (added customization_t like in HL SDK 2.3)
Engine: increased local_state_t->weapondata up to 64 slots
Engine: updated IVoiceTweak interface
Engine: new lightstyle system with local time and custom interpolation
Engine: fixed a bug with lightstyle save/restore (previously only first 64 symbols of a pattern can be saved)
Engine: updated r_efx_api_t interface
Engine: updated engine_studio_api_t, removed incompatible function StudioGetTexture, added three new (just as existing ones in CS:CZ)
Engine: added ref_overview to support custom overview implementation
Engine: render interface now marked as a version 30 (due to many changes applied)
Engine: updated triangleapi_t interface
Engine: updated cl_dll interface (also added support for single export that called 'F')
Engine: a little update to enginefuncs_t (server interface)
Client: fixed a crash on shutdown if custom renderer uses AVI-files
Engine: applied a scale for decals on brushmodels or world geometry
Engine: updated model_state_t that keeps info about studiomodels for studio decals, including a body and a skin
Engine: got support for custom studiocache on static and tempents
Engine: write R_Srpite_WallPuff from pEfxAPI
Client: fixed a bug with beam sorting (solid beams were drawed in translucent pass)
Render: added a special flag for decals that indicates a local space (any decal after first shoot)
Render: applied emboss filter on studiomodel textures
Render: was rewritten a client event system for studiomodels to get more predictable results
Network: storing existing decals and static entities into new demo
Network: protocol was revised to version 48
ImageLib: fixed an old bug with saving of non-aligned 8-bit bmp-files
Server: fixed a bug with reloading of hl.dll at every change of a map
Server: a client part of save-file was revised. New version is 0.68

[b]XashXT, version 0.65 (stable) changelog:[/b]

Client: all exports are merged into a single export that called 'F'
Client: RenderAPI was updated to version 35
Client: background track is rewritten. Now it's using internal engine player instead of fmod.dll
Client: added MusicFade like in Paranoia modification
Render: added overbrights from XashXT: Custom Build 0.7 (thx to SovietCoder)
Render: added a fog code from XashXT: Custom Build 0.7 (thx to SovietCoder)
Render: fixed a beam code (solid beams were drawn in translucent pass)
Render: added grass code (a bit modified) from XashXT: Custom Build 0.7 (thx to SovietCoder)
Render: got support for a new system of lightstyle local times (a way to save too long light sequences)
Render: fixed a bug with disappearing of dynamic shadows
Render: fixed frustum bug with far plane
Render: fixed some bugs of func_monitor
Render: fixed some bugs in Aurora code
Render: restored mode kRenderWorldGlow for sprites
Render: finalized studio cache code
Render: studiomodels event code was rewritten (to get more predictable results)
Render: optimized rain and snow code, limits are increased
Server: env_spark now supports prefixes +-
Server: momentary_rot_button immediately stops on prefix >
Server: func_rotating toggles directon on prefix > (only when stopped)
Server: func_rotating ignores direction toggles from momentary entities
Server: entities which are attached to a player use his yaw angle now
Server: momentary_door immediately stops on prefix >
Server: fixed some bugs in env_laser code
Server: got to work an air shake for env_shake
Server: created cvar sv_allow_PhysX for user control
Server: func_pushable can be walk on stairs now (testing option)
Server: func_tracktrain can reverse direction on prefix > (only when stopped)
Server: added "parent" field for multi_manager and multi_watcher (useful in some cases)
Server: now all the triggers supports prefixes +-
Server: angle-based trigger now gets an angle transform from parent
Server: rewritten the ichthyosaur's code (Stupid Quake Bug fix)

P. S. If you a new with Xash3D, please, check this manual about proper installing of the engine. XashXT should be installed in a same folder with the engine, as addon/mod for it (with its own executable - xash.exe).

For the ModDB Page and download link, click here!

Finally something now to test.

Saw this.I'm sold.

I didn't even know this exists. Until clicked on it on moddb's "latest articles" box. Pretty impressive stuffs there.

o.O i think this engine would be great for mapping medievel theme maps

Alternatively, Source.

Good looking aside i still stand by what i said, he would better make his own engine with hl emulation or something rather than basing it on a lets face it obsolete engine.

I think it is an engine written from scratch that just supports HL stuff. Atleast according to the moddb page.

Edit: No, wait, I misunderstood. Then it does seem like a bit of a waste of time...

What's with the obsession with trying to up GoldSrc's limits? Mods, engines, etc. all adding things Source can already do and without looking so goofy. Is it the pressure to having higher quality with Source or something? Maybe I'm just being a downer, but I'm lost as to why someone would use this, or make it.

Like Archie said in one of his Q&A videos for The Core, it's probably because people are fond to Half-Life and so wants to use its vanilla or relative engine's modifications. We are HL fans after all (remember: there are people that are still mapping and modding with the Build Engine, commonly known as the Doom or Duke Nukem 3D engine).

Anyway, for who that doesn't know that, the Xash3D engine has been used in famous HL mods like Paranoia and Afraid of Monsters: Director's Cut.

The only limit that should be released is map size and number of objects/entities on the map. And a more efficient method to render all of it.

gs already has a big enough map size and the upped entity limit is now 2k or 4k + you get the luxury of using MP which these engines don't support.

Cooler than Trinity, still just as pointless. Use Source for its capabilities or Goldsource for its charm - not something that tries to be both and ends up falling short in both regards.

Yeah Archie is right, there is a reason there is GS and Source. If you want the middle ground there is always idTech

Many projects exist simply because the creator enjoys working on them. Is that not enough of a reason for this to exist?

Yes, perhaps, but he could have made his own engine which probably would take less time than reverse-engineering GS and which he could have used for stuff without it being illegal.

Reverse-engineering software is not illegal. The only way something like this could be illegal is if it uses code that has been stolen from Valve - as far as I know, this engine is written from scratch to replicate GS, but doesn't use any of the original GS code.

Besides, why should anybody be telling someone how to spend their time? If someone wants to put effort into recreating Goldsource-related software from the ground up, why shouldn't they not be allowed to?

EDIT: Of course, the HL EULA does forbid reverse-engineering, but let's just ignore that...

I don't have anything against someone making something for fun, that's an excellent reason, and if it's the main reason, fair enough.

But it doesn't seem like that's the driving force for a lot of the "upgrades" to GoldSrc. It seems people cannot stand to leave GoldSrc for the less painful alternative for one reason or another, and would rather try to put some of Source's basic features into GoldSrc and often end up with funky-looking results. So I'm questioning why that's being done. If it's the fun thing, works for me, otherwise, what the heck?

Yeah the GS "detox" can be hard, the fact that its simple and still looks ok is what make people stick to it.

Besides, why should anybody be telling someone how to spend their time? If someone wants to put effort into recreating Goldsource-related software from the ground up, why shouldn't they not be allowed to?

Fair enough. I just don't understand the fascination with upgrading the GoldSource engine. Old games have charm because of the way they look and their limitations, if you are going to completely change them you might as well migrate to a more modern engine.

And, as your link says, reverse engineering is usually a breach of contract since most eula's prohibits it.

Old games have charm because of the way they look and their limitations

Exactly! This is why I love both low poly modelling and pixel art and games featuring these styles. I wouldn't want to try an upgrade them as such with fancy rendering and high poly models. I enjoy working on The Core but when I started I was pretty ignorant of Source and it's benefits and that's why I went with an HL1 mod. 6 years later, I'm starting to loathe working with GoldSource for The Core. However, I'm not about to fold it into some beefed up version of the engine with fancy graphics and shaders. That's how Duke Nukem Forever got started.

That's not to say I wouldn't use GoldSource again in future, but I certainly won't be doing anything on this scale again.