Merge lp:~widelands-dev/widelands/bug_1571009_work_area_radius into lp:widelands

Proposed by Klaus Halfmann
Status: Merged
Merged at revision: 7973
Proposed branch: lp:~widelands-dev/widelands/bug_1571009_work_area_radius
Merge into: lp:widelands
Diff against target: 71 lines (+30/-7)
2 files modified
src/logic/map_objects/tribes/workarea_info.h (+21/-4)
src/scripting/lua_map.cc (+9/-3)
To merge this branch: bzr merge lp:~widelands-dev/widelands/bug_1571009_work_area_radius
Reviewer Review Type Date Requested Status
Klaus Halfmann Needs Resubmitting
GunChleoc Approve
Review via email: mp+292066@code.launchpad.net

Description of the change

This fixes 1571009 and adds some more Docs for the WorkareaInfo.

Im not usre about the Lua-Mapping, perhaps returning some kind of null might be better?

To post a comment you must log in.
Revision history for this message
Miroslav Remák (miroslavr256) wrote :

See diff comments.

Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :

Thanks for the hints

Revision history for this message
Miroslav Remák (miroslavr256) wrote :

Diff reply.

Revision history for this message
bunnybot (widelandsofficial) wrote :

Continuous integration builds have changed state:

Travis build 1020. State: failed. Details: https://travis-ci.org/widelands/widelands/builds/123553136.
Appveyor build 852. State: failed. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1571009_work_area_radius-852.

Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :

hope I fixed the codecheck issues now.

Revision history for this message
GunChleoc (gunchleoc) wrote :

The Lua functions always return an int, that's how the interface works.

I don't agree with your TODO comment - see diff comments.

Otherwise, code LGTM - I'm still waiting for the compiler for testing.

Revision history for this message
Miroslav Remák (miroslavr256) wrote :

Diff.

Revision history for this message
Miroslav Remák (miroslavr256) wrote :

> The Lua functions always return an int, that's how the interface works.
Sure, but why are you bringing this up? Has anyone said otherwise?

Revision history for this message
GunChleoc (gunchleoc) wrote :

Tested and working :)

Please remove the TODO comment before merging.

review: Abstain
Revision history for this message
GunChleoc (gunchleoc) :
review: Approve
Revision history for this message
GunChleoc (gunchleoc) wrote :

For merging, set a commit message, then add a comment with ATbunnybot merge in it.

Revision history for this message
bunnybot (widelandsofficial) wrote :

Continuous integration builds have changed state:

Travis build 1021. State: passed. Details: https://travis-ci.org/widelands/widelands/builds/123665737.
Appveyor build 853. State: failed. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1571009_work_area_radius-853.

Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :

Whats the Problem with Appveyor?
I did not find the Problem.
Did the build take to long?
Did I cancel it?

Revision history for this message
Tino (tino79) wrote :

Yes, inderectly: We have rolling builds on Appveyor. This means the moment you commit a new revision, the current build of the branch is cancelled.

Revision history for this message
GunChleoc (gunchleoc) wrote :

I still don't agree with your TODO comment. The Fortress has multiple workareas on purpose - it shows you the area that it will be able to conquer when you upgrade to a Citadel. If you have ideas for improving the code, replacing the map with a uint is not the way to go.

Revision history for this message
Klaus Halfmann (klaus-halfmann) wrote :

Hello Gun, I reviewd that comment in workarea_info.h again.
Its just that I do not fully understand the usage of that map, yet.
So if you know what stings are used, please add them.

As of the implementation of std:map this will be correct, I guess.
But it usually is a abd idea to depend on some implemenation that
may change. OTOH the hashcode of integer may not change ever again.

Example: From Java JDK1.3 to 1.4 the Implementation of String.hashCode()
was changed. Some code had implicit dependencies on the order of Elements
in string based maps an therefore started to fail.

Please feel free to change the comment to your liking.

review: Needs Resubmitting
Revision history for this message
GunChleoc (gunchleoc) wrote :

Now I understand what you're getting at, you have a valid point about the sort order. Thanks for explaining :)

@bunnybot merge

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/logic/map_objects/tribes/workarea_info.h'
2--- src/logic/map_objects/tribes/workarea_info.h 2015-11-28 22:29:26 +0000
3+++ src/logic/map_objects/tribes/workarea_info.h 2016-04-23 16:57:13 +0000
4@@ -1,5 +1,5 @@
5 /*
6- * Copyright (C) 2005, 2008 by the Widelands Development Team
7+ * Copyright (C) 2005-2016 by the Widelands Development Team
8 *
9 * This program is free software; you can redistribute it and/or
10 * modify it under the terms of the GNU General Public License
11@@ -25,9 +25,26 @@
12 #include <set>
13 #include <string>
14
15-// This type is used to store information about workareas. It stores radii and
16-// for each radius a set of strings. Each string contains a description of an
17-// activity (or similar) that can be performed within the radius.
18+/** The WorkareaInfo stores radii and for each radius a set of strings.
19+ *
20+ * A Workarea is a "circle" around a building that this building affects
21+ * or is needed by this buildingr., e.g. Areas for Mines, Fields of a Farm.
22+ * Worareas are shown on the Map when clicking on or placing a building.
23+ *
24+ * Each string contains a description of an activity (or similar)
25+ * that can be performed within the radius. Examples are buldings
26+ * that can be upgraded like a Fortress, and will have a bigger
27+ * workarea then.
28+ *
29+ * See LuaBuildingDescription::get_workarea_radius, InteractiveBase::show_work_area
30+ */
31+
32+// TODO(Hasi50): LuaBuildingDescription::get_workarea_radius will only give us the very first
33+// size found, which seems to be correct but depends on the std:map implementation
34+//
35+// We could just use a unit8 as base for the map?
36+// We should document (as const) the expected stings.
37+
38 using WorkareaInfo = std::map<uint32_t, std::set<std::string>>;
39
40 #endif // end of include guard: WL_LOGIC_MAP_OBJECTS_TRIBES_WORKAREA_INFO_H
41
42=== modified file 'src/scripting/lua_map.cc'
43--- src/scripting/lua_map.cc 2016-04-22 06:55:37 +0000
44+++ src/scripting/lua_map.cc 2016-04-23 16:57:13 +0000
45@@ -672,7 +672,7 @@
46 case (MapObjectType::WARE):
47 default:
48 throw LuaError((boost::format("upcasted_map_object_to_lua: Unknown %i") %
49- static_cast<int>(mo->descr().type())).str());
50+ static_cast<int>(mo->descr().type())).str());
51 }
52 }
53 #undef CAST_TO_LUA
54@@ -1871,10 +1871,16 @@
55 /* RST
56 .. attribute:: workarea_radius
57
58- (RO) the workarea_radius of the building as an int.
59+ (RO) the first workarea_radius of the building as an int,
60+ nil in case bulding has no workareas
61 */
62 int LuaBuildingDescription::get_workarea_radius(lua_State * L) {
63- lua_pushinteger(L, get()->workarea_info_.begin()->first);
64+ const WorkareaInfo& workareaInfo = get()->workarea_info_;
65+ if (!workareaInfo.empty()) {
66+ lua_pushinteger(L, workareaInfo.begin()->first);
67+ } else {
68+ lua_pushnil(L);
69+ }
70 return 1;
71 }
72

Subscribers

People subscribed via source and target branches

to status/vote changes: