L2J Server

Actually, almost all static database will be moved in the xml.

Hmm, so somebody is actually thinking about doing it?
Interesting...

Well, that'll stuff the dropcalc then.

It relies on the databases. Without them, it's useless.

Importing the XML was difficult, with some coders using ", others using ' and various codes in different orders, made writing a parser difficult.

So ... in order for the dropcalc to work, all the XML data has to be parsed back into ... databases!

I might as well throw in the towel now.

I'm going to grab a bottle of wine and get pi**ed.

That'll be a few years of work down the toilet then.

I knew I shouldn't have put the effort in to bringing the dropcalc up to date.

i agree with you msknight

and for that reason I don't like some static data in XML files (because this is not static always) and when this data change in client, and if you want to compare XML data with Client, you need to convert XML to database (SQL) so double work

so I prefer SQL because is more friendly to work with PHP websites (drop calculators and related things)

You guys have really hacked me off.

All that work. Wrecked.

PHP has a maximum run time of only a few seconds, as set in the PHP.ini file. There is no way on this earth that I can write a routine that will import a large XML file.

It was difficult enough when you took the recipes out ... at least splitting the files in to blocks of numbers, I had a chance to recursively call the same chunk of code with each number block in turn ... if you take some of the larger static stuff in to XML ... I stand no chance.

That news has really upset me. XML. Pah.

...and another thing ... I have a chunk of customising SQL code that removes some of the mobs ... how am I going to manage that in an XML file? It was bad enough having to re-edit the skill for the healing potion, before you put the code back in and made it an option in the server config.

If I've got to edit XML files to alter raid boss respawn times, remove mobs and all the other stuff that I do ... that makes administering a server a whole load more difficult.

Previously, I just loaded up my custom sql file and ran it. Job done in a few seconds.

Now, you tell me I'm going to be consigned to editing loads of XML files ... probably by hand.

That sucks.

I'd like to apologise for the tone of my language last night.

It was mostly alcohol and depression talking.

The fact remains, however, that if the data is taken in to XML, it will render practically all dropcalc functionality useless.

To work, it would need to import large XML files which, with the 30 second execution limit of PHP, would be impossible. It was actually the quests which I was able to re-work with a self-recurring system.

Plus, even if that were done, it would be practically impossible for an administrator to change any XML data with the dropcalc; they'd have to be on the server itself, defeating much of the benefit of having a web system to administer the world.

Also, with various coders using different standards and orders in the XML that has already been coded, to try and write an efficient XML parser in PHP is like trying to cut wood with a blunt axe.

Personally, I'd like to see the XML already written put back in to database format.

By the way, one of the recipe imports failed. YOu might want to look at the XML behind it. Perhaps it is a duplicate name or something...

Failed - insert into knightrecch (`rec_name`, `rec_id`, `rec_item`, `level`, `makes`, `chance`, `multiplier`, `xml_id`) values ('pata i', '5008', '0', '4', '264', '60', '1', '436')
1000 recipes, made of 6258 items found.
999 recipes, made of 6258 items imported.

Taking the data to XML is a seriously bad move for any system which aims to support both the game, and the player.

A dropcalc is very important to the continuity of a game. Lock out the dropcalcs and to those who are new to L2J, you've got an unplayable game. Why do you think I came to L2J in the first place ... if you can't work out where the drops are on legitimate L2, the game is impossible to play without literally devoting your whole life to it.

At that stage it becomes not so much a game, more an obsession. Look what is happening in Korea now; a population addicted to on-line gaming. By locking out the dropcalcs, the game goes from being an all time classic star in the sky, to one of the worst life-sucking drudges out there.

There is nothing worse than following instructions given by a passive dropcalc and going on a farming grind, to later find out that the mob doesn't even drop what you want, or that the rates are completely wrong and you stand a 0.003% chance instead of a 1%.

The dropcalc needs to be able to talk with the same, live, data that the server instance is using.

Without that kind of support, the whole thing is pointless IMHO.

There are no xml read and parse subroutines in php ? As well as its not possible to import them in the temporary tables and refresh on demand or once per day ?

Also, i does not use dropcalc on my server, but other private php site, utilizing html caching system. Should sort of cache be added to the dropcalc, reducing db and cpu usage ?

with the 30 second execution limit of PHP, would be impossible.

http://php.net/manual/en/function.set-time-limit.php

The 30 second is there for a reason ... preventing a php script from hogging the server if something goes wrong.

I don't think it is reasonable to ask people to up this limit in order to run the dropcalc.

Also, running an import function every 24 hours is not good. There will be some point during the 24 horus where players on some servers will experience a slow down. Where is this data supposed to be, "cached," if not in a database? Can you expand on that idea please?

Also, the 30 seconds is 30 seonds on the processor. A slower processor will execute less than a faster processor in that 30 second time limit. I hit this problem before.

Well, in PHP5 there are libraries for XML like SimpleXML and like DS said, some caching system would help a lot but yea, I have to admit that retrieving some specified data from database is much much easier than from XML.

RiZe ... could you help me understand this, "caching," thing please? I can't get it in my head as to where this data would be cached, if not in a database.

It might help me if I could understand this further.