explain parsing mechanism, so i dont forget it.
This commit is contained in:
		
							parent
							
								
									39b1f57b50
								
							
						
					
					
						commit
						ff0b0bfd19
					
				| @ -4,6 +4,37 @@ Logs Submodule | |||||||
| The Logs Submodule is the core parsing mechanism in Scon. | The Logs Submodule is the core parsing mechanism in Scon. | ||||||
| It defines classes for opening logfiles from zips, directories, or as a stream, and are intended to be used by higher level apis to adjust to the wanted log retrieval scenario, while keeping the base logic how logs are interpreted unified. | It defines classes for opening logfiles from zips, directories, or as a stream, and are intended to be used by higher level apis to adjust to the wanted log retrieval scenario, while keeping the base logic how logs are interpreted unified. | ||||||
| 
 | 
 | ||||||
|  | The Parsing Mechanism | ||||||
|  | --------------------- | ||||||
|  | In this example, parsing complete files: | ||||||
|  | 
 | ||||||
|  | 	* Sessions represent a container which hold logfiles from the same directory. | ||||||
|  | 		-> it has a parse_files method which initiates first pass parsing for the given filenames in the package. | ||||||
|  | 		-> only 'game.log', 'combat.log' and 'chat.log' are supported for now as session.game_log, session.combat_log and session.chat_log. | ||||||
|  | 		-> you can only parse one of those files, e.g. first only game log, later combat or chat. | ||||||
|  | 	* Logfile class directly has 'lines' property holding all the 'lines from the log'. Each kind of logfile has its own subclass in logfiles. | ||||||
|  | 	* this lines list is converted from a string list to dictionaries, containing log, logtype, and timestamp data in the first parsing. | ||||||
|  | 	* these dicts are scanned by the class factories and replaced with class based representations of the log packet, coming from their submodule. | ||||||
|  | 		-> the dict is moved into the dict .values of the created class. | ||||||
|  | 	* usually at this point, one would discard all dicts, as they represent unknown or unimportant data, what you have left is a list of classes. | ||||||
|  | 	 | ||||||
|  | 	from here, all lines contain some instance of a class, already telling us, which kind of log this is | ||||||
|  | 	however to update the rest of the log information, one has to at least call "unpack" once on the instance. | ||||||
|  | 	having this finetuned in multiple steps however allows us to gain speed by ignoring unwanted information (as combat logs e.g. tend to be large) | ||||||
|  | 	all other functionality is planend to be in the high level api .game | ||||||
|  | 	 | ||||||
|  | 	e.g.: | ||||||
|  | 	for line in game_log.lines: | ||||||
|  | 		if isinstance(line, Log): | ||||||
|  | 			if line.unpack(): | ||||||
|  | 				print(line.values.keys()) | ||||||
|  | 	 | ||||||
|  | 	-> unpack can be called several times, as it only unpacks once. | ||||||
|  | 	 | ||||||
|  | 	 | ||||||
|  | 	 | ||||||
|  | 
 | ||||||
|  | 
 | ||||||
| For the programmer, following submodules are of particular interest | For the programmer, following submodules are of particular interest | ||||||
| 
 | 
 | ||||||
| Game | Game | ||||||
|  | |||||||
		Loading…
	
		Reference in New Issue
	
	Block a user