vera/nuclide
4
0
Fork 0
Code Issues 32 Pull requests Projects Releases Packages Activity

Update History.md

Browse source
This commit is contained in:
Marco Cawthorne 2022-10-02 17:23:44 -07:00
parent 4b75b36c89
commit 8b6d3ae7ee
Signed by: eukara
GPG key ID: CE2032F0A2882A22
1 changed files with 34 additions and 32 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

66
Documentation/History.md
View file

@ -1,53 +1,55 @@
# History
In November 2016 eukara started work on 'OpenCS', a project which focused
solely on creating a clean-room implementation of Counter-Strike 1.5 in QuakeC
for FTEQW, which then was the only Quake engine fork which adhered to the
GPL and supported the level and model format of Half-Life mostly to spec.
Its strong game-logic enhancements such as Client-Side QC as well as its
In November 2016 **eukara** started work on **OpenCS**, a project which focused
solely on creating a clean-room implementation of **Counter-Strike 1.5** in QuakeC
for **FTEQW**, which then was the only Quake engine fork which adhered to the
GPL **and** supported the **level and model format** of **Half-Life** mostly to spec.
Its strong game-logic enhancements such as **Client-Side QC** as well as its
QuakeWorld backbone also made it more desirable over other Quake engine forks.
OpenCS was feature complete with all CS 1.5's content had to offer by December
of 2016, however the name conflicted with the 'OpenMW' sub-project 'OpenCS',
**OpenCS** was feature complete with all CS 1.5's content had to offer by December
of 2016, however the name conflicted with the **OpenMW** sub-project **OpenCS**,
so eukara changed it to avoid any future conflicts.
To emphasize the free-software aspect, eukara renamed the project FreeCS.
To emphasize the free-software aspect, eukara renamed the project **FreeCS**.
Work on FreeCS had then paused so more work could be done on what would later
become the 'gs-entbase' component. Another project required more compatibility
Work on **FreeCS** had then paused so more work could be done on what would later
become the **gs-entbase** component. Another project (**The Wastes**) required more compatibility
with the full set of map entities present in Half-Life.
When those matured, they were then backported to the FreeCS tree.
In November of 2017, FreeCS was featured on Phoronix.
When those matured, they were then backported to the FreeCS source tree.
After the release of The Wastes in April 2018, the game which introduced the
'gs-entbase' component, more work was done on FreeCS in regards to the netcode.
Then, in November 2017, **FreeCS** was featured on Phoronix.
After the release of **The Wastes** in April 2018, the game which introduced the
**gs-entbase** component, more work was done in the FreeCS source tree in regards to the netcode.
A lot had been learned about prediction and taking full advantage of the
custom networking available in FTEQW, but new features have also been
added to the engine to take full advantage of what the content had to offer.
Features like interacting with OpenAL's EAX extension, model-events, support
for WAD3 decal parsing and countless QuakeC extensions were all added by
either Spike or eukara himself to make FreeCS possible.
Many projects running on FTE have since taken advantage of these extensions
as well!
custom networking available in **FTEQW**, but new features have also been
added to the engine to take full advantage of what the content had to offer:
By the summer of 2019, the Half-Life Deathmatch component started taking shape.
Features like interacting with [OpenAL's EAX extension](EFX.md), [model-events](VVM.md), support
for WAD3 decal parsing and countless QuakeC extensions were all added by
either Spike (FTEQW Author) or eukara himself to make everything possible.
**Many projects running on FTE have since taken advantage of these extensions
as well!**
By the summer of 2019, multiple other mods from other engines started taking shape.
At this point, the tree was overhauled so it would support multiple mods easier
and that a lot of code would be shared between all of them.
This is the structure of the src tree we still use to this day.
So a name had to be thought of that would neatly tie all projects under one
roof together: Nuclide!
*So a name had to be thought of that would neatly tie all projects under one
roof together*: **Nuclide!**
The name Nuclide calls back to an earlier project, which tried to create
a work environment similar to GoldSrc for the original Quake engine.
**Trivia**: *The name Nuclide calls back to an earlier project of ours, which tried to create
a work environment similar to GoldSrc for the original Quake engine.*
In April of 2020, the weapons were rewritten to be fully client-side predicted.
This brought the Counter-Strike component on par with the advances of the other
games that Nuclide supports.
So the meaning and scope of Nuclide has changed, mainly to make work easier
as at one point TW and FreeCS were two seperate code-trees. Now they're unified
into one. I'd like to consider Nuclide to be FTE's reference SDK for game-logic,
like 'Source SDK Base' is to 'Source Engine'.
So the meaning and scope of **Nuclide** has changed, mainly to make work easier
as at one point The Wastes and FreeCS were two seperate code-trees. Now they're unified
into one. We'd like to consider Nuclide to be FTE's reference SDK for game-logic,
like **Source SDK Base** is to **Source Engine**.