Next Release

[PatriotNorwood]

Wow! Brilliant you have your own language.
Really though, in all truth what you guys are doing is really neat. I have a question concerning scourceforge, can you upload changes to your mod directly their?

 

[Kailric]

Wow! Brilliant you have your own language.
Really though, in all truth what you guys are doing is really neat. I have a question concerning scourceforge, can you upload changes to your mod directly their?

Yep, you mention doing a Star Wars mod and we'd be happy to allow you to use our dll and other game files. Nightinggale can better explain how he can open another module on sourceforge so you can upload stuff too. Using Git is the way to go as you can track your changes. If you mess something up so bad you have no idea how to fix it you can revert back to a previous version, that is always handy

 

[Trade Winds]

I know we are taking steps to preserve saved games, but I am not all that great at it, plus it seems that sometimes breaking saved games can't be helped, and for one we don't have access to the exe file.

I don’t know If I understand it well the concept of breaking savegames.
As part of your quality work, you are trying to create a savegame data pool that can be read when new fixes or additions have been patched to M:C.

But from my experience, when a new version has been released or bugs have been fixed, I prefer to start a new game to avoid any previous malfunctions or to take advantage of new features. Not breaking savegames makes more sense for gigantic colonization maps or for long marathon modded BTS games with expanded tech trees.

So taking that into account, I don’t know if from the magician point of view, it is really worth devoting coding time to make it savegame friendly.

 

[Nightinggale]

I don’t know If I understand it well the concept of breaking savegames.

Depending on the situation, it is beneficial not to break savegames. Until we (I) wrote some savegame recovery code, savegames would die easily. Now it can figure out what to do even if you add a new unit or something like that, which seems quite good for XML modders.

You are right that savegames containing buggy data should be restarted. However a number of parameters are now recalculated on load instead of being saved meaning in some cases, buggy data will not be saved and simply saving and reloading fixes the problem.

In the case of games being affected by the bug 2.5.3 fixes, I would encourage starting a new game though.

That bug also shows that we have no quality check procedure where we read through code written by another person and verifies that nothing was overlooked. That is likely more a sign of lack of people than lack of quality intensions.

 

[raystuttgart]

That bug also shows that we have no quality check procedure where we read through code written by another person and verifies that nothing was overlooked. That is likely more a sign of lack of people than lack of quality intensions.

That is one of the most important lessons we learned in TAC:
(When we started RaR that lesson was already well taught.)

A big mod with several modders does need structured and well working quality control.
(Especially if you have several DLL modders.)

There were team members that did nothing else than alpha and beta testing.
Code one programmer wrote was always checked by another programmer.
...

File Checking (e.g. commit logs), early Alpha Testing (intensive functional tests directly after implementation), good Beta Testing (Autoplay with Debug DLL, logs, generally playing), ...

Now in RaR we also don't have specialized team members for quality control anymore but it still needs to be done.
That is why I spend about 50% of my time checking absolutely everything that I create myself or other team members and partners commit to SVN.

There is not one little bit of code, graphics or even text added to the mod, that I don't try to have at least a quick look on.
(Just checking DLL code is not sufficient enough.)

People make mistakes, no matter how good they are.

Good quality control and testing really pays out !
Trying to search for bugs weeks (or even months) later is much more time consuming than early quality control.
And most likely lots of small bugs will simply slip throught without ever getting reported.

Of course even if you have good quality control, there will still be some bugs that slip through.
(Nobody is perfect but it will be much less bugs and thus much less work later on for searching and fixing bugs reported.)

I can only give you the advice to establish good quality control methods.
It will dramatically improve quality of your mod and save you a lot of time on the long run.

 

[Nightinggale]

Good quality control and testing really pays out !

I fully agree and I planned to proofread whatever Kailric commits. However the stuff I checked looked ok and I ended up skipping the majority of it due to time constraints.

Maybe we should seriously rethink our quality control. Adding comments on what we intend the code to do will also make it easier for other people to spot if the code actually does something else. It is kind of tricky to read the code from other people if there is no comments. I know that my level of comments has gone down since I started modding because I somehow adapted to the level of comments already in the code

 

[Kailric]

I know we all want to be as professional as possible, but this is just a hobby. And we all have time restraints. Even writing long posts on the forums takes up a good bit of time that could be spent coding or play testing. Of late there have been days when all I was able to accomplish was several posts on the forums. And attempting to fully comment our code takes away even more time. Anyway, I don't let it bother me too much when bugs some how make it through our limited quality control. I just fix them and carry on

 

[raystuttgart]

Well, it is your mod and your decisions how to handle things.

If you think that commenting code and early quality control is a waste of time then I won't be arguing with you.
(To my experience it makes life as a modder much easier and less time consuming though.)

 

[Kailric]

Well, it is your mod and your decisions how to handle things.

If you think that commenting code and early quality control is a waste of time then I won't be arguing with you.
(To my experience it makes life as a modder much easier and less time consuming though.)

I never said it was a "waste of time", how can we waste time that we do not have? For the 2.5 release I was the only tester for the most part. I was able to play through one game which took me all week with the limited time I have. I corrected what I could correct with issues still being out there, but Night and I both agreed to go ahead and post the release so others could help out.

We don't have a legion of helpers as you did for the R&R project, so we do what we must. Either I spend months play testing, which with my play style may never uncover certain bugs, or we release for others to help.

Also, Autoplay is great, but it does not find everything and depending on the types of bugs it may not find anything.

 

[raystuttgart]

There is no need to argue.

I simply wanted to tell that certain methods of structured working (e.g. good commenting and early quality control) will make your life as a modder much easier.

Of course some of the tasks involved are not very fun and take time.
But you will save a lot of time on the long run and drastically increase quality of your mod.

My time for modding is also very very limited.
But I still invest time in thorough quality control, because I am convinced that it is absolutely necessary if your mod has reached a certain size and shall still keep good quality.
(That is why we have several weeks before every release where no new features are developed and only improvments are allowed.
This week and the next 2 weeks we will be doing nothing else than improving quality of the mod for the upcoming Release 2.1.)

Some things I have found very useful:

Spoiler :

1) Once a feature is fully implemented, taking a bit of time to do some code optimization. (incl. some commenting)

2) Taking a close look at the change log of every commit or using a good diff tool if files are too large.
(That is one aspect why SVN or GIT are so useful.)

3) Taking some time before a release to do a short quality check / walkthrough of code and XML.

4) Checking error logs of the game (especially the ones for graphics) before a release and trying to get rid of potentially dangerous warnings and errors there.

5) Running at least one long Autoplay session (ideally with Debug DLL) before a release.

----------

Once you have established some routine with things like that, you will see that the time you have invested really pays back.

If you create a huge mod with massive amount of changes and don't establish good quality control methods, there is a good chance that at some point you will go crazy for searching bugs and running after problems.

I can only repeat:
This is not about spending time. This is about saving time.

Also, I don't think that speed of development is more important than quality of the mod.

----------

But as I said, this is your mod.
I am just sharing my experiences as a modder.

I won't be annoying you anymore with that topic.

 

[Nightinggale]

I know we all want to be as professional as possible, but this is just a hobby.

I strongly disagree with that statement. If we don't do anything about the lack of quality control, we will end up killing the gameplay due to the number of bugs. Also Ray is right that quality control is faster than bugfixing.

I'm actually not asking much of other people for this. All I said was that adding comments about what the code is supposed to do will help other people figuring out what you intend to do and maybe catch if the code does something different. I'm not asking for a novel in comments either.

5) Running at least one long Autoplay session (ideally with Debug DLL) before a release.

It would appear that Ray has been too busy to study the new makefile and still assumes the makefile to have debug and release targets only. We have 4 targets and the assert DLL is likely the best one for this specific task. It's optimized meaning it can do a plenty of rounds while it still check all asserts and will inform us if something failed.


M:C 2.5.3 is only released because of lack of quality control regarding savegames. That got me thinking. What if the savegame code is changed in a way where this will no longer happen? Or better yet: how do we avoid bugs in savegames?

I came up with this: (using CvCity as example)
First CvCity::readWrite(FDataStreamBase* pStream, bool bRead) is made. Then CvCity::read() and CvCity::write() calls it with bRead set to true and false respectively and they do nothing else.

Code inside readWrite() will then look like

pStream->Read(bRead, &m_iID);

This will then read or write as needed. One list of variables for both reading and writing and we will can't go out of sync.

Next I will write a perl script to look up each readWrite() function. It will then look up the header file for that function and go through it. It will expect every m_* to be present in readWrite() and in the same order. To allow unsaved data, we add

NOSAVE(m_iCache);

This way we will get a complain whenever we add data to a class without considering if it should be part of the savegame.

It would be ideal if the check could be made to a pre-commit hook. That way it will not be possible to commit even locally if there is a class-readWrite variable desync.

There are plenty of details I haven't figured out yet, but this is the main idea that I came up with to avoid a similar incident in the future.

 

[raystuttgart]

If we don't do anything about the lack of quality control, we will end up killing the gameplay due to the number of bugs.

That is exactly what I am saying.

Most large modding projects I have seen failing did not fail because they lacked good modders.
They simply failed because they were unorganized and nobody was willing to do quality control.

Those projects were only adding, adding and adding.

In the end, they had massive amount of great ideas and generally good features but the mods as a whole were unplayable because they were unbalanced,
were full of bugs and performance issues, had lots of missing texts, ...

Also Ray is right that quality control is faster than bugfixing.

Exactly.
Finally somebody understands what I am talking about.

1 hour you spend into (preventive / early) quality control will most likely save you 3 hours of analyzing and fixing bugs later on.
And you will most likely discover many small glitches and small quality issues that would never be reported by a user but still worsen quality.

It will save time and increase quality of a mod.

It would appear that Ray has been too busy to study the new makefile and still assumes the makefile to have debug and release targets only.

I of course know that your makefile exists, but I am too lazy to start changing the methods I have learned over years of modding.
My "Old School"-methods simply work for me.

 

[Kailric]

I understand what you two are saying, but I am the quality control and there is only so much I can do. There was very little help if any for testing all the new features that were added in 2.5, and I was quite surprised that there wasn't more bugs reported. We basically released so that others could help in bug testing. So, until we have more than me doing quality control I see no better way to do this.

I can start adding more comments yeah, but still it's just you and I, Night, so it's simple to say "hey your codes not working would you mind fixing it."

Plus I can't rightly quality control any thing that Night does anyway, because it's generally over my head.

Anyway, the point is either we get more help in the quality control sector or we'll just have to keeping posting a release so others can help.

If you want to add code to check for missing saved game variables then by all means do so. Unless it's simple easy, a better solution would be for me to make sure to check my check list when adding a new variable. If we ever have several programmers busting out code on this then yeah, that may be a good time investment.

Edit: What we can do is just post a release version for testers, if we have any at the time, and let them help test things out. The two or three testers we have are uncomfortable with Git so it's a solution.

My current main goal is a new Victory condition, but I have been side tracked with the new trade screen class.

 

[Nightinggale]

I can start adding more comments yeah, but still it's just you and I, Night, so it's simple to say "hey your codes not working would you mind fixing it."

If you add comments and good commit messages, then I can figure out what you are trying to do, which will allow me to proofread your commits without spending too much time.

Plus I can't rightly quality control any thing that Night does anyway, because it's generally over my head.

Whenever I'm ready to commit, I check the diff line by line. I actually catch some potential issues this way, though the most common mistake I correct is adding blank lines for no reason. This mean my commits are not without quality checks even if nobody else looks through them.

If you want to add code to check for missing saved game variables then by all means do so. Unless it's simple easy, a better solution would be for me to make sure to check my check list when adding a new variable. If we ever have several programmers busting out code on this then yeah, that may be a good time investment.

As I said, it will just grap all words starting with m_ in the class and make sure they appear in the same order in readWrite(). That shouldn't take too long to code. Writing readWrite() will likely take longer, but we could save that time later as it will remove the task of keeping read() and write() in sync.

Edit: What we can do is just post a release version for testers, if we have any at the time, and let them help test things out. The two or three testers we have are uncomfortable with Git so it's a solution.

If people don't want to/don't know how to use git, then they can use the browser interface. To get the newest version in release-2.5 branch, goto https://sourceforge.net/p/colonizationmodcollection/Medieval_Conquest/ci/release-2.5/tree/
Click "Download snapshot" and you will get a zip with those files. Don't do it now as it will be the same as 2.5.3, but it can be used as a pre-release test download.

My current main goal is a new Victory condition, but I have been side tracked with the new trade screen class.

If you wanted to write a victory condition, then why did you ask me to write a trade screen class

Finally somebody understands what I am talking about.

I understood that even before Civ4 came out. The issue isn't what I'm unaware of the importance of high quality. The issue is that I haven't invested the time to figure out what Kailric is writing. That can be a rather time consuming task to figure out if he is writing something else than he intend to write if you have no idea what the intension is.

 

[Kailric]

If you add comments and good commit messages, then I can figure out what you are trying to do, which will allow me to proofread your commits without spending too much time.

I will work at writing better commit and comments

If people don't want to/don't know how to use git, then they can use the browser interface. To get the newest version in release-2.5 branch, goto https://sourceforge.net/p/colonizationmodcollection/Medieval_Conquest/ci/release-2.5/tree/
Click "Download snapshot" and you will get a zip with those files. Don't do it now as it will be the same as 2.5.3, but it can be used as a pre-release test download.

I'll just post a link to this snap shot for the testers then.

If you wanted to write a victory condition, then why did you ask me to write a trade screen class

I asked you to write it so I could focus on the Victory Condition. I didn't know it would only take you an hour and then that got me all excited about the new Trade Screen code so I had to check that out.