making 128 open source - what is left to do

[VS]

Hello!

After some thought and reading about making open source friendly to contributions and such, I decided to start moving in that way, finally for real.

Nearly all objects have assigned authorship. This might be seen as a bureaucratic thing, but was necessary to get right before even starting to look at the situation. If you ever wondered where did the revision numbers go when nothing in the set changed - that's why.

Once the "contacting" period is over (which is almost true), it's time to take a breath and start shoveling away the content that can't be used under the new license. Obviously there is a lot of things that will need replacement. And since brooding somewhere in corner and hoping that people come and do things will not work, here is THE list.



Currently there are three important authors who can't be contacted and their work can be considered lost:
Haru
Rmax500
Propermike
Other than this, there are several other unreachable authors whose contributions count two or three objects, maybe sometimes ten.

Note: everyone whom I managed to contact agreed. The problem is just getting to them.

Removal of all their objects, combined, will hurt the set in many different ways. Analysis...

• High speed trains like TGV or Shinkansen - almost exclusively Haru's work.
  
• Passenger trains, *MUs - per above.
  
• Ethanol chain - all made by Rmax.
  
• Special buildings - many made by Rmax.
  
• A few factories - made by Rmax.
  
• Locomotives - apart from the steam age covered extensively by Raven, there will be many gaps.
  
• Buses - doubledeckers ale solely work of single no-go author.
  
• Trucks - here most trailers will stay, but est. 60-80% of engines will go.
  
• Ships - passenger department will be lacking a lot, even more than now. The "shipping department" even right now (before removing iünlicensed objects) lacks in all aspects.
  
• Trams - what is left can be only up to two cars long.
  

As you can see, these are all "unique" assets. The rest, like city houses or citycars, will suffer a loss in diversity, but not critical.



Of course there are also some positives!

Perhaps the most interesting part is that I managed to assemble a large (emphasis really intended) collection of rail vehicles for 19/20th century times. As long as someone can go through this ocean and sort out what is acceptable and what not, the starting date coud move as far back as 1850. The "surplus" vehicles might be used to fill the narrow gauge waytype, too.

There is a lot of houses from Raven, waiting just to replace other buildings or possibly be coded as cmpletely new objects.

Nearly all important objects (without which some aspect of game won't work) can be kept or substituted temporarily.



What must be done in order to meet the goal - get 128 to a free, releasable state?

Priorities:

1) Factories

Steel mill (steel_mill)
Goods factory (classical_goods_factory)
Electronics (electronics_factory)
Forest (Nutzwald)
Sandquarry
Materialswholesale
Home market (Moebelhaus)
Surface coal mine (open_coal_mine)
Gas station (modern_fuel_station)

Either the author is unknown, or unreachable. Some are of very low quality, too.

2) Game objects

Schwebebahn depot and stations.

3) Vehicles

I guess that the existing content can be spread along the timeline enough to keep the set usable. Preferred order:

Locomotives for all purposes - rail transport is the blood of all transport games!
Passenger (high speed) sets
High capacity buses (double deckers?)
Trucks - meaning these that pull trailers, the "American" kind
Ships - we'll need almost everything. Some reefers for meat & fish, something for cars, goods, and big psg. liners and small ferries.

[IgorEliezer]

VS, have you tried to get authors' e-mails from old forum?

[VS]

Yes. The pak128 author "cheatsheet" has 84 entries, of which some 95% have email addresses. Unfortunately nothing helped.

[The Hood]

See my comment in the "who's who" thread about using PakBritain graphics if you think they are graphically consistent.  You can use any of mine, and Kieron is happy for his stuff to be released on opensource too (I'm putting everything together to upload all current sources I have to PakBritain sourceforge in the next few days)

[vilvoh]

Wouldn't be possible to use industry graphics from before-rmax's epoch? I'm sure there must be some stuff from Mhz or Napik, somewhere... :-\

[VS]

No. We even have (still!) a few uglies, particularly the home market, which just sucks for crying out loud.

There are a few things that could be used as goods factory, but other than that, no.

[dantedarkstar]

Sorry for exercising necromancy, but I wanted to ask:

Are the opensource factories still sorely needed for pak128, and if so which ones are most critical ?
I ask, because I feel like making attempt at some buildings, and incidentally making those that are in demand would be good, wouldn't it ?

[VS]

Of course! It's still the same:

Steel mill (steel_mill)
Goods factory (classical_goods_factory)
Electronics (electronics_factory)
Forest (Nutzwald)
Sandquarry
Materialswholesale
Home market (Moebelhaus)
Surface coal mine (open_coal_mine)
Gas station (modern_fuel_station)

[whoami]

Dantedarkstar will need the .dat files for these existing ones, to encode the new ones, doesn't he?

[VS]

Hmmmm... does he? I think the only settings needed to carry over are production settings and maybe climate. Since hte new ones will most likely have different size (?), we'll probably need the old ones for backward compatibility. Keeping it simple, let them stay under old name, so the new ones get new names anyway. Image coding is dependent on the item at hand anyway, so - there is nothing I could think of to carry over.

I'll attach them nevertheless.
http://simutrans-germany.com/files/upload/factories-dats.zip

[dantedarkstar]

Uhm... I "manufactured" my own dat file
Of course it will probably have to be tweaked before being incorporated into pak128. And the person to do the tweaking would be probably you, since you have big picture of the whole industry etc. I'm here mainly to supply graphics.
So far I learned that minimum production and production variance doesn't behave like described in simutrans-germany wiki. I get final numbers about twice as large as I expected from the values I put in.

Anyway, version 0.1 sand quarry is already done (under the name sand_quarry, feel free to change it anytime or tell me what name should I use if there's a grand scheme for that). Further versions will emerge as I gather strength to tweak it.


When I'm finished with quarry, I think I'll try tackling Steel Mill. I expect it to be a lot tougher than sand quarry. After all, I can't do worse than the current one and... well... it looks complicated

[VS]

So, perhaps the list should be refreshed.

Right now, these factories do not have a free replacement:

Steel mill (steel_mill)
Goods factory (classical_goods_factory)
Electronics (electronics_factory)
Forest (Nutzwald)
Materialswholesale
Home market (Moebelhaus)

The rest is either substitutable by other items or not needed.

[Lmallet]

Regarding forests, Fabio was working on something here: http://forum.simutrans.com/index.php?topic=1566.0
Was it ever completed?

[VS]

Fabio is always slow, behind the scenes, and surprises everyone. I guess we've got to wait for a surprise

[Fabio]

Fabio is always slow, behind the scenes, and surprises everyone. I guess we've got to wait for a surprise

actually, sudden changes in life make difficult to keep a steady working plan
i promise i'll do something about it soon (i don't paint nor play since march...)



EDIT:

check out the news here

EDIT2: UPDATED TODAY

[Zeno]

Any news on the market and the steel mill?? I'll start and old style goods mfg soon; Btw I also have some work on planes, where I've detected a couple of vehicles more would finish that section for a long time (posted here.

Maybe we could make a list (not only of industries, but general) and keep it updated here to see the progress... What do you think?

[sdog]

this might be a silly question, but even after an extensive search i couldn't find the sources of pak128. there mus't be an svn repository but i couldn't find the link to it.

[vilvoh]

pak128 is not opensource yet, so there's not open public repository to where you can get the sources. It's on the way to turn into open source, but there're some basic objects that need replacement. You can get a free version of pak128 called openPAK128 at Nightlies site, but I think it's not as playable as the original version.

[sdog]

i'm looking exactly for those sources of openPAk128. i'm not sure if werniman compiles the nightlies from the non-free pak128 by excluding non-free or it's own svn, git etc.

i suppose that part of the full pak128 is not under an open license doesn't neccessarily require it not to be available openly, since copyright prevents the use outside of simutrans. but i'd not be surprised if it wasn't.

[vilvoh]

As far as I know, it compiles the openPAK128 version from a private repository, but I don't know the details. On the other hand, I guess pak128 mantainers, basically VS, prefers to open the pak128 repository when everything is ready, instead of releasing it incrementally. Anyway, I guess that If you request him some free content, he'll surely provide it.

[sdog]

vilvoh, gracias por la respuesta.

i think completeness of a project would indicate that a version control isn't necessary anymore. but i also reckon it's likely quite some work to really branch off the open pak128.

i'm mainly asking since i just wanted to see the sources, in order to decide if i will either contribute to james petts pak128.britain port to experimental or can start some work on a port of open pak128 to experimental simutrans parameters. (that's in my oppinion the more promissing approach to some simulation aspects)

[vilvoh]

Well, the sources of pak128.Brittain are available at the official SVN >> pak128.Britain folder, so you can have a look.

Anyway, and this is my personal opinion, STExp is a completly new and independent version of Simutrans, there's no compatibility with official paksets therefore If I must decide between collaborate in a new pakset with full support for STExp from scratch or port an existing one, I would bet for the first option.

As I see it, porting an existing pakset may need to rebalance everything, in addition to add the new features, as these ones might influence in basic parameters like price, running cost, power, gear, etc.. As far as I've heard, balancing paksets is one of the most annoying task in Simutrans.

[sdog]

right now balance of pak128 with experimental is rather good (tested with passengers only). it's almost impossible to make any profit, as good as impossible to make enough profit to expand. but it is possible. so it's about perfect from my point of view. actually much better than in simutrans standard, where it's extremely easy to make huge profits.

experimental's balance is not so far from standard away at the moment. i think james et al did a great job there sofar.

it is very sensible however to work on pak128 britain however. it's just, while i think it is very good, i don't love it. it's just to british, and orderly. i very much like the chaotic twist in pak128, with equipment more or less randomly picked from allover the world, some graphic inconsitencys and so on. it's my favourite pak set, and i really long for using some of the experimental features with it.

by the way: basic compatibility with experimental should be achieved very easily. i think only some weight limits of ways need to be changed. gravel road to 999t (to allow that huge bulk truck to be operated); city roads to 41t; the cheapest rails to 75t instead of 70t (all profitable train engines in the early game can't be used on slow rails atm)


ps.: sorry for straying to far from topic. (if one of the mods objects, please move it in a new thread, thanks in advance)

[VS]

Well, as it stands...

Regarding "open":

• There is a great number of things that can not be released under open license simply because that can't happen without the author's consent.
• Most of the pakset works without these many things.
• But not all of it!
• I am waiting to get all the critical pieces replaced. It is SLOW

Regarding experimental:

• I do not like the possibility of breaking the community. I know this is politics and silly. Regardless; I will not make pak128 use anything that would make it incompatible with standard Simutrans.
• Nothing against features that would enhance Experimental players' games and do not break standard.
• Just give us suggestions!

[sdog]

thanks for your reply Vladimír,
i will answer roughly in order of your items.

it wasn't clear to me how restrictive the licence under wich the non-free content of pak128 was used is regarding the sources.

do items 2 and 3 mean that the free content's sources will only be publicly available when the missing things are completely available, or those necessary for pak128 to work are available?

the great possibility i see when pak128 becomes open is that there could be quite a lot of branches, practicaly everyone who likes (and can) modifying it for himself.
i'm not so sure what you mean with breaking the community. would you consider different forks and branches of the sourcecode as such a break? would you consider the linux community, as an example to make the question less abstract, as broken or fractured? there are thousands of different distributions, and contributers and users have free choice where to invest work or what to use. but on the other hand it does not appear to be fractured to the outside (e.g. linux vs. windows users flame wars)

i read in another thread that makeobj would ignore parameters not specified in it's build. if that's the case dat files containing parameters for experimental could be compiled for trunk without change of files.

the only problem i see immediately is the maintenance, exp. offers running costs and fixed monthly costs. they would need to be tweaked. However this could be easily solved, if james just introduces a new parameter for exp. running costs and using that.

thank you for offering to implement our suggestions to make pak128 as it is, more compatible with experimental. i'll keep my eyes open and post some. out of my head they're the ones in my previous posting.

there's another question forming in my mind:
what is the status of the .dat files of non free content? most likely was part of it written by the original author and part by someone else, balancing the pak? some parameters in it is just information (like seats in a bus) that is not copyrighted. others might be guesses, wich would be copyrighted.

sdog

[DirrrtyDirk]

You can't really compare the Linux community to Simutrans. Linux is bigger by several orders of magnitude. So it's a bit far fetched to say that branching is no (potential) problem based on the fact that it works for the Linux community. Oh yes, if we had these hundreds or thousands of people worldwide working on Simutrans... 

[sdog]

correct dirrrty dirk,
and i think i only transported what my point not was with that example. very badly phrased by me, and also suggestive. i wanted to ask more detailed if with broken he meant that it is not desired to break it up completely, or also to prevent it to be fragmented, but still cohesive to some degree. as i don't see much danger for the first case, but consider the second quite likely.

ps.: i'm not so sure if it's wise to post this reply, since i've asked more out of curiousity, and i'm reaching troll like post counts. (so just tell me nicely to stfu, and i will :-)

[Fabio]

for instance, i think all dat entries for exp only (e.g. reversibility, comfort level, weight limits) could be put in dats. when running makeobj they will be ignored, but we could run a second time makeobj-exp and compile pak128-exp.
balancing, instead, should be made for std.
instead, way constraints (a cool feature i would really love) would probably create mess in pak128-std.

[VS]

Sorry for tl;dr. You asked This is definitely not mandatory reading, most of this can be pieced together from my other posts.

it wasn't clear to me how restrictive the licence under wich the non-free content of pak128 was used is regarding the sources.

Hah! A license? You wish! Current status is that it's all more or less based on belief that "they" won't do "bad stuff", open to any interpretation. I don't know how long have you been around, but compared to other communities, our history has been oriented rather on "closed", so it worked. Actually I would dare say rabidly closed. Pakset sources were always locked away and protected and you better not ask for access!

do items 2 and 3 mean that the free content's sources will only be publicly available when the missing things are completely available, or those necessary for pak128 to work are available?

I will recycle a phrase I used recently: it's technically infeasible.

The root of all problems here is ultimately the fact that it's a svn repo. For some reasons we don't want parts of it visible. But it has history and all that. We can't restrict people to checkouts from only some of the folders and from some revisions onward. Well - we can, I am sure a svn hook wizard would hack something together. But it would be absolute hell and defeat the whole point of having a vcs.

Plus, the folder layout has changed a few times - I think maybe once, since it was never a radical overhaul of everything, but there were some smaller long-term changes as well. I don't even remember all the paths that would have to be protected somehow

The plan is - roughly - to keep this repo as a backup of what was for ages untold, and with the open version start anew. All of these factors combined together make it easier to wait - IMO.

Of course if you ask for a one-time transfer of all that is open, the needed manual sorting is not that much of a burden.

the great possibility i see when pak128 becomes open is that there could be quite a lot of branches, practicaly everyone who likes (and can) modifying it for himself.

This has been my goal since ever. Actually 128.brit used 128 items as placeholders (still uses?) and... dunno, I think that's the "right thing to do". One of my reasons for going open.

i'm not so sure what you mean with breaking the community. would you consider different forks and branches of the sourcecode as such a break? would you consider the linux community, as an example to make the question less abstract, as broken or fractured?

Scale is the key, everything. I feel Dirk answered that one for me. Not much to add.

Breaking the community is something that does not really have to happen with forks etc. I am just... wary? It's not even that it might be inherently bad, but there is not much to break apart I fear.

i read in another thread that makeobj would ignore parameters not specified in it's build. if that's the case dat files containing parameters for experimental could be compiled for trunk without change of files.

Yep, that's precisely what I meant with "Nothing against features that would enhance Experimental players' games and do not break standard."

the only problem i see immediately is the maintenance, exp. offers running costs and fixed monthly costs (...)

And this is perfect example of "I will not make pak128 use anything that would make it incompatible with standard Simutrans." Note that your suggested solution does fix this concern.

what is the status of the .dat files of non free content?

I can't repeat exactly the words I used already somewhere, but I think there is no value in dats, nothing to copyright. It is like filling in a form. No new value created. If you want all dat files of pak128, be my guest

This is a whole can of worms; one could argue that the parameters can be used creatively and that DATs are in fact a declarative language, like html, which would bring up a nice question whether html files can be copyrighted, or what sets apart imperative languages, and if Turing-completeness means anything there or if Lisp or Scala or Python is better than C and God forbid what other crap. Or eventually the highly popular "where do you draw the line if it's all ones and zeros". Let's not go down there... please...

for instance, i think all dat entries for exp only (e.g. reversibility, comfort level, weight limits) could be put in dats. when running makeobj they will be ignored, but we could run a second time makeobj-exp and compile pak128-exp.
balancing, instead, should be made for std.
instead, way constraints (a cool feature i would really love) would probably create mess in pak128-std.

More or less agreed. The way constrains are something I thought would suck mightily if implemented - ever - and as a bit array, even. But later I changed my opinion. They would instantly solve the sea/river ship problem, even if nothing else. The logic in that is powerful. (Which is why I dread it at the same time - it might also lead to unnecessary complexity for player, just because it will be possible with such system.)

Actually I dare say in five years or so, if Simutrans is still around (and it WILL be), it will converge towards experimental, or rather toward what it is/has now & in near future. The conservative "branch" (not really a branch) will be simply a subset of the possibilities, just like pakHajo.

[wlindley]

It would be wonderful if the Blender sources were part of the repositories as well... then there could be a script to apply the Pak128 or pak128.Britain (or pak64, or pak192 or...) lighting and color schemes, and the appropriate price balancing, and make whatever sets you want.  Even better if those Blender files also incorporated work done for OpenTTD's OpenGFX and other open projects, so we could really have a build-your-own-world pak creation tool.  Am I dreaming or could that be done?

[neroden]

So, perhaps the list should be refreshed.

How about another refresher of the list?  With the forest it sounds like we're down to
five missing factories.  Any other holes filled in yet (either factories, or vehicles)?

[wernieman]

A little Information about "nightly openPAK128"

The diferrent between PAK128 and openPAK128 ist not the SVN. In the generation script ist a Switch, wich could only use the "free" part of the PAK128 or all.

With this switch I geht the openPAK128, without I geht the normal PAK.

So in the source this PAKs are the same and so I could not make an anon acces to everybody to the source...

The Reason for the openPAK128 was:
When somebody whant to help to bring the PAK128 to "open", he could see wich Parts are not there .. and could draw them ...

[The Hood]

@wlindley, you are dreaming.  I reckon about 50% of the graphics work alone in pak128.Britain is getting from the blender model to a correctly aligned png file.  If I didn't have to do that, then pak128.Britain would be a lot further advanced by now!  Someone may come up with a clever automated solution (which would be great), but that would probably be an awful lot of work (I did try myself, but until blender introduce macros I worked out it would be quicker just to do it the manual way after wasting 2 whole evenings on it).  Then there is the whole dat file writing and THEN, the moster of balancing the whole lot.  You get the idea...

However, if you (or anyone else) want to play at converting blends to pngs automatically, I'd be more than happy to supply you with the blends you want from pak128.Britain, and of course dat and pngs are publicly available on SVN. 

[vilvoh]

@wlindley, In addtion to what The Hood has said.

The idea sounds tempting but hard to achieve. First of all, not all objects were painted using Blender, therefore you can't produce scaled version for the different paksets. Then there's another problems. In each pakset, each kind of object has its own scale. The scale is different for trains, ships, road vehicles and buildings. In addition, pak128 scale is not the double of pak64 scale. So it's not a matter of taking the original source files, and using a script, modify the size of the object. In almost all cases you need to correct and deform the original model in order to make it not seem disproportionated. I talking about making shorter, wider, longer, taller, etc.. and many ocasions the result is not satisfactory. The object seems deformed, specially vehicles.

Would be different if we're talking about paksets of the same size (i.e. pak128 and pak128.Britain)

[prissi]

Furthermore, in small sizes blends needs a lot of rework and pixel pushing to work out. Raw blend files are almost unusable. (Or they usually are very bland. pak96, which is almost exclusively hand painted and pak64.german, "blended" at 512*512 size and then hand optimized show, what I mean.)