Configuration data detection method and device, equipment, medium and product

Abstract

The invention relates to the technical field of computers, and discloses a configuration data detection method and device, equipment, a medium and a product, and the method comprises the steps: obtaining an original configuration file obtained through conversion based on source configuration data; the original configuration file comprises at least one sub-configuration file; respectively creating a corresponding file processing thread for each sub-configuration file in the original configuration file; analyzing the original configuration file to generate a target configuration file in a standardized format corresponding to the sub-configuration file; based on the file processing thread, detecting the target configuration files according to a corresponding detection rule, and determining a detection result of each target configuration file; and generating a detected configuration file according to the detection result of each target configuration file. According to the method and the device, the configuration file can be timely and quickly detected, the detection requirements in various items can be flexibly adapted, and the universality is relatively high.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to methods, apparatus, equipment, media, and products for detecting configuration data. Background Technology

[0002] When a game runs, a configuration file is typically needed as a source of some of the game's data. In various game projects, configurations are usually edited based on spreadsheets (such as Excel), and the configured content is exported as a configuration file that the code can directly read (such as a JSON file) so that the game can read it during runtime.

[0003] Because configuration content may contain errors, it is necessary to perform necessary data checks on the configuration content. Current data checks can easily introduce uncertainty into the normal development workflow and lack cross-project applicability. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, device, medium and product for detecting configuration data to solve the problem of poor universality in configuration data detection.

[0005] Firstly, this application provides a method for detecting configuration data, the method comprising: Obtain the original configuration file derived from the source configuration data; the original configuration file includes at least one sub-configuration file. Create corresponding file processing threads for each of the sub-configuration files in the original configuration file; The original configuration file is parsed to generate a target configuration file in a standardized format corresponding to the sub-configuration file; Based on the file processing thread, the target configuration files are processed according to the corresponding detection rules to determine the detection results of each target configuration file. Based on the detection results of each target configuration file, a detected configuration file is generated.

[0006] Secondly, this application provides a configuration data detection device, the device comprising: The acquisition module is used to acquire the original configuration file obtained by transforming the source configuration data; the original configuration file includes at least one sub-configuration file. A module is created to create corresponding file processing threads for each of the sub-configuration files in the original configuration file. The parsing module is used to parse the original configuration file and generate a target configuration file in a standardized format corresponding to the sub-configuration file; The processing module is used to perform detection processing on the target configuration files according to the corresponding detection rules based on the file processing thread, determine the detection results of each target configuration file, and generate the detected configuration files based on the detection results of each target configuration file.

[0007] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the configuration data detection method of the first aspect or any corresponding embodiment described above.

[0008] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute the configuration data detection method of the first aspect or any corresponding embodiment described above.

[0009] Fifthly, this application provides a computer program product, including computer instructions, which are used to cause a computer to execute the method for detecting configuration data in the first aspect or any corresponding embodiment described above.

[0010] The configuration data detection method provided in this application detects exported raw configuration files, enabling rapid problem identification—detection occurs immediately upon export, ensuring no delay in problem discovery. Furthermore, it is non-intrusive, not requiring intervention in the export process and thus having no impact on it. The detection process is independent of the export process and subsequent game execution, allowing for plug-and-play functionality. It is highly suitable for projects added later without prior data detection design, minimizing disruption to the original workflow. The detection process parses the raw configuration files in a standard format, adapting to various configuration file types. File detection is performed using separate file processing threads, enabling parallel processing without interference between threads. Detection is executed based on corresponding rules, flexibly adapting to the detection needs of various projects. The file detection process is highly versatile and can be used across projects. Attached Figure Description

[0011] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the first process of a method for detecting configuration data according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a second process for detecting configuration data according to an embodiment of the present invention; Figure 4 This is an overall flowchart of file detection after export according to an embodiment of the present invention; Figure 5 This is a schematic diagram of multi-process file management according to an embodiment of the present invention; Figure 6 This is a structural block diagram of a configuration data detection device according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0015] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0016] With the rapid development of the video game industry (including console games, online games, etc.), video games have gradually become a part of people's daily entertainment. Almost all games have configuration files as a source of some data for game operation. At the same time, the existence of configuration files also allows project participants in non-technical positions such as designers to modify game content more flexibly and quickly, optimize the game experience, and build and adjust the game's numerical system.

[0017] Many projects use Excel to edit configurations, then export the configured content (which can be called source data) into file types that other code can directly read (such as JSON, TXT, CSV, Lua, etc.) for the game to read during runtime. The file type of the exported target file can be selected based on the technology and language used in the game. Some game projects may not use Excel, but they still need to export to a file type suitable for the technology chosen by the game project. This shows that the configuration process has significant incompatibility.

[0018] As game development and operation progress, the amount of game content increases, and the complexity and complexity of configuration requirements also rise. Relying solely on manpower to ensure the accuracy of every configuration data point is unrealistic. In daily work, an individual might make mistakes handling two or three spreadsheets, but a game project can easily involve dozens or even hundreds of spreadsheets, and the risk of errors is even higher when multiple teams are working together on modifications. Therefore, it is necessary to perform essential data checks on configuration content to identify obvious problems early (such as ensuring that primary keys in tables are not duplicated and that timestamps do not overlap), reduce human error, and improve the quality of configuration files and overall development efficiency.

[0019] In current game projects, the following methods are generally used to perform configuration data testing in advance: (1) Detection in the export process: The project is independently developed, and data detection logic is added to the export process; (2) Data detection before it takes effect: After the data file is exported, before it is imported into the game and takes effect, an additional step is added to detect the generated data; (3) Data activation detection: In the game logic, add corresponding logic to the places where configuration data is used to detect the configuration data.

[0020] If the project has made technical plans in advance, when exporting to target files (i.e., json, txt, etc. mentioned above), some detection rules can be added to the export tool, that is, detection is performed based on the above method (1). However, this will make the export process more complicated, and the exported content may be wrong due to problems in the data detection process, introducing additional risks; at the same time, adding a data detection process usually requires the implementation of data association checks between tables, which will significantly increase the time consumption of the data export process when the data volume is large, and it is necessary to find a way to optimize the detection speed. In addition, if other projects have different editing tools, they cannot be reused, and the universality is poor; if an old project needs to add detection, the original process will be greatly adjusted, which is easy to introduce a large amount of development and risk items.

[0021] Regarding the above method (2), the timing of problem discovery is delayed, and it is impossible to discover the problem immediately during export and make immediate corrections; similarly, this method also has the problem of poor universality.

[0022] For the above method (3), the problem is discovered later, only when the game is running, and protection code needs to be added to the game logic, which increases the difficulty of maintaining the logic code and introduces uncertainty into the normal development flow; it has poorer universality, as it can only be used in this project and there is no possibility of reuse.

[0023] As an optional application scenario of this invention, such as Figure 1 As shown, application 101 is installed in terminal device 110, and user 130 can interact with application 101 through terminal device 110 and / or access device of terminal device 110.

[0024] For example, application 101 can be arbitrary, such as an application used to inspect configuration data. Figure 1 In the application scenario shown, if application 101 is active, the terminal device 110 can display the interface 102 of application 101. The interface 102 may include various pages that application 101 can provide, such as interactive pages, settings pages, query pages, etc.

[0025] In some embodiments, terminal device 110 is communicatively connected to server 120 to provide services to application 101. Terminal device 110 may be a mobile terminal, fixed terminal, or portable terminal, etc., including but not limited to mobile phones, desktop computers, laptop computers, multimedia tablets, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some embodiments, terminal device 110 may also support any type of interface, and server 120 may be various types of computing systems or servers capable of providing computing power, including but not limited to mainframes, edge computing nodes, computing devices in cloud environments, etc.

[0026] It should be noted that, Figure 1 This is merely an example of an application scenario and does not limit the scope of protection of this invention.

[0027] According to an embodiment of the present invention, a method for detecting configuration data is provided. This method allows for immediate detection of configuration files after exporting them. During the detection process, the configuration files are parsed in a standard format, and data detection is performed on different threads, making it versatile. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0028] This embodiment provides a method for detecting configuration data, which can be used in the aforementioned terminal devices, such as mobile terminals. Figure 2 This is a flowchart of a configuration data detection method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps.

[0029] Step S201: Obtain the original configuration file obtained by converting the source configuration data; the original configuration file includes at least one sub-configuration file.

[0030] In this embodiment, when configuring valid items, the corresponding configuration data can be set based on spreadsheets such as Excel, i.e., the source configuration data. This source configuration data is then converted to obtain a readable configuration file, which, for ease of description, is referred to as the original configuration file. For example, the original configuration file can be a file in formats such as json, txt, csv, or lua.

[0031] For complex game projects, the configuration file may contain multiple sub-files, or sub-configuration files. For example, each table in the source configuration data, or each page in a table, can generate an independent sub-configuration file, which can then be combined to obtain the original configuration file containing multiple sub-configuration files.

[0032] Step S202: Create corresponding file processing threads for each sub-configuration file in the original configuration file.

[0033] In this embodiment, a separate thread for file processing is created for each sub-configuration file. Each sub-configuration file needs its own corresponding file processing thread; for example, there can be a one-to-one correspondence between sub-configuration files and file processing threads.

[0034] In related solutions, the detection code is typically written using scripts. A key reason for this is the low development difficulty and learning curve of scripting languages. However, scripting languages ​​generally involve single-threaded operations such as file loading and reading. Therefore, if there are many files or a large amount of computation, the computation time will be long, and it is easy to enter a state of waiting for file processing to complete, causing computational blockage. This embodiment, by using multiple file processing threads, not only achieves parallel processing, but also ensures that the different file processing threads do not interfere with each other, making it easier to achieve universal file detection.

[0035] Step S203: Parse the original configuration file to generate a target configuration file in a standardized format corresponding to the sub-configuration file.

[0036] Since the original configuration file may have different formats, and even different sub-configuration files may use different formats, this embodiment parses the original configuration file to extract the source configuration data, and then converts the source configuration data into a file of a unified standard format, i.e., the target configuration file. Each sub-configuration file is converted into its corresponding target configuration file.

[0037] For example, the filenames and data of each readable sub-configuration file can be obtained. The file data can then be parsed into a two-dimensional array, similar in structure to an Excel tab with rows and columns. This yields the target configuration file in a two-dimensional array format, meaning the configuration data within the target configuration file is represented as a two-dimensional array. A corresponding data parser can be configured to adaptively transform the data after reading it, based on the original configuration file's structure (i.e., the data parser function), ultimately converting it into a two-dimensional array. For ease of understanding, this two-dimensional array structure can be viewed as tabular data; the target configuration file can be considered a table.

[0038] In this embodiment, each sub-configuration file can be parsed first to generate the corresponding target configuration file, and then the file processing thread can be used for subsequent detection processing; alternatively, each file processing thread can simultaneously perform parsing and detection tasks, and this embodiment does not limit this approach. By standardizing the format, unified detection of different configuration files can be achieved subsequently, ensuring the universality of the detection method.

[0039] In addition to built-in parsers for common configuration file formats (such as JSON, TXT, and CSV mentioned earlier), the system also allows for customized parsers. This means that regardless of whether the final generated file is TXT, JSON, Lua, or any other format, a custom data parsing and conversion module can be written. After reading the configuration file using a multi-process, multi-threaded approach, the file data is passed to the customized data conversion module, which converts it into a two-dimensional array and returns it. This allows the system to enter the data detection task and output the detection results in a multi-process, multi-threaded environment. Therefore, the method provided in this embodiment is not mandatory regarding the stage of the project or the file format used to store the final configuration data. It can be quickly integrated through modular operations, flexibly adapting to various projects and exhibiting good versatility.

[0040] Step S204: Based on the file processing thread, the target configuration files are processed according to the corresponding detection rules to determine the detection results of each target configuration file.

[0041] In this embodiment, rules for detecting configuration files can be pre-set, i.e., detection rules. Since the target configuration file has a uniform format, it is only necessary to set detection rules applicable to this uniform format file, and there is no need to set separate rules for different format types (such as json, txt, etc.).

[0042] The detection rule can be a general rule, such as checking whether the primary key of the table is duplicated or whether there is overlap in time. Alternatively, the detection rule can also include user-defined customized rules, which can point to one or multiple sub-configuration files, depending on the actual situation.

[0043] For a specific file processing thread corresponding to a target configuration file, it can obtain the detection rules corresponding to that target configuration file, execute those rules to detect the target configuration file, and finally obtain the detection result for that target configuration file. Other file processing threads can be processed in a similar manner, and this embodiment will not elaborate on this.

[0044] Step S205: Generate the detected configuration file based on the detection results of each target configuration file.

[0045] After obtaining the detection results of each target configuration file, all the detection results can be combined to generate the detected configuration file, which is the file after detecting the original configuration file. This detected configuration file can then be used as the game's configuration file for the game to run.

[0046] For example, if no anomalies are detected, the original configuration file can be directly used as the final generated configuration file. If some sub-configuration files have problems, they can be automatically corrected, or a reminder message can be generated to instruct manual correction. Finally, the corrected configuration file will be used as the configuration file after detection.

[0047] The configuration data detection method provided in this embodiment detects exported original configuration files, enabling rapid problem detection. Detection occurs immediately upon export, ensuring timely problem identification. Furthermore, it is non-intrusive, not requiring intervention in the export process, and has no impact on the export workflow. The detection process is independent of the export process and subsequent game execution, allowing for plug-and-play functionality. It is highly compatible with projects added later without prior data detection planning, minimizing disruption to the original workflow. The detection process parses the original configuration files in a standard format, adapting to various configuration file types. File detection is performed using separate file processing threads, enabling parallel processing without interference between threads. Detection is executed based on corresponding rules, flexibly adapting to the detection needs of various projects. The file detection process is highly versatile and can be used across projects.

[0048] This embodiment provides another method for detecting configuration data, which can be used in the aforementioned terminal devices, such as mobile terminals. Figure 3 This is a flowchart of a configuration data detection method according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps.

[0049] Step S301: Obtain the original configuration file obtained by converting the source configuration data; the original configuration file includes at least one sub-configuration file.

[0050] Please see details Figure 2 Step S201 of the illustrated embodiment will not be described again here.

[0051] In some optional implementations, step S301, “obtaining the original configuration file obtained from the source configuration data conversion,” may include: determining a root directory for recording the original configuration file obtained from the source configuration data conversion; and obtaining the original configuration file from the root directory.

[0052] In this embodiment, during the export process, source configuration data can be obtained, converted into a readable raw configuration file, and recorded in the corresponding root directory. This root directory is then passed to the subsequent detection process, allowing the raw configuration file to be quickly retrieved from this directory during the detection process, enabling immediate detection after export.

[0053] The data root directory can be passed in via command line, and different operating systems provide corresponding calling methods, allowing you to process it according to your system. After exporting, the detection results can be output by adding a simple detection call; the detection process is easy to integrate, and for users (such as planners), it basically does not add any extra steps, making it simple to implement and highly versatile.

[0054] Step S302: Create corresponding file processing threads for each sub-configuration file in the original configuration file.

[0055] In this embodiment, there are multiple sub-configuration files; and a multi-process + multi-thread approach is used for synchronization detection. Specifically, step S3020, "creating corresponding file processing threads for each sub-configuration file in the original configuration file," includes steps S3021 to S3022.

[0056] Step S3021: Create the main process and multiple child processes.

[0057] In this embodiment, when processing data detection for multiple configuration files, multiple processes can be created to implement file management. Specifically, a main process is created, which serves as the main file manager; and multiple child processes can also be created based on this main process, each of which can serve as a secondary file manager to manage multiple sub-configuration files.

[0058] For example, to speed up computation as much as possible, a corresponding number of processes can be created based on the number of CPU cores on the current device to perform parallel computing; one process serves as the main process, and the rest serve as child processes.

[0059] For each core in the device, a process is created. The advantage of this multi-process approach is that it can more fully utilize the device's performance, improve the utilization of multi-core CPUs, and ensure detection efficiency.

[0060] Step S3022: Assign at least one sub-configuration file to be detected to each sub-process based on the main process, and create corresponding file processing threads for each assigned sub-configuration file based on the sub-process.

[0061] In this embodiment, the main process manages the allocation of all sub-configuration files to determine which sub-configuration files(s) need to be assigned to which sub-processes. For each sub-process, a corresponding number of file processing threads can be created based on the allocated sub-configuration files to ensure a one-to-one correspondence between the two.

[0062] In this embodiment, multi-layered file management can be achieved based on the main process and child processes; by combining various threads (i.e. file processing threads), a general file processing solution can be achieved.

[0063] Step S303: Parse the original configuration file to generate a target configuration file in a standardized format corresponding to the sub-configuration file.

[0064] Please see details Figure 2 Step S203 of the illustrated embodiment will not be described again here.

[0065] Step S304: Based on the file processing thread, the target configuration files are processed according to the corresponding detection rules to determine the detection results of each target configuration file.

[0066] Please see details Figure 2 Step S204 of the illustrated embodiment will not be described again here.

[0067] In this embodiment, a common detection rule can be set for each target configuration file, such as detecting whether the ID is duplicated or whether the column name is duplicated. This common detection rule is a self-checking rule, which only needs to use its own target configuration file. That is, when the file processing thread executes the detection rule, it only needs to complete the detection based on its own target configuration file and does not need to depend on other target configuration files.

[0068] In some optional implementations, for target configuration files that require special rule detection, rules can be customized for specific target configuration files, while also allowing the acquisition of other target configuration files for correlation detection. Some or all of the target configuration files may also have correlation detection rules, which refer to rules that rely on other target configuration files for detection. For example, target configuration file A contains activity time information, and target configuration file B contains activity reward information. If it is necessary to detect whether the reward configuration of target configuration file A is abnormal within a certain period, then data from target configuration file B can be used for correlation detection.

[0069] Specifically, step S304, "based on the file processing thread, performing detection processing on the target configuration file according to the corresponding detection rules, and determining the detection results of each target configuration file," may include steps a1 to a2.

[0070] Step a1: For the first file processing thread used to detect the first target configuration file, if the detection rules of the first target configuration file include associated detection rules, obtain the second target configuration file corresponding to the associated detection rules based on the first file processing thread.

[0071] Step a2: Based on the first file processing thread, perform detection processing on the first target configuration file and the second target configuration file according to the association detection rules, and determine the association detection result of the first target configuration file.

[0072] In this embodiment, the file processing thread that detects the first target configuration file is called the first file processing thread. If the detection rules for the first target configuration file include association detection rules, then it is necessary to obtain other target configuration files associated with the first target configuration file, i.e., the second target configuration file.

[0073] Specifically, the first file processing thread can actively obtain the second target configuration file. After obtaining the second target configuration file, it can perform the association detection of the first target configuration file and the second target configuration file, and finally obtain the association detection result of the first target configuration file.

[0074] In this embodiment, users are allowed to set associated detection rules. That is, the project team only needs to focus on the detection rules of the current project data, without having to consider the running performance and how to obtain other data, such as how to achieve cross-process data query.

[0075] Figure 4 The overall flowchart for file detection after export is shown. Figure 4 As shown, after the project generates readable code data from the data source, it stores the readable code data in the form of configuration files in a preset root directory, which stores the original configuration files. Passing the data root directory to the detection process allows the original configuration files to be retrieved from the root directory. A certain number of processes are then created, and each process is assigned a certain number of sub-configuration files. Corresponding file processing threads are created, and subsequently, each sub-configuration file can be read in parallel based on these file processing threads, and then parsed, detected, and processed to finally output the detection results.

[0076] Optionally, a multi-process file manager can be used to achieve cross-process data acquisition. Specifically, step a1, "obtaining the second target configuration file corresponding to the association detection rule based on the first file processing thread," may include steps a11 to a13.

[0077] Step a11: Based on the first file processing thread, initiate a data acquisition request to the first child process corresponding to the first file processing thread; the data acquisition request is used to obtain the second target configuration file corresponding to the association detection rule.

[0078] Step a12: If the second target configuration file is the target configuration file assigned to the first child process, obtain the second target configuration file based on the first child process and send the second target configuration file to the first file processing thread.

[0079] In this embodiment, if the first file processing thread involves association detection rules and needs to obtain the second target configuration file processed by other threads, that is, cross-thread file retrieval is required. In this embodiment, cross-thread file retrieval is achieved based on multi-threaded, multi-level file management rules.

[0080] Specifically, for the first file processing thread, a data acquisition request for the second target configuration file corresponding to the association detection rule can be initiated to its corresponding first child process, so as to utilize the first child process or even the main process to realize the acquisition process of other files.

[0081] Figure 5 This illustrates a schematic diagram of multi-process file management. For example... Figure 5 As shown, a main process and multiple child processes are created. For ease of description, two child processes are used as an example, namely child process 1 and child process 2. The main process distributes tasks to each child process, assigning the files that each child process needs to process to the corresponding child process, thereby creating the corresponding file processing thread.

[0082] like Figure 5 As shown, there are three target configuration files to be inspected: file A, file B, and file X. Child process 1 needs to process files A and B, so two threads can be created: file processing thread 1 and file processing thread 2. Child process 2 only needs to process file X, so only one thread can be created: file processing thread 3. Each file processing thread generally needs to perform data self-checks on its respective file and can adaptively determine whether special rule checks are required, and whether the special rules are correlation detection rules.

[0083] Figure 5 In this context, file processing thread 1 has association detection rules, meaning it needs to perform cross-file association detection, and it needs to use file X for association detection. It can be understood that file processing thread 1 is the first file processing thread, file A is the first target configuration file, and file X is the second target configuration file.

[0084] At this time, file processing thread 1 sends a data retrieval request to child process 1 (i.e., the first child process) to obtain file X. Figure 5 In step ①), subprocess 1 can obtain the file X (i.e. the second target configuration file) through the multi-process management mechanism, and then return file X to file processing thread 1 for association detection.

[0085] If the second target configuration file is a target configuration file assigned to the first child process, then the second target configuration file can be obtained directly based on the first child process without needing to cross processes.

[0086] by Figure 5 As shown in the example, if child process 1 receives a data retrieval request for file X, it first checks whether file X exists within its own system (i.e., ...). Figure 5 Step ②), for example, checking if a file processing thread exists to process file X. If file X exists internally, it can be determined that the second target configuration file is the target configuration file assigned to the first child process, and file X can be read directly; otherwise, it means that the second target configuration file is not the target configuration file assigned to the first child process (e.g., ...). Figure 5 As shown, file X has not been assigned to child process 1), so step a13 needs to be executed.

[0087] Optionally, step a12, "obtaining the second target configuration file based on the first subprocess", may include steps a121 to a122.

[0088] Step a121: Based on the first child process, forward the data acquisition request to the second file processing thread used to detect the second target configuration file.

[0089] Step a122: Send the second target configuration file to the first child process based on the second file processing thread.

[0090] In this embodiment, if the second target configuration file is the target configuration file assigned to the first child process, it means that the first child process has created a second file processing thread for detecting the second target configuration file. That is, the second file processing thread is a thread inside the first child process. Therefore, a data acquisition request can be directly sent to the second file processing thread to obtain the second target configuration file returned by the second file processing thread without needing to cross processes.

[0091] Step a13: If the second target configuration file is not the target configuration file assigned to the first child process, the first child process forwards a data acquisition request to the main process to obtain the second target configuration file from the main process and sends the second target configuration file to the first file processing thread.

[0092] In this embodiment, if the second target configuration file is not the target configuration file assigned to the first child process, the first child process needs to forward the data acquisition request to the main process to perform cross-process communication and realize cross-process file acquisition.

[0093] Optionally, step a13, "forwarding a data acquisition request to the main process based on the first child process to obtain the second target configuration file from the main process", may include steps a131 to a134.

[0094] Step a131: Forward the data acquisition request to the main process based on the first child process.

[0095] Step a132: Determine the second child process for allocating the second target configuration file based on the main process, and forward the data acquisition request to the second child process.

[0096] Step a133: Based on the second child process, forward the data acquisition request to the second file processing thread used to detect the second target configuration file.

[0097] Step a134: The second target configuration file is sent to the second child process based on the second file processing thread, so that the second target configuration file is sent to the first child process in sequence through the second child process and the main process.

[0098] In this embodiment, when retrieving files across processes, it is necessary to combine the main process and multiple child processes to achieve multi-layered file management.

[0099] Specifically, continue with Figure 5 As shown in the example, since the required file X does not exist within child process 1, child process 1 needs to send a request to the main process to obtain file X (i.e., Figure 5 After step ③), the main process determines the child process corresponding to file X, that is, the second child process that allocates the second target configuration file (file X). Figure 5 In this context, child process 2 is the second child process. Therefore, the main process can forward data retrieval requests to child process 2 (i.e., ...). Figure 5 Step ④ in the process. Subprocess 2 further determines the second file processing thread used to detect the second target configuration file, namely file processing thread 3, and forwards the request to obtain file X to it (i.e., Figure 5 (Step ⑤) can then feed the file X of this process back to the main process, and then through the first child process, finally send it to the first file processing thread.

[0100] Optionally, the method further includes steps b1 to b2.

[0101] Step b1: For the second file processing thread used to detect the second target configuration file, upon receiving a data acquisition request for obtaining the second target configuration file, it determines whether the second target configuration file has been loaded.

[0102] Step b2: If the second target configuration file has not been fully loaded, cache the data retrieval request, and respond to the cached data retrieval request after it has been loaded to return the second target configuration file.

[0103] In this embodiment, if the file processing thread completes the loading and parsing of file data (e.g., parsing it into a two-dimensional array), the required data, i.e., the second target configuration file, is returned immediately; if the loading and parsing are not completed, the request is cached and the data is returned only after the loading is complete. like Figure 5As shown, file processing thread 3 (i.e., the second file processing thread) needs to check whether the data loading is complete, that is, whether file X has been loaded. If not, it waits for loading until it is complete. If loading is complete, it returns the data, that is, returns file X to the main process (i.e., ...). Figure 5 Step ⑥). The main process then returns file X to child process 1 (i.e., ...). Figure 5 Step ⑦ in the process will eventually return file X to file processing thread 1 (i.e., ...). Figure 5 Step ⑧ in the process enables cross-process file querying and retrieval.

[0104] In this embodiment, the design based on a multi-process + multi-threaded simultaneous operation mechanism significantly improves the detection speed compared to ordinary serial data detection. Furthermore, the benefits become even more pronounced as the data volume and the complexity of the detection rules increase.

[0105] Step S305: Generate the detected configuration file based on the detection results of each target configuration file.

[0106] Please see details Figure 2 Step S205 of the illustrated embodiment will not be described again here.

[0107] Optionally, the method may further include: caching the child process after it has completed the detection task of each of the assigned target configuration files; and destroying the main process and each child process in response to a destruction command for the main process.

[0108] Unlike traditional processes that are destroyed directly after a task is completed, in this embodiment, the child process is created by the main process. If the main process is not destroyed, the child process will be cached. As long as the main process is still running, the existing child process can be directly used the next time the child process is called, that is, the necessary detection tasks can be directly assigned to it, reducing the time consumption of child process creation.

[0109] Specifically, in this embodiment, an executable program can be provided. This program can pass the folder path of the executable file (i.e., the root directory of the original configuration file) through the command line and perform the detection in the background. As the execution is completed, the child process will be cached for the next use. The corresponding child process will only be destroyed when the main process is destroyed.

[0110] For example, it can be executed through the front-end interface. That is, after clicking through the provided interface, the original data export script of the project is invoked, and the subsequent process is executed according to the folder path. When the interface is not closed, after the detection is performed once, the sub-process will be cached for the next use. That is, the next time you click, you can directly use the already created sub-process for detection and calculation.

[0111] The method provided in this embodiment, through processes such as file path input, multi-process distribution of file detection tasks, multi-threaded file loading, inter-process file data query, detection rule execution, and detection result output, can quickly detect exported configuration files, promptly identifying problems without waiting for them to be provided to the next stage. Furthermore, it allows for the customization of specific detection rules, ensuring efficiency while obtaining compliant detection results. Game project teams can quickly acquire the ability to detect exported configuration data without altering their existing configuration export workflow, ensuring efficient execution. Moreover, it provides a general template for detection scripts and an interface for cross-file queries, allowing specific projects to focus only on the detection rules for their current project data. When cross-table queries are needed, relevant interfaces can be called, and specific related detection rules can be written, eliminating the need to customize the entire detection scheme and maintaining a relatively simple and independent data export workflow.

[0112] Furthermore, for project teams using this detection method, they only need to focus on the parser with obvious project customization, general self-check rules, and special table detection rules. They can complete the integration of the configuration data detection function with almost no impact on the current export process of the project, which has high portability.

[0113] This embodiment also provides a configuration data detection device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0114] This embodiment provides a device for detecting configuration data, such as Figure 6 As shown, the device includes: The acquisition module 601 is used to acquire the original configuration file obtained by converting the source configuration data; the original configuration file includes at least one sub-configuration file. A module 602 is created to create corresponding file processing threads for each of the sub-configuration files in the original configuration file. The parsing module 603 is used to parse the original configuration file and generate a target configuration file in a standardized format corresponding to the sub-configuration file; The processing module 604 is used to perform detection processing on the target configuration files according to the corresponding detection rules based on the file processing thread, determine the detection results of each target configuration file, and generate a detected configuration file based on the detection results of each target configuration file.

[0115] In some optional implementations, the number of sub-configuration files is multiple; The step of creating corresponding file processing threads for each of the sub-configuration files in the original configuration file includes: Create a main process and multiple child processes; The main process assigns at least one sub-configuration file to be detected to each of the child processes, and the child processes create corresponding file processing threads for each assigned sub-configuration file.

[0116] In some optional implementations, the step of performing detection processing on the target configuration files according to corresponding detection rules based on the file processing thread, and determining the detection results of each target configuration file, includes: For the first file processing thread used to detect the first target configuration file, if the detection rules for the first target configuration file include associated detection rules, the second target configuration file corresponding to the associated detection rules is obtained based on the first file processing thread; Based on the first file processing thread, the first target configuration file and the second target configuration file are detected and processed according to the association detection rules to determine the association detection result of the first target configuration file.

[0117] In some optional implementations, obtaining the second target configuration file corresponding to the association detection rule based on the first file processing thread includes: Based on the first file processing thread, a data acquisition request is initiated to the first sub-process corresponding to the first file processing thread; the data acquisition request is used to acquire the second target configuration file corresponding to the association detection rule. If the second target configuration file is a target configuration file assigned to the first subprocess, the second target configuration file is obtained based on the first subprocess and sent to the first file processing thread; If the second target configuration file is not the target configuration file assigned to the first child process, the data acquisition request is forwarded from the first child process to the main process to obtain the second target configuration file from the main process, and the second target configuration file is sent to the first file processing thread.

[0118] In some optional implementations, obtaining the second target configuration file based on the first subprocess includes: The data acquisition request is forwarded from the first subprocess to the second file processing thread used to detect the second target configuration file. The second target configuration file is sent to the first child process based on the second file processing thread.

[0119] In some optional implementations, the step of forwarding the data acquisition request to the main process based on the first child process to obtain the second target configuration file from the main process includes: The data acquisition request is forwarded from the first child process to the main process. Based on the main process, a second subprocess is determined to allocate the second target configuration file, and the data acquisition request is forwarded to the second subprocess. The data acquisition request is forwarded by the second subprocess to the second file processing thread used to detect the second target configuration file. The second target configuration file is sent to the second subprocess by the second file processing thread, so that the second target configuration file is sent to the first subprocess in sequence through the second subprocess and the main process.

[0120] In some optional implementations, the processing module is further configured to: For the second file processing thread used to detect the second target configuration file, upon receiving a data acquisition request for obtaining the second target configuration file, it is determined whether the second target configuration file has been loaded. If the second target configuration file has not been fully loaded, the data retrieval request is cached, and after loading is complete, the cached data retrieval request is responded to to return the second target configuration file.

[0121] In some optional implementations, the processing module is further configured to: After the subprocess completes the detection task of each assigned target configuration file, the subprocess is cached. In response to a destruction command for the main process, the main process and each of the child processes are destroyed.

[0122] In some optional implementations, obtaining the original configuration file derived from the source configuration data includes: Determine the root directory for recording the original configuration files obtained by transforming the source configuration data; The original configuration file is obtained from the root directory.

[0123] The configuration data detection device provided in this disclosure can execute the configuration data detection method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0124] Figure 7This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0125] The following is a detailed reference. Figure 7 This diagram illustrates a suitable structural schematic for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 701, which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 702 or a program loaded from memory 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the electronic device. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0126] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0127] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 709, or installed from a memory 708, or installed from a ROM 702. When the computer program is executed by the processor 701, it performs the functions defined in the configuration data detection method of the embodiments of the present invention.

[0128] Figure 7 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0129] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the configuration data detection method shown in the above embodiments is implemented.

[0130] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0131] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for detecting configuration data, characterized in that, The method includes: Obtain the original configuration file derived from the source configuration data; the original configuration file includes at least one sub-configuration file. Create corresponding file processing threads for each of the sub-configuration files in the original configuration file; The original configuration file is parsed to generate a target configuration file in a standardized format corresponding to the sub-configuration file; Based on the file processing thread, the target configuration files are processed according to the corresponding detection rules to determine the detection results of each target configuration file. Based on the detection results of each target configuration file, a detected configuration file is generated.

2. The method according to claim 1, characterized in that, The number of sub-configuration files is multiple; The step of creating corresponding file processing threads for each of the sub-configuration files in the original configuration file includes: Create a main process and multiple child processes; The main process assigns at least one sub-configuration file to be detected to each of the child processes, and the child processes create corresponding file processing threads for each assigned sub-configuration file.

3. The method according to claim 2, characterized in that, The step of performing detection processing on the target configuration files based on the file processing thread according to the corresponding detection rules, and determining the detection results of each target configuration file, includes: For the first file processing thread used to detect the first target configuration file, if the detection rules for the first target configuration file include associated detection rules, the second target configuration file corresponding to the associated detection rules is obtained based on the first file processing thread; Based on the first file processing thread, the first target configuration file and the second target configuration file are detected and processed according to the association detection rules to determine the association detection result of the first target configuration file.

4. The method according to claim 3, characterized in that, The step of obtaining the second target configuration file corresponding to the association detection rule based on the first file processing thread includes: Based on the first file processing thread, a data acquisition request is initiated to the first sub-process corresponding to the first file processing thread; the data acquisition request is used to acquire the second target configuration file corresponding to the association detection rule. If the second target configuration file is a target configuration file assigned to the first subprocess, the second target configuration file is obtained based on the first subprocess, and the second target configuration file is sent to the first file processing thread; If the second target configuration file is not the target configuration file assigned to the first child process, the data acquisition request is forwarded from the first child process to the main process to obtain the second target configuration file from the main process, and the second target configuration file is sent to the first file processing thread.

5. The method according to claim 4, characterized in that, The step of obtaining the second target configuration file based on the first sub-process includes: The data acquisition request is forwarded from the first subprocess to the second file processing thread used to detect the second target configuration file. The second target configuration file is sent to the first child process based on the second file processing thread.

6. The method according to claim 4, characterized in that, The step of forwarding the data acquisition request from the first child process to the main process to obtain the second target configuration file from the main process includes: The data acquisition request is forwarded from the first child process to the main process. Based on the main process, a second subprocess is determined to allocate the second target configuration file, and the data acquisition request is forwarded to the second subprocess. The data acquisition request is forwarded by the second subprocess to the second file processing thread used to detect the second target configuration file. The second target configuration file is sent to the second subprocess by the second file processing thread, so that the second target configuration file is sent to the first subprocess in sequence through the second subprocess and the main process.

7. The method according to claim 4, characterized in that, The method further includes: For the second file processing thread used to detect the second target configuration file, upon receiving a data acquisition request for obtaining the second target configuration file, it is determined whether the second target configuration file has been loaded. If the second target configuration file has not been fully loaded, the data retrieval request is cached, and after loading is complete, the cached data retrieval request is responded to to return the second target configuration file.

8. The method according to claim 2, characterized in that, The method further includes: After the subprocess completes the detection task of each assigned target configuration file, the subprocess is cached. In response to a destruction command for the main process, the main process and each of the child processes are destroyed.

9. The method according to claim 1, characterized in that, The process of obtaining the original configuration file based on the source configuration data includes: Determine the root directory for recording the original configuration files obtained by transforming the source configuration data; The original configuration file is obtained from the root directory.

10. A device for detecting configuration data, characterized in that, The device includes: The acquisition module is used to acquire the original configuration file obtained by transforming the source configuration data; the original configuration file includes at least one sub-configuration file. A module is created to create corresponding file processing threads for each of the sub-configuration files in the original configuration file. The parsing module is used to parse the original configuration file and generate a target configuration file in a standardized format corresponding to the sub-configuration file; The processing module is used to perform detection processing on the target configuration files according to the corresponding detection rules based on the file processing thread, determine the detection results of each target configuration file, and generate the detected configuration files based on the detection results of each target configuration file.

11. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the method for detecting configuration data according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the method for detecting configuration data according to any one of claims 1 to 9.

13. A computer program product, characterized in that, Includes computer instructions for causing a computer to execute the method for detecting configuration data according to any one of claims 1 to 9.

Images