[Release] Star Wars Galaxies Official Source Code (Client/Server)

Quote:

---

Originally Posted by DNC

To clean up Windows side.
Headers and C++ files that reference #include ....
A couple Thousand "relative path" #include are incorrectly referencing the location of the #include

What do I mean?
For example, open a header that has multiple header #include .
They are obviously referencing other #include (as expected), but the majority of those referenced #include headers (both from standard headers and C++ files)... the header you open (instead of containing code) contains a "relative path" to the "expected" header file being referenced. These "relative path" #include statements are "85%" referencing an incorrect "relative path". Not all do this, so you can't just modify it based on that.
Linux side, the siteSetup.sh creates symbolic linking blah blah (I haven't tested whether this is actually still a concern on the linux side of the code or not). To clean up the Windows code, it would essentially need a lot of work.
By the time you reach 1/3 of the 152 projects getting cleaned on Windows. You'll be roughly sitting at 3000-3300 files modified by hand.

Just noting there is a Lot of work with this code "out of the box" to get it functional Windows side why I wont waste time working on this.
It can be done. So enjoy.

- - - Updated - - -

PS there are 13,853 headers...
Before someone posts with a statement like add folders to your Include path.
LOL
Unless you want to add pretty much 1/3 of the folders "manually" that isn't happening.
Do it right and fix the header references.

---

Does that mean the linux files are ok and "ready" to be used without any modification (excluding the compiling and setting up) ?

This thread is just sad. Here we have the official files and everyone is complaining about the emu scene crashing. That's not the case development of the emulator doesn't have to stop just because someone releases the official files. It almost sounds like a bunch of cry babies. Yes they've been working on it for 10 years that's even more of a reason for them to continue development on it. They can add more things to their emu than the official one. Because they wrote it and they understand it. There isn't an excuse to why we cannot have more than one server.

Quote:

---

Originally Posted by SanGawku

Yeah they do, But SWGEmu is pre-CU and i hear thats where SWG Really shined so I think I am going that direction.
I will weigh my decisions in a few hours when I get off work. But yeah.
The Emu scene has been around for the past 10 years and I don't want to be the one Single handedly responsible for destroying it.

I'm an asshole but not that much of one.

- - - Updated - - -

---

You won't be destroying anything. Perhaps some people will stick with the emu scene and some will go to the official server. I personally think you should release a guide on compiling the files. Someone eventually will.

any word on the repack's status since there's really been no update for weeks now..?

Quote:

---

Originally Posted by vosmus

any word on the repack's status since there's really been no update for weeks now..?

---

You didn't read through, did you?

SanGawku said he won't make it. Because of the SWGEmu Community.

I honestly doubt, that with the fact that SWGEmu has remained open source for as long as it has, that it will have any issues regarding the leak of this source code. The structure of code SWGEmu uses, it would be absolutely a waste of time to use the leaked code as a reference, other than possibly for quest data. PSWG may be the only community that would have to worry about it; but even then, PSWG I doubt will have anything to worry about as long as they open their source and keep it available for public viewing, so that Lucas Arts/SOE/Disney have really nothing to push upon.

However, with that said... Anyone who hosts a server publicly with these files, would have to be completely foolish. I see no harm in someone releasing this with a hardcoded limit of like 5 players or such, so that people can play with their friends.

If someone wanted to release the fixed source; there's still a matter of figuring out how to actually run the server. Your average run of the mill kinda person probably wouldn't be able to figure it out.

Regardless, the source is open now, it's only a matter of time before someone really starts to take advantage of it. I'd really hate to see someone fixing this code and start selling it so people who can't figure it out. That's the last thing we need with this leak. I personally haven't bothered even browsing the source files, because I am quite pleased with SWGEmu's progress. I've been following them since the first year the project started.

~~Edit:

Just read that PSWG actually has already gone open source.

For the sake of curiosity, as I've never actually tried NGE, I was curious to attempt to get this to load. I was going to try PSWG but for some reason their registration page tells me I am using a proxy (that of which I am not). I have experience working with the client file structure, and I imagine their server structure follows the same patterns; however my experience with coding is not as advanced as some of the others here. Unfortunately I won't be able to release a repack either for those interested in the LAN environments, unless someone is willing to go into a little detail as what was missing for this project to compile?

I get the feeling that a library of some sort is missing? (Such as the Boost Library?).

I'm actually half curious now. Perhaps if someone would rather not disclose the information publicly, perhaps send me a message and when appropriate I will release a repack with a hard-coded limit for those willing to play with their friends.

Edit:

In other news... have you guys seen this yet? #hype https://youtu.be/jXU5k4U8x20

Quote:

---

Originally Posted by DNC

Snip

---

Thanks for your effort regarding this matter. Perhaps the creation of the login server that is missing won't be a great hindrance, considering ProjectSWG uses a NGE revision and it of course has it's own login server. I would imagine it would likely take time to get them to communicate together. However, I'm unsure about "SWGGuy's" presence in the SWG scene but he did have a capture available with a JTL screenshot. Perhaps this is how they've managed to get it functioning?

Edit:
Unless of course, it is as you say, they've just leaked the files, while excluding the loginserver and third party lib.

Quote:

---

Originally Posted by DNC

I don't know who is whom based on the usernames in this thread. Except for Timbab of course.

Regarding the concept of using another loginserver or creating one. Either or is fine and shouldn't be difficult since you have the rest of the code and what it expects to send / receive.

I'm just alerting you to what is necessary. Using the files in this thread (IE the same as found on reddit).
You'll be modifying more than 2 lines of code. You will need to create a loginserver. You will have script formatting issues.
At which point you can start focusing on real issues, aka residual bugs and how you'll replicate the spawning (buildouts) in game, for starters.

Just making sure you have an idea what you're truly going to need to work on (again, for starters).

---

Right, and that's understood. Of course the first goal is to get it operating in the first place. While, once it's operating, of course placing spawns will be time consuming, but it's something that we can contribute to on a whole once the package is operational. SanGawku mentioned that only a few of the projects weren't compiling. If possible I'd like to know what steps were taken to get at least that far.

Quote:

---

Originally Posted by DNC

I've stated those steps and was laughed at.
Correct the improper "relative" paths in the headers.

I'm not working on it, just clarifying why I wont work on it (especially with the personal project at the moment).

Also tired of people asking for a "simple repack" or "simple tutorial".
There wont be one, because this code isn't simple period.
5 coding languages (perl, python, java, C, C++) and oracle db alone.... I need not say more (there is a lot more than just this) and anyone stating otherwise are utter liars.

Good luck to all of you

---

Thank you though. I believe I understand what you mean now. I'll fiddle with it and I'll try getting it to work along side the PSwg login server.

I thought I had posted yesterday: First off swgemu isn't open source. When MMOEngine's code is available, let me know. Additionally, all of the projects have 5 user login caps on them last I checked. They all used pre-compiled files to ensure it wasn't tampered with. And much like previous comments about the vitriolic nature of gamers in general and the SWG emulation community in particular, they've scared off the majority of competent programmers and reverse engineers with their hostile and childish behavior. On to the important stuff:

Server: RHEL4/CentOS4 with -devel rpms, Oracle DB 9 (check readme for exact version.), gcc 2.95.3 or gcc 3.2.x (If RHEL4 came with gcc-2.96, you might need to upgrade, it is probably on 3.2 from the RHEL4 CDs/DVD but I haven't set up a VM to check.) Everything else, including Oracle 9 client libs/headers is in the source archive.

Client: Either Visual Studio 6 or 2003, DirectX 8/9 SDK (I don't know if they were seperate or combined. You need whatever one last supported Win9x as a build target most likely), perl (StrawberryPerl or something, 2003-2005 vintage, most likely. They use Perl for the build scripts on Windows!!!) There might be some other pre-requisites when you get to that point. Builds should probably be attempted on WinME, Win2k (Possibly SP3 or lower), and unpatched WinXP. You can certainly try with newer versions, but I providing the versions that most closely match what the original build environment most likely was.

If you get the server compiled and want it playable over the internet, go with a VPN, ideally over a Tor or I2P hidden service. It provides the least risk of legal drama, and Tor is fast enough to handle interactive VPN sessions if you have the hardware.

Honestly if anybody had a workable compiled version of the server and all the required materials that would be great. I miss NGE and NGE was the only part of SWG i played. The EMU for NGE isn't getting anywhere. If i had the materials, i would just play it offline and have no intention to redistribute it. I only want to feel the same things i felt years ago to be honest lol.

I feel similiar, although about Pre-CU. One of the nice parts Pre-CU was that there was no 'Levels' and while there were 'Classes', they had a fixed endpoint, at which point you could either grind for the privilege of building end-game loot yourself, hunt the galaxy for dangerous creatures which you might now be powerful enough to solo, or wander the galaxy teaching others your trade.

A fun feature that was lost with the NGE: Previous versions of SWG were scriptable to the point where handicapped players were able to interact with the world almost as well as normal players. Many of those features got broken and never fixed in later versions of the codebase.

Additionally, although you shouldn't get up too much hope: The original class names appear in the source code. While I haven't dug around enough to see if the old support code was deleted, optioned, or commented out, it is slightly possible that Pre-CU/Pre-NGE features are still there, and given sufficient patience could be reimplemented with all the added features, ships, equipment, etc that was added in the intervening years until SWG's closure.

Quote:

---

Originally Posted by rageofrages

First off swgemu isn't open source. When MMOEngine's code is available, let me know.

---

I'm pretty sure SWGEmu opened their source code on April 4th. ~

Quote:

---

Originally Posted by DNC

You're absolutely correct.
Don't get your hopes up. The data isn't there etc etc.

LordVenom is correct as well, swgemu has been open source, but a lot longer than April 4th.

For a few years now I've had a development environment of swgemu and played "on n off" locally.
But it is still no NGE and I prefer the newer content over the older.
Not that either are dull, just personal preference.

- - - Updated - - -

What made the game... Wasn't which version it was (there were several -- pre-cu, cu, nge, tc .....)
What made the game and "populated" most of the barren landscape, were the players and their housing / communities.
This is what made the game. Not the branding, not the lack of spawns, not the older or newer content, but the depth other players added to the game.
At least that is my opinion. ;)

---

Right, SWGEmu has been open source basically since they started, but rage mentioned their "Engine" which until before April 4th, had a hard-coded time limit of 1 hour(approx) of server up-time. I believe it was on April 4th they removed the cap and opened up the code that controlled this. (However I could be mistaken...)

I'm not sure about the new changes in NGE, as I never had a subscription beyond Pre-CU, nor did I try any trials, I've always found myself comfortable playing in SWGEmu and have been following for a long time. With the release of this leaked code, I was hoping for this to be a good way to immerse myself into the new updates and content, with my friends (most of which have never even played SWG).

I'm still looking into the code, and slowly going over it. Haven't gone too far, as this is all a bit much to just jump into for someone at my level; however if I do manage to figure it all out and get it operational, I will implement a "X" man limit (maximum group size) so players can play the game with their friends and experience the game yet again (or for the first time).

Edit:

I'd also like to mention that I have a great deal of experience handling the client structure, of adding and modifying new content in the tre files. I did have a development environment set up as well, and I managed to import a majority of all the new armors, weapons and housing to the SWGEmu environment. Never ended up actually finishing that project as I got distracted elsewhere. However, with this release of the client source code; this opens up the world, as has been said, of re-implementing Pre-CU/NGE in the newer engine. While this feat would of course take a long time, we have the client files available as reference points to once again make this dream a reality. It would be a very interesting to accomplish, and it might just be the next greatest revelation in SWG history.

I understand the legal problems behind this, and I realize that this is probably not something you'd want to go on with large-scale publicity, however, there are always those willing to push their limits.

Seeing as my last post got eaten by a spurious logout:

SWGEmu's frontend code is open source, MMOEngine/Engine3 is not. Additionally it is in violation of the GPL since Quadtree.* QuadtreeNode.* and possibly a few other files with headers either modified or omitted are included in its codebase. Given that the copyright includes the WowTeam (c)2004 or something, it could not simply be arbitrarily relicensed for Engine3 inclusion without still adhering to the GPLv2 or later.

If you have any doubt regarding its closed source nature, open up a random header, like include/system/lang.h

Code:

---

/*
Copyright (C) 2007 <SWGEmu>. All rights reserved.
Distribution of this file for usage outside of Core3 is prohibited.
*/

---

Additionally it has connection restrictions in place and is set to segfault after about an hour of usage so they can force you to play on their 'official' servers instead, and hussle you for money for all the 'hard work' they put in copying someone else's 'valuable intellectual property'.

A large portion of the emu scene really seems to have a double standard regarding the freedom of other people's information versus the 'hard work' of their own. SWGemu is an example of that.

Also for historical record: The last truly open source version of swgemu was the Core1 releases back in '06 or so, during the first round of shitfests that got Ultyma or whatever he was going by at the time his infamy. It also lead to some guy named Joker running off with the swgemu donation account, and them in turn begging for more money with the claim it would make work progress faster. This whole fiasco lead to a half dozen spinoff projects, most of which moved just as slowly as SWGemu due to a lack of open sharing of packet analysis, a lack of competent devs (they were and mostly still are a bunch of script kiddies and self inflated amateurs.)

That said:
Updates on compiling: RHEL4.7 iso is too new. A number of compile errors are due to g++, cc, c++, or gcc being called directly in a non-autotools makefile (RHEL4.7 includes gcc 3.2.3 as 'gcc32' and uses gcc 3.4 as the default compiler, which has a whole pile of new errors due to differences in how it interpreted source code.) You can either modify those directly or make a new directory with symlinks from gcc32/g++32 to cc, gcc, g++, c++, and cpp (symlinked from gcc32, which will act as gcc32 -E, or the c preparser)
Additionally the compilation error on UnicodeCharTraits.cpp in the soePlatform library is a simple fix on the first line:
((__GNUC__ == 3)) to ((__GNUC__ == 3 && __GNUC_MINOR__ < 2)
I believe the actual cutoff is >gcc-3.2.1, where a number of unimplemented functions stlport453 and other code (like ChatAPI2) relied on were quietly added during a 'minor' revision, leading to a ton of no longer compiling apps because the testcases assumed all gcc3 versions were non-conformant.

stlport/config/stl_gcc.h requires a similiar addition on line 154:
...
#if (__GNUC_MINOR__ >= 2)
#define _STLP_USE_NEW_IOSTREAMS
#endif
.. outer #endif for __GNUC__ >= 3

I may try with RHEL3 later and see if I can get closer to finding the proper development environment to build it.

Meantime:
ibm-jdk-1.3 rpms are on rpmbone.
oracle 9i is only available with an Oracle support contract, or if you can find a torrent of it somewhere.

Hope a few technically savvy flameproof devs will take it upon themselves to finish this. It would make an excellent FU to all the people who have hindered the advancement of an open SWG emulator this past decade.