Opened 16 years ago
Closed 10 years ago
#333 closed enhancement (fixed)
Improve XML-Level-Loader
Reported by: | bknecht | Owned by: | muemart |
---|---|---|---|
Priority: | major | Milestone: | Version 0.2 Codename: Bellatrix |
Component: | GameLoader | Version: | 0.2.0 |
Keywords: | Cc: | ||
Referenced By: | References: |
Description
There are two major issues with the Level-Loader. First, the error messages are not very conclusive, because we do not check what's written in the file. Second, a bit more specific, syntax errors in lua are devastating for the loader. Especially if the code is commented out, lua still yields errors, which it should not.
Example (this yields to unreadable XML code for the XML-Loader):
...
<!-- <?lua end >? -->
...
Your task is to catch the most common errors and yield more conclusive error messages to make the level development and debugging of errors in level loading easier.
Change History (7)
comment:1 Changed 15 years ago by landauf
comment:2 Changed 15 years ago by bknecht
Notice the error in my example. Since the lua tag isn't closed correctly there is an error in lua, which results in unreadable XML code. I agree that your example should not yield an error (although you cannot really just write "end"). The lua-code should correctly yield errors and we should not even try to parse the resulting XML if a lua-error occurred. Lua errors are usually quite conclusive.
I don't think that your proposed uncomment syntax works already, or does it? That would be a good way to just totally ignore everything between two of such tags. Would really help a lot.
The second part of the ticket is clear: We agree on the needed improvement with the XML errors.
comment:3 Changed 15 years ago by landauf
Yes I noticed your error but thought it was by accident. And yes I think the proposed uncomment syntax works, since it's a valid XML-comment and doesn't match the Lua-tag-pattern.
Handling Lua errors should be easy because there MUST be a way to distinguish between normal output and error output (a flag, an exception, a returnvalue, …). If an error occurs, we simply don't insert the output into the XML-file.
The second part of the ticket however is much harder and has to take care of included files and Lua-generated XML-code (and maybe even more - like namespaces for example).
comment:4 Changed 15 years ago by bknecht
I see, I thought your suggestion would comment out lua code as well. Usually we uncomment if we want to leave out some parts of the level. And then the errors happen inside the uncommented parts, because the lua part is still executed and the developer doesn't remember to check the lua code in the uncommented part. That's why a tag to also uncomment lua code inside the XML would be cool. But that maybe becomes complicated.
comment:5 Changed 15 years ago by landauf
- Owner changed from nobody to landauf
- Status changed from new to assigned
comment:6 Changed 10 years ago by landauf
- Owner changed from landauf to muemart
- Status changed from assigned to new
comment:7 Changed 10 years ago by landauf
- Resolution set to fixed
- Status changed from new to closed
I don't agree. Lua > XML, so we first parse the Lua tags in the file and THEN parse XML. Therefore it's ok if Lua gets parsed in this example:
<!-- <?lua end ?> -->
What you get is a Lua-generated XML-comment which is of course completely senseless, but it's not a bug. What you have to do, if you want to uncomment a Lua expression is the following:
<!--?lua end ?-->
This is the only correct way.
You're however completely right when talking about XML-error-messages. They have to be improved A LOT.