CivEffects

[Kailric]

Hey, well, when you don't know much about coding you try to make things as easy as possible, thus I take on Danish Frugality when it comes to coding and make do with what I got and what I know

 

[Nightinggale]

I changed the format for help text once again. It's now this:

printTag(szHelpText, pCivInfo, L"ALLOWS_BONUS" , pCivEffectInfo->getAllowsBonuses() , &CvGlobals::getBonusInfo );

The clever bit here is that the blue bold parts of it should be identical on every line. This is followed by the TXT_KEY and then the variable. This is followed by two pointers to get functions, which match the types set in the first two variables in the InfoArray. If one or both get*Info functions aren't needed, they can be omitted. My plan is to make either the compiler or assert fail if there is a mismatch between the InfoArray and what is written. I considered avoiding the get function part, but it would move getting the correct get function into runtime rather than compiletime and I prefer to detect as many errors as possible at compiletime.

The concept says this should be able to handle all tags from CivEffect. There is no longer a need to figure out which of the functions to use as they have all been renamed and rewritten to match in arguments and only differ enough for the compiler to pick the right one.

I now start wondering about this "help display engine". It is heavily based on templates and needs to be static, as in one cpp file only. That would be a valid argument to move CivEffect help back into the general help file and then the "engine" on top, allowing all help functions to use this in the future.

Also as I go through everything, I skip more and more on strings and testing. Kailric said he would fill out the missing strings, but somebody will presumably have fun going through every single tag to test it once there is a release test build. We shouldn't release as such this time without making an "internal" test build as in everybody from the forum can download and test. It should not be uploaded to the usual stable release places.

Maybe we should make an unstable folder on SF to place release candidates. That will allow us to tell people it's unstable while everybody can still download and we have download statistics, giving us an impression of how many actually test the game. There should be a short message telling people to report any problem either on SF or in a dedicated forum thread. It should also mention that it is a "public pre-release test build".

 

[Kailric]

We'll have time to check much of it ourselves before release as I want to do some extensive play testing to balance the game a lot more. I need to go back and read the post the testers made on this version as well.

 

[Nightinggale]

I finished typing all the code to generate help text for all general CivEffect tags (that's most of them). There could be some missing, which are specific to some type. I think the gift section (1000 gold to first to discover and so on) is missing, but that's about it.

The arguments to GetText are as follows:

1d|int value from changes/modifier/int
2s|name of first class
3F|getChar image of first class
4s|name of second class
5F|getChar image of second class

If any of the fields aren't used, they tend to become blank, except for the int, which becomes 1. One special condition is that if only the number is set, then 5F becomes the char for YIELD_CROSSES. There is no logical explanation for that. It's just that we reuse a vanilla string, which requires that char in an argument.

Using buildingClass as first class in an infoArray and using the pointer for BuildingInfo will automatically trigger code to convert the InfoArray content to BuildingInfo before displaying it. The same with units as well as if UnitClassTypes is used as a standalone argument. No need for manual conversion code or extra function names anymore. There is a TXT_KEY for positive and negative. Which one to use is set by changes/modifier/int and if there isn't one, the positive is always used, making it silly to add the negative one (though I think I might have done that with some quick copy paste )

The classes as in types and numbers are in the top of Info/CivEffectInfo.cpp
The help text is in CvGameTextMgr_CivEffect.cpp
The text is in xml/Text/DLL-CivEffect_Help.xml

The help text in the xml is put in the same order as in cpp, with positive before negative. This makes it much easier to check if all are present.

I didn't bother to actually add the strings for the last 2-3 groups as my brain stalled on the constant copy-paste actions and string searching. Instead I did run a test to see if the TXT_KEY strings shows up ingame (they do) and that it didn't assert while doing so. With the high amount of asserts I added to the code, the no asserts result strongly hints no coding issues. Sure it can't tell if the display is how humans would want it, but it checks for type mismatches and stuff and the test can be done in seconds.

I think I have done my part to CivEffects. Now it's Kailric's turn to take over and write some strings. I kept the old code as inactive where it is possible to search for the old strings. Preferably they are renamed to match the new code and the old strings are removed from xml whereever they are. Keeping unused strings is less than ideal. I plan on script sorting and searching TXT_KEYs, but that will be a future project.

Remember to get good text for this. Not only is it the player's intro to how the game works, it is also the xml modder's guide to what each tag does, at least until we get a proper guide.

 

[Nightinggale]

I thought I was done and only needed to bugfix this, but now I noticed I missed traits and eras. Even worse, it turns out that Founding Fathers provides traits and looking at that, it makes the most sense to convert FFs to CivEffects as well. This mean 3 more xml files should be converted. At least the CivEffect engine is running and it is just a matter of attaching the files and then a lot of xml work.

 

[Kailric]

I get his error when trying to build the develop branch...

1>NMAKE : fatal error U1073: don't know how to make '.\..\DLL_Sources\.\autogenerated\git_version.h'

 

[Nightinggale]

It should be autogenerated provided you have perl and git installed.

Running perl scripts

It should be generated when the makefile writes this line.

 

[Kailric]

It should be autogenerated provided you have perl and git installed.

Running perl scripts

It should be generated when the makefile writes this line.

Ok, looking back at this now.. I have perl installed and I installed smartgit, was there some kind of basic git that was needed to be installed?

 

[Nightinggale]

Ok, looking back at this now.. I have perl installed and I installed smartgit, was there some kind of basic git that was needed to be installed?

Try opening a cmd and type "git --version". If git is installed as intended, then it should print some version string. Alternatively type "gi" and try to tab complete git.exe. The same goes for perl. You should be able to tab complete perl.exe.

Third option is to make the file manually. Create the file autogenerated\git_version.h in the source and add the line

static const char* szGitVersionString = "Kailric's manual string";

Clearly it's not intended to be made manually, but that doesn't really matter right now. It's more important to make you able to compile right away.

The sideeffect of not having this automation working is that the string is added to savegames to make the "correct" dll easier to identify when debugging savegames. It's likely not really an issue anytime soon.

1>NMAKE : fatal error U1073: don't know how to make '.\..\DLL_Sources\.\autogenerated\git_version.h'

Given that this is still an issue, I will try to experiment a bit with this to see if I can force it to appear for me. Maybe I have an uncommitted file or something, which makes the difference, though I don't think so. Maybe it can't be created unless a file already exist with that name or something.

Whatever it is, we need to figure out precisely what goes wrong and fix it. It's an unstable development environment if it doesn't compile out of the box.

 

[Kailric]

Ok, yeah I see at the start it says...

Running perl scripts
1> 'git' is not recognized as an internal or external command,
1> operable program or batch file.

So, as I asked do I need the basic git installed and not just smartgit? I know before that I had installed more than one version of git, like tortuous git or something.

 

[Nightinggale]

The idea is that smartGIT is enough. It is a GUI frontend to a command line git and the makefile calls the command line edition directly. Inside smartGIT there is an option to set the path to git. Your system path should also point to this location. If not, then you will get this error.

For now just add the header. I will look into the setup I use and see how the system path is set. Maybe it can be fixed by changing the makefile or project files. Worst case you need to install multiple git versions or mess with system path settings, but I don't think it is that bad.

 

[Nightinggale]

I pushed a change to the makefile. Now it will assume git to be placed at the default smartGIT install location. If that fails, it can be set in Makefile.settings. Open smartgit, goto edit->preferences->commands->executables and copy the path for git. Then open Makefile.settings and add the line

GIT=PATH

PATH is whatever you copied from smartGIT.

I also added the script to set up the exe path. Close the project, run the script (in project files) and then open the project again. The debug menu is now able to start the game with and without debugger attached. Also starting it from the project will make it check if it should be compiled first.

 

[Kailric]

I'm back!!

Finished up the floors in my house and done my school this week and spring break is coming up so hoping to do some work on M:C.

However, I am still having build issues. I did as you posted above and didn't seem to have git issues, but now I am having this...

FDialogTemplate.cpp
1> MD5.cpp
1>NMAKE : fatal error U1073: don't know how to make '.\..\DLL_Sources\.\autogenerated\git_version.h'
1> Stop.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(43,5): error MSB3073: The command "set TARGET=Debug
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(43,5): error MSB3073: nmake clean /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(43,5): error MSB3073: nmake source_list /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(43,5): error MSB3073: nmake fastdep /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(43,5): error MSB3073: nmake dll /NOLOGO" exited with code 2.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

 

[Nightinggale]

I'm back!!

I'm seeing ghosts

However, I am still having build issues. I did as you posted above and didn't seem to have git issues, but now I am having this...

If git fails to run (according to the output just before the rror you posted), then you need to add this to Makefile.settings

GIT=C\:Program Files (x86)\[COLOR="Red"]SmartGit[/COLOR]\git\bin\git.exe

The path naturally has to match whatever path SmartGit decided to use on your computer. Looks like I have two versions of git installed, one with the red part and one without it. I picked the one without it for the makefile default, which seems to be wrong. I may correct that soon, particularly if this line fixes your problem. It caused problems for the compile server as well.

Speaking of this feature and the compile server, I will have to edit it somewhat because it doesn't work correctly when executed with the build script. It seems to be windows itself, which fails to pipe git output into the script input. It should work, but doesn't and rather than investigating why windows is acting up, I will most likely just make a temp file to store the string in and avoid piping data entirely.

Windows is btw not my friend. I have severe problems with it and that is the main reason why I'm not really active in the git log. I'm might have to make a full reinstall

 

[Kailric]

Yes, that is exactly what I have in the makefile that is located in Project Files folder. I was having other issues until I added that line, but this is the only issue at the moment. Don't know what to do now, sorry.

 

[Nightinggale]

I will rewrite that code tomorrow to allow the compiler to work even if it fails to find git.

 

[Nightinggale]

Now I should have fixed the issue. The makefile will now compile the DLL without requiring either git or perl. It will make the git version string into either "GIT ERROR" or "PERL ERROR", but other than that it should work just fine. It prints some warnings in case it fails and ideally the problem should be fixed. After all the idea in the version string is to assist when debugging a savegame.

I changed the project file calls to the makefile. If one step fails, it will no longer move on trying to compile something we know will fail. This makes the error output more readable as well as a faster quit if something went wrong.

I also fixed the issue where the compile server didn't read the version string from git. It should do so now, which should help with debugging. Nobody will know which revision the DLL is from unless it is stored in it as the compile server doesn't log this info.

I'm having serious problems with windows btw and ended up coding this fix on the compile server. It's really slow and I only did it because the problem holds back Kailric. I need to fix windows itself (or reinstall) before I can mod the DLL

 

[Lib.Spi't]

Time to smash some windows!!

 

[Kailric]

Ok, I'll check it out now.

You upgrade to windows 10 yet? That fixed the issues I was having

 

[Nightinggale]

I have been too busy programming to keep this thread up to date. I think I finished this feature. It still lacks some help text and it messed with the XML files. This means there is a massive XML task waiting and I decided to work on an editor to make it easier to handle. Also if I finally make that editor, we will have it for future tasks and it will hopefully speed up development.