Ryzom

this thread is for some offical responses to our feedback... if any is going to be given of course.

the feedback threads have had a couple of days to ferment on the general forum now and i think that youve had most of the replys your going to get it turns from feedback to wishlists if you leave it too long wouldnt it be time to make descisions based on the feedback and implement a patch to the ats and get it tested out ASAP? ;P

just my 2 pennys worth

I'm just hopelessly confused that changing a monsters spawn point actually takes time to implement

amitst wrote:I'm just hopelessly confused that changing a monsters spawn point actually takes time to implement

If its part of the database etc (coordinates, roam distance, spawn time etc) then surely it makes sense it has to wait for a patch date, doesn't it?

grimjim wrote:If its part of the database etc (coordinates, roam distance, spawn time etc) then surely it makes sense it has to wait for a patch date, doesn't it?

If it's strictly a change in the database, which I would imagine these things are, that's the kind of thing they should actually be able to do dynamically.

I suppose they could have written it such that these things are queried once and then held in memory. If that's the case, then it would require a server restart for these database changes to take effect (i.e. patch cycle). However, it's really poor data access design if there's no way to flush out cached values without a restart and I've got to give them the benefit of the doubt that they wouldn't have done that.

From the letter Jessica wrote, it sounds like their internal tools for managing content are somewhat lacking. I imagine once they create better tools, we just might see things become more dynamic outside of the patch cycles.

grimjim wrote:If its part of the database etc (coordinates, roam distance, spawn time etc) then surely it makes sense it has to wait for a patch date, doesn't it?

db or not, building a patch is nearly a ritual. DEVs sure work with something like a CVS (Concurrent Versions System). The spawns are probably allready fixed it the CVS, but they have to wait until the last planned fix/change is in the CVS. Then the source will be freezed and a patch will be build out of the frozen snapshot of development. Another thing is, that there is a client- and a serverside patch. This all is about logistics.

micrix wrote:db or not, building a patch is nearly a ritual. DEVs sure work with something like a CVS (Concurrent Versions System). The spawns are probably allready fixed it the CVS, but they have to wait until the last planned fix/change is in the CVS. Then the source will be freezed and a patch will be build out of the frozen snapshot of development. Another thing is, that there is a client- and a serverside patch. This all is about logistics.

I work as a developer so I understand source control and use it everyday (used to be CVS, now Perforce and sadly, a short stint on Microsoft's VSS). I also know that a source control system is almost never used to manage database assets. In fact most don't even have the ability to do revision control on data in a database.

Of course if there's code change, that has to go through a proper revision control process. Data change, however, should not have to go through such a rigorous process, especially if proper interfaces are made to the data (i.e. no a raw SQL interface).

If I told the buyers at my company that every time they wanted to add new product to our store, they had to wait for the next patch cycle, well, I'd probably have my resume more up to date than it is Instead, there's interfaces to the database that allow them to go in and manage the product data without needing to understand about the database particulars and without having to be hampered by the rigid control process that is necessary for smooth code management.

aylwyne wrote:I work as a developer so I understand source control and use it everyday (used to be CVS, now Perforce and sadly, a short stint on Microsoft's VSS). I also know that a source control system is almost never used to manage database assets. In fact most don't even have the ability to do revision control on data in a database.

Of course if there's code change, that has to go through a proper revision control process. Data change, however, should not have to go through such a rigorous process, especially if proper interfaces are made to the data (i.e. no a raw SQL interface).

If I told the buyers at my company that every time they wanted to add new product to our store, they had to wait for the next patch cycle, well, I'd probably have my resume more up to date than it is Instead, there's interfaces to the database that allow them to go in and manage the product data without needing to understand about the database particulars and without having to be hampered by the rigid control process that is necessary for smooth code management.

First my condolence to VSS

Well, what should i say ? The software does not support streaming update atm. And a daily down- and patchtime doesnt sound useful and is more work to do.

While the routines concerning the database can be managed within the CVS i belief that the reorganization of the database itself is done manually. And i dont want to switch place with that person ever. Even not for a free livetime subscription

I only posted this to show that simple changes can take a little longer if you need to wait for codefreeze

VSS?

*horrific flashbacks to website work*

<Vader> NOOOOOOOOOOOOOOOOOOO!!!! </Vader>

micrix wrote:Well, what should i say ? The software does not support streaming update atm. And a daily down- and patchtime doesnt sound useful and is more work to do.

Things like changing a mob spawn location, timer, etc. shouldn't require any kind of streaming update to the client at all. That should be completely server-side. Our clients don't control spawn rates/locations or need to know anything about them. When the server decides a new mob should appear, it tells our clients and our client just displays it.

micrix wrote: ...i belief that the reorganization of the database itself is done manually. And i dont want to switch place with that person ever. Even not for a free livetime subscription

I only posted this to show that simple changes can take a little longer if you need to wait for codefreeze

Agreed. Fortunately, that looks to be a problem they're trying to solve right now. Right now, I imagine that they have fairly rough tools for modifying the database. They might be as rough as simply using a SQL interface to execute update statements, although I'd hope they're at least beyond that But it was stated that they're working on tools to help manage and develop content.

grimjim wrote:VSS?

*horrific flashbacks to website work*

<Vader> NOOOOOOOOOOOOOOOOOOO!!!! </Vader>

Thought that was Luke...
Sounds like Black Box Theory to me... trying to determine the logic based upon observations. Poor Schrödinger's Cat... *last brain cell pops!*

-Raku