Page 2 of 2

Re: [BUG] A Bazillion bugs in blueprint.xml

Posted: Fri Oct 05, 2012 4:28 pm
by Icehawk78
Hissatsu wrote:Well, I disagree, lets leave it at that. I just had same problem with Artemis (great game btw!) that also parsed XML without being strict, while i was making an editor for that game, and since i used .net, it was strict, and i couldnt parse anything that came from mission makers because like every single one had violations of standart.

I'm an IT specialist myself, and I understand all the advantages of strict standarts, but I think computers are made to serve mankind, not the other way around. Therefore, no matter what, computer must do all it can to prase human command and serve, and only if it cannot stop and say "unable to comply". If i say <b>Bold<i>ItalicBold</b>Italic</i> it is obvious what formatting I want and no problem to understand that. If <!---- --> is parseable, computer should parse it, and so on.

Its like imagine if on Star Trek's bridge, the onboard computer, while the ship is in critical situation, will educate capitain in proper use of english pronounciation instead of complying to his orders, even if those were given hastingly (given the direness of the situation).

(For reference, starting with "I disagree, let's leave it at that" and then going on to support your position with the entire rest of your post comes across a bit disingenuous - if I rebut the points you've made, I'm ignoring your "lets agree to disagree" and sound like a pugnacious jerk, if I ignore them then to any outside observers, it could be seen as not having a response to the points you made. Not sure if that was intentional or not, but giving you the benefit of the doubt, I wanted to point out that phrases like that rub me the wrong way and feel like attempts to shut down further communication for whatever reason.)

Now that I got that out of my system...

Naturally, non-standard/strict parsers can and have been written, and are occasionally used by projects. So, obviously, a parser could be used to read the game files. However, you're then restricting yourself to whatever language/framework that parser is implemented in, or forced to reinvent the wheel for whatever your pet project language is. Neither of these are conducive to working on what you actually want to, though.

The primary problem with your reasoning that "computers should do whatever they can to do what humans want them to" is exactly as Derakon stated - the standards were created so that everyone knows what the parser can understand - if it violates the standard/core spec, then the parser can't understand it, because you're not using it.

Code: Select all

<tag1 id="test">Thing</tag4>
<tag2 id="thing1"name="thing2" />

Simply put - the above snippet isn't XML. If it's in the middle of otherwise valid XML, then, that's the point at which the parser says "unable to comply" because that's just as much "not XML" as having a chunk of compiled assembler in the middle which you expect to be executed at that point in the parsing. When you think what was done mostly makes sense, and make assumptions, in the short term that helps you work around problems where you don't want to inconvenience the user by saying "Hey, you screwed up, be more specific and fix it", but in the long term, you end up with Internet Explorer which throws away every standard and instead says "Nah, we're gonna do it my way, screw everyone else".

What it sounds like you really want is an AI, which can take any form of garbled human input, determine what they "really meant" and then work with that. However, until that time (and that's a whole separate philosophical discussion, lol), you're either stuck "fixing" it in the original, or making each end user who wants to manipulate it programmatically "fix it" themselves.

Re: [BUG] A Bazillion bugs in blueprint.xml

Posted: Fri Oct 05, 2012 6:15 pm
by Derakon
Also, speaking as a developer, I have far more important problems to work on than trying to figure out what random gobbledegook is supposed to do. If my users had to choose between "Make the parser less strict" and "Make the parser more featureful" then they will choose option B, every time. It's not much effort for them to write compliant input, after all, especially if the parser does a good job of pointing out what they did wrong.

Complaining that the parser is strict is kind of like complaining that you have to use exactly a 3/8" screw instead of a 5/16" or 7/16" screw to assemble your IKEA desk. Sure, IKEA could make a special screw hole that accepted more screw types, but it's more effort for them (driving up the cost of the desk and reducing the number of products they can provide) and it wouldn't work as well as just using the right screw in the first place.