How to use DoCommandP

[Wahazar]

Finally, I just added industry_list command console for displaying valid industry IDs and names:

Code: Select all

DEF_CONSOLE_CMD(ConIndustryIdList)
{
	IConsoleHelp("Registered industries IDs and names:");
	uint8 id = 0;
	while (id < NUM_INDUSTRYTYPES) {
		  
		IndustrySpec *indsp = &_industry_specs[id];
		if (indsp->name != STR_NEWGRF_INVALID_INDUSTRYTYPE)
		{
			char industry_name[512];
			GetString(industry_name, indsp->name, lastof(industry_name));
			IConsolePrintF(CC_DEFAULT, "%d : %s", id, industry_name);
		}
		id++;
	}
	return true;
}

I want to make similar function for object, but have no clue, where objects are stored (newgrf objects, because standard objects are defined elsewhere).
Thanks in advance for any help.

[frosch]

You probably want to replace

Code: Select all

if (indsp->name != STR_NEWGRF_INVALID_INDUSTRYTYPE)

with

Code: Select all

if (indsp->enabled)

.

For objects it's basically the same, just replace INDUSTRY with OBJECT, i.e. NUM_OBJECTS and _object_spec.
Dito for houses, cargos, ...

Maybe you also want to display the NewGRF data (GrfId, Local Id, Name) from IndustrySpec::grf_prop, so it gets some relation to NewGRF readmes/documentation.

[Wahazar]

For objects it's basically the same, just replace INDUSTRY with OBJECT, i.e. NUM_OBJECTS and _object_spec.

Thanks for answer. I tried _object_specs but it was out of the scope, therefore I wonder if other variable is used to store it.
Extern redeclaration helped.

Good idea with additional newgrf information. I have two version depending on additional command line parameter - short Id+name list and detailed one.
It works fine with IndustrySpec, but access to grf_prop cause game crash in case of ObjectSpec.
Probably it is related with something like GRFFilePropsBase< 2 >, but I have no idea how to properly access such structure?
What <2> stand for in C++?

[Alberth]

It's the actual parameter list of a template.

[adf88]

Don't use IDs. Use names. If you are creating a custom OpenTTD build, translating industry names is not a problem any more.

You can do the translation during scenario save/load procedure - convert all labels from names to IDs while saving, from IDs to names while loading, from names to names while changing the language.

Alternatively you can implement a separate type of labels - industry labels - and do the translation while displaying/placing these labels. In this case industries could be picked from a GUI list instead of typing their names. These new labels would have to be stored like regular labels so a non-patched OpenTTD client can play the scenario. The only thing that would change is the way how your custom client handles them.

[Wahazar]

It's the actual parameter list of a template.

I looked at some handbooks, including "An Idiot's Guide to C++ Templates", but I still don't understand, how I should properly change following code to properly fetch newgrf filename without segmentation fault:

Code: Select all

ObjectSpec *objsp = &_object_specs[id];
...
objsp->grf_prop.grffile->filename

Don't use IDs. Use names. If you are creating a custom OpenTTD build, translating industry names is not a problem any more.

I'm using these Id both for creating in scenario editor or building during game via tile label game script.

[Alberth]

perhaps 'grffile' is NULL?

[Wahazar]

perhaps 'grffile' is NULL?

Sure, for first five objects.
Same apply for industries, if no industry newgrf is loaded.

Note to myself: one more pointer check is better than one less.

[adf88]

Don't use IDs. Use names. If you are creating a custom OpenTTD build, translating industry names is not a problem any more.

I'm using these Id both for creating in scenario editor or building during game via tile label game script.

And I'm telling you that you don't have to bother any users with bizarre industry IDs! You're creating a custom OpenTTD client for scenario editors right? So show to them a GUI list with industry names so they can simply pick an industry of their interest instead of typing it's ID or name. While displaying industry labels, print industry names, not IDs. None of the users will ever have to know that there exists something like industry ID.

[Wahazar]

None of the users will ever have to know that there exists something like industry ID.

OK, but how to use GSIndustryType.BuildIndustry function without knowledge of certain ID then?
Here is example of input file:

Code: Select all

PrintWorks Martin,Y,0,-1836,-1047,7
>>>Tiskarna:1960:7:30,N,0,-1670,-1645,0

First line define instant creation of industry Id=7 in scenario editor.
Second line create just a label, to be used later by TileLabel Industry Builder GS for building industry during game (on non-patched openttd).
How to tell GS, which Id should be used?

[adf88]

I'm suggesting to modify only the GUI part of the OpenTTD. Internally nothing would be changed. Industry labels would still be stored (in .scn files) as regular labels containing industry IDs. The only thing that would change is the way how OpenTTD displays them and the way how they are being placed/edited. I can think of few approaches.

Approach 1 - on the fly.

• Inside .scn files: store industry labels as regular text labels (ID+year+range)
• In memory: store industry labels as regular text labels (ID+year+range)
• While displaying labels: test whether a label has this specific format (ID+year+range) and display translated text (name+year+range)

Approach 2 - precomputed, translated text.

• Inside .scn files: store industry labels as regular text labels (ID+year+range)
• In memory: store industry labels as regular text labels, but translated (name+year+range)
• During scenario loading: test whether a label has this specific format (ID+year+range) and translate it (name+year+range).
• During scenario saving: test whether a label has this specific format (name+year+range) and untranslate it (ID+year+range).
• During in-game language change: re-translate industry labels.

Approach 3 - precomputed, binary.

• Inside .scn files: store industry labels as regular text labels (ID+year+range)
• In memory: store industry labels as binary industry labels (ID+year+range). Create a separate type (struct) for them but keep them inside the same pool as regular labels.
• During scenario saving: store them as regular text labels (ID+year+range).
• During scenario loading: test whether a label has this specific format (ID+year+range) and parse it into binary industry label.
• While displaying industry labels: convert them to a translated text (name+year+range)

Independently of whether you use any of the above approaches, you can always change the way how industry labels are being placed/edited. You can display a GUI list from which an industry can be picked.

BTW, perhaps it's better to use local IDs (these defined by GRF authors) so one can do scenario editing on a non-patched client (these IDs may be documented somewhere else).