Topic: Read conf files to generate building help

GunChleoc
Avatar
Topic Opener
Joined: 2013-10-07, 15:56 UTC+2.0
Posts: 3317
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2013-10-23, 12:28 UTC+2.0

While working on the help files, I noticed a mismatch between "Dismantle yields" in a building's help file and the corresponding conf. I think we could prevent errors like this if part of the help files were generated based on the data in the conf files. I tried writing a Lua parser for the conf files, but already failed trying to read the file contents with Lua's IO library - all I get is attempt to index global 'io' (a nil value).

I'd be happy to have a go at this is someone could get io.lines ([filename]) to work for me.


Busy indexing nil values

Top Quote
SirVer

Joined: 2009-02-19, 15:18 UTC+1.0
Posts: 1442
Ranking
One Elder of Players
Location: Germany - Munich
Posted at: 2013-10-23, 22:56 UTC+2.0

The problem you describe is https://bugs.launchpad.net/widelands/+bug/1074353 . The correct solution is not to parse the conf files from Lua, but to provide a Lua API for the help files (and the rest of Widelands). This task is not difficult, but a bit tedious and the interface is not completely clear to me. I think you could add the necessary wrapping, documentation and tests from what I saw you do so far and I would gladly provide you with the necessary support.

In c++, most tribe objects have an Instance type (i.e. ProductionSite) and a description type (i.e. ProdutionSiteDescr). You can ask each productionsite for its parameters like this: productionsite->descr()->output_wares(). Something similar is currently not possible in Lua. You can ask some buildings for some stuff (i.e. you can ask a productionsite for its workers, but that will return the currently stationed workers in this building, not something like "what worker slots are available in this building"). I could now image two ways of doing thinks. Either

  1. add the descriptions directly to the building: building.output_wares (would return something like {"marble", "stone"} for a quarry). But this could potentially clash with specific informations (i.e. would get_workers return the workers that are here or that could be here?). Also, in the help file you need the generic information without having a specific building object to ask for information (i.e. you want to show help for a lumberjacks_house even though none has been build yet).
  2. add a description class that can be asked for a building type without having a building: building.description.output_wares or p1.tribe.get_building_description("lumberjacks_house").building_wares

I think I like 2 better, but that means that the existing API needs to get slightly changed so that generic information is no longer available on the buildings themselves.

Do I make any sense at all? However, most of this stuff should be pretty straightforward and simple wrappers - but they need to get done. We could pair via screen sharing (i.e. over google hangout) and write the first wrapper together and then you could do the rest or so.


Top Quote
GunChleoc
Avatar
Topic Opener
Joined: 2013-10-07, 15:56 UTC+2.0
Posts: 3317
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2013-10-25, 07:38 UTC+2.0

I also like 2 better. I'll try to catch you on IRC this weekend.


Busy indexing nil values

Top Quote
GunChleoc
Avatar
Topic Opener
Joined: 2013-10-07, 15:56 UTC+2.0
Posts: 3317
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2013-12-13, 16:55 UTC+1.0

@SirVer: I've got myself an IRC client so I can keep the channels open. /query me when you have some time and we can see about finding a date when we can work on this?


Busy indexing nil values

Top Quote
SirVer

Joined: 2009-02-19, 15:18 UTC+1.0
Posts: 1442
Ranking
One Elder of Players
Location: Germany - Munich
Posted at: 2013-12-14, 14:50 UTC+1.0

Will do.


Top Quote
GunChleoc
Avatar
Topic Opener
Joined: 2013-10-07, 15:56 UTC+2.0
Posts: 3317
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2013-12-19, 16:06 UTC+1.0

I have finished implementing this for the simple values.

We now need to extend the API in buildcost.h before we can start grabbing the building costs. We will need access to the list of ware names + amounts. If someone could implement this, I will then try to get this into Lua.

Branch is here: https://code.launchpad.net/~widelands-dev/widelands/bug-1074353

Edited: 2013-12-19, 16:07 UTC+1.0

Busy indexing nil values

Top Quote
Adamant

Joined: 2012-10-11, 16:21 UTC+2.0
Posts: 180
Ranking
Widelands-Forum-Junkie
Location: Alemania
Posted at: 2013-12-26, 23:44 UTC+1.0

SirVer wrote: ... 1. add the descriptions directly to the building: building.output_wares (would return something like {"marble", "stone"} for a quarry). But this could potentially clash with specific informations (i.e. would get_workers return the workers that are here or that could be here?). Also, in the help file you need the generic information without having a specific building object to ask for information (i.e. you want to show help for a lumberjacks_house even though none has been build yet). 2. add a description class that can be asked for a building type without having a building: building.description.output_wares or p1.tribe.get_building_description("lumberjacks_house").building_wares

I think I like 2 better, but that means that the existing API needs to get slightly changed so that generic information is no longer available on the buildings themselves.

I am not really sure If I don't think about same but my Idea about is this: DSCR-Data could for Class ProductionSite could placed either static or unstatic Section (C++ does not know about static Section but seperate Object-Data from Class-Data and Methods into single DataCode-Structure and the latter is static resp is what I refered with static Section) but that would make all different Types of ProductionSite share same DSCR. The plain other Way arround is if all Instances of ProductionType gets personal DSCR Object what would be unnecessary as different Instances can concern same ProductionSite-Type as SubClass. So add simply Pointers to Instances which points to shared DSCR resp to their SubClass-TypeInstance (wow-wow-wow .. OOP-Terms leaves me here now. Thing of Class SubClass resp Type SubType which mainly points to its SuperClass here ProductionSite and to shared Members like DSCR) which then can take more Data and Pointers to more shared Items and DSCR is just one of many. I am not sure if that deals the PRoblem explained above.

Edited: 2013-12-27, 01:29 UTC+1.0

Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too.

Top Quote
Adamant

Joined: 2012-10-11, 16:21 UTC+2.0
Posts: 180
Ranking
Widelands-Forum-Junkie
Location: Alemania
Posted at: 2013-12-27, 01:24 UTC+1.0

In Context of adding new DSCR.Section into CONF-Files I want to point to Fact that DSCR cocerns to DATA for GUI especially and there are other Things inside CONF-Files which concerns to GUI as well. These are Section which explain how to display Wares in WareHouse-View while the Item-Icon concerns IMO more to specific Ware but the WareHouse (Issue of Model Control and View resp to DataEncapsulation OOP Concept. Ware knows how its look like while WareHouse knows how to present it.). This or that Way there misses Section GUI as Top-Category to put inside Things which concerns Look&Feel of MapObject-Instances resp Classes. When cleaning up there I would like to see also Flag and Frontier outsourced into specific Folder no Matter if its Data is small but due to it does not fit into Level of Scope of Tribe-Config same like Carrier got its own Folder.

There is Kind of Rule that a SubFolder in Folder Tribe is a Tribe (alright! :D) and that SubFolder with eg Name FooTribe contains a File named CONF that contains CFG for that Tribe. For real do even all other SubFolders below FooTribe contains GameObjects defined in CFG-File always named CONF. When you work with FileEditor and have opened multiple Files that's rather confusing. Better change Rule that Folder FooTribe contains File FooTribe.conf which dfins Tribe instead. This is easy to code resp compute and is known to work fine resp usual Convention to name Files according to its concerning Class. As Tribes are all located below Folder Tribe I would like to see same for SubClasses Worker and Site, Fields and Wares and Resources cleaning up Tribe-Folder totally. Thus origins Opportunity to resign for Declaration-Part in Tribe-Folder like eg for Wares as Folders listed below Folder Wares can do that alternatively and thus simplifies Modification of Tribes extremely.

For Trees in specific World Trees implement Kind of LifeCycle via Transformation-Chain inclusive DST of Dead Tree. I think existing Infrastructure resp Code is able to easily transform Site insite into advanced Site into burning Site and Ashes resp Ruin without Need for special Support from ECO resp that existing Support can get changed to update Site-Features resp treat Sites with Features supplied from Ruin properly. However, aside of Suggestion for special Adaption Aim here is again to drop Ruin and BurningSite out of Tribe's CONF as special Matter while use existing generic Mechanism resp advance these to cover new Tasks. Technical Point is if Lumberer calls Tree's fall-Method then similar could pressing destruct-Button call specific Destruct-Method of Site. Btw figured out that there exist several Ruins for Babarian Buildings which could allow alternative Destruct-Method to left these Ruins instead the Standard-Ruin-Type. Again was Aim here to tide up CFG for Tribe. In that Scope I wonder should Carrier resp especially Worker resp CONF-PRGs be able to place Flags manually resp provide that Interface and use it. It's somewhat surprising when a new MilitarySite gets crewed and new Sight reveals that Frontier Markers are already there .. who placed them?

However, good Moment to ask for these Changes as DSCR as new Item means Work in same Code-Region. In that Context I ask also to replace implicite Play/Call of Idle-Animation by Idle-Program which allow more Freedom to custumize that Ability. In that Context I would like to see (get able to write CONF) that Carrier close to Taver enter it to drink a Beer due to Summer is hot. Even if these small Things won't have Meaning for GamePlay-Issues (eg just Animation without mining a Beer in Tavern) these enrich the Game visually what means to be nice Alternative resp Opportunitiy to change Behavior of Idle-Chain especially.


Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too.

Top Quote
GunChleoc
Avatar
Topic Opener
Joined: 2013-10-07, 15:56 UTC+2.0
Posts: 3317
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2014-01-14, 11:34 UTC+1.0

Thanks for yor input, but we already have it covered and started working on a patch. It's just a case of writing soe wrappers face-wink.png


Busy indexing nil values

Top Quote