JGR's Patch Pack

[redivider]

Im trying to figure out how to get logic signals from your patch to his patch but my 0 c++ skill is not helping... how the heck does one go about doing it? I alteast managed to compile vanilla ttd after hours of struggling.

[ino]

I am assuming you are the same guy as https://www.reddit.com/r/openttd/commen ... m_signals/.

I think JGR mentioned before that he is not interested in Logic Signal, but I might be wrong. And TBH, I haven't found anything I cannot do with routefinding restriction.

No offence, but if you are not comfortable in C++, I wouldn't suggest you try to do it yourself though. While OpenTTD code is pretty good, it is extremely complex.

The main branch in JGR is `jgrpp`. I don't think it even has `development` branch. Each branch is a feature directly apply on top of vanilla OpenTTD code, and the branch with `-sx` means it also use JGR's savegame extension procedure (which is located in `save-ext`). All branch are merged to `jgrpp`, but is kept separate for (I believed to be) maintenance purpose.

[redivider]

Just tried it, got a billion errors, yay, gonna try again tommorow. If I can figure out how the @@ marking line system thing works I dont think its actually that hard. The logic signal patch barely has any lines, well most are just declarations etc. I just need to check same variables and change them and then merge the patches in correctly. One day Ill finish it. And ye Im the same guy.

Edit: Nevermind I just realized there is a programable signal in advanced settings that i SOMEHOW missed...

[KeldorKatarn]

Programmable signals != Logic Signals. And as I said, the standard logic signal patch was NOT in good condition. it had tons of problems that needed fixing. IF JGR is interested he should go through my code instead. I think I added it way before I even thought about doing proper commit separation so people can read it, at that point I was doing the repository purely for myself, but if he just looks for the signal type and then works his way back through every dependency and occurance of it, he should be able to somehow integrate it into his code. Our code bases are almost identical where the signals are concerned anyway.

[Alberth]

If I can figure out how the @@ marking line system thing works I dont think its actually that hard.

This is easy. It's a defined file format, known as unified diff. There are a number of variations within the format, but @@ is part of the basic format.
Wikipedia amongst others described the format.

[JGR]

Is the industry generation of cargo also scaled to the town generation of cargo? If not, could you add it in?

It's not, this isn't really practical due to NewGRF industries.

I don't plan to add logic signals. Programmable signals is an (almost) complete superset of the functionality.
The programmable signals implementation as originally imported was also very poor quality.
If I was starting again from scratch I would not bother including either of them, frankly.

[KeldorKatarn]

I agree that they're probably not worth it.

Also btw JGR, I'm about to steal 2 years worth of your patchpack into my version I'd like to thank you for the work you're putting into making small usability changes and importing all kinds of stuff. I would never have the time for half these things. You're one of the few C++ devs out there that I trust enough to just copy & paste most of the code and trust it'll work fine.

[Wahazar]

I tested these slot operations, interesting feature, some my remarks:
[*] there is lot of "train lost" messages spamming when train search its path trough section which temporarily have no free slots, not sure if bug or feature?
[*] 2-way path signals operations should be done only when train is facing to the signal, not backward, eventually there should be option to choose both direction or one (is it necessary to have both?)

Regards,
Mc

[ino]

I tested these slot operations, interesting feature, some my remarks:
[*] there is lot of "train lost" messages spamming when train search its path trough section which temporarily have no free slots, not sure if bug or feature?
[*] 2-way path signals operations should be done only when train is facing to the signal, not backward, eventually there should be option to choose both direction or one (is it necessary to have both?)

Regards,
Mc

1. I have use slot extensively and have not experience that before though. Normally, I found that lost train come from misusing 'Deny'. Did you use Deny or Wait at PBS when doing slot?

2. There's an 'If entry direction is front/back' condition for you to use. Entry from back is useful when you have two-way path signal as a station starting signal, you can use entry from the back to guide train to proper.l platforms.

[Wahazar]

Did you use Deny or Wait at PBS when doing slot?

Yes, it was that case, now with "if entry direction" things are much easier.

[ino]

Now, I just realised this feature was added in trunk, and I am unable to figure out what it is so please JGR enlighten me. What is "through-load" ?

[agentw4b]

Im trying to figure out how to get logic signals from your patch to his patch but my 0 c++ skill is not helping... how the heck does one go about doing it? I alteast managed to compile vanilla ttd after hours of struggling.

There are no logical signals in the JGR patch. I also tried to solve it a few months ago in the discussion below, and the reactions to inclusion of logical signals into normal play or JGR patch pack were rather negative.



viewtopic.php?f=33&t=47690&start=120


Logic signals : viewtopic.php?f=33&t=68436

Logic signal are in Joker's patch pack, but I do not know , where I downloaded it.


Perhaps it would be better to do some gamescript for manual control of switches and traffic lights. I will try to do this.

[NekoMaster]

So while JGR Patch pack allows more then 64 GRFs to be loaded in single player, apparently (accord to some people that like to use a lot of GRFS) no more then 63 GRFs can be loaded in multiplayer.

Is there a way to disable/fix that limit for multiplayer (even if say, loading 255 grfs might be a bit demanding on the computer or internet for download)

[kamnet]

So while JGR Patch pack allows more then 64 GRFs to be loaded in single player, apparently (accord to some people that like to use a lot of GRFS) no more then 63 GRFs can be loaded in multiplayer.

Is there a way to disable/fix that limit for multiplayer (even if say, loading 255 grfs might be a bit demanding on the computer or internet for download)

You could go into the source code and modify it, but you're going to significantly increase the likelihood of desyncs and unstable connections.

[KeldorKatarn]

Why on Earth would that increase the desync probability? It makes no difference for desync if one or one thousand NewGRFs are loaded. And it is possible to remove the multiplayer limit. I've already done it. JGR will probably include it in his pack soon as well, he's looking over my code to see if I missed anything.

[KeldorKatarn]

So while JGR Patch pack allows more then 64 GRFs to be loaded in single player, apparently (accord to some people that like to use a lot of GRFS) no more then 63 GRFs can be loaded in multiplayer.

Is there a way to disable/fix that limit for multiplayer (even if say, loading 255 grfs might be a bit demanding on the computer or internet for download)

it has nothing to do with download. The client doesn't download anything from the server. It simply gets a list what newGRFs it needs. If it doesn't have them, it can't connect to the game. The 62 limit is there because that's the number of "newgrf names" the server can send to the client in one message, because the message has a size limit.

I removed that by simply sending multiple messages. Once the client knows what to load and has done so, no further communication like this is needed since from that point on server and client are in perfect sync and have both loaded the exact same NewGRFs.

[peter1138]

The multiplayer server browser list uses UDP for efficiency when getting server information from each server. 1 network packet is received from the server which tells the client what's needed to connect. If you have to send more than 1 packet, you need to handle retries for lost packets (which is pretty common, especially as you get a burst of packets from all the different servers at once)

If you handle retries, you might as well use TCP because that's designed to be reliable in the first place. But querying all the servers with TCP has quite a lot of overhead.

[KeldorKatarn]

The game already implements retries for lost packets. The initial packet might just as easily gotten lost as any of the others. I've made sure the client knows what the correct order of the packets is. The actual game connection does already happen via TCP.

[NekoMaster]

So while JGR Patch pack allows more then 64 GRFs to be loaded in single player, apparently (accord to some people that like to use a lot of GRFS) no more then 63 GRFs can be loaded in multiplayer.

Is there a way to disable/fix that limit for multiplayer (even if say, loading 255 grfs might be a bit demanding on the computer or internet for download)

it has nothing to do with download. The client doesn't download anything from the server. It simply gets a list what newGRFs it needs. If it doesn't have them, it can't connect to the game. The 62 limit is there because that's the number of "newgrf names" the server can send to the client in one message, because the message has a size limit.

I removed that by simply sending multiple messages. Once the client knows what to load and has done so, no further communication like this is needed since from that point on server and client are in perfect sync and have both loaded the exact same NewGRFs.

When I mentioned downloading I meant like when joining a server with GRF's and one has to download the exact GRFs the server is running to join it, having lots of GRF may be a bit slow to download at times (larger GRFs might also take a bit of ones data cap if you live in a place like Canada or the USA with small data caps like 2GB)

[SimYouLater]

So while JGR Patch pack allows more then 64 GRFs to be loaded in single player, apparently (accord to some people that like to use a lot of GRFS) no more then 63 GRFs can be loaded in multiplayer.

Is there a way to disable/fix that limit for multiplayer (even if say, loading 255 grfs might be a bit demanding on the computer or internet for download)

it has nothing to do with download. The client doesn't download anything from the server. It simply gets a list what newGRFs it needs. If it doesn't have them, it can't connect to the game. The 62 limit is there because that's the number of "newgrf names" the server can send to the client in one message, because the message has a size limit.

I removed that by simply sending multiple messages. Once the client knows what to load and has done so, no further communication like this is needed since from that point on server and client are in perfect sync and have both loaded the exact same NewGRFs.

When I mentioned downloading I meant like when joining a server with GRF's and one has to download the exact GRFs the server is running to join it, having lots of GRF may be a bit slow to download at times (larger GRFs might also take a bit of ones data cap if you live in a place like Canada or the USA with small data caps like 2GB)

2GB data caps? There are some places in the US that are horrible (Comcast are evil, IMO) and probably some places in the provinces with flat land or permafrost where internet is slow, but I live in a small town in Canada. We have fiber internet. 2GB is insanely low.

Also, I'm saddened that those larger depots are too much work to add. It would really enhance the realism.