"Inspect in place" - newgrf info displayed for debugging

[andythenorth]

This thread tracks efforts to make newgrf creation better by providing various in-game debug information and other tools.

Newgrf Debug Info / Tools - Progress
- DONE Newgrf developer mode as config option http://vcs.openttd.org/svn/changeset/19515/
- DONE Reload newgrfs from console http://vcs.openttd.org/svn/changeset/19515/
- PATCH AVAILABLE Show values of industry registers, special flags and cb flags

- In-game offset editor for vehicles
- Show values of special flags and cb flags for vehicles
- Enhance date cheat: set year directly instead of clicking arrows back/forward (to test intro dates, date specific nfo)
- Set current load amount for vehicles (testing loaded vehicles is time-consuming esp. for secondary cargos).

- (I'll add other suggestions here, send me pm/irc)

-- How to Use the Tools --

1. openttd.cfg setting for newgrf_developer_tools

Code: Select all

[gui]
newgrf_developer_tools = true

2. console command 'reload_newgrfs' - no more trips to the newgrf window, just hit ~, up arrow, enter

[andythenorth]

It's often stated that nfo is hard. It's not really.

But debugging grfs is really hard. I know there are logging tools for detailed output, but that's not how my coding brain works. Pretty often I get tripped up by stupid things like not setting a cb flag correctly.

This mockup screenie shows how it could work:
- An advanced config option would enable the little 'bug' button on the menu bar.
- When that button is clicked, a simple window would show relevant info for the object in question. Contents would obviously vary for industries, vehicles etc.

inspect_in_place_2.png (26.01 KiB) Viewed 4427 times

I would be keen to help anybody who was prepared to try and produce a patch for this. I can compile, test, help with text strings and formatting, and possibly write some GUI code. And hey, I've drawn a bug icon already for the button

bug.png (166 Bytes) Viewed 3995 times

cheers,

Andy

[2007Alain2007]

Hi
Also there would be no need to add this in the seting gui becuse many players will never need this
so its on in the config you can turn it on/off defult off

[cmoiromain]

I agree this is useless in trunk. Only a very little portion of players would use it.
However, the patch itself is usefull indeed; the best way do distribute it IMO is either to let grf developpers compile it themselves, which most coders will probably be capable of, or to add to the nightlies a special developper build with this tool, and maybe some others if they are developped later.

[planetmaker]

I agree this is useless in trunk. Only a very little portion of players would use it.
However, the patch itself is usefull indeed; the best way do distribute it IMO is either to let grf developpers compile it themselves, which most coders will probably be capable of, or to add to the nightlies a special developper build with this tool, and maybe some others if they are developped later.

Few people or only developers using a feature does not mean that it should not be in trunk. Who of the players uses the debugging command line options or any other of the command line options or even Ctrl+B ingame or alike? Nevertheless all those things are useful features built into trunk for good reason. Also certainly not every grf developer (many of those are mostly graphics artists, not coders) is capable or willing to compile OpenTTD for him/herself, thus it'd put up an unnecessary barrier. Making the development of add-ons easy is IMHO a good thing, too.

[cmoiromain]

Who of the players uses the debugging command line options or any other of the command line options or even Ctrl+B ingame or alike?

Good point... The thing is, developers are often reminding that each new feature is some extra work to maintaint later on, so the fewer, the better. That being said, maybe you are right, and this debug option should be in trunk. But would it be best to have it activate-able from the condig menu, or from the console? I believe giving too many options to the average player is bad; OpenTTD already has scores of settings, which is good because it allows everyone to choose the features he likes, but on the other hand this huge amount of parameters can seem overwhelming.

[andythenorth]

Good point... The thing is, developers are often reminding that each new feature is some extra work to maintaint later on, so the fewer, the better

If it's not in trunk it will have to be maintained anyway. It's the same amount of work either way. I often have to compile nightlies or diffs from devs to test some newgrf feature. I'm not excited by the idea of having to regularly remove then reapply a debug patch

But would it be best to have it activate-able from the condig menu, or from the console?

Console. I 100% agree with you on too many options being a bad thing

[Eddi]

OpenTTD is definitely lacking some serious GRF debugging features. For example fixing sprite offsets, or following the execution of callbacks [i.e. breakpoints/single step]

IMHO the newgrf authors need to make a list of required/useful features and then get a dev to work on them.

[andythenorth]

(content moved to first post of this thread)

[andythenorth]

r19723 contains *serious* cookies for newgrf authors