Customs Package Standard

[znromonk]

We all know that customs go to different folders depending on the type item (class sprite, monster, item, map). Also, adding custom items is not as easy as copy the files from one location to another and replace any existing files. It involves adding specific lines to different files individually (eg. the idnum2*, num2*, lua files et al.). If I am adding tens of different customs from different sources, it becomes a difficult and time consuming job.

So, here is my proposals for packaging and distribution of customs.

The directory structure.

PackageFolder
 |___package.ini
 |___item.act
 |___item.spr
 |___any_other_files

package.ini (text to be appended, custom type, and spr/act locations which would be interpreted by a tool - see plans below)

[type]
item

[id]
1101

[description]
A basic one-handed sword.
Class :^777777 Sword^000000
Attack :^777777 25^000000
Weight :^777777 50^000000
Weapon Level :^777777 1^000000
Required Level :^777777 2^000000
Applicable Job :^777777 Novice, Swordman Class, Merchant Class, Thief Class^000000

[displayname]
Sword

[resname]
¼Òµå

[act]
locations where act file should be copied

[spr]
locations where spr file should be copied

Proposal 1

If someone could make a tiny tool that could copy the spr/act and append the respective files, that would be great. The tool could be used like the Thor patcher. The spriter could pack the custom files as a small executable which is compiled like the "Config Embeder" from Thor. The user/client just runs the executable and all the copy/edit is done on the fly.

Pros

• Easy for the end-user
  

Cons:

• Added work for the spriter
  
• Executables are not the most trustworthy file types. If the RO client is installed in the restricted directories, the application would require elevated rights. Not really desirable.
  

Proposal 2

Spriters package the customs as an archive following the directory structure above or a more agreeable one. Make a small tool available client-side that reads the archive and takes the necessary actions.

Pros

• Less work for the spriter
  

Cons:

• Same as Plan 1 about the Executable nature of the tool.
  

Conclusion:

I have realized that it is not the best of times to request this change and that private servers use GRF and not data folders (so do the new clients) (a grf version of the tool ??). But, I've had this thought for a very long time and thought I should put it out there. Also, I would have attempted to make a prototype of the tool myself if my coding skills weren't amateurish.

[GreenBox]

That's great idea \o/

I prefer it like a package manager: ropm install customs.pkg

Then the customs.pkg is just a rpm like file with a package.ini file that contains the all item data and can install to item_db2/idnum2*/num2*/lua all data needed.

[znromonk]

Thanks for the comment.

A filetype would be nice. But to not force the users to download a software to open the package, it could be based on one of the archiving filetypes. Just like you could open a setup executable with 7z because it is multiple files "packed" into one. In any case a software like winzip/7z should be made to open the files and do what is mentioned in the ".ini" file.

[GreenBox]

Users must use the package manager to install the package, there is no way to do this perfectly without an executable.

Is the same risk as when you download some tool from rAthena Downloads.

[Lemongrass]

oh some guy with the same idea as me. just wait a little longer something is approaching soon.

[Euphy]

I agree with Greenbox. So long as we provide an "official" executable and/or release the source, a Package Manager program seems the best way to go.

As much as I like the idea of having all the information provided by the spriter, lots of additional information will likely be added/modified by the end user in nearly all cases. While I suppose things like ID and description could be provided, it may be more useful to have options in the packaging program to directly edit these fields.

[znromonk]

Euphy, your post has actually brought up a very good point.

If the spriter gives an item with ID 1500, but the ID is already used by another custom item on the user side, there would be a conflict. We could use incremental addition to the client-side files, but that also has a problem which I will explain next. In case of a conflict, another ID has to be chosen. Now this causes a problem.

IF it is a private server, the change in IDs client side (while server-side IDs remain the same) can cause gravity errors.

The only solution I see is to create a public database table of the custom items (this would be easy for rA since they host the IP Downloads) and give them IDs. So when the package installer tries to install a custom item, it will fetch the ID from the rA database. This will eliminate the ID conflicts, and server-side and client-side mismatches, provided the user does not manually add items to the client-side files. But ofcourse, the PServers need to keep thier item_db IDs in accordance with the rA custom item database.

The user/spriter could override this option by giving a static ID in the ini file too (like original plan as shown in the first post).

[Euphy]

A database of custom items/IDs seems a bit unreasonable. There's no way that everyone would abide to it, nor should they have to. I was thinking more of an input section in the package-extracting program, where an ID could be specified. Actually, if someone could write the program to display all the changes it would make and allow editing, that would be fantastic.

[GreenBox]

There is no need for that, customs in each package should start with id 0, the PM will detect the last used ID and start adding by it.

[znromonk]

@GreenBox, @Euphy

The main reason for a common database is:

If the ID is dynamically added (incrementally), shouldn't the ID of the same item match that on the server side ? If the user has more items on his/her client-side, IDs won't match and cause issues.

@Euphy

You are right in having visual tool to see what changes are being done. Since, IDs are the ones that can cause problems, maybe one with the options like so ?

|-----------------------------------------------------------------------|
|  Package Tool - Conflict Found				_ [] X	|
|-----------------------------------------------------------------------|
|Recommended ID: _________________(As in the server db)			|
|Current ID: _________________(As expected incrementally)		|
|									|
|[ ] Shift Other IDs down (Radio Buttons)                |
|[ ] Replace ID                                |
|[x] Add Incrementally                            |
|					_________	___________	|
|					|   OK	|	|  Cancel |	|
|-----------------------------------------------------------------------|

Edited June 23, 2012 by znromonk

[DarkIrata]

Why not making a main packing tool which can compile and decompile files.

Also allow to write directly to the files which needed to be edit with a easy insert.

This would be much much easyer for all. You dont need a high quality program what check all, only a simple tool ~

For Spriter:

- Easy to place the files in on or 2-3 folder or by choose self the files~

- Click on compile

~ CustomSpriteXYZ.dafuq

For Server Owner:

- Choose folder (test data folder as example)

-[ Application auto detect needed .txt and .lua files ]

- Owner put needed information to the fields

- Choose the CustomSpriteXYZ.dafuq file

- Click on Decompile

~ Application insert in each .txt and .lua files a string with the name (from the information) and the files in the right folder

Only what the Owner would need more then only that tool would be a config file where he can put from which ViewID the application should go on

or by detecting it by itself (string split)

Wouldnt it be much easy?

Sry for my bad english, tired as hell ^^

Edited June 23, 2012 by Irata

[znromonk]

@Irata,

The 2 proposals I gave in my OP is exactly that. The issue we are currently discussing is ID duplication, ID mismatch with server's db and how to resolve it.

[DarkIrata]

My fail, not understand yours correctly ^^

MySQL ID check is easy. Also for the files. If you let the Server Owner write by him self from wich id the application should go on.

I really dont see any problems which really hard to solve ^^

i mean, its not hard to open a file read the last line and check for the last letters or numbers ^^

If you want i could make a example tool, currently i have much time ^^

Forogot it, had enough time, here a example tool > http://www.mediafire...vwc7yt3ikyjfkp2 < not fully working, but for a example its enough.

Easy file Compiling to a Zip and Decompiling. Auto Item ID Detection, Auto Data folder inserting (currently only example data).

Small problems like the idnum2itemresnametable and other files need a Ansi text encoding for the Auto Item ID Detection.

Really i dont see any problems to make a tool like this, i know my example is... not the best.. but it shows thats it possible, also for a Dev Newbie ^^

Edited June 23, 2012 by Irata

[chriser]

Hi guys, i am currently developing such a tool approx.

 

A bit of history:

We are building up a new server, and i am responsible for all the client and server stuff (core, client patching, database).

I get tons of sprites from the other guys to get them ingame, but after about 100 sprites written in all the files, i decided to build a tool that does the work for me. Currently,I have a working console app, on which I can drag a folder/list of sprites and it asks for every sprite the Name, Description, Type, etc...

I coded it for my needs, as I get the complete correct folder structure for the sprites from the other guy. I just got the idea of checking rAthena Forums, maybe there is such a tool and I don't have to optimize my solution.

I saw this, and I will continue on this idea, because I think this would be great for ALL the poor guys who have to write tons of sprites in all the files.

 

Created a googlecode project with my code sofar (it's C#, and its very pre-alpha): https://code.google.com/p/rathena-item-generator

 

It would be cool if there would be other guys with knowledge of C# and are interestent in participating on this project.

Just PM me here and tell me something about you (C# knowledge, rAthena knowledge, RO knowledge, personal things if you want, etc)

 

Greetings

chriser

Edited March 16, 2013 by chriser