Belugas wrote:

1. If i read the code correctly, we provide 512 total slots. So substract the 110 usual native houses and you have 402 available ones.

2. Care to explain the "Allow many houses on one slot" ? Pretty illogical for me

3. You want to change name? But can't you do that while loading the properties? Or do yo want to change it ingame?

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5103

George wrote:

1. 512 per game, but only 256 per GRF, right?
2. I mean there may be one houseID (that is located on the land slot), but its' graphics and behaviour is totally different depending on some condition. Year of build, for example. So, I have a general "hotel", on houseID XX that can be build in any year. When the hotel is built in 1920-th, then it has a small house graphics with low capacity (population). In 1960-th it is built as a medium house with medium capacity, and in 2000-th it is a tall building with high capacity. Is it clean now?
   3)Yes, I want to change it in game. Like "Old hotel", "hotel", "modern hotel" while it is only one houseID.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5105

Belugas wrote:

1. would be possible under only 2 conditions :
   a) prop 8 and 9 will be extended to W instead of B in version 8 of NFO
   b) two new props been added, which will be the long version of prop 8/9
   honestly, I do not know which one is better. b) sounds like a big hack to me, honestly. Only a0 sounds sane. But I jabe no clule as to when it could be done.

About 2), i migh give it a try to implement the requested callback, although i cannot promise you anything, i'm on a too tight schedule at work, and frankly, there days, i'm pretty pissed off by the simple look of a computer...

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5121

George wrote:

Fine, Belugas, I just made a request :)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5123

Belugas wrote:

grrrr.... props 08/09 have nothing to do with it...
I just woke up with that in mind :(

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5125

Belugas wrote:

Good news : -> http://wiki.ttdpatch.net/tiki-index.php?page=Action0
-> "The is an extended byte since 2.0.1 alpha 61, to support the definition of >255 sound effects. In OpenTTD since r13482, extended IDs can be used for vehicles as well. However there is currently a caveat that articulated parts must be below 128."
This applies to the local id of the house you are defining. Not prop 8/9. So, it means that is an extended byte, which means more than 256.
So 1) is already done :)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5126

George wrote:

Made a test. The problem is with action 3 - looks like it does not apply new graphics to extended byte House ID

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5129

George wrote:

[09:34:13] <@rubidium> looks like the action 3 doesn't read an extended byte
[09:35:03] <@rubidium> though I'm not sure whether just making it an extended byte doesn't break existing newgrfs (that assume it's a byte)
[09:37:32] <@rubidium> changing that would possibly require a newgrf version bump, but I'm far from certain

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5130

frosch wrote:

Increasing the 512 limit is unlikely, as the map array is already filled for houses.

Increasing the 256 limit to 512 does not sound reasonable, as it is a lot of work for only a factor 2 more houses.

A callback-36-like callback is troublesome for house population (town population would run out of sync if population changes after the house is built -> desyncs in network). Other properties seem to not cause any problems.

Maybe access to some variables can be restricted for the population callback - But looking at them, no house variable is safe. I.e. even the house age is limited at 255, so you cannot reconstruct the construction year and therefore the population after those 255 years are full.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5251

PhilSophus wrote:

A callback-36-like callback is troublesome for house population (town population would run out of sync if population changes after the house is built -> desyncs in network).

I don't see how this should be problematic, if you would do something like that:

town_population -= house_population;
house_population = callbackX();
town_population += house_population;

The result should be the same for all clients and the server, or do I miss something? Only question is, when should it be called? Once a month, once a year, every 256 ticks, when getting cargo? Something like that, I guess.

I've kind of a Mars colonizing scenario in mind (kind of idee fixe, not that I had even started with it), where arriving colonists (which are produced by a space port) are converted 1:1 into population. Each habitation dome would just increase population until an upper limit. In that case the latter would come handy.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5252

frosch wrote:

ok, so you would say loop the map array once a year and update the population in the HouseSpec.
But that way you change the population of all houses of that id, no matter when they were built.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5253

George wrote:

Frosch: why do checking house tile animation frame number is not safe? I planned to use it to store the population variant.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5259

frosch wrote:

Currently the population is needed:
a) When loading/creating a game to calculate town populations.
b) When joining a multiplayer game to calculate town populations.
c) When building a house to increment town population.
d) When removing a house to decrement town population.
e) In the house tile loop to produce cargo.

Furthermore it is not possible:
- to store the population per house as there is no space left in the map array (i.e. every time the population is needed the callback has to be called),
- to trust the newgrf to always return the same callback result as that failed horribly in the past.

The only possible solution I currently know of is
- to call a callback in the yearly loop to update the town population by calling it before and after the age incrementing,
- to let this callback only access the age variable and maybe some variables which never change after the house is finished,
- but especially do not allow access to the animation frame, as it may change all the time and not only during the yearly loop.

But honestly, I doubt this callback is very useful as e.g. the houses which were build in the same year would update all on the same first january.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5260

George wrote:

Frosch:
Do I understand it right, that when CB 2E is defined, case e) does not happen?
So, THE only usage for house population is town population?

Then, may I ask to split the task into two?

1. the house name callback (as understood the discussion it is relative easy to do)
2. the house population callback, that should be frozen for now unless landscape array change planned, when this information could be stored on the map.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5264

PhilSophus wrote:

Okay, the piece of information I was missing in my previous comment was that houses do not have off-map storage as industries do. So, we can't store the population per house instance. I don't know if it would help George, if not the population of each house, but of each house type could be changed (i.e. providing a callback that would be called once per house ID per time period and would change the population of all houses of this type)? Hmm, getting the town population in sync afterwards seems a bit of a hassle (easy, but costly solution, recalculate town populations by iterating over all house tiles on the map).

As for my idee fixe: It seems if I were ever to realize it, I would probably be better off to give industries the possibility to contribute population to their related town. Making industries "better houses" would also solve the issue that habitation domes would have to be larger than 2x2 to look nice (see also George's #1983).

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5279

frosch wrote:

PhilSophus: We discussed with george, that CB 2E is already enough, and changing population by callback is unimportant.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5281

George wrote:

PhilSophus: The same population per house type is useless. I'd change population to average population for the type.
Frosch: And what about a name CB?

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5283

frosch wrote:

name is no problem at all, just wondering whether it would be a callback on its own (maybe when textstack would also be needed somewhen), or whether a callback-36-like callback should be introduced (in case there would be more modifiable properties somewhen, but currently I see no other property which is not controllable already by some other callback, which would make sense to be modified; except population).

however, I am not planning to add any newgrf features until I get around to do the grf version 8 cleanups.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5285

George wrote:

Frosch: select the way you prefer. Both CB36 or new CB would be fine.
As for me, a new CB would be easier.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5287

Belugas wrote:

After checking stuff, it seems that allowing more than 256 houses per grf set causes problems here and there.
First, action 3 only accept bytes (thus 256 objects).
Second, there are some varactions that are expecting only bytes as parameters (see var action 61).
Third, action 00 extended byte means that local id 255 is reserved and cannot be reused.

All stuff I cannot fix. So I guess you'll have to do the same kind of multiple grf files that you've started to do with the Vectors GRFs
From my point of view...

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5319

George wrote:

No problem to have 2 GRFs. But Name CB is still required. Having many IDs with per GRF limitation as there is for vehicles would be cool, but currently 512 types is a hard limit, I suppose.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5321

Belugas wrote:

Name service Callback is on my plate indeed.
No promised date tough ;)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441#comment5332

Belugas closed the ticket.

Reason for closing: Implemented

well...the name callback.
The others been not possible to do...
r15172

This comment was imported from FlySpray: https://bugs.openttd.org/task/2441