Topic: Makeobj offset

[Fabio]

New Pak128 will have train tracks lowered by 4px. Hence, all rail vehicles will be lowered by 4-5px as well. The problem will be with addons which sources were not released.
The original policy was for pak files not to be unpaked in order to preserve a close source copyright if that was the author's choice.

What I suggest here is a new makeobj command:

Code: [Select]

MAKEOBJ OFFSET pakname x-offset y-offset
This command should apply a given (x, y) offset to all images but the icon (if present), the same as if the offsets were already present in the dat file at packing time.

This command could be used by addon sites maintainers (e.g. SNFOS) in order to realign their closed source addons.

[Markohs]

What about making a utility to extract a .pak to a .png + .dat file?

[Fabio]

What about making a utility to extract a .pak to a .png + .dat file?

Exactly what was always denied

The original policy was for pak files not to be unpaked in order to preserve a close source copyright if that was the author's choice.

We can't presume the author's agreement (however likely) to unpacking their addons, especially if we lost contact with the original author.

My proposal, however, would just operate within the pak file without infringing any copyright.

[Ters]

Code: [Select]

MAKEOBJ OFFSET pakname x-offset y-offset
This command should apply a given (x, y) offset to all images but the icon (if present), the same as if the offsets were already present in the dat file at packing time.

This command could be used by addon sites maintainers (e.g. SNFOS) in order to realign their closed source addons.

I strongly believe that would be a violation of copyright, as would any modification of pak files released as such. The fix must be applied as the pak file is decoded by the game itself.

[Fabio]

I strongly believe that would be a violation of copyright, as would any modification of pak files released as such.

I tend to disagree. Copyright should cover the image inside the pak, dat files were said in this forum not to be copyrightable.

The fix must be applied as the pak file is decoded by the game itself.

And how do you tell the game which paks should be offsetted? There could (and I hope there will) be addons released with the new standard, beside the official pakset objects.

[Ters]

I tend to disagree. Copyright should cover the image inside the pak, dat files were said in this forum not to be copyrightable.

Dat files is perhaps not copyrightable, but the pak, being a combination of a copyrightable set of images and some possibly not copyrightable information about how to use the images, most likely is. It doesn't seem right that one can take someone's images, write a dat and generate a pak file from it. Essentially rewriting a dat to make a new, different pak file should be wrong for the same reasons.

And how do you tell the game which paks should be offsetted? There could (and I hope there will) be addons released with the new standard, beside the official pakset objects.

They'll have to be listed explicitly somehow. Alternatively, just go for full incompatibility, or don't break compatibility in the first place. Sometimes there are no easy solutions. I'd advice sticking to the safe side, at least until a qualified lawyer has given advice.

[Dwachs]

If you know the list of affected objects, then the offset replacement can be done via a text-file, similarly to compat.tab. Applying the offset to all loaded pak files might also hit pak-files created with the new alignment in mind.

[prissi]

First there is a utility to unpack stuff, it is just not distributed. But then, even changing offsets is altering the work!

For instance, when they decide to change quite a few german writing rules "new german spelling", authors forbid (and sued in at least one case) when the company did publish with corrected spelling. This only involved spaces in certain composita and capitilisation, so it was equivalent to the offsets.

The old paks were likely having a earlier makeobj version, i.e. all paks packed with that version (or a smaller version) are affected. That can be added to the program. This would require a bump of makeobj for vehicles for the sake of pak128, which we certainly can do.

But offsets are things which cannot be changed later without breaking stuff. If you decide to move tracks, you will break addons; not only cars, also bridges, tunnels and stations will be mismatched. I see no proper way out there.

[wlindley]

Such stuff and nonsense is why distributing "closed-source binary blobs" is a bad idea for all free software.  The Simutrans community should cease distributing paks without source, or at least "orphan" the "blob" paks with a warning that you're on your own if you use them.  For the good of the community, we should only distribute code (source or compiled) and graphics under a proper free-software license.  Otherwise we get into these absurd, time-wasting, arguments which only prevent progress.

Let this be an incentive to seek re-licensing of the existing creative works.  If we can't modify old paksets, they are already as good as dead... sad but true.

[greenling]

Hello All
Since yesterday 19.45 i not more a friend from the f*** Double high code.
This code kill in all pakset the development and update.
The f*** Double high code kill the useably from old addons too.

 

I can in Moment not really to make new modells for pak064 and pak128.

 


Mod note: Please be nice with people and respect their work. This kind of behavior is unacceptable.
~IgorEliezer

[kierongreen]

Vehicles are largely unaffected by double height code - Fabio has just taken the opportunity while redrawing ways to lower rail vehicles in pak128.

As for ways and bridges - yes these need more images now but that's to use with a more varied landscape which should hopefully make the game more interesting to play. With pak64 all addons will continue to work just as before.

[Sarlock]

Backward compatibility is always a concern as software advances and evolves.  Being unable to alter some of the artwork from eras past presents a hurdle that we should certainly make an effort to accommodate but ultimately at some point we have to be prepared to jettison them in favour of advancement.

All current trains can be reconfigured with the new alignment.  Existing addons that have active authors can be reconfigured as well, if the authors are willing and the content is targeted towards pak128 style rail vehicle alignment.

If not, then those addon rail vehicles will still work, they will just be 4 pixels too high.

The same goes for the half heights and the impact it could have on some addons.

In my opinion, it's not worth worrying about the impact to a few copywritten addons with inactive authors.  The half height feature is an amazing addition to the game.  Let's move forward.

I will certainly do my best to satisfy any specific requests for replacement graphics for addons that are lost.

[Fabio]

I think tab files would do.
Multiple offset_xxx.tab files could be provided by addons sites maintainers and placed in the addons folder to be loaded at runtime.

[IgorEliezer]

Hello All
Since yesterday 19.45 i not more a friend from the f*** Double high code.
This code kill in all pakset the development and update.
The f*** Double high code kill the useably from old addons too.

 

I can in Moment not really to make new modells for pak064 and pak128.

 


Mod note: Please be nice with people and respect their work. This kind of behavior is unacceptable.
~IgorEliezer

greenling, enough!

I believe every developer and pak artist of this community have read your concerns about old paks becoming incompatible with double-height. You don't need to go mad and curse to call attention to this fact because we are aware of this.

Haven't you read that our developers have worked hard to break as little as possible the addons and paksets as well as our artists are converting their paks to the new system? If something goes broken it's not because we did it for fun, it's because it's impossible to keep backward compatibility forever for everything.

[prissi]

Well, about dismissing addons easily: The biggest (yes about twice the size of all other worldwide communities) is the japanese community. The have probably more addons that there are vehicle in the normal pak128. They are just not so visible ...

Just look at the rails and station this would made useless:
http://japanese.simutrans.com/index.php?Addon128%2FRailTools%201
http://japanese.simutrans.com/index.php?Addon128%2FRailTools%202

The vehicles may be fixed, if we bump the vehicle version number in makeobj and add a hackish add offest for waytype (or else all cars and stuff would need to change). But honestly leaving the way offsets like they were is by miles the better solution. Or built at least a compatible pak128 and a new one, if these offsets are anyway moved by algorithm. (Although I fail to see how moving will work with stations. The will overlap into other tiles with all these bad visual effects.)

[kierongreen]

pak128.Britain is sticking with the old offsets (for now at least). I'd drawn half the new bridges before Fabio made the first comment about changing offsets.

[Fabio]

New tracks have the same alignment of tram tracks. Considering that already now people sometimes mix tram and railways tracks, I wouldn't say the old addons will be totally thrashed.
Of course their realignment would be preferable if easy. 

[jamespetts]

Hmm - what is this offsets issue?

As to the copyright problem, the solution is proper open sourcing, as is employed by Pak64 and Pak128.Britain. I thought that Pak128 had also become open source by now?

[Fabio]

Hmm - what is this offsets issue?

Here's a summary of the issue:

I'm still thinking about rail tracks. In a way, I would like to get rid of the raised ballast (like other paksets did) replacing it with a flat one.
PROs:
- look better when double tracks
- more clearance in tunnels/under bridges
- better interoperability with trams, having the same tracks
CONs:
- rail vehicles need repositioning (easily done with a script to add vertical offset ~4px)
- catenaries need adjusting (anyway they would need a revamp sooner than later)

Raised ballast looks nice, but I agree that there are way too many reasons not to have it. If you decide to redo the tracks like this, I am not going to complain

New Pak128 will have train tracks lowered by 4px. Hence, all rail vehicles will be lowered by 4-5px as well.

New tracks have the same alignment of tram tracks. Considering that already now people sometimes mix tram and railways tracks, I wouldn't say the old addons will be totally thrashed.
Of course their realignment would be preferable if easy. 

I thought that Pak128 had also become open source by now?

Official Pak128 is Open Source indeed, but the same might not apply to third parties' addons.

[Markohs]

I'd not worry of addons, it's their authors reponsability to keep them up to date. You should only care about pak128, imho.

What you can ofc offer, is modify them if they are open sourced (i.e. the .png and .dat are released, that's how things should have been done)

[prissi]

I do not think fabio will download all 3000 train cars, sever rails sets and 100 station buildings on the japanese addon pages for pak128 and repack them them. Even if most of them have source with them. At least this seems not fair to him. So it is certainly better to offer some kind of compatibility if this is the way pak128 is bent to go.

For rails, bridges, tunnels, and stations I fail to see how a backward compatibility can be reached without some drawing errors (especially for tunnels) or ugly overlapping of platforms on tracks.

[VS]

One issue raised by Kieron - and so far not considered much - is that 128.Britain uses the same alignment as 128. The addons and even core vehicles are interchangeable as of now. That would change, too.

The real question is, how many players will really be affected (or rather alienated) by this, and how many of these are important to "us" (Simutrans the project)?

If a compat-offsets.tab file could exist, listing objects and offsets to correct their position, generating it semi-automagically at migration time sounds doable, even if it's some work. As that file would exist on a per-pakset basis, it would even allow some more interoperability...

[kierongreen]

The problem is working out which vehicles to apply offsets to. Ways, bridges and stations can't really just have offsets applied - they need entirely new graphics.

[prissi]

As said, we can bump the vehcile revision (curretnly 10) to 11, with the only difference that there is a global xy offset per waytype and direction defined, whivh shifts paks revision 10 or lower by this amount in this direction.

As Kireon said, I am more worried about stations, bridges, tunnels and elevated tracks where simple shifting does not work. But then those can be replaced by a compat.tab. A relatively extensiv4e one for the addons, but much much less than the vehicles.

[kierongreen]

Global shifts shouldn't happen - there might well be some old paks with the correct offset already for example.

Though as Fabio says - in the end this is only a matter of a few pixels. Old addons will still load they just won't look entirely correct (and old ways and bridges would not be compatible with double heights anyway).

[z9999+]

Global shifts shouldn't happen - there might well be some old paks with the correct offset already for example.

+1

It is each player's choice.

[Fabio]

Though as Fabio says - in the end this is only a matter of a few pixels. Old addons will still load they just won't look entirely correct (and old ways and bridges would not be compatible with double heights anyway).

I borrow this image to strenghten the concept:

real game, pak128.japan

Between trains and tracks there is exactly a 4 px gap: as you can see, nothing earthshaking.
(Basically new railtracks alignment should more or less match Pak128.Japan's)

[prissi]

We could still add an optional downshift for older makeobj. That is still easy to dow and will benefit also pak128 Japan (obviously setting it to a different makeobj vehicle node version).

[VS]

I tried to write three times, why filtering by makeobj version isn't enough... And then finally saw why it is enough.

Except it isn't, because I know many people who intentionally use old makeobj :(

[Ters]

I don't like basing this on makeobj version because:

• It is something of a global solution to a local problem, and requires indentifying a specific pak set for doing a pak version "compatibility" fixup.
• Poor flexibility. It is difficult to reuse the same solution later. It might hit too broad (old pak versions with correct alignment) or too narrow (new pak version with wrong alignment).

[prissi]

It will only affect pak128 road vehicles. People using old makeobj can use their old alignment, and people using new makeobj use the new one. Or, (even easier to implement) keep the old alignment (4 px too high) but simutrans will shift all vehciles by four pixels. This way the makobj version will not matter, and the documentation will be still correct.

[kierongreen]

If there's to be any shifting I'd suggest it would be in a tab file similar to compat.tab (maybe even in the same file).

That way users can choose which addons they want shifted. As to why it's not good to use just makeobj versions - consider that pak128 will have a different offset now than pak128.Britain. However they will both be compiled with the same makeobj version.

[sdog]

I have difficulties to follow this discussion a bit, since the solution seemed very obvious to me (thus there must be a reason it is not):

Why not define an offset to the dat file? Instead of having a guess based on makeobj or doing global changes with the posibility of side effects.

[kierongreen]

The problem is with dat files where players might not have access to the sources.

[sdog]

The problem is with dat files where players might not have access to the sources.

But in such cases, makeobj would just not add an offset. And everything ought to be fine?

All pak128 sources are free and available. Those who want to use pak128 without offset, for downward compatibility, could just turn off the offset in all dats and 'compile' it without offset.

That'd be only a minute extra work, nothing compared to balancing what they need of pak128 to their own. SNFOS or japanese simutrans certainly wouldn't have any difficulty doing that.

Orphaned closed source single object addons would perhaps be affected. But, the collectors and those who appreciate those very much could still compile a non-shifted pak128. In general they'd have to keep old pak versions and old binary versions of simutrans as well anyway. For any archiving one has to keep the contemporary devices needed to access the archive material. What's true for floppies and old atari games also applies to antique simutrans addons. I mean we're accepting this for other aspects of the game where old parts become obsolete. Doesn't matter if code or old way/bridge graphics.