What needs fixing before we release V34

Release versions often have extremely annoying bugs that are easily fixed in the SVN within the next week. Is it possible to release a 'patched' download version when this happens? If it isn't too difficult, I agree in principle with the point that it should not be necessary to wait for version vnn+1 to fix these kind of bugs in vnn (and likely introduce its own...)
 
Release versions often have extremely annoying bugs that are easily fixed in the SVN within the next week.

This is because they are not found when the testing is done on the "frozen" SVN version before the release.

Testing is hard - I test as thoroughly as I can but only with those game options I am interested in or understand. In theory each game option doubles the amount of testing you need to do.

Is it possible to release a 'patched' download version when this happens? If it isn't too difficult, I agree in principle with the point that it should not be necessary to wait for version vnn+1 to fix these kind of bugs in vnn (and likely introduce its own...)

In theory yes, but as I mentioned above by the time we have fixed any problems with the previous version there will also have been added a large amount of new stuff, all untested.
 
Currently we get dead end techs (religions and punk cultures) appearing in the game even when the module for the religion or punk culture is turned off. This less than optimum since the AI will research those techs where as the player will know not to disadvantaging the AI even more.

I think this and making the optional modules properly optional is important and should be done either for this or the next release.

The only option with the religions is to have the tech defined in the same module as the religion so that when the one is turned off both are off. The alternative of using the WoC AndDependancy tag either causes an infinite loop in the loading of the XML or just crashes the XML - i can't remember which at the moment. I did a lot of work trying to get a WoC solution since having all the techs in one place is preferred. I think it has something to do with the fact that different icons are displayed for the tech depending on if the religion has been founded or not.

I have not tested this for the Punk Cultures.

Making them properly optional means that turning them off does not cause errors. Which means that leaders will need to be changed to consider which should be their preferred religions in a way that matches these options eg if a leader has Shinto as their preferred religion, what religion should they have if Shinto is not in the game.
 
This is because they are not found when the testing is done on the "frozen" SVN version before the release.

Testing is hard - I test as thoroughly as I can but only with those game options I am interested in or understand. In theory each game option doubles the amount of testing you need to do.
&
In theory yes, but as I mentioned above by the time we have fixed any problems with the previous version there will also have been added a large amount of new stuff, all untested.

It's quite understandable that the discovery of new bugs ensues from the release, as dozens (or more, but surely not thousands:crazyeye:) more players start to play the new game. Testing by you guys is entirely adequate and I'd never say otherwise;).

How about if the 'freeze' continued say 24 hours after the official 'release', and was extended if any such quick-fix bugs were found (until they were fixed naturally)? That could work...:)
 
Doh! I figured out why the routes were going to the animals; I was telling them to!

However when I use the correct bit of code for routes I get a C++ exception elsewhere. I suspect that WIDGET_PEDIA_JUMP_TO_ROUTE is not defined.

@Thunderbrd Can you have a look? Attached is the code that is failing. It goes in the Assets/Python/Contrib/Sevopedia folder replacing the one that is there.
 
If it is not defined, the error would be WidgetTypes does not have it.
C++ exception is usually when the data provided exceeds the range of input expected, such as trying to jump to building ID 9999 when there are only 1000 buildings.
More likely iData1 and iData2 are mixed up
 
When I pass it WIDGET_PEDIA_JUMP_TO_UNIT it displays the list of routes but goes to the unit implying that the list of routes is correct. When I pass WIDGET_PEDIA_JUMP_TO_ROUTE it does not list the routes and gets the error.
 
Yup, as I mentioned, the Widget itself is already defined, just that the input data is not what is expected.

Using WIDGET_PEDIA_JUMP_TO_UNIT for Routes will still display the list correctly, because total number of routes is less than number of units. If you hover over the items, it will show hover text for units instead.

Using WIDGET_PEDIA_JUMP_TO_CIV for Units however, will give you the same C++ exception error, because number of units > number of civs. When it is trying to get the hover text for the units, it is screwed because the input data exceeds what it is expecting.

Thus, the widget itself is defined, just defined wrongly :D
 
Ok... that shouldn't be too tough to fix. Particularly since I have some clue as to what might be wrong. I'm on shaky ground with widgets but I think I can probably repair that one pretty easily. I'm glad you're finally getting around to working on it now - it's very good timing for me to address my errors there.

I take it that file is a replacement I can use to test the adjustments made to correct things in the dll?
 
I take it that file is a replacement I can use to test the adjustments made to correct things in the dll?

Actually there are two, I forgot the other. I dumped the Total War one and was trying to use Platypings. So that file plus the attached folder. It goes in Assets/Python/Contrib for now.
 
Ok, I think I've fixed my end but I believe there's an issue with the Platy version. Can't verify for sure.

I think the problem was that the widget py enums had fallen out of order to the c++ side enums but really only in such a way that it affected this one widget (would've affected more but they seemed to be re-organized to have incidentally fallen back into synch with each other for the majority of them... I've now realligned those lists to each other and that should thus be finding the correct references for you.)

However, despite all running correctly in the dll (it seems to be anyhow) I'm not getting any listings up in the Routes section and I found it a little odd that the first route it attempts to call through the widget is the 6th route (7th really - route 6 is the 7th in the enumeration.) so it's not clearly running through each of them unless it's reordering before it calls them. I suppose it would be ordered by alphabetic rather than index order eh?

Anyhow, it's calling them correctly through the dll but it isn't displaying them so now I believe it's an issue on the python side - perhaps something to do with BUG incompatibility with Platy's work?

I'm committing the files you gave me as well as an updated dll which also fixes my Size Matters hang bug. (Soon as I can anyhow.)
 
Ok, I think I've fixed my end but I believe there's an issue with the Platy version. Can't verify for sure.

I think the problem was that the widget py enums had fallen out of order to the c++ side enums but really only in such a way that it affected this one widget (would've affected more but they seemed to be re-organized to have incidentally fallen back into synch with each other for the majority of them... I've now realligned those lists to each other and that should thus be finding the correct references for you.)

However, despite all running correctly in the dll (it seems to be anyhow) I'm not getting any listings up in the Routes section and I found it a little odd that the first route it attempts to call through the widget is the 6th route (7th really - route 6 is the 7th in the enumeration.) so it's not clearly running through each of them unless it's reordering before it calls them. I suppose it would be ordered by alphabetic rather than index order eh?

Anyhow, it's calling them correctly through the dll but it isn't displaying them so now I believe it's an issue on the python side - perhaps something to do with BUG incompatibility with Platy's work?

I'm committing the files you gave me as well as an updated dll which also fixes my Size Matters hang bug. (Soon as I can anyhow.)

OK. Yes they are sorted alphabetically. I have not had a chance to test the actual page because it was falling over before we got there. I may revert to the Total War one who knows, especially since Platyping has just put out a new version of that page:mischief:
 
Nothing wrong with the old version, but good luck converting it to work with Sevopedia :D
 
Everything is the wrong size. So I went back to the one from Total War which was written for SevoPedia but the widgets are in the wrong order for that or something. I'll get rid of the Platyping version and put the old one back in and when you have time Thunderbrd can you have a look at it again. :sigh:
 
Ok... what's happening? It's still not showing up with any route listings? I'll have to update to look into it and I'm attempting to fix our tech bug (very complex) so it might be a bit.
 
Of course all the layout are different :D
You can't expect mine to work with Sevo without ammendments...

Just use WIDGET_PYTHON and you don't need to waste time with the dll :D
 
Oh by the way, did you guys get that advisor screen-merge fixed that i sent the picture about ?
 
I understand that, but what I meant was the bugs from both should be fixed first. It doesn't really help if the bugs from v33 get fixed but the bugs from v34beta (at least most) aren't fixed in v34final as well. ;) To tell the truth, if that had been done before any of the "final" versions were released, it wouldn't be a problem at all. It just seems arbitrary to release a "version" that is just another SVN release with the version number slapped on it.

I know everyone is chomping at the bit to move forward, but sometimes you simply can't do that. After all, most players don't want to be beta testers. It is boring for the modders to sit on their hands while other bugs are fixed, but someone has to make the decision of whether this mod is meant for the players or the modders/testers.

The SVN is a great tool for either fixing bugs or adding content. Doing both at the same time, not so much...It should be used for the former before a new version, the latter after a new version, and both after that. Then the cycle starts over.

TLDR version: fixing the previous version in the new version is not the correct way to do it. The correct way is to fix everything new, release, add new, fix new, release, etc etc etc.

TLDR version: fixing the previous version in the new version is not the correct way to do it. The correct way is to fix everything new, release, add new, fix new, release, etc etc etc.

I totally agree. Pushing constant flow of new stuff and choosing quantity over quality is a guaranteed way of making a big bug mess.

Excuse that mod makers could leave if they should consider making their work more bug free sounds totally ludicrous and really raises a question of their motives of doing the entire mod. Who are they doing what they are doing and why ? It really sounds like a insane excuse, after all this mod is a bug mess exactly for that reason !:adding too much and fixing too little. Point of making anything is to create a working product and only after that improve it gradually, not to roll in a constant bug mess.

Quite a priceless response that get real there when suggested that you should make your current mod as complete and bug free as possible without constant flood of change and new. Want to get something finished and working before making new content ? Get real ! No, we have to push and pump more and more and more into it or the makers might leave us ! Seriously WTH guys - rhetoric question. There is a serious priority misplacement here.

Your quan over qual -tactic produces in 4,5 years a immersive civ mod of very rich detail where you can't for example upgrade air units. Not too fkn bright folks, no one wants to play with broken toys, no matter how shiny they are. I really don't want to rub that likely now fixed air thingy to your faces but such a major issue should have awakened you to the fact that more, more and more is not always more and that amount of new stuff certainly doesn't rule over quality. Almost like just adding more has become a self feeding end to a means instead of means to an end to you and thats just plain wrong.


This really looks much more like a commercial gamehouse trying desperately to add more and more to sell more of their products and thus breaking them than a community working for free to improve the game they love. When a fear of losing the makers prevents making working products, there is something very wrong.

Maybe those makers are just fed up, not caring about the quality anymore, past the real point of their leaving and thats why you don't dare to raise issues. It seems so and if that is the case, this project have lived beyond it's means and time. A project Frankenstein where all the pieces want to walk in a different direction. Someone there seem to care far too much about this product and some could care very little if even that and it shows man, it shows. It shows from many words and deed.

This would certainly explain why your action formula on that huge air promotion bug was firstly a total silence for months to a guy who reported it before me, secondly a flood a empty excuses and only after that a slow, gradual actual work to find and fix the game breaking bug the size of an giant elephant. After all, it only took over 4 years of unselfish mod making to create this bug. Am I evil ? Maybe little but for a reason. :) Biting but honest sarcasm about real issues is the best way to show something one does not want to see but needs to see. Stab them with their own humor I say. Have at you !

Choose rush and quantity over quality and you will always end up with a bug mess. Of course you can again lash at me for all this for again being a terrible evil troll that dececrates your precious child.

Want to nail me on the troll cross again ? I brought my own cross for your convenience. My cross on this is the fact that I still care about this mod and want to see it as a finished, working product. One who gripes, cares. Silent ones are lukewarm, satiated and care not.
 
Bug fixing isn't as simple as clicking one's fingers and Hey Presto! Done.

You need decent amount of programming knowledge in python and c++ to know
1) Which area to look for the bug
2) How to fix the codes
3) Whether the fix will result in other bugs

Furthermore, you also need a thinking brain to consider whether the codes will work in all situations instead of just the general situation.
For instance, colonists will only work for the most general situation, cities built manually by humans, only.

Then you need to invest time into all this, which is provided free, and yet constantly pushed to solve this and that by players who have never contributed anything to it.

So, instead of complaining X is bugged, how about taking time to learn programming, then find the solution for it, and tell the modders, "X is bugged, this is the solution, see whether it helps"
 
Back
Top Bottom