Author Topic: Compiling the pak  (Read 2823 times)

0 Members and 1 Guest are viewing this topic.

Offline Iluvalar

Compiling the pak
« on: November 11, 2015, 09:23:48 PM »
Sorry to annoy you guys, but I've been wasting 3 hours trying to go around.


As I understand it I need http://moscript.sourceforge.net/
But it's down right now on sourceforge. Does someone have a copy ? Do I have it right ?

Offline Spenk009

Re: Compiling the pak
« Reply #1 on: November 12, 2015, 02:22:42 PM »
I think we need a tutorial on how to compile the pak. Unlike compiling the executable, I've had no luck here either.

Offline Vladki

Re: Compiling the pak
« Reply #2 on: November 12, 2015, 06:01:55 PM »
On linux I use make. At least for experimental version it works fine.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Compiling the pak
« Reply #3 on: November 13, 2015, 10:57:23 AM »
Apologies for the delay in replying: I have been somewhat busy these past days. You can compile the pakset either: (1) manually; (2) using the MakeAll.mos script (Windows); or (3) using the makefile (Linux).

(1) is very tedious, and I do not recommend this unless you are stuck with the other methods.

(2) is quite easy: the script itself can be found in the root folder of the Github repository. You then just need to install Python in order to run the script. Run the script either by double clicking the icon for the script in Windows Explorer or from the command line (this has the advantage of preserving on screen any error messages), and then move the resulting pakset folder to its appropriate location in the Simutrans folder structure.

(3) is not something that I know a great deal about, as I do not use Linux at home. Perhaps Vladki could elaborate on this if this is the OS that you use?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Iluvalar

Re: Compiling the pak
« Reply #4 on: November 14, 2015, 12:33:21 PM »
Ty for the answer, I struggled to use make directly on Linux. I'm still unable to achieve it.

However, I did manage to reuse the python script from pak128 in order to add your vehicles and factories to my experimental pak-ilu (http://forum.simutrans.com/index.php?topic=14891.0) along side the pak128 ones. If you want to make a tour there to try it and to tell me what it lack to be playable into experimental ?

Offline Vladki

Re: Compiling the pak
« Reply #5 on: November 14, 2015, 12:37:55 PM »
I use make to compile pak128-brit-exp. I'll check if the standard pak compiles too. I'm not sure. I know that I had to do some fixes in Makefile for czech and swedish paks. Maybe I did it for british pak as well.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Compiling the pak
« Reply #6 on: November 14, 2015, 12:44:31 PM »
Ty for the answer, I struggled to use make directly on Linux. I'm still unable to achieve it.

However, I did manage to reuse the python script from pak128 in order to add your vehicles and factories to my experimental pak-ilu (http://forum.simutrans.com/index.php?topic=14891.0) along side the pak128 ones. If you want to make a tour there to try it and to tell me what it lack to be playable into experimental ?

I have noted your interesting work on a rebalanced version of Pak128. Balancing in Experimental is in many ways different to Standard (and there are code changes in progress which will affect the balance further; I intend to balance Pak128.Britain-Ex on the basis of historically researched figures once I have completed the balance critical code changes), so it seems unlikely that the same pakset will balance well both on Standard and Experimental. However, I have not experimented in any detail with balance in Experimental yet (awaiting the changes to the code described above), so if you are interested in undertaking such experiments, it would be very interesting indeed to see the results.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Iluvalar

Re: Compiling the pak
« Reply #7 on: November 14, 2015, 05:44:20 PM »
Well, I'm not a professional game designer but I ran the math and if you don't use any balance levers you can't maintain more then 2 combinations of road+vehicles viable at any given point. The one you maintain viable for the low traffic area and the one with optimal profit per km. One would use other vehicles if a line with different km/h is close enough so they could save on road maintenance. But this is not the same level of decision making, it's just an after tought.

Also, most road would be straigth with very little curves. Unless you throw to the player enough profit that he don't care about economics.

The only way I found realistically to create more complex networks in a balanced way was to

a) Force a permanent traffic jam in every line. A production so dense that the player would be force to fill the road completely. After all, in real life the roads are full of factories to produce and that's what happen. But in simutrans you don't want that much traffic because it's just annoying. You want to deal with traffic in one area or two, but not on every single corner because all the roads are full of your own trucks which unnaturally spawn from a single factory.

b) The only other way I found was to make the speed bonus high enough to create different bubble of optimal solutions depending on the amount of traffic created in the roads. But then I had to break a few realistic figures. The road and vehicle cost grow exponentially, the speed bonus is enormous and 1 ton of paper and 1 ton of ink makes 1 ton of books, etc. Sadly I had to..

I'm affraid, I have to tell you. You can either stick to historical figures and have a very poor array of options as a gamer so the game turns out to be a creative open box with no relevant economics (which is completely fine to me, but there is no real point in talking about "balance") or you have to cut into some realism in order to make the game enjoyable and challenging.

However I did my best to keep the basic of the design of the vehicle intact. I rounded the speed to the closest road value, but I kept the speed for road and trains. I had to tweak the speed of boats and planes, but I kept them in relation to each others. IE. The fastest boat is still the fastest. So they still look realistic at least from the visual perspective.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Compiling the pak
« Reply #8 on: November 14, 2015, 06:56:16 PM »
This is precisely why I have been developing Experimental to have more realistic features to make balancing based on historical figures more viable (by simulating the things that makes reality balance in the way that it does); balancing in Standard is rather simple for my taste (although some prefer the relative simplicity of Standard; that is why there remain the two branches), and also why I plan not to start balancing until I have completed the balance critical features.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Iluvalar

Re: Compiling the pak
« Reply #9 on: November 15, 2015, 05:30:31 AM »
I'm afraid that that realism won't generate what we have in the reality. In real life, factories are building themselves on the road for the most part, and not the other way around. In reality, all vehicle are pretty much the same designed to fit the same roads limit and highly dependent to the current technology not around distinct options that could constitute a game.


If you go the realism route all in, you'll end up with roads that can't be paid by the player alone in a close grid like modern city where there is 10 barely relevant way to go from point A to B, and a set of vehicles that all make around 8-12% of profit per years. No matter which one they are, which route the player really take and which factory he chose to link. Because that's the typical rate of profit investors are looking to make in real life so they compete with each others no matter what until they reach their limits. And you will end up with some sort of creative mode but with money constraint. (Which is fun in its own category, but sub optimal in term of gameplay)


I made my ROP of 10% per month on purpose. So the player always have something new to spend on and don't get bored at looking at his trucks moving for 10 years. To give an exemple.

Offline Vladki

Re: Compiling the pak
« Reply #10 on: November 15, 2015, 07:00:17 PM »
Ty for the answer, I struggled to use make directly on Linux. I'm still unable to achieve it.

Makefile is OK. You just need to copy or symlink the makeobj executable to the same directory as Makefile. The compiled pak is then in ./simutrans/pak128.Britain.

When loading some oder savegames I noticed some missing objects (offices, cemtery), but that may be because I played them with older (single-height) version of pak.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Compiling the pak
« Reply #11 on: November 15, 2015, 08:54:14 PM »
I'm afraid that that realism won't generate what we have in the reality. In real life, factories are building themselves on the road for the most part, and not the other way around. In reality, all vehicle are pretty much the same designed to fit the same roads limit and highly dependent to the current technology not around distinct options that could constitute a game.

The part about the factories I understand, but not the second sentence, I am afraid. Can you clarify?

Quote
If you go the realism route all in, you'll end up with roads that can't be paid by the player alone in a close grid like modern city where there is 10 barely relevant way to go from point A to B, and a set of vehicles that all make around 8-12% of profit per years. No matter which one they are, which route the player really take and which factory he chose to link. Because that's the typical rate of profit investors are looking to make in real life so they compete with each others no matter what until they reach their limits. And you will end up with some sort of creative mode but with money constraint. (Which is fun in its own category, but sub optimal in term of gameplay)


I made my ROP of 10% per month on purpose. So the player always have something new to spend on and don't get bored at looking at his trucks moving for 10 years. To give an exemple.

Perhaps we have different ideas of what makes a good game: it is awfully tedious, I think, if one makes so much money that the investment in what would be in reality a major asset is so trivial that it makes a full return on its capital within a year: assets become near disposable in those conditions, and thus do not really behave like assets at all, but more like commodities. With a 10% per month return on investment, there is no incentive to undertake long term planning, and little incentive to maximise efficiency (even at a third of optimal efficiency, a vehicle will still repay its capital cost in 30 months, which is trivial). A 10% per month return on investment renders purchasing decisions of little consequence and makes the game far more casual and, in my view at least, much less interesting than it has the potential to be with realistic rates of return on investment (circa 2%-10% per annum for moderately successful to very successful enterprises).

It may be that you prefer a more casual game, but that is not what I am trying to create with Experimental and Pak128.Britain-Ex - the idea is for a game lasting nearly 300 game years to be played out on a huge map on a multiplayer server, with players logging on, making changes to their network for a few hours and then logging off again every day (or, for less intensive players with smaller companies and less time, or perhaps players who share the management of companies with others, a few times a week).

I am not quite sure what you mean by the first part about the roads, as city roads are owned by the relevant city and not paid for by the players.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Iluvalar

Re: Compiling the pak
« Reply #12 on: November 16, 2015, 02:23:51 AM »
I meant that In real lifes factories are built on roads that are already there most of the time. Road arent build by the transporter, they are built a mix or complex political decisions and the need to avoid and deserve the buildings that are everywhere around. Take a look to the direction you take in car from point A to point B. You'll notice that your constantly turning side way from your objective. Our road are made in 90 degrees because they are meant to cover the space, not to lead to a specific destination.

If you let the players build the roads.
A- They wont be able to pay the real price for them.
B- The resulting network wont fit the real ones.
C- Real vehicles which make profit under real road configurations will be overpowered in that parallel world.

You need to find a strong incitative for the players to NOT build their road straight. While still behing challenged into designing it. Not just filling a sort of labyrinth trough a ton of obstacles like real life. You won't find anything in real life that look like this.

You're right about network games, I'll need to turn the cloak real slow or accelerate it even further for an arcade mode which could be played in one sitting of about 1-2 hours max.

But you're wrong about the difficulty of my pak. First I made the profite, the road maintenance and the vehicle running cost to be equal 1:1:1. So if you lose 10% of the good earning in any way, you lose 30% of the maximum profit And it's near impossible to reach the pure max profit. You could fall from 60% of optimal profit to 30% of optimal profit.

The speed of the roads also act as tier with ever growing cost and difficulty. The 200km/h road cost 500'000$ a tile. The full starting money ! So there is no "end" on the amount of project you can build on one map. You don't just reach the optimal profit after building your line. So you could make 1/3 of the profit, but you would quickly end-up a fraction of the size of your competitors.

There is also a lots of long term planing, the most successful players will build higher speed roads and pay for the maintenance at first and slowly grow around it in order to make the optimal profit around the end. They need to forsee and take that risk.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Compiling the pak
« Reply #13 on: November 16, 2015, 11:06:56 PM »
The point about factories and roads is interesting, but less significant (at least in Pak128.Britain-Ex) than you suggest because, in that pakset, most industries (including all early industries) are set to be built in towns where there is already a road network, and later industries that are built out of towns are mostly the heavy sort of industries to which one would normally build a rail rather than road connexion. This arrangement is more realistic, I think, as early industries were almost invariably built in and around settlements in order to have enough workers.

However, some consideration may need to be given to restricting out of town industries to being built next to an existing road to prevent the problems that you discuss. I should be interested in people's views generally on that subject.

As to the difficulty of your pakset, I see that you have put in place compensating mechanisms to prevent it from being too easy, so I was perhaps hasty when I suggested that it would be easy. I think that it is probably just a matter of having a different taste in what sort of challenge to have: the ideal with Experimental is to have as realistic a challenge as possible: the things that are interesting and challenging about real life transport planning should be, in so far as possible in this sort of game, the same things as are interesting and challenging about playing the game. The idea is that one should solve challenges in the game in the same sort of way as one would solve the equivalent challenges in reality, so that players can imagine that they are in charge of a real transport network and make the sorts of decisions in the game that they would make if they were in charge of a real transport company.

I fully accept that this sort of realism is not to everyone's taste (which is why we have the separate Experimental and Standard branches in the first place), but there are a goodly smattering of people, including me, who do like the realism, I think, so it is all worthwhile in the end. Your experiences in finding what aspects of Standard do not permit realistic balancing are most useful in understanding how to develop Experimental to allow a realistic balance, and I am most grateful to you for sharing them. If you have any more, I should be very interested to know about them.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Vladki

Re: Compiling the pak
« Reply #14 on: November 17, 2015, 12:35:36 AM »
About factories and settlements. Historically, either industries were built in pre existing settlements - mostly the end of chain. Or the settlement was built around the industry - e.g. mines. Middle of the chain could be either close to the source or close to the final product depending on which product was more suitable for transport. Only farms and forests were in middle of nowhere.

Offline Iluvalar

Re: Compiling the pak
« Reply #15 on: November 17, 2015, 06:56:02 PM »
Since we are talking about difficulty. This is quite a good topic. A good exemple of how a change you aim for one purpose also impact the remaining gameplay. We talk about the RoR but I think now you agree that it's a matter of time scale and it doesn't really change what the player have to do to make that profit. What do change the difficulty however is the amount of maintenance and running cost. The more you have of those, the more the smallest mistake make you lose money. However, I think that's where you are confused. Because at the same time you increase those, you reduce the amount of options to the player. The more expensive they are, the more straight the roads must get. At the end, you want to challenge the player, but he just have less options to consider so it become easier (and more boring).


Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Compiling the pak
« Reply #16 on: November 17, 2015, 08:55:04 PM »
I am not sure that I follow what you are trying to say, I am afraid. I do not think that I am confused: we just have different preferences as to realism. Roads to out of town factories are a very small aspect of the overall game (especially in a pakset where most industries are built in towns), and are certainly not decisive as to balancing. In so far as that is an issue, consideration can be given to one of two possible remedies: (1) constraining out of town factories to be built next to existing roads; or (2) causing an out of town factory to build its own road. None of these things means that there is anything inherently wrong with setting out to balance a pakset according to historical prices and setting out to modify the code such as to allow this to be done.

(There is also, of course, nothing inherently wrong with your approach: as I wrote above, the difference between the two is a matter of taste).

As to the rate of return, what is important is the relationship between: (1) the rate of return on an asset; and (2) the asset's profitable lifetime. In reality, road vehicles are generally intended to last circa 15 years and other types of vehicles about 25 years, although some of both classes last much longer for various reasons. A world in which an asset earns its price within 2 years is a world in which one can always, without fail, upgrade to the latest technology in everything. A world in which an asset earns its price within 10 years (and the profit on the remaining years is necessary to cover the various fixed overheads before one gets into a net profit) is a world in which one has to think carefully about what to upgrade and when, and what to cascade. A world in which an asset earns its keep in 2 years is a world in which a bad choice of asset has fewer adverse consequences than a world in which an asset earns its price in 10 years. There are huge implications to each departure from reality that make the way in which the game is played different from what obtains in real life, and therefore less a simulation game and more of a logic puzzle game.There is nothing inherently wrong with logic puzzle games that are loosely based on transport: it is just that I (and I suspect others) prefer something more realistic.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Iluvalar

Re: Compiling the pak
« Reply #17 on: November 18, 2015, 06:38:08 AM »
Wait. You said "a bad choice of asset". Are you saying you will leave bad choices on purpose in the depots ? I'm affraid if you push that realism to the limit, you will eventually fail to please to both type of players. The creative/sandbox players will find themselves forced into playing the top tier of vehicles unable to play whatever they want. While the challenge driven players will soon after their first sitting grasp which vehicles are overpowered, abuse of them and get an easy game with less choices then expected.


Before you go too far in the design of your balance and in the additions of new feature in experimental, I'd suggest you take some time trying to reflect on how all this will work together. I'm pretty sure you'll need to compromise on something in order to keep what really matters to you.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Compiling the pak
« Reply #18 on: November 18, 2015, 11:13:40 PM »
By "bad choice of asset", I meant one that is bad for that work for which it is intended. I do not intend there to be vehicles that are all-round bad that people will quickly learn to avoid (there may be some like that at present owing to their relative cost, but only because the pakset has not been balanced yet).

To given an example: in 1912, the London, Tilbury & Southend Railway built a series of 4-6-4 ("Baltic") tank locomotives intended to work the London to Southend expresses which were becoming too heavy for their existing, smaller classes to work at a good speed. There was an error made, and they were found to be too heavy for a section of elevated track near the Fenchurch Street terminus in London. They had to be used on short workings terminating at Barking, for which they were not well suited, and which work could equally well be done by the smaller classes. There was nothing inherently wrong with them (when in the same year the Midland Railway took over, it transferred the locomotives to commuter work out of St. Pancras as well as the somewhat limited services between St. Pancras and Southend by way of the Tottenham & Forest Gate line, where they did quite well after a few initial issues were resolved; but this would not have been an option for the L&TSR had the Midland not taken them over in that year), but they were a bad choice of asset for the L&TSR because they were not able to do what they were intended to do because they were too heavy.

One of the design aims of Experimental is precisely to add parameters so that there can be a far greater range of optimum assets for different specific tasks than in Standard. One example of this is the addition of tractive effort to power as a physics parameter of vehicles, as well as different physics modelling for steam locomotives (which are constant force machines) and other forms of locomotion (which are all generally constant power machines). Another example is the addition of loading time and comfort parameters to vehicles; yet another example is the addition of weight limits for ways. All of these make the choice for the player far less simplistic than it is in Standard; having the return on investment realistically balanced will make getting that choice right just as (relatively) important as it is in reality.

I have spent many years reflecting on how this will work together as I have been working on Experimental and slowly processing the list of balance critical features, and continue to do so. If you think that I need to compromise on something specific, I should be very interested to know what that specific thing is and why compromise in a specific way on that specific thing is necessary to achieve a specific goal.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.