DevChat Log - November 7th, 2009

[ad27499]

Thanks guys, Keep up the good work

[RegularJohn]

Thanks for the info and hard work on the OR Devs & team

//RJ

[abovocipher]

thanks for the post, very informative. cant wait to try the OR release

[amphitryon]

Excellent dev chat, and the BEST description of the OR to date.

makes me wonder why SOE never did an 'OR' of their code as opposed to the hack and slash of the NGE. It would seem to indicate that by the time of the NGE, the remaining devs had no idea how to deal with the preNGE code.

Here the SWGEmu devs are showing a LOT of foresight by make sure their code is not only optimized, but readable as well so that future Emu devs won't need to rewrite everything.

Good job (and better than most SOE dev chats I have seen!)

[Uli]

Originally Posted by odwill

<torbersane> when the OR is complete will that allow for easier implementations of custom content? Will any options of custom content be done as modular so that one server could have a miner profession and say another server decided that it wants to be only pre cu 14.1?

<@bobius> Yes! A "Feature Manager" is in the works so that it will allow quick toggling of custom content

<skitch> will the OR give the ability to add new races as playable?'

<@cRush> Many modifications like new professions will require client modifications as well as server side modifications.

<@bobius> No, this is another thing that will require client size modifications. We do not currently endorce modifying the client.
<@cRush> Anything modifying the client will not be hosted, nor distributed via SWGEmu networks.



<kraken666> will we see any customer artwork in the form of transports, armor, housing, clothes, or any other player or dev generated items?

<@bobius> Adding new types of armor, buildings, clothes, or anything like that would require client modifications.
<@bobius> However, quests and events do not. We will make it possible for the community to create new quests and live events.
<@cRush> Anything involving new graphical artwork that isn't already in game is a client mod.
<@cRush> Reusing the same graphical artwork to create a "new" item is doable.

Why is there a Client Development Team Then?
Shouldn't they be moved into different Sector's since what they are technically doing something that is not going be related in anyway to the SWGEmu Networks.

Also

"Reusing the same graphical artwork to create a new item is doable" that is classed as a client mod as well (Just wanted to add that onto the end of "doable")

[Kayliaah]

Originally Posted by Uli

Why is there a Client Development Team Then?
Shouldn't they be moved into different Sector's since what they are technically doing something that is not going be related in anyway to the SWGEmu Networks.

Also

"Reusing the same graphical artwork to create a new item is doable" that is classed as a client mod as well (Just wanted to add that onto the end of "doable")

Wow a miracle, you're back.
And that's how I felt when I read this, all this content that has been created over the years will be pretty much useless lol, what a waste it's sad.
If at least, some things are released, perhaps they will be added on other servers, just hope they're stable and ran by serious people...

[bobius]

Originally Posted by TuleenDonai

I'm still a bit confused about the Berkely DB structure vs. MySQL DB.

In looking at the code, it seems to me that you are using the Berkely DB for internal object management, AND you are using MySQL to manage player information that would get loaded and unloaded as players log on and off. That's where I get a bit caught around the axle. If I understand correctly, it appears that the Berkely DB would actually manage "In RAM" volatile information, but if the power gets pulled, you'll still need something like MySQL to maintain "Non-volatile" game state information.

This could be the result of an incomplete OR and/or observing "in-progress" code. There seems to be an overall thinking that Berkely DB will replace MySQL.

Are we to see future Berlkey DB constructs that actually "write" information into a file-based DB structure?

Can one of you Devs enlighten here?

Basically we will be using MySQL for two things (as of now, this may change).

1. Populating the static object db the first time you start the server after a wipe. (You can't load objects from the objectDB that aren't there)

2. Referencing objects that are in the berkelyDB

For example, when you login we hit the MySQL db to fetch a list of your characters and their objectids. We send those to you. You request character Tuleen which has an object id of 100001. We load player 10001 from objectdb.

Since all the objectdata is serialized, there's no quick way to poll the objectdb for information (like player object ids for your account), so we use myself for that sort of thing.

Only a very small amount of data is ever going to be read or written to MySql. That's why you get the performance increase.

[Ketaris]

Ditto to Uli and Kayliaah on the client modifications. I was a bit concerned when I read some of that as well. Can it be elaborated on a bit more? Has this always been the policy, or is it a recent change? Either way, what is the rationale? Does it conflict with the privacy policy?

[Decebal]

Good read!

[Kyrm347]

Thank you Devs for this Devchat, I appreciated the answers you provided for questions from us.

Originally Posted by Ketaris

Ditto to Uli and Kayliaah on the client modifications. I was a bit concerned when I read some of that as well. Can it be elaborated on a bit more? Has this always been the policy, or is it a recent change? Either way, what is the rationale? Does it conflict with the privacy policy?

I also was curious about the statements by Devs dring the DevChat about no new client side mods. This would cancel any future "upgrades" to much of the game. There are tons I of client side mods I think should eventually be added to SWGEmu that would enhance the game experience, some of which I think should have been ingame from SWG release.

My first instinct when I saw it in DevChat was that this is a "fine print" issue. If so I can understand why more has not been said about it.

Please if possible Devs, more information on this subject is desired by some of us. If necessary you can PM me with the info if you are reluctant to share it publically here, as I am seriously considering hosting and running a Server for SWGEmu v1.0. My future abilities as a Admin to modify and add content is an important factor in my decision making process as to whether I will go ahead with this idea.

Thank You.

[jj8926]

That's some good information, and thanks for posting! I wish I could have made it!

But looking at what was said about client-side mods, I'm going to go on experience from what was said in the past. DON'T QUOTE ME, AS I HAVE NO IDEA OF OFFICIAL POLICY! I'm just going on what I think/hope is the case. I would also like an official word on this.

But what I think they mean is that the original dev team is working on an exact replica of 14.1, with no additives on the base code. As such, all extra content would be considered outside of their scope/plans. Someone on the side may come in and create client-side mods for servers to use, but the SWGEmu devs will not officially endorse these as SWGEmu compatible, as it's not their mission statement. It's sort of like all the Future Server Ideas. They are not endorsed by the team, and the team will not work on them, though some may work on them in an individual capacity, not relating to the original SWGEmu project.

As I said before, I'm not sure that this is the case, this is just what I get from prior statements made on this case, as client-side mods were never officially endorsed.

[Labyrinth]

Originally Posted by jj8926

That's some good information, and thanks for posting! I wish I could have made it!

But looking at what was said about client-side mods, I'm going to go on experience from what was said in the past. DON'T QUOTE ME, AS I HAVE NO IDEA OF OFFICIAL POLICY! I'm just going on what I think/hope is the case. I would also like an official word on this.

But what I think they mean is that the original dev team is working on an exact replica of 14.1, with no additives on the base code. As such, all extra content would be considered outside of their scope/plans. Someone on the side may come in and create client-side mods for servers to use, but the SWGEmu devs will not officially endorse these as SWGEmu compatible, as it's not their mission statement. It's sort of like all the Future Server Ideas. They are not endorsed by the team, and the team will not work on them, though some may work on them in an individual capacity, not relating to the original SWGEmu project.

As I said before, I'm not sure that this is the case, this is just what I get from prior statements made on this case, as client-side mods were never officially endorsed.

Good summary (though I don't know anything about the official policy either). This is the same sense I get about all of it; that the devs might support it unofficially as fellow players, but don't support it from the stand point of the project, probably for legal reasons.

[Kyrm347]

Ok then, their statements are starting to make sense to me. Thanks jj8926 and Labyrinth for attempting to assist me with an answer. Hopefully a Dev will confirm and/or clarify if you understanding of this issue is correct.

[Utherix]

Originally Posted by Kyrm347

Ok then, their statements are starting to make sense to me. Thanks jj8926 and Labyrinth for attempting to assist me with an answer. Hopefully a Dev will confirm and/or clarify if you understanding of this issue is correct.

I would like to know as well.

[raculot]

Originally Posted by Uli

Why is there a Client Development Team Then?
Shouldn't they be moved into different Sector's since what they are technically doing something that is not going be related in anyway to the SWGEmu Networks.

Also

"Reusing the same graphical artwork to create a new item is doable" that is classed as a client mod as well (Just wanted to add that onto the end of "doable")

I would like to know this as well. It does seem to be in conflict with previous statements on the subject.