"Client Features page" ?
 

On the wiki installer guide it says there is a "Client Features page". I can't seem to find it. Has it not been created yet? I haven't messed with Eqemu in over a year and I just read somewhere that titanium wasn't going to be supported any more. Which is what I had been using. I already knew the newer clients had access to different features. I have no idea which features or if they are even relevant. But, I had also read back then that they were unstable? Which is why I stuck with titanium. Anyone care to break this down for me? :confused:

Thanx in advance.

Not sure where you would of read that, but I'm guessing that was on one of
the custom servers ? It's usually the individual server owner that makes the
choices of what clients it wants to support, usually involving the content of
the server. Most of the servers on the EQEmu list are independant of their
own development.

There has been talk of it amongst the devs..but, I don't recall ever seeing anything on the forums.

This is why I keep backups of source updates (usually a month's worth). Just in case
you evil devs and I reach a fork in the road. (chuckle)

Kinda like Github does automatically?

http://wiki.eqemulator.org/p?Play_Gu...etting_Started

"See the ClientFeatures page to view some of the differences between the clients. Also see the Client_Versions page for details on determining if the client you have is compatible with EQEmu or not."

It seems like the page just hasn't been made yet? And this would be my own private server. I am not playing on someone elses.

(chuckle) Not sure if you understood what I meant. But to clarify, after typing
"git pull" and it pulls the updates to the source folder. I copy the whole folder
over to another backup drive. Hence - a whole bunch of source folders, with
dates on them.
Kind of the same concept of running into quest updates. I keep what I need
and toss the elink ones, oops I mean the other ones, away <grin>

I think what he means is that you can revert your local repo to any previous commit..thus, eliminating the need to keep historical repos.

Of course, you can't revert your database so easily..so, a backup of those would be more prudent.

Ohhh, ok, I didn't know one could do that with the git. Generally right now, aside from the
backups I copy, I keep my source folder seperate then copy it over to a new folder to
compile. I do this because I do a few edits to a couple files, but want to keep the main
source files as they came.

That's where forking a repo and putting changes in there is useful. You can commit the upstream changes down to yours and manage conflicts and not have to manually re-edit things every time.

Ok, (chuckle), I think I need to go to forking repo school, that was just bit over my head.
I haven't put any effort in to learning advanced stuff in git pulls/repos, etc. Eventually :)