News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Train Stacker System (and possibility of introducing chose-your-own-path)

Started by Karel2501, October 28, 2020, 10:56:08 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Karel2501

Hello, dear community. I'd like to talk about the subject of train stackers.
You know, those systems that prevent your trains from queuing up in a long in front of a high through-put station? Essentially a system of parallel lines in front or behind your actual train station allowing multiple trains of the same line wait their turns without making a que that could jam up your main transport arteries?
Railroad stackers are actually a common and natural part of railroad infrastructure.

However, despite being potentially INSANELY useful in Simultrans, they are not currently possible to make. The reason is simple: within a stacker, there is always going to be one of the lines that is faster than the other. And with the subborn refusal to add chose-your-own-path signals, this prevents the trains from stacking up the way they should, instead forcing them to make a que along the shortest route, defeating the purpose. I find this to be honestly the biggests shortcoming in this otherwise fantastic game.
There is an option how to create said stacker - using the "chose your own platform" signal and simply creating a train station purely for the purpose of holding these trains. An illustration of what I mean provided in the pic. The problem with that solution is that his requires each of the stacker lines to be designated as a station title (usually cargo), and the platform has to be as long as the trains incoming if not longer. (again, see pic related) Now: Given the upkeep prices for each train platform, making a multiple lines of cargo stations just to serve as a stacker is INSANELY COSTLY and thus unviable, even if technically functioning as I need.

So I've came up with to propositions how this could be solved. Firstly: (and this should be relatively simple)
I would like to propose a new type of "platform tile", which we could call "Stacker-platform" or "train parking platform" or whatever. This should be invisible (or versy subtly marked), but behave mostly like a regular station platform, except it would not store, load or unload goods, and it's upkeep would be zero or minimal. Trains would still be allowed to stop at it and been given instruction to wait (though "minimum load bigger than 1 and then waiting time being introduced). This would essentially allow us to create large "shadow stations" that cannot be used to load or unload, but can (throgh the use of chose-your-own platform) divide trains into functional train stackers at the cost of maybe a 1 buck a month per platform tile, or none.
I'm sure more use of them could be made elsewhere in the game, and their implementation should not be difficult. It's literally few adjustments to an existing platform entity, I don't think it even needs a new sprite, at worst literally some kind of color tint.

Second solution:
Actually enabling the **** chose your own path signals, even if they were by default off and purely optional. This is not the only time chose-your-own path signal could be useful, but honestly, I find the most glaring one. Simply mark the entrace to the stacker with chose-your-own-path signal, and the end of each stacker by "end-chose your own path" and be done with it. However, reading through older discussion on this subject and getting a sensation that this is just "not an option", which I for the love of god cannot comprihend. Why in a game so specifically targeted at experience and non-casual users, where player is already given so much freedom and tools (and with them, responsibility for his own screw-ups) does not have this simple option (which already exists in the game, we already have the chose-your-own-platform signal which already contradicts the "always deterministic" model of train behavior to begin with).

But I digress. The "stacker platform", allowing us to simply create upkeep-less stations that can't be used to store, load and unload goods / passengers, but allows us to make trains stop there and more importantly, are treated as platforms thus allowing the use of chose-your-own platform making the trains stack side by side, would be honestly more than enough.

So: thoughts? Chances of implementations? ****, I anyone gave me some pointers how to make such an entity, I would gladly try myself, except I don't know where to even begin...

Thank you for reading, and if I sound aggrivated a bit, I do appologize. I respect this community, and I genuinely love the game, it just feels like these are some glarring and odd omissions in what would otherwise hold a perfect logistic sim back. And I don't want to open old wounds, even if I strongly disagree with some older sentiments about the mechanics.
I just want to have an option to create basic train stackers, as they are common in real world railyard infrastructure and very needed here in Simutrans.

prissi

First there are no stacker stations in real life, apart from depots. There are lots of these in OpenTTD, granted.

The choose path signals indeed require an end of choose path signal. Else it cannot guess, if the path is free. This is a looming recipe for desaster as soon as there is more than one entry or exit. Otherwise such signal require half a day of coding, since a lot could be derived from the choose signal.

However, solution 2 is already possible to do yourself: You can make a platform with zero capacity and no good enabled and zero maintenance. Just take any station tile, change the dat definition and compile it with makeobj. So this means in the dat file

enables_pax=0
enables_post=0
enables_ware=0
maintenance=0
cost=0
capacity=0

and the rest like the normal tile. Done.

Vladki

Such platforms already exists. In pak128.britain-ex, the goods siding is quite cheap, and has zero capacity. I'm not sure if that applies to standard version of the pakset though.
Also in pak128.CS we have bus stops with zero capacity (you can use even level=0), and low maintenance for similar purpose. (MANB_*)

However there is one point that these can be used to "cheat" and extend the catchment area of regular station. Therefore they are not completely free. But you can get the source files from https://sourceforge.net/p/simutrans/code/HEAD/tree/ and modify them for you own game.

Karel2501

Thank you Vladki for the quick reply.
Unfortunately, me and britain-ex pack aren't exactly friendly (it tends to crash on me) plus I just enjoy the aesthetics of a standard 128 a bit more.
I've looked into the goods siding, but it's still quite expensive for such a big piece of infrastructure. As for editing and modifying them myself... I'm not sure where to begin with it. I have no experience with editing PAK files, clearly they can't be edited through text editor of any sort. I did manage to manually just transfer "goods siding" from one pack to another, but it literally clashes with the size of the rails between the two paksets, plus the price is still too steep.
I'm going to and read up a bit on how to modify PAK files and maybe figure out something, but if you'd have any suggestions on where to start, I'd be grateful. If there is any easy way manipulate values and properties of any entitires in the game, I don't see it now...

Karel2501

To Prissy:
First, I'd like to thank you as well for replying. I'm gonna get a bit confrontational at the end of this post, but please don't take it as some kind of personal attack, it's just that I feel some things need to be said about some decisions about Simutrans design - one and only one aspect of it. And I'm going to say them only because I really value Simutrans enough to risk my appearance just for a chance of improvement.

But before I get to that:
"First there are no stacker stations in real life, apart from depots. There are lots of these in OpenTTD, granted."
I tend to really strongly disagree. Pic related. There is a train depo nearby, but this is a simple train stacker (or train parking lot or whatever you **** call it) in Atlanta. And you'll see smaller version of these in front of just about every major mine or major industrial complex in my country. Maybe our cultural definitions of "depot" differ, because to me, "depot" is where you actively service vehicles, and these are not there for servicing, they are there to make room for higher priority trains to go through first and wait for their time.

"You can do that yourself. Just change the dat file and compile with..."
Well, I have NO clue how to do any of that, since I still haven't figured out how even start meddling with PAK files, where to find the dat file and how to recompile that, but you gave me at least SOME pointers, and I'll jump right into figuring this stuff out. I am genuinely grateful for your reply in this manner, even if it still leaves me with more questions than answers.

Now to the harsher part:
"The choose path signals indeed require an end of choose path signal. Else it cannot guess, if the path is free. This is a looming recipe for desaster as soon as there is more than one entry or exit. Otherwise such signal require half a day of coding, since a lot could be derived from the choose signal."
It's a disaster if you use it poorly. Why not leave this up to the playe?. Why not allow him to have more options, even if it risks screwing himself over? Why is a game that is so mature, so uncompromising and high-respecting of it's audiences suddenly turning into such a patronizing thing, threating the player as so dumb that he can't be trusted with a tool that has a potential to backfire if used wrong?
And again: Making this disabled by default, hell, hiding in the config file to be unlockable would surely solve the problem of people inexpertly screwing up their railroad systems?

I really, really cannot comprihend this logic. You can already get equally screwed with misuse of the chose your own platform thing so this whole argumentation sounds hollow, and again: The core argument for not letting people CHOSE to take advantage of this possible option is so **** patronizing and arrogant towards the userbase it kinda shocks me. I can't help myself feeling like this has nothing to do with potential confusion and the "strict deterministic behavior doctrine" (which we - again - haven't been adhering to since the chose your own platform has been introduced ANYWAY), but that it is some kind of irrational and bizare matter of pride trying to stress out how much SimuTrans is NOT like OTT. That is to say, that it's a result of (perhaps unconscious) snobbism.
And if I'm not wrong about that, it's especially sad and pointless, there are so many other, FAR greater and FAR more important elements distinguishing Simutrans from OTTD that this weird obsession makes NO sense. Simultrans's BASE simulation, economy, destination-based goods tracking, all of those things are what makes SimuTrans so different (and in my eyes, vastly superior) to OTTD. Lack of chose your own path signal is insignificant.

Anyway, those are my two cents to this chose-your own path subject. Take them or leave them, I guess I can't change the whole community's attitude. I'm just telling you: It is not based anything resembling actually reasonal basis - it's a arbitrary decision that has no logical justification.

Mariculous

Your image looks like an ordinary classification yard.
There is no shunting in Simutrans.

Anyways, I'd like to see a little bit of dynamic train passing in simutrans too using choose signals on open track, but as Prissi said, it's not that simple.
Simutrans extended does allow this, but it's really not as useful as one might expect.

Vladki

@Karel, no need to get confrontational. I believe nobody thinks that players are stupid to use advanced features. But the game is quite complicated already and beginners tend to run into the same issues over and over. So I understand if there is some reluctancy to implement more complications.

Pak128.britain-ex is for simutrans-extended (a fork of simutrans) so it cannot be loaded by standard simutrans. However simutrans extended has improved choose signals that work partially in the way you suggest - they choose path, even if there is no station (platform) or if the train is not scheduled to stop at that station. And then as Prissi well suggested the end-of-choose sign is important to show where the alternative routes merge and the search for alternatives should stop. But in such case there must be free path through the station and beyond, otherwise the train will just wait at the choose signal.

Regarding PAK modifications. You cannot edit PAK directly. Each PAK file is made by compilation of DAT file (text file with definitions of what the object is), and one or more PNG files showing the graphics. They are compiled using makeobj (command line tool), which creates the final PAK file. I'm not sure if there is some thread explaining makeobj for beginners. Maybe here:
https://simutrans-germany.com/wiki/wiki/en_doPak
https://simutrans-germany.com/wiki/wiki/en_BuildingsDef

Regarding the train yard - this is most probably shunting yard, where trains are reassembled (CZ: seřadovací nádraží), which is not usedul in simutrans, as train reassembly is not implemented.  In real life, cargo trains are waiting on which ever station is at hand, when it is necessary to overtake. So usually each station has a few extra tracks for overtaking, but it is not centralized. Also overtaking trains is not easy in simutrans. If you need to overtake slow trains by express trains, then a long passing loop signaled with priority and minimum speed signals may be more useful than such yard with choose signals.

Also if you find that too many trains are waiting for clear track, or free platform at loading station, probably you dispatched too many trains and can send some of them to depot (and sell them or use on some other line).

Karel2501

I am sorry if I sound confrontational, but these are my honest thoughts. To say that it is because it would scare the begginers makes zero sense. First of all by your own admission it's intimidating as it is, even most basic actions can be very hard to figure out, so this is literally the LAST thing to make it any more inaccessible. Second of all: MAKE IT OPTIONAL THEN. The game already allows you to customize the game parameters to a RIDDICULOUS degree, and most of the advanced settings - if messed around without good idea what you are doing are going to break your game. How is including the option to a chose your own path tucked away into the same menu (Or indeed, config file) where you configure max ticks per month and specifics of tractive effects making things somehow worse? The game already puts an insane amount of trust into the player when customizing his game, without little guidance. So arguing by accessibility to newcomers - when we talk about function that does not have to be on by default and be part of the extensive settings only brave or experienced users ever meddle with, is - wishing no offense - absurd. Which is what makes drives my suspicion that the real reasons why the community stands against it have little to do with reason.

These functions being implemented into experimental further fuel that suspicion - that the refusal to include it was really just an out-dated sentiment that nowdays makes no sense. Unfortunately, Experimental does not work with my prefered pak-set, and most of the available one's are rather sparse, unfinished, or for whatever reason tend to crash as soon as I try to start a new game (partikularly the brit one).

Otherwise, thank you for the links about the use and editing of PAK files. I'll chew through them and maybe I'll manage to create what I need, I'm starting to understand it now.

And please: do not take what I'm saying personally - it's really not about desire to be confrontational or insulting. But I've been tracking this discussion about chose-your-own signals for a long time, and I have a very, very strong feeling a lot of (perhaps unconscious) dishonesty is underlying it. And I like to get to the root of things, even if it costs me some favors. All of the arguments I've seen (difficulty to implement, daunting to newcomers, strict adherence to the deterministic philosophy etc...) are not functional arguments: every single one can be solved or disproven easily. I am still waiting for an argument that would be actually rational.

Outside of that, I am of course, genuinely thankful that you are even engaging me on this subject. Please don't misinterpret my thoughts as sighn of lack of gratitude or respect for the community. As I say, I just want to really cut to the core of things, and as quickly as possible.

Roboron

For help with creating pak files, see the wiki Development Index https://simutrans-germany.com/wiki/wiki/en_Devel_Index

Now talking about my position. I've not played OTTD, so I can't say much about their solution, but I have played a lot of A-Train. If you know nothing about A-Train, I will tell you one important thing: it doesn't use signals! Of course they are very aware of this and, instead of signals, one needs* to use "temporary platforms" (specifically designed for that) to manage busy tracks, which sounds exactly like the second thing that karel is proposing. I like this solution because it doesn't need to change any existing code, and is less prone to accidental errors by players. Overall I prefer simple, elegant solutions, and this sounds like one.

* Of course the game is heavily based on micromagement of schedules, and the route can be defined by the player, so one can avoid using temporary platforms with enough micromanagement, but that does not scale well (can't say I didn't try).

Mariculous

A rather simple solution to this is implemented in extended.
Try it out and you will notice it's not pretty satisfactory. Much more effort would be needed to implement a choose signal that can send slow trains to the sidings in time, as done in the real-world.
If you still think it's rather easy, prepare a proof of concept.

Vladki

@Karel, simutrans-extended works pretty well, and british pak is the most complete. Actually I play almost exclusively only extended for last few years. Download the latest nightly here: http://bridgewater-brunel.me.uk/downloads/nightly/
Forget about any older versions (and especially if they are called experimental - those are obsolete).

Karel2501

Well, my attempt to create a new PAK object ended up with Makeobj simply not working at all. It literally does nothing upon activation, even through administrator tools. Any idea what might be the issue? By the way, the first link that was supposed to download Makeobj instead downloaded a Mac version of Simultrans, the second attempt (following the wiki link) just leads to a dead site, and third attempt, link provided through instruction on making paksets for Experimental did give me a Makeobj executable, and instruction to unpack it into simultrans core directory, but upon activation, it does literally nothing.

I will later give Experimental another try, but seriously, the last few times I've tried, it did not end up well for me...

Vladki

makeobj is command line tool. You have to invoke it from command prompt to see the output. If you run it without any arguments it will just print short hints what the arguments should be.  Simplest is:

makeobj pak128

That will compile all dat files in current directory.

And do not use makeobj for extended (or experimental). Such paks can be loaded only by simutrans-extended.

Karel2501

Thank you for all your time and replies.
I give up.
I've managed to do everything as the guides said, I got the makeobj run through cmd, got message: writing file Staker, followed by WARNING: cannot read ./NTUSER.DAT
And nothing happened. Now PAK file created, at least not anywhere I can see. I have no clue what to do more.

I still think this could be done so, so much easier and more intuitively it's beyond belief. It's still kinda hilarious that after all the **** trouble one has to do to make one adjustment to one entity in the game, people argue that chose your own path signals would be "too much for newcomers". I'm gonna give Experimental a try, maybe it won't crash every single time I try to load a map.

Still, thank you all for help, I appreciate the time and patience you had with me, I really do.

P.S. if anyone is capable of creating what I mentioned: A new type of "ghost" station that for little or no upkeep that allows me to create a stacking lines the trains will be able to use as platforms, even though they don't load/unload any goods and overcome the issue that way, let me know please. Personally, I can't figure it out, I just can't get the makeobj do what it is supposed to, even though it should be relatively simple.
Thank you again.

Mariculous


Karel2501

I noticed, you can't use anything with it. Even it's own generated map's crash 80% of the time, and the city generation is abhorent, creating solid square layouts every single time. Oh my. And I was so hoping the game is moving forward now. I really appreciate people doing all of this stuff for free, and I want to love Simutrans because when it comes to actual simulation and options, it's unsurpassed. But my god does it have some weird baggage with it, and I can't comprehend why everything about it turns out to be absurdly complicated, when there is no reason for any of this...

But still, thank you all.

Mariculous

The good thing about Simutrans is, you can help improving things at any time  :)

Karel2501

Apparently not, given even the process of creating basic new object in form of a PAK is literally too complicated for me.

BTW: what the hell is up with Experimental Britain-Ex unstability? Is there a repositorium of specifically Experimental-compatible height maps (as apparently any of the height maps I had for my 128 will crash it). Is there some very strict limit on terrain size or features (because most random-generated maps crash as well) that I need to know? Is there a settings I need to tweak to make the towns not look like absolute shite and have at least remotely natural shape to them? It feels like such a step down from the 128 in terms of basic usability.

Vladki

I have no stability problems with simutrans-extended, and pak128.britain-ex. Are you using the latest nightly from the link I gave you?    Remember simutrans-experimantal was renamed to simutrans-extended a few years ago. So if you run Experimental, you are running some old version that may be ****.   

The square shape of cities is know bug, but nobody had the time to fix it yet. It does not affect playability, so the few people who do the coding focus on more important things. As Freahk said, you are welcome to join the development team and fix it if you think it is so trivial :-P

About Makobj crashing - if you run it without specifying the which dat file to compile, it will look for ALL *.DAT files in current directory. Make sure you run it in directory where there is nothing else than makeobj.exe, and your dat and png files. NTUSER.DAT is windows system file so it is obvious that makeobj cannot understand it and crashes.

Roboron

Quote from: Karel2501 on October 28, 2020, 07:43:38 PMBTW: what the hell is up with Experimental Britain-Ex unstability?

If you have problems installing extended, and since I know you are coming from Steam, you have an <extended> beta branch available on Steam which will replace your Standard installation with Extended, and your Britan pakset with Britain-Ex. So far it has not caused me any crash. It should be up-to-date so don't worry about the version.

Karel2501

I never said fixing the issues with Experimental is easy. But I can tell you for sure that getting chose-your-own-path signals to work in standard is easy, because it IS ALREADY THERE, it's just intentionally crippled. The rest of my complaints were actually about how needlessly complicated everything is. I see no reason why objects are stored in a way where they can't be modified directly, despite LITERALLY consisting of two easily editable files: dat and pgn. Or why makeobj is so temperamental. And for the record: yes, I'm running the latest build of the Extended, and I haven't managed to get a single game running. I had the whole thing verified too. They unvariably crash after the map generation. Again: There might be some parameters I should know about that may be causing this. I suspect some heightmap features, maybe. Maybe it hates pre-existing height maps. Maybe it hates certain numbers of cities. Hard to tell as there is literally no info on any of this. Oh, and having your cities look like absolute **** and give no good way to introduce infrastructure is not what I would call unimportant, but that is besides the point.
As for the makeobj, it was located in a directory where no other .dat files are located: Literally only the modified .dat file based on the provided on from the links, and a relevant and properly named pgn.
There are NO other .dat files in the directory. Ntruser.dat is, as I found out, literally on a completely different drive. I also did the process with generic PAK128 parameter, and when specifying the actual adress of the .dat file in question, both to the same exact result.
And look, I'll freely admit I'm not good at this kind of ****. I've made an error somewhere along the way for sure, I'm sure making new PAK files isn't that hard, and I'm just unlucky and not diligent enough. Then again, I just wonder if the whole process is necessary - for so many reasons.

Mariculous

Quote from: Karel2501 on October 28, 2020, 08:21:24 PMI never said fixing the issues with Experimental is easy. But I can tell you for sure that getting chose-your-own-path signals to work in standard is easy, because it IS ALREADY THERE, it's just intentionally crippled.
So uncripple it and prove us that it works :)

Quote from: Karel2501 on October 28, 2020, 08:21:24 PMI see no reason why objects are stored in a way where they can't be modified directly
You get faster load times every time someone launches the game at cost of spending some time in compilation.
I see no reason not to do this!
Well originally it was also a (rather bad) way to protect authors content, back in a time where most paksets were not open source.

Quote from: Karel2501 on October 28, 2020, 08:21:24 PMAnd for the record: yes, I'm running the latest build of the Extended, and I haven't managed to get a single game running.
You're the first one I see with that issue.
Please file a kind bugreport so the issue can be fixed.

Didn't read on, too toxic. Sorry.

Vladki

One reason I can think of why you have problems runnig simutrans extended is, that you have some leftover config files from standard in the same directory. Download http://bridgewater-brunel.me.uk/downloads/nightly/packages/Simutrans-Extended-Complete.zip  and unzip it into clean directory and try again. I'm not using windows so I don't know if windows version assumes some directory for saves etc by default. So it may be good to move anything that belongs to simutrans standard out of the way.

Karel2501

To Freakh
Dude, if the train CAN properly pathfind from "chose your own platform" to end signals already, but only does it if it confirms there is a platform between them, then rather obviously, there is an extra condition there, meaning removing it would solve the issue. And as many people who spoke of the Extended version, it has clearly been done already: it has just for some reasons not been implemented here as well.

As for the use of PAK files, I see two good reasons why not to use them. Firstly, as you yourself admit, they are DESIGNED not to be meddled with, as a copy protection back when it wasn't open source. In a game that now RELIES on open-source community activity, this is literally a backwards decision. And I somehow doubt there are not other ways to compile the data in a way that can be reverse mingled with. Second one, it relies on packing software that needs to be ran through CMD - alone a **** unnecessary thing, but more to the point clearly unreliable. I've been meddling with it for the past hour: tried literally everything. The **** thing even includes very clear instructions on how to be used (I can get the makeobj respond, it's just that even if I use it precisely as instructed, it always spits out some random lines about node points and then does nothing). This is not a good system to have in a game that again, relieas on wider public helping to shape up the game. You want to talk about how chose-your-own-path would be confusing to newcomes? Well then why do you make it a NIGHTMARE to make even the slightest adjustments and additions to the game's content, something that I'm sure scares away more users than any confusion caused by said signals.

Finally, you literally do not know what "toxic" means, and refusal to read what others say proves that more than anything. I'm sorry for not coddling you, but that does not make me toxic - my concerns are valid, and I'll happily admit where my own shortcomings come in. I just treat you as a **** adult that does not need to be reassured every five seconds about how great everything is.You should get used to it.

To Vladki: Thank you for that suggestion, but unfortunately, it was my very first thought as well. I did a clean sweep of everything before switching to the Extended branch, and after that verified the intergrity on the top. That is not the issue.
I did eventually manage to generate some maps that worked, but the city generation is so abysmal it makes it almost unplayable anyway. Even when I ban large cities, and set median population of cities to around 500, the game will ALWAYS generate at least one perfectly rectangular city 50x150 tiles large, and even the small cities look completely absurd. It's not just an aesthetical issue, it's also a mechanical one, as you can't take advantage of the natural town layout to integrate your own infrastructure. So crashes aside, base elements like city generation in Extended are nowhere close to be in a properly playable state.

I would not mind, I can completely understand that Extended is essentially a EA project, that it does not CLAIM to be polished. I'd be happy to wait a year and then giving it a proper go. But the fact that people tell me I've got to play that because for reasons NOBODY CAN EXPLAIN RATIONALLY, basic functionalities have been skipped in the otherwise far more polished and stable Standard version is what grinds my gears.

I've proposed two relatively simple solutions to a problem I know for a fact TONS of people have. Unfortunately, one is rejected on basis of pure snobbery, the other near-impossible due to the most inefficient tools ever selected for an open-source-driven project, and the only constructive reply I've got is: go play a different version of the game - it solves your particular issue, as long as you don't mind everything else being broken.

Please understand why this kind of discourse leaves me somewhat bitter.

Vladki

Quote from: Karel2501 on October 28, 2020, 10:11:48 PMDude, if the train CAN properly pathfind from "chose your own platform" to end signals already, but only does it if it confirms there is a platform between them, then rather obviously, there is an extra condition there, meaning removing it would solve the issue. And as many people who spoke of the Extended version, it has clearly been done already: it has just for some reasons not been implemented here as well.

That is not how the choose-signal (in standard) works. It just looks for free platform. End-of-choose sign is just to limit the search of free platform - either to exclude some platforms or to avoid searching the whole map :).   In extended, this was improved to search for free path even without platforms as you suggest. But it was not "removing some arbitrary limitation". It was adding functionality that was not there before. Honestly I don't know why this improvement was not ported to standard. Maybe just nobody tried to do so...

Compiling with makeobj is still very important. Compilation of the whole pak128.britain-ex takes 4,5 minutes on my copmuter (i5-4250U). I believe you would not be patient enough to wait 5 minutes for the game to load.

If you post here the output of makeobj, and the relevant DAT and PNG file, we can check and help.

Roboron

I've never used MakeObj (I'm not a pak designer so I've never needed it), but I have always been curious about how it works. So this time, I did the work for you, and I've learned how makeobj works in the process.

1. I went to the pak128 sources, then searched for train platforms https://github.com/simutrans/pak128/tree/master/infrastructure/rail_stations
2. The basic freight platform seems to be "opentrainstop", so I downloaded both "opentrainstop.dat" and "opentrainstop.png". I put them in a folder alone with makeobj.
3. I edited opentrainstop.dat, and I added prissi's parameters. The I renamed "opentrainstop.dat" to "temporayplatform.dat" (only the .dat, not the .png, so I don't have to also replace references to the .png)
4. Then I executed makeobj, first with no parameters to show the help, then with the command "makeobj PAK temporaryplatform.pak temporaryplatform.dat" (it creates a temporaryplatform.pak output file from a temporaryplatform.dat input file).
QuoteMakeObj PAK <pak file> <dat file(s)>
         Creates a ready to use pak file for Simutrans from the dat files
5. I went to try it in-game, but images were wrong. It showed the text part of the png instead of the graphics. Since I am an experienced user, I guessed that it was because I have not specified the graphics size! Back to makeobj help:
QuoteMakeObj pak128 <pak file> <dat file(s)>
         Creates a special pak file for with 128x128 images
6. So that is what's missing. Final command is "makeobj pak128 temporaryplatform.pak temporaryplatform.dat". Results attached.

As a first-time using MakeObj it was pretty straightforward. Even more, if I had read the wiki, I would have known that the first attempt was going to fail, since the wiki mentions it!
However, if I can suggest something, I would prefer to deprecate "PAK" Makeobj option. It is really confusing for new users, as you can see, not only because it doesn't say what the default behaviour is, but also because always specifying the size of the pak is imho a good practice.

I hope my experience also help you get started with makeobj.

P.D.: About the argument that is stupid to have a command line tool to package software... It is invalid. Command line tools are perfect for software that only does "one job". And Makeobj being a command line tool doesn't prevent anyone to make an actual GUI that uses Makeobj internally! It's just that, as simple as it is, it is pretty stupid to make a GUI only for that ;-)

makie

I take a empty folder for my work.
Copy the .dat and .png in this.
And call "makeobj pak128" in this folder. ---> Do all .dat in this folder.

Then it is no need to declare the files in the comand-line.
You can make a button on the desktop for this call.

TurfIt

Quote from: Karel2501 on October 28, 2020, 08:21:24 PM
But I can tell you for sure that getting chose-your-own-path signals to work in standard is easy, because it IS ALREADY THERE,
Well, I can tell you for sure that chose-your-own-path signals, in standard, ARE NOT THERE. The choose signal, that is there, is a concession to the "deterministic philosophy" snobbery. It is also a hack. But a hack that can be lived with given the signals application only at the end of a path. As for a chose-you-own-path signal, I'll have to trot out the argument of "difficulty to implement" (correctly). Sure, you could layer another hack on top of the already hack choose signal, but the next complaint will be about the inevitable performance hit. See, path finding is expensive, and choose signals throw out already found routes to find an alternate, repeating much work. And yes, that could be changed, but by the time the snowball of changes ends, you're changing some real fundamentals of the code. So, lot's of work, just to finally end up with trains that send themselves all over the place.

Really, you should try playing Transport Tycoon and/or Transport Tycoon Deluxe. The originals. They have chose-your-own-path signals, indeed every signal is a choose signal. Build a large train network. Let us know how fun chose-your-own-path signals are!  (hint: they ain't).


Quote from: Karel2501 on October 28, 2020, 07:09:59 PM
I still think this could be done so, so much easier and more intuitively it's beyond belief. It's still kinda hilarious that after all the **** trouble one has to do to make one adjustment to one entity in the game, people argue that
Let's see:
  - download makeobj from sourceforge - 15 secs.
  - unzip - 5 secs
  - download source files (.dat, .png) for a pak128 train station from sourceforge - 30sec. (Had to browse around a while to find where they be...)
  - edit .dat with changes as given above - 5 secs.
  - run makeobj to assemble the .pak - 5secs.
60 seconds and done. Don't see how that is anything but absolutely trivial.

Roboron

Quote from: makie on October 28, 2020, 11:22:19 PMAnd call "makeobj pak128" in this folder. ---> Do all .dat in this folder.

Then it is no need to declare the files in the comand-line.

Another useful thing the help does not display :/

Isaac Eiland-Hall

No.

I am locking this topic. The behaviour by this member is unacceptable. A new topic may be started on the subject, but any further rudeness will result in consequences.


I have invited OP to create a new thread without the attitude or attacks. I have also set their account to require approval for posts, so a moderator/admin will have to approve any post before it appears.