Page 154 of 243
Re: JGR's Patch Pack
Posted: 26 Nov 2020 22:23
by JGR
andreasaspenberg wrote: 26 Nov 2020 19:56
the editor only have one map size. that size also works perfectly when i use a generated map. please either fix the issue or remove the editor. no sense in having an editor when its maps does not work in multiplayer. i also did not place the uranium mines, power plants and those others. those appeared through the industry generator, which is disabled for all other industries.
Please see here for how to operate the scenario editor:
https://wiki.openttd.org/en/Manual/Scenario%20editor
I cannot magically make your machine or those of your clients go faster.
Re: JGR's Patch Pack
Posted: 28 Nov 2020 12:58
by andreasaspenberg
i am not asking you to make my pcs faster. they are fast enough. the game works perfectly in multiplayer when i use a generated map, even when using the maximum map size. it does not however work when using a map made with the editor. then all clients lags and drops. my pcs all have intel core i7. they are all over 3 ghz while the host have 6 cores. it is clearly a bug in the game.
Re: JGR's Patch Pack
Posted: 28 Nov 2020 14:53
by jfs
There is no difference between a generated map and a map made in the editor whatsoever. The only differences can be how large you make the map, and what you put on it.
If you want someone to actually be able to look at your problem, you should share a savegame of one of your generated maps that play well, and a savegame of one of your editor-made maps that cause problems. Then someone will be able to analyze those savegames and figure out why they cause different behaviour.
Re: JGR's Patch Pack
Posted: 28 Nov 2020 20:25
by Amak
andreasaspenberg wrote: 28 Nov 2020 12:58
i am not asking you to make my pcs faster. they are fast enough. the game works perfectly in multiplayer when i use a generated map, even when using the maximum map size. it does not however work when using a map made with the editor. then all clients lags and drops. my pcs all have intel core i7. they are all over 3 ghz while the host have 6 cores. it is clearly a bug in the game.
you can increase timeout settings in openttd.cfg found normally in C:\Users\CptAwesome\OneDrive\Documents\OpenTTD\
You are looking for the settings:
max_init_time = 32000
max_join_time = 32000
max_download_time = 32000
max_lag_time = 32000
Maybe others, these are what I changed when my laptop could not join a 4k/8k map over my lan, now I have no problems; maybe it solve your problem too
.
Re: JGR's Patch Pack
Posted: 28 Nov 2020 23:14
by Azurlazar
Azurlazar escribió: ↑18 Nov 2020 18:21
Yeah I know that, but I mean, with this hipotetic option you could switch the architectures specially if you are useing the "32bpp extra zoom proyect" architecture, or any specific architecture you want to load and switch. Because I think the way you said would be only for one architecture in an immovable concrete way.
Gadg8eer escribió: ↑12 Nov 2020 20:53
I'll think about it, I might be able to make a GRF that selects the buildings based on a user menu parameter instead of the selected climate. If you don't want to wait a few months, you could learn to program a GRF in NML yourself very easily...
https://www.tt-wiki.net/wiki/NMLTutorial
Azurzar escribió: ↑10 Nov 2020 22:10
Thanks friend, I will take a look at the tutorial out of curiosity, I would love to learn. I do not know if I correctly expressed what I wanted, I rewrite it here: for a simply aesthetic or stylistic reason, I would like to have the chance to choose not only the climate, but the architecture independently, in such a way that even architectural mods can interpret which class should spawn regardless of the weather. So I can have temperate buildings in arctic climates <3. If you manage to do it, I have no problem waiting <3 ...
Gadg8eer escribió:
Ah, I see. Unfortunately, that would not be doable as a GRF, and I doubt it will ever be added as a code change to the game. Sorry, this community is very stubborn about saying "do it yourself" to anyone who asks for anything.
Arriba
Ty dud! I already understand what you say, but that is why I raised it here in this forum of this beautiful patch that plays with important changes to the code. I think it would be a widely used feature, although it is true that today nobody gives a damn about such subtleties. There is much more interest in the vehicles themselves than in the context in which they operate, speaking clearly from a strictly visual point of view.
Regards!
Re: JGR's Patch Pack
Posted: 30 Nov 2020 10:23
by dol422
Hi,
Please find attached crash report. This happened whilst attempting to restart an existing savegame.
Re: JGR's Patch Pack
Posted: 30 Nov 2020 19:22
by JGR
dol422 wrote: 30 Nov 2020 10:23
Hi,
Please find attached crash report. This happened whilst attempting to restart an existing savegame.
Thanks for the bug report. This is fixed now and will be in the next release.
Re: JGR's Patch Pack
Posted: 01 Dec 2020 14:41
by Argus
When loading joker patchpack games there are problems with the vehicles, collision nrt versions?
Re: JGR's Patch Pack
Posted: 01 Dec 2020 18:21
by JGR
Argus wrote: 01 Dec 2020 14:41
When loading joker patchpack games there are problems with the vehicles, collision nrt versions?
Could you post the jokerpp savegame that you're using, I'll take a look.
Re: JGR's Patch Pack
Posted: 01 Dec 2020 18:38
by Argus
Re: JGR's Patch Pack
Posted: 01 Dec 2020 18:42
by Argus
Where I only have cars, it doesn't. There must be trams or other types (trolleybus as an example)
Re: JGR's Patch Pack
Posted: 01 Dec 2020 21:25
by JGR
This is fixed now and will be in the next release. See attached for a save which will load in v0.39.1.
Re: JGR's Patch Pack
Posted: 01 Dec 2020 22:07
by Argus
Thanks. What is the reason?
Re: JGR's Patch Pack
Posted: 01 Dec 2020 23:46
by JGR
Argus wrote: 01 Dec 2020 22:07
Thanks. What is the reason?
Remapping of road/tram type IDs from JokerPP savegames was not quite correct, so tiles could end up with the wrong road or tram type.
Re: JGR's Patch Pack
Posted: 02 Dec 2020 12:23
by michael blunck
I have a problem with those "custom features" in OTTD trunk:
Code: Select all
"C" "FTST"
"T" "NAME" 00 "property_mapping" 00
"B" "SETP" 01 00 04
00 00
"C" "A0PM"
"T" "NAME" 00 "station_min_bridge_height" 00
"B" "SETT" 01 00 05
"B" "FEAT" 01 00 04
"B" "PROP" 01 00 1c
"B" "FLBK" 01 00 00
00 00
->
22 * 0 07 8D 01 00 05 04
23 * 0 00 04 01 01 00
1c 08 01 01 01 01 01 01 01 01
24 * 0 00 04 01 01 01
1c 08 01 01 01 01 01 01 01 01
25 * 0 00 04 01 01 02
1c 08 01 01 01 01 01 01 01 01
26 * 0 00 04 01 01 03
1c 08 01 01 01 01 01 01 01 01
In trunk (1.8 ) I get "unknown action0 property 0x1c (sprite 23)"
Also the feature test doesn't seem to work:
Code: Select all
22 * 0 07 9D 04 00 05 05
23 * 0 07 8D 01 00 05 04
24 * 0 00 04 01 01 00
1c 08 01 01 01 01 01 01 01 01
25 * 0 00 04 01 01 01
1c 08 01 01 01 01 01 01 01 01
26 * 0 00 04 01 01 02
1c 08 01 01 01 01 01 01 01 01
27 * 0 00 04 01 01 03
1c 08 01 01 01 01 01 01 01 01
gives "unknown action0 property 0x1c (sprite 24)"
BTW, nfo specs says that 0x8B is a byte? Or is it a DWord in JGRPP?
regards
Michael
Re: JGR's Patch Pack
Posted: 02 Dec 2020 14:03
by JGR
The condition looks inverted here, probably it should be as below, to jump if the bit is clear.
Same here, this skips over the block if the feature is indeed present.
michael blunck wrote: 02 Dec 2020 12:23
BTW, nfo specs says that 0x8B is a byte? Or is it a DWord in JGRPP?
All normal variables are 4 bytes/DWORD sized.
The NFO specs indicating that a variable is a byte is just a hint that the upper 24 bits can be assumed to be 0. That can be freely ignored as required.
Re: JGR's Patch Pack
Posted: 02 Dec 2020 15:52
by michael blunck
For some reason I thought that \70 would correspond to 00, and \71 to 01. My bad ...
Thanks for reminding me.
regards
Michael
Re: JGR's Patch Pack
Posted: 03 Dec 2020 00:13
by Eddi
JGR wrote: 02 Dec 2020 14:03The NFO specs indicating that a variable is a byte is just a hint that the upper 24 bits can be assumed to be 0.
uhm, that sounds wrong. it may happen to be true in OpenTTD, but in general, and in particular in TTDPatch, i would think it rather means "upper bytes can contain arbitrary data
Re: JGR's Patch Pack
Posted: 03 Dec 2020 10:49
by michael blunck
JGR wrote:
All normal variables are 4 bytes/DWORD sized
Does that mean, there are indeed (some) variables which are not 4 bytes?
I mean, the nfo docs specify a lot of different var sizes, which I take consideration of in my m4nfo implementation. Which would be quite more simple in case all vars were indeed 4 bytes? Except the problem Eddi mentioned?
Another question regarding your custom feature implementation:
There are different names for features and associated property mappings. So, for checking a specific feature I'd have to use e.g. "action0_station_prop1B", and to check for success of its associated property mapping I have to use " station_min_bridge_height". There might be reasons for this, but couldn't the names be the same? I'm aware there are features which don't establish property mappings.
Is it needed to test both for the availability of a feature and then again for success of the mapping process?
And are programmable/restricted signals (as custom features) the same (signal type == 6), only different by setting bit 24 in var18? I.e. for a programmable signal I'd have to set signal type to 6 and also bit 24 in var18? So, there's no signal type 7? I mean the TT range is still quite empty? Or are programmable and restricted signals the same, internally? And thus need to be handled by the same signal type?
regards
Michael
Re: JGR's Patch Pack
Posted: 03 Dec 2020 12:31
by JGR
michael blunck wrote: 03 Dec 2020 10:49
JGR wrote:
All normal variables are 4 bytes/DWORD sized
Does that mean, there are indeed (some) variables which are not 4 bytes?
I mean, the nfo docs specify a lot of different var sizes, which I take consideration of in my m4nfo implementation. Which would be quite more simple in case all vars were indeed 4 bytes? Except the problem Eddi mentioned?
Variable 0x85 (TTDPatch flags) is one which comes to mind as clearly not 4 bytes, however this is special cased and only usable for bit tests.
michael blunck wrote: 03 Dec 2020 10:49
Another question regarding your custom feature implementation:
There are different names for features and associated property mappings. So, for checking a specific feature I'd have to use e.g. "action0_station_prop1B", and to check for success of its associated property mapping I have to use " station_min_bridge_height". There might be reasons for this, but couldn't the names be the same? I'm aware there are features which don't establish property mappings.
Is it needed to test both for the availability of a feature and then again for success of the mapping process?
And are programmable/restricted signals (as custom features) the same (signal type == 6), only different by setting bit 24 in var18? I.e. for a programmable signal I'd have to set signal type to 6 and also bit 24 in var18? So, there's no signal type 7? I mean the TT range is still quite empty? Or are programmable and restricted signals the same, internally? And thus need to be handled by the same signal type?
regards
Michael
The names are different are they are conceptually different things, though in retrospect the names could have been made the same. I'm a bit reluctant to change them now though as there are already GRFs using them.
The default property mapping fallback mode is such that mapping an unknown property or action 5 type and then using it is not an error, the property is simply skipped. (This is why all the values are length-prefixed).
Testing any one of these is sufficient, it's not necessary to test all/multiple of them:
* Testing the feature name 'property_mapping' or 'action5_type_id_mapping' respectively.
* Testing the mapping success via the SETT field and var 0x8D.
* Testing the feature name for the specific property.
If you're doing something more complicated than just setting properties you may need to do more than one test, or use a specific one instead of just 'any one of these'.
The redundancy of mechanisms is so that no matter what is being done and how complicated it is, there is a way to do it correctly which falls back on all of: trunk OpenTTD without property mapping, patchpack with property mapping and without feature, patchpack with property mapping and with feature.
michael blunck wrote: 03 Dec 2020 10:49
And are programmable/restricted signals (as custom features) the same (signal type == 6), only different by setting bit 24 in var18? I.e. for a programmable signal I'd have to set signal type to 6 and also bit 24 in var18? So, there's no signal type 7? I mean the TT range is still quite empty? Or are programmable and restricted signals the same, internally? And thus need to be handled by the same signal type?
Programmable pre-signals are signal type == 6.
Restricted signals are not a signal type. Any signal can have a routing restriction program attached. bit 24 in var18 indicates this if the feature is enabled.
Currently there is no signal type == 7.