Task for Devs: Implement new ST 'pRO' and 'bRO'

[kLabMouse]

Because of Recent changes in Client binaries We need to Implement
New ServerTypes, using new ServerType system
1) Server pRO -- ServerType pRO
2) Server bRO -- ServerType bRO

As They are using RE clients and packets, We can copy some functions from kRO server types.
New Server Types must inherit only from ST0, because Support of numbered ST's will be dropped upon release.

(optional)
As some servers use different data and tables, we also need to Implement loading of Table files (except for servers.txt) from their folders (Example for pRO: /tables/pRO/*.* ) if some data do not exist there, then load it from tables root.

All of These features, must be implemented before 2.1 Release.

[kLabMouse]

ServerTypes for pRO,bRO and rRO where implemented by EternalHarvest
Loading of Server specific table files by kLabMouse

Please note. That we need to fill Server specific tables. (structure like kRO or twRO has).

Also, we need Supporters to test out all server specific features, and help developers resolve some issues.
Anyone?

[Technology]

nice, this is exactly what the "every server supporting kore" needs, finally separated npc/monster/portals/...
But there is something else it needs, a hand full of supporters...
Just a few people that represent their server.
So get to work damnit! (i kid, i kid...)

just committed a patch that should fix the addTableFolders option, bah thats why it wasn't working at first...

Code: Select all

Index: functions.pl
===================================================================
--- functions.pl	(revision 7069)
+++ functions.pl	(working copy)
@@ -421,8 +421,7 @@
 			push @new_tables, $dir . '\\' . $st_type;
 		}
 		# now set up new path to table folders
-		@new_tables = (@new_tables, Settings::getTablesFolders());
-		Settings::setTablesFolders( @new_tables );
+		Settings::setTablesFolders(@new_tables, Settings::getTablesFolders());
 	}
 	
 	# Process adding Custom Table folders
Index: Settings.pm
===================================================================
--- Settings.pm	(revision 7069)
+++ Settings.pm	(working copy)
@@ -306,7 +306,7 @@
 }
 
 sub addTablesFolders {
-	return @tablesFolders = (@tablesFolders, split($pathDelimiter, shift));
+	return @tablesFolders = (reverse(split($pathDelimiter, shift)), @tablesFolders);
 }
 
 sub getTablesFolders {

and while we are at reorganizing tables
lets rename all the table grf extracted table files back to their original name? (allow for easy extracting)

items.txt -> idnum2itemdisplaynametable.txt

and lets prefix the kore/RO client hardcoded ones with a context tag and choose logical names?
(to allow for easier searching, since these are the ones we adjust manually)
just an example: (TAG_purpose||contents)

equiptypes.txt -> ITEM_equipid2name.txt
headgears.txt -> ITEM_id2viewid.txt
itemtypes.txt -> ITEM_typeid2name.txt

any better format suggestions?

Code: Select all

[kore or RO client files]
equiptypes.txt			ITEM_equipID-name.txt
headgears.txt			ITEM_ID-viewID.txt
itemtypes.txt			ITEM_typeID-name.txt

spells.txt				SKILL_spellID-name.txt
skillailments.txt		SKILL_ailmentID-name.txt
skillstatus.txt			SKILL_statusID-name.txt
skillslooks.txt			SKILL_lookID-name.txt
skillsstate.txt			SKILL_stateID-name.txt
skillsencore.txt		SKILL_encore_handle.txt
skillsarea.txt			SKILL_area_handle-type.txt
skills.txt				SKILL_ID-handle-name.txt		(grf: skillnametable.txt - handle - name | RO client: ID - handle)

emotions.txt			MISC_emotionID-name.txt
sex.txt					MISC_sexID-name.txt
haircolors.txt			MISC_hairID-name.txt
directions.txt			MISC_orientationID-name.txt
elements.txt			MISC_elementID-name.txt

monsters.txt			NPC_monsterID-name.txt
npcs.txt				NPC_map-coordinates-name.txt

recvpackets.txt			PACKET_ID-length.txt
packetdescriptions.txt	PACKET_ID-description.txt

cities.txt				MAP_rsw-name.txt				(grf: indoorrswtable.txt - rsw | we can add cities ourselves and let kore combine both)

servers.txt				
portals.txt				
portalsLOS.txt			
commanddescriptions.txt	

[grf files]
itemslots.txt			itemslottable.txt
maps.txt				mapnametable.txt
itemslotcounttable.txt	itemslotcounttable.txt
itemsdescriptions.txt	idnum2itemdesctable.txt
items.txt				idnum2itemdisplaynametable.txt
quests.txt				questid2display.txt
resnametable.txt		resnametable.txt
skilldescriptions.txt	skilldesctable2.txt
skillsp.txt				leveluseskillspamount.txt

also, maybe we can we make %skillSP_lut obsolete?

Code: Select all

	Settings::addTableFile('skillssp.txt',
		loader => [\&parseSkillsSPLUT, \%skillsSP_lut]);
	Settings::addTableFile('skillssp.txt',
		loader => \&Skill::StaticInfo::parseSPDatabase);

[Technology]

Please note. That we need to fill Server specific tables. (structure like kRO or twRO has).

Also, we need Supporters to test out all server specific features, and help developers resolve some issues.
Anyone?

Why make a list of people that volunteer to extract the latest table files for a server this time. (till supporters kick in)
kRO: Technology
euRO & rRO: EternalHarvest


note: however maybe we can do some renaming in kore before start doing this, otherwise its 2x work

[kLabMouse]

note: however maybe we can do some renaming in Kore before start doing this, otherwise its 2x work

True. But! Some users will have problems updating Kore.
I Suggest make an a File Alias Option, so Kore will support both files.

Or Better Implement it just before 2.1 Release?

[kali]

Just implement before 2.1 release

Why do we have to use TAG system - maybe just make a readme that explains what all these files are (or maybe a header comment). That way we can even try and read the files from a grf directly (no need to extract, just give kore the path to your data.grf)

[Technology]

Just implement before 2.1 release

Why do we have to use TAG system - maybe just make a readme that explains what all these files are (or maybe a header comment). That way we can even try and read the files from a grf directly (no need to extract, just give kore the path to your data.grf)

the thing is, these files with a TAG are not extracted from a grf, they are hardcoded data in the RO client.
And being able to read directly from the grf is exactly why i proposed to rename the grf extracted files back to their original name.
As you might or might not know, i've been experimenting with grf perl bindings but it wasn't successful in the end.
I never said we have to use the "TAG system", i only suggested some possible naming convention to open up discussion about it among the developers.
Because a name like for example headgears.txt isn't exactly clear to be honest. Why did i choose such tag system? To split up the files in categories so they would be easier to look up and so you can easily see which files are extracted from grf and which aren't and also what is contained in the files or what they are used for.

[kali]

I see. Yeah, that would make it more understandable

I thought tags were to be used from files that can be directly extracted from the grfs, my bad

[kLabMouse]

Then there is Another Question, or better say 'Task'.
To Dump Client hard coded Tables we also need a tool to do that task.

[dejaime]

I have bRO installed and fully up-to-date and maybe a couple hours a day, how can I help?