#1215 closed defect (fixed)
[PATCH] Trade can occur between two incomplete buildings
Reported by: | gudo | Owned by: | O.Davoodi |
---|---|---|---|
Priority: | Release Blocker | Milestone: | Alpha 10 |
Component: | UI & Simulation | Keywords: | trade, patch |
Cc: | Patch: |
Description
When setting up a trade route, it is possible to trade between two incomplete structures.
Place two Market foundations, but do not build them. Attempt to establish a trade route between the two Trade will happen successfully.
Attachments (6)
Change History (24)
comment:1 by , 12 years ago
Milestone: | Backlog → Alpha 10 |
---|---|
Priority: | Should Have → Must Have |
comment:2 by , 12 years ago
Priority: | Must Have → Release Blocker |
---|
comment:3 by , 12 years ago
Keywords: | review added |
---|---|
Summary: | Trade can occur between two incomplete buildings → [PATCH] Trade can occur between two incomplete buildings |
comment:4 by , 12 years ago
comment:5 by , 12 years ago
Attached new patches for ticket 1215. Added the check to simulation. Note:Ignore that "train" part in input.js please.
by , 12 years ago
Attachment: | patch2.patch added |
---|
by , 12 years ago
Attachment: | patch3.patch added |
---|
follow-up: 8 comment:6 by , 12 years ago
attached a newer patch. removed the lines from other tickets. but i'll commit them together.
comment:7 by , 12 years ago
Keywords: | patch added |
---|---|
Owner: | set to |
comment:8 by , 12 years ago
Replying to Spahbod:
attached a newer patch. removed the lines from other tickets. but i'll commit them together.
How are you creating the patches? Could you apply them all locally and then create a single diff/patch
from the root directory of your working copy? That makes it a bit easier to review and test :)
comment:9 by , 12 years ago
For reasons unknown I can't create a single patch. It seems that my session, helpers and components svn folders are separate. I can't make a single patch of them.
follow-up: 11 comment:10 by , 12 years ago
Do you really need to pass targetState? You can achieve the same thing with using the already present cmpTargetIdentity to check if the target is a foundation. Maybe you need to create a cmpTargetFoundation to check this.
But code like if (!this.CanTrade(currentMarket, currentMarket))
seems strange.
comment:11 by , 12 years ago
Replying to leper:
Do you really need to pass targetState? You can achieve the same thing with using the already present cmpTargetIdentity to check if the target is a foundation. Maybe you need to create a cmpTargetFoundation to check this.
But code like
if (!this.CanTrade(currentMarket, currentMarket))
seems strange.
I tried cmpTargetIdentity and got a bunch of errors and warnings.
But I changed the patch.
by , 12 years ago
Attachment: | finalPatch1.patch added |
---|
by , 12 years ago
Attachment: | finalPatch2.patch added |
---|
follow-up: 14 comment:13 by , 12 years ago
Sorry, I meant using Foundation.js as you do now.
You have some changes from your batch training patch in finalPatch2.patch. I would also name the variable like the others. Like cmpTargetFoundation instead of targetState. Apart from that the patch is looking good, though I am not really able to review it :-) .
comment:14 by , 12 years ago
Replying to leper:
I would also name the variable like the others. Like cmpTargetFoundation instead of targetState. Apart from that the patch is looking good, though I am not really able to review it :-) .
Indeed the convention is to name component references like "cmpFoundation
", although I don't think it's been added to Coding_Conventions yet. (The reason we use e.g. targetState
in GUI scripts is because they don't access components directly, only a limited entity state created by GUIInterface
so it would be wrong to call them cmpFoo
.)
I'll move the SVN conversation to forum messages to avoid cluttering this ticket.
comment:15 by , 12 years ago
Yep, it should be cmpTargetFoundation
to be consistent with the other variables in that function.
Couple of things in input.js
:
- Needs spaces around the "
&&
" - Rather than indenting the
switch
and adding a longif
/else
, better to doif (tradingDetails === null) return {"possible": false}; switch (...) { ... }
to minimise the distance between the error condition and associated return.
by , 12 years ago
Attachment: | input.js.patch added |
---|
Patch that fixes the problem of trading with incomplete markets.
by , 12 years ago
Attachment: | Trader.js.patch added |
---|
comment:18 by , 12 years ago
Keywords: | review removed |
---|
Thanks for the patch. I applied a slightly modified version stripped of the code from other patches.
At first glance it seems like a good solution for the UI side of things. Usually we add checks to both UI and simulation (so that modified UIs, AIs, etc., can't accidentally or intentionally trigger these bugs). Is there a corresponding check we can perform for the simulation? Relevant code would probably be
Trader.CanTrade
inTrader.js
.