News:

Want to praise Simutrans?
Your feedback is important for us ;D.

[Project Canceld] MakeObj Patch: Comments on all rows in dat

Started by Max-Max, April 13, 2013, 01:24:16 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

prissi

A comment in the copyright string is not very likely. Any letter combination is valid copryright strings (including \n) as well as for names. Especially for this line comments this does not make sense. (There are even objects with spaces in their names). [## is a valid filename too.]

I would also refrain from comments after obj. Usually the comment of what an object comes can be just plain text lines above the actual object (as it is now in most dats I saw [if there was a comment at all]).

As said, simutranslator is fed with the same datfiles. Since simutranslator will ignore images it cannot retrieve, comments after images are ok. But for all other entries I would abstain from comments. Moreover, apart from simutranslator (where dat files are uploaded too) there are several parsing tools which would break too. The all can cope wil random text at the beginning because they ignore nonmatching lines, but otherwise will be confused by C style block comments and trailing line comments.

If a pakset author really wants to use those, maybe just call a preprocessor before parsing by makeobj is the simpler solution.

Ters

I find that comments on the end of lines make files more readable than files with comments and statements on alternate lines. Does to ability to write ## in copyright strings really outweigh this? Those who use # in file names are heading for trouble either way, as that character has a special meaning in URLs.

Max-Max

@Prissi

A little bit earlier (reply #34) I gave 4 solutions and asked for your opinion, you must have missed that one :)
- My code doesn't have bugs. It develops random features...

prissi

My standing is that we are heading for trouble with this, and some pak sets like pak128 or pak192 and other which use sripting systems would struggle on this. Same maybe as tile cutter. Giving the times to implement that on simutranslators and the phython tools, and so on I am very reluctant to add this.

Commenting stuff at the end of the line is a very programmer thicking. You would not enter a box with your name
Pristovsek ## Maybe Dr. in front?
into an official form. Rather
Name=Pristovsek
So why you would expect any artist doing such weird stuff then? And if you want to comment offsets, no problem as you could do this already today (just avoid the .)

Sure it is easy to add a remove_trailing_comments() function, and call it for whatever object you want. I could see the use for images, and maybe for some other entires (where comments were possible also today due to ignoring superflous input.)

But I highly doubt a comment feasture will be used at all. I am the only pakset developer who replied on this thread. Without further input, I somewhat have to assume this is a solution without a problem.

Max-Max

Isn't it more confusing if you can put a ## comment after an image[] but not after a name or obj?
If ## is implemented it should be the same for the whole "script".

Also, just because ## is implemented doesn't mean that everyone HAS to use it right away everywhere on every single line.
I also said I will drop the block commenting /* */, no point since # can be used instead as you stated in the beginning.

I think we have agreed so far to use the sequence (space)## for trailing comments. I gave 4 alternatives with pros and cons, asking which of them would you (prissi or other developers) prefer?
- My code doesn't have bugs. It develops random features...

kierongreen

I've used end of line # comments for 2 years now and it worked just fine, I didn't even think to check whether it was allowed first...

Obj=ground
Name=LightTexture
Image[0][0]=images/texture-lightmap.0.14 # flat ns|ew
Image[1][0]=images/texture-lightmap.1.6 # sw1
Image[2][0]=images/texture-lightmap.0.6 # sw2
Image[3][0]=images/texture-lightmap.1.7 # se1
...

Of course it worked in this case because image.y.x is looking for x and y being numbers so anything afterwards is ignored.

VS


My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Ters

Quote from: VS on May 03, 2013, 10:57:27 PM
IMO external tools can adjust really easily...
But I'd prefer it if their authors came forth and said that they were in on the change, and not only had the ability, but also the time to do the change. It's not uncommon for people here to suddenly take some time off for weeks or months. It took a while to gather all subwebsite owners for the server move. This is not only a code change, but a change of an (informal?) standard, so all involved parties should be heard first, or at least have had a reasonable chance to be heard. Is all even aware of this topic?

prissi

Ok, there was aparently a misunderstanding. I would prefer such comments for individual lines: Like for images, maybe also for all numerical fields get_int() but not automatically for standard entries.

Max-Max

Okay, after the discussion on projects that just dies :P I will step forward and post an good example of what "to do" :)

I have abandoned this concept because I don't see the point to have remarks only to work on some lines and not on some others. I would like to see a consistent system that would work on all lines.

So, I have put this project back into the drawer to collect dust...
- My code doesn't have bugs. It develops random features...