JGR's Patch Pack

[Gliptal]

Hello, im kinda of new to OpenTTD modification.
So im trying to play your patch with all the NewGRFs and stuff it containts. I downloaded the windows binary version for 64 bits, then I extracted everything from the archive and opened the game from that folder. Then it prompted me to download the graphics after that told me that it detected no sound but thats not a problem.

The things is that the game doesnt have any NewGRFs or scripts or anything, its just the normal game.

What im I doing wrong?. Thank you for your help

The additions in this patch pack are not NewGRFs, but "patches" which are code modifications and cannot be disabled without recompilation. Everything is already included in the executable.

[Redirect Left]

Hello, im kinda of new to OpenTTD modification.
So im trying to play your patch with all the NewGRFs and stuff it containts. I downloaded the windows binary version for 64 bits, then I extracted everything from the archive and opened the game from that folder. Then it prompted me to download the graphics after that told me that it detected no sound but thats not a problem.

The things is that the game doesnt have any NewGRFs or scripts or anything, its just the normal game.

What im I doing wrong?. Thank you for your help

Patch packs work by editing the source code. The changes implemented are hardcoded into the game you are supplied with.

[mak]

Hello, im kinda of new to OpenTTD modification.
it's just the normal game.

What im I doing wrong?. Thank you for your help

Edit of post.

Oh. no its not,

Many 'things' have been added to the'basic' OTTD but are posssibly not easily noticed at first use.

You are doing nothing wrong. Just explore a little more and then add the GRF's that you would like or need.

[wallyweb]

Hello, im kinda of new to OpenTTD modification.
it's just the normal game.

What im I doing wrong?. Thank you for your help

Edit of post.

Oh. no its not,

Many 'things' have been added to the'basic' OTTD but are posssibly not easily noticed at first use.

You are doing nothing wrong. Just explore a little more and then add the GRF's that you would like or need.

A good place to explore is the first post of this topic. It lists all of the patches that JGR has applied to his pack.

[3iff]

Bug found with 30.1...however as you seem to have had problems with this version it may not now be relevant. However, I'll explain, just in case it's a real issue. I'll obviously test 30.3 but won't be able to report back for a week.

When AI tries to form a group, the AI crashes with "Wrong number of parameters" for the code:-

Group = AIGroup.creategroup(AIVehicle.VT-Rail);

This is within SimpleAI-V10 (although V14 is the current version but the code is the same - Builder.nut).
It has always worked perfectly in JGR versions pre v30. I'm back using v29.0 and have no issues with AI players.

The mouseover industry window issue I reported has been fixed in 30.1 - thankyou for that.

This suggests that the AI compat files are missing/not updated.
Can you check that these are installed as well as the executable, language files, etc.

Ok, I'll double-check all of this. It's just odd that V29.0 works fine with exactly the same files as are available for 30.1 (I just copy the new exe/lang files to the right places and rename them as appropriate...). I might try a fresh folder for everything.

I'll report back in a week. Thanks again.

[Eddi]

(I just copy the new exe/lang files to the right places and rename them as appropriate...)

that is generally a dangerous thing to do, because you might miss essential files. which is probably the cause of your error.

always use a clean folder.

[Brumi]

It's definitely the compatibility files that are causing the crash. Vehicle groups can be organized in a hierarcy since 1.9.0, so AIGroup::CreateGroup got an extra parameter: the parent group of the new group.

compat_1.2.nut should contain the following excerpt:

Code: Select all

/* 1.9 adds parent_group_id to CreateGroup function */
AIGroup._CreateGroup <- AIGroup.CreateGroup;
AIGroup.CreateGroup <- function(vehicle_type)
{
	return AIGroup._CreateGroup(vehicle_type, AIGroup.GROUP_INVALID);
} 

If this part is not there in your file, then your compatibility files are not up to date

[eekee]

Edit: Make that 3 bugs: "Can't remove signals from here... Train in the way" means you can't remove signals when it's safest to do so. What? It's a nuisance on a very busy slow line full of long fast-accelerating trains. It's not fun trying to add signals to the line, either. I'm recalling just how glad I was when OpenTTD lifted this restriction.

This is the same as in trunk, it doesn't seem an unreasonable restriction.

No, trunk (edit: actually 1.9.0) allows removing signals with trains 'in the way'. As for reasonableness, imagine adjusting details of this network with all those maglevs wooshing around and pause-building disabled. I learned the hard way when is best to remove signals. (The amount of time I put into each network is not reasonable, I'm sure.)

Now fixed in trunk, or at least in today's nightly build: openttd-20190420-master-gc17736b493-windows-win64.zip. I can wait, I just won't move certain saves to JGRPP until its next release. I haven't been playing them anyway.

[SimYouLater]

Also, any chance of the Larger Depot patch getting into this? I asked about it, I think... two months ago?

It is on my list of future things to do/look into/consider.
The list is quite long and there are other things with higher priorities, so I can't make any promises at present.

It's been 8 months. Just checking in, to see if this will still be awhile, or if it's planned anytime soon?

...

You didn't see my post, did you?

[JGR]

It is on my list of future things to do/look into/consider.
The list is quite long and there are other things with higher priorities, so I can't make any promises at present.

It's been 8 months. Just checking in, to see if this will still be awhile, or if it's planned anytime soon?

...

You didn't see my post, did you?

I only have a finite quantity of free time for OpenTTD-related activities.
A feature like this is likely to be non-trivial quantity of work/time for me both prior to release, and afterwards in processing incoming bug reports, whilst providing only marginal utility.
Naturally, real life demands, bugs, and more interesting development areas will take priority, and therefore there is no concrete plan for when it or anything else may or may not come to some manner of fruition or otherwise.

[SimYouLater]

It's been 8 months. Just checking in, to see if this will still be awhile, or if it's planned anytime soon?

...

You didn't see my post, did you?

I only have a finite quantity of free time for OpenTTD-related activities.
A feature like this is likely to be non-trivial quantity of work/time for me both prior to release, and afterwards in processing incoming bug reports, whilst providing only marginal utility.
Naturally, real life demands, bugs, and more interesting development areas will take priority, and therefore there is no concrete plan for when it or anything else may or may not come to some manner of fruition or otherwise.

Alright, fair enough. Sorry to bother you.

[acs121]

This may be a stupid question, but I couldn't find the "Larger Depot patch" and I'd want to know what it is myself. Thank you in advance.

[SimYouLater]

This may be a stupid question, but I couldn't find the "Larger Depot patch" and I'd want to know what it is myself. Thank you in advance.

Search for "Juanjo". He made the patch.

[Qwerty Asd]

can you add custom airport? mybe we need custom airport that can designable like train station

[acs121]

can you add custom airport? mybe we need custom airport that can designable like train station

Well, it's not like other patches that have been suggested for implemention in this patch pack, this one hasn't even been coded in a releaseable version.
IIRC Juanjo began a patch for custom airports some time ago, but it's not ready for any implementation.
And again, I highly doubt JGR has lots of IRL leftover time to code such a patch.

[jfs]

Custom airports have been on the wishlist for many, many years. The problem is the movement of aircraft on the ground, it's very complex setting it up so they can't deadlock, for example three or more aircraft each waiting for one of the other to move, and none of them can. The existing airports already have some very carefully designed state machines that prevent deadlock situations, if you wanted player-designed airports you would likely end up with lots of unsolveable problems.

There is halfway some support for NewGRF-designed airports, and as far as I know there have also been attempts at making the ground movements state machine controllable from NewGRF, but it hasn't been finished.

[eekee]

The problem is the movement of aircraft on the ground, it's very complex setting it up so they can't deadlock, for example three or more aircraft each waiting for one of the other to move, and none of them can.

This is already a problem for both road vehicles and trains, it's already part of the game. It's solved in road vehicles (including trams) by letting them overlap after a waiting period. If the player doesn't like it, he can change the setup, although it's not always easy. It's not solved in trains, but it's not too hard to avoid in network design. Either solution could work for player-designed airports. I prefer the train solution because it's less ugly, and I think it's probably workable. Planes follow specific tracks rather like trains. The road vehicle solution could be excused with, "Planes on the ground are basically very big road vehicles with limited visibility and speed."

[acs121]

The road vehicle solution could be excused with, "Planes on the ground are basically very big road vehicles with limited visibility and speed."

Yes. They do have limited visibility and speed. Unlike road vehicles
Road vehicles are allowed to take over each other IRL just as in OpenTTD because we consider you have great visibility and speed (unless you're taking over a snail).

[eekee]

Yes. They do have limited visibility and speed. Unlike road vehicles

Road vehicles are allowed to take over each other IRL just as in OpenTTD because we consider you have great visibility and speed (unless you're taking over a snail).

I wasn't talking about that. Give a road vehicle Full Load orders for a drive-through station with limited supply (or i guess no supply), so it will be waiting a long time. Clone it 3 or 4 times, let them go and watch the queue. After several minutes, (5 or 10, perhaps,) the third or 4th vehicle will drive to the front of the station through the vehicles in front! The same happens in gridlock, easy to observe with HEQS, refit the Dynamo Express tram to its longest length. It's 5 squares long.

[Eddi]

vehicle will drive to the front of the station through the vehicles in front

while that is a solution to the deadlock problem, it is not a good solution.

the thing is, with both trains and roadvehicles, the player has methods of influencing the vehicles (like, letting them turn around), that you don't get with planes, that's why it's more important to put pressure on the designers to avoid such deadlocks.