Crash #6581 moving object in production window
Moderator: Oberlus
Re: Crash #6581 moving object in production window
See, I'd love that, but it's a Git diff file so Geoff can't commit it, chance of doing it in SVN? (the code itself is way beyond me, but thanks for the work).
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: Crash #6581 moving object in production window
PhilSophus, for an example popup menu in a similar context, take a look at ProdQueueListBox::ItemRightClicked in ProductionWnd.cpp
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
-
- Krill Swarm
- Posts: 11
- Joined: Thu May 16, 2013 9:52 am
- Location: Germany
Re: Crash #6581 moving object in production window
I essentially copied it from BuildItemDoubleClicked. Only the passing of a queue_pos to outgoing signals was added. So, if there is anything missing, it was already missing before.Geoff the Medio wrote:Some range-checking on the iterator parameter to BuildItemRightClicked would probably be best before attempting to use what it points to.
Yes, maybe, but I didn't want to dig deeper.Geoff the Medio wrote:Rather than right click immediately enqueuing, I'd have it create a pop up menu with commands to enqueue at top or bottom.
It looks overly complex. Decoupling parts is a good thing unless you overdo it in such a way, that even changing something trivial becomes a nightmare. I mean, adding a modifier key to a mouse click would have required to change a long chain of signals, some of which are used almost everywhere.Geoff the Medio wrote:Elaborate?PhilSophus wrote:Phew, what a codebase.
BTW: I noticed savegames became incompatible due to my change. Is there a savegame version identifier somewhere, that needs to bumped?
Re: Crash #6581 moving object in production window
I think that previously saved games became incompatible because you changed constructors in one of the back-end classes (ProductionQueueOrder), which the boost (de)serialization code notices and doesn't like; changing any of their attributes would do it also. Merely changing regular class methods, and any changes to the UI, should not render saved games incompatible. Still, even though it might have been possible to cobble together a pair of the existing ProductionQueueOrders to accomplish the same effect without rendering old saved games incompatible, I think your approach is probably better.PhilSophus wrote:BTW: I noticed savegames became incompatible due to my change. Is there a savegame version identifier somewhere, that needs to bumped?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Crash #6581 moving object in production window
Quite plausible... It'd still be better with safety checks.PhilSophus wrote:So, if there is anything missing, it was already missing before.
Are you arguing for or against (more) decoupling?Decoupling parts is a good thing unless you overdo it in such a way, that even changing something trivial becomes a nightmare. I mean, adding a modifier key to a mouse click would have required to change a long chain of signals, some of which are used almost everywhere.
Regardless, I'm clear on what you (might) suggest as an alternative to how things are structured now... I suppose signals could be initially written with lots of unused parameters to make them more future proof, but that would make things more complex, with not much benefit.
(I also question your definition of "almost everywhere"...)
No; some changes break saves. Updating a version number won't change that.BTW: I noticed savegames became incompatible due to my change. Is there a savegame version identifier somewhere, that needs to bumped?
You can possibly rescue the save by loading it in the old version, ending the turn, and then before doing anything (in particular issuing any orders, ie. not modifying any queues), re-saving, and then trying to load that in the new version.