exe replacement

[flowerpot]

Ugh, I just finished a hairy merge. Structure.java, Unit.java, Faction.java, Game.java, Gui.java, PlanetWindow.java, State.java, C.java, Comp.java, Util.java and WindowSize.java all conflicted and some had big and complex conflicts. Some of that was due to my unit_building branching of at 0.8.0 with 0.8.3 and your two mods coming on top of it. I'd rather not have such a merge again soon. And netbeans was not helping that much either. For some reason it started showing all sorts of errors painted in red so that it was difficult to find the actual merge markers, also shown in red, in the files. It is a mixed blessing maintaining branches with multiple developers, if those branches exist for a long time before merging the histories can become pretty convoluted. A lesson learned, perhaps. I reckon I should have merged those changes from master to my unit_building branch as soon as they were deployed.

Well, anyway, I merged my unit building code with master and pushed to github and thus basic unit building which takes into account input units is now deployed. And I updated README.md to include instructions on how to build units. I didn't know what the EFS "room finding" algorithm is so I made unit building so that if there is no room in the building city then the surrounding 6 hexes would be checked for a suitable space to deploy created units. If no room was found the building would be delayed by one year.

[flowerpot]

OK. I've just made a fresh start, deleting all my repos at Github and my Phoenix project (after saving the src folder). Then I forked your repo, cloned the fork, made a new branch (rsw1) off the master, checking out that branch at the same time, copied my saved src folder over the project's src folder, committed everything, and pushed branch rsw1 to my fork without merging. I hope I've understood you correctly, and you didn't want me to merge, or edit my changes into your files.

Actually I started using that myself, making a new branch of the master and first integrating my unit building modifications to that and if all goes well then just do a simple fast forward merge to master. Actually I have been thinking of going so far as to push that new branch to github to test eg. authorship data is preserved and only push the master after I'm sure everything is ok. That way I will never (knock wood) have to re-init the github repo again.

Unfortunately, I didn't try compiling until after pushing, and now I've found there's a small problem. You've renamed a file (in folder gui) from Resources.java to Resource.java. When I copied my source over yours, I re-added the old Resources.java without deleting the new Resource.java. The new file was inconsistent with the rest of my source, and the compiler objected. No big deal, but I thought I'd better mention it, as you may be surprised I uploaded a version that doesn't compile!

Well, you should, always before committing, not only compile but play a short test game, moving a few units, attacking, saving and loading. When testing unit building I used your fillGalaxy to fill hexes with units so that unit building would be short of room and noticed that for 16 planets with 20 units per hex the compressed save file size is 4MB which is close to the java switch -Xss32m eg. 32MB stack size on threads. So if you really filled the galaxy 32MB might not be enough. Even 64MB might not be enough. But then we can't increase the stack size much cause then we run into the out of memory problem. So just to note that if try to save/load with a full galaxy you might have a stack overflow.

And I moved my "cleanLine" method into Util, as it's used by all 3 of my readers.

Proper error logging code needs to be included in those but basically it is almost just a simple procedure call inclusion.

Incidentally, at the moment Game declares two variables: "turn" (which is the number of the current faction) and "current_faction" (which isn't used). Let's agree to continue calling it "turn" and delete "current_faction".

I commented out current faction.

If we ever need a local faction number variable in a context where "owner" isn't appropriate (because we're not referring to ownership of anything), perhaps we should call it "faction_num", "faction_index", or for short "f_idx" (by analogy with p_idx).

f_idx is good.

Strictly speaking, perhaps we should be declaring such faction variables as an enum type instead of int. But I doubt it's worth changing. We're not using enum types much, and I for one am in no hurry to do so.

What little experience I have with java enums, I don't quite like them. They are a bit overgrown for simple enumeration. Also, the f_idx is stored as an int everywhere in EFS datafiles so an int based enumeration seems natural.

Alternatively, we could get rid of the boolean parameter and have two public methods intended for general use: deleteUnitExcCargo and deleteUnitIncCargo.

We might choose the overloaded way, ie. have deleteUnit() which deletes cargo and deleteUnit(boolean preserve_cargo) which does not delete cargo if preserve_cargo = true.

My thinking is that I want there to be no doubt about which methods are approved for creation and disposal of units, so that we can be sure that all creation and disposal is being funnelled through just those methods. "Delete" is the word I've chosen as indicating an approved method for unit disposal, but I'm open to using a different word if you think another one is clearer, maybe "destroy". I just didn't want it to be anything that suggested it was restricted to loss in combat.

After the unit building merge I have some refactoring to do since I made my own deleteUnit and unit creation procedures.

Better, I'll create a single method "initialiseUnitGameData(unit)" that intialises move_type, type_data and camo for one unit. createUnitInHex can call that for new units, and you can initialise units at the start of the game with just one loop that calls it for each unit. If it later turns out we need to initialise any more unit data, we only have to add the new code in one place.

Sounds sensible.

I'd also like to add a common initialisation method to Unit, for doing any initialisation that can be shared between both constructors.

That sounds reasonable.

5. Harvest.java in dat can be deleted ?

??? That's my reader for the harvest DAT files: FARM.DAT, etc.

Ah, I thought you had moved reading to Resources as well.

6. EfsIni gets EFS.INI data as a java Properties object.

OK. (I don't know anything about java Properties yet.)

It's just a glorified hashtable with string keys and values. The beef is in autoreading an entire init file with a single read operation. Downside is I don't think it provides for detailed read error reporting.

On the subject of your GameResources class, I'm not clear what this is for, and whether I should be putting anything in it myself.

Well, my ultimate solution to all loading of datafiles would be to do that wrapped in a progress manager displayed during game loading. There would be a proper loading screen etc. and then wherever the datafiles are now initialized would just need a simple pointer copy. But thinking about loading screens seems like a waste of time at this point. Although I may just implement that as an interesting exercise.
GameResources and Resource in gui were added halfway through the project when I thought that all datafile loading would naturally go in to its own class. Earlier I have been rather lazy at refactoring, adding new functionality preferentially.

Thinking some more about the subject of resource consumption, I'm strongly leaning towards maintaining a permanent secondary structure for cargo pods. Having such a structure not only saves execution time, it also makes programming easier, because I can program in the way that's simplest and most natural, without worrying about execution efficiency. Of course that has to be weighed against the extra programming effort to handle the structure. But I think it's worth it.

(A late response, sorry.) I have been leaning towards this. Something like an ArrayList of Factions of ArrayList of planets of ArrayList of resource_types of LinkedList of resources with planetside pods added to the beginning of the list and space pods added to the rear.

I was also concerned that we might overlook places in the existing program that create, move or delete units, all of which require updating the structure. But the IDE makes it quite easy to find such places, and I believe there are very few, namely:
- setUnitCoords (two versions)
- dropDead*, removeDead and resolveGroundBattleFinalize

- landStack, launchStack, moveSpaceStack. setUnitCoords only sets in_space, p_idx, x and y of a unit or stack.

If you agree, I'll proceed to implement the secondary structure, and modify those methods accordingly.

Go ahead.

[tichtich]

I sympathize with your merging difficulties. I think you're right that it's not worth developing a long-standing unmerged branch, unless the chnages are so separable that there will be very few conflicts. Once I've implemented the changes you've agreed to, I'm going to try harder to avoid conflicting with you, and to keep my changes to "my own" files. I've wanted to refactor or tidy up a few things you've done already, but I'm nearly finished with that now.

I'm unsure about how to proceed now. Forking from your repo again doesn't update my fork, so I assume I should be fetching direct from your repo, and not from my fork. In other words, I should fetch from your repo but push to my fork.

If you want me to continue not doing any merges, then--as far as I can see--that means I must work just from the revision I fetched from you (after branching from it). In other words, I can't make any changes at all between pushing my revision and fetching your next merged revision. I'll adopt that policy if you like, but of course it will slow me down. Alternatively, I could do an informal merge, just by copying over and/or editing the files I've fetched. Then those changes would look to Git as if I'd made them since branching, and there would be no sign of a merge. But, unless we have a continuing problem with your NetBeans not accepting my merges, it seems to me it would be better to merge properly, under Git's control. I suggest we try that again.

Maybe your idea is not that you don't want me to merge, but that you don't want the merged revision to be my master. I don't fully understand the special role that the master branch plays. But I guess that when I merge my new branch with my master, the merged revision automatically becomes my master. Perhaps I could avoid that by making a new branch off the master, calling it "rsw2" and then merging that with my current branch "rsw1".

That's all I have time for at the moment.

P.S. I'm finding it helpful to use GitGui for its "Visualize all branch history" option. There doesn't seem to be anything similar in NetBeans.

[tichtich]

I couldn't resist fetching your latest revision, just to see what you've done. Congrats on unit building. It's nice to see a major feature added, particularly as you've added additional functionality beyond the limitations of EFS's UI.

A few details I noticed...

1. Spies and assassins don't seem to ever finish being built, but doppelgangers do!

2. Your building code doesn't use creatUnitInHex. Since you've given me permission to funnel all creation/deletion/moving of units through my methods, shall I modify your building code to call createUnitInHex? EDIT: I didn't notice you said you intend to refactor this. I'll leave that to you.

3. You've created a new secondary data structure, faction_cities. I just want to sound my usual note of warning about keeping such structures up-to-date, or making sure we don't use them after they might no longer be up-to-date. You can't assume that faction_cities will remain up-to-date throughout the start-of-turn phase (as I'm now calling it). Cities might disappear due to starvation, plague or rebellion (and perhaps other things I haven't though of). If faction_cities is purely for the use of buildUnits, then it would be safer and clearer to make it local to that method. You were probably expecting it to be of use to other start-of-turn methods. And I for one could use such a structure. But I think it's safer for me to generate my own local version as and when I need it. The cost in run-time effciency is probably not too great. If you're concerned enough about the efficiency that you think it's worth sacrificing some safety and clarity, then I would suggest getting rid of my updateEconomy method and moving the individual methods (like feedUnitsAndCities) to advanceTurn. Then at least we can more clearly see the sequence in which things happen during the start-of-turn phase. That might be a good idea anyway. The division between what goes in updateEconomy and what is called directly from advanceTurn is somewhat arbitrary. One might say that building units is part of updating the economy. It seems to me that the main reason for keeping buildUnit in Game, rather than putting it in Economy, is that it keeps my work separate from yours, and not so much that the function is logically separate.

EDIT: Of course another option is to maintain a permanent secondary structure for cities, divided by faction and possibly by planet.

[tichtich]

When testing unit building I used your fillGalaxy to fill hexes with units so that unit building would be short of room and noticed that for 16 planets with 20 units per hex the compressed save file size is 4MB which is close to the java switch -Xss32m eg. 32MB stack size on threads. So if you really filled the galaxy 32MB might not be enough. Even 64MB might not be enough. But then we can't increase the stack size much cause then we run into the out of memory problem. So just to note that if try to save/load with a full galaxy you might have a stack overflow.

That's a bit worrying! I suggest that we try to reduce the size of Unit objects. We could delete some unused fields, and convert others from int to short or byte. It looks like most of them are stored as bytes in the galaxy file.

Also, the f_idx is stored as an int everywhere in EFS datafiles so an int based enumeration seems natural.

I agree, and it applies to other values too, but I wouldn't apply the same logic to flags. Flags (like CanBeCargo) are expressed as integers in the data files, and you've read them into integers. I think it would be a little clearer and safer to read them into booleans. Leaving them as integers, you run the risk that sometimes you may test "if(can_be_cargo == 0)", and other times you may test "if(can_be_cargo == 1)". That could potentially result in an inconsistent state if someone put the value 2 in the data file: the unit would be neither transportable nor non-transportable! There are only a few references to such values in the code so far, and they could easily be changed. I suggest doing that before coding any more readers for data files. (There's a load of such flags in STRBUILD.DAT that we're not reading yet.) If we leave them as integers, we should make a point of always testing against 0, not 1, e.g. "if(can_be_cargo == 0)" or "if(can_be_cargo != 0)".

We might choose the overloaded way, ie. have deleteUnit() which deletes cargo and deleteUnit(boolean preserve_cargo) which does not delete cargo if preserve_cargo = true.

I've decided--unless you object--to go with deleteUnitInCombat and deleteUnitNotInCombat. The first will automatically delete any passengers, except for space units on carriers in space, which will be disembarked. That makes sense for combat, and it's what EFS does. The second one will disembark any passengers that can be disembarked in the current environment, and delete any others. If they both call a shared helper method to get the work done, it will be private, and not intended for any other use. I think having two differently named methods maximises clarity. Voluntary termination of loaded transports (disbanding or using them as inputs) can be disallowed. (The player can unload the transport manually and try again.) If it is allowed, then the player must expect to lose any units that can't be disembarked.

[flowerpot]

oh no,

I made a mistake, I just looked at your rsw1

Then I forked your repo, cloned the fork, made a new branch (rsw1) off the master, checking out that branch at the same time, copied my saved src folder over the project's src folder, committed everything, and pushed branch rsw1 to my fork without merging. I hope I've understood you correctly, and you didn't want me to merge, or edit my changes into your files.

Edit
Of course you should have merged the latest updates into your sources, or inserted your modifications by, I took that for granted, but not merge your sources with the master. Now rsw1 is behind, my amendments are overwritten, I don't know which version it is. EfsIni has that data copied from EFS.INI which can't be included in Phoenix.

[tichtich]

oh no,

I made a mistake, I just looked at your rsw1

Then I forked your repo, cloned the fork, made a new branch (rsw1) off the master, checking out that branch at the same time, copied my saved src folder over the project's src folder, committed everything, and pushed branch rsw1 to my fork without merging. I hope I've understood you correctly, and you didn't want me to merge, or edit my changes into your files.

Edit
Of course you should have merged the latest updates into your sources, or inserted your modifications by, I took that for granted, but not merge your sources with the master. Now rsw1 is behind, my amendments are overwritten, I don't know which version it is. EfsIni has that data copied from EFS.INI which can't be included in Phoenix.

Don't worry. I know what changes I made in rsw1. I'll merge those into your latest revision ASAP (but not on the master branch), and let you know when I've uploaded it to my fork.

[tichtich]

OK. I've merged your latest uploaded revision with my latest local one, on new branch rsw2, and pushed that to my fork. Everything seems to be working.

I think I'm now finally straight about when and how to merge, so let's hope there won't be any more problems.

New changes:
- Cities now eat, as well as units.
- Eating only occurs if consume_food is true (in EfsIni).
- Only Houses eat. (I'm not sure if we'll want some other factions to eat. But we can easily change this later. For now, limiting eating to Houses will reduce the amount of console output.)

P.S. Just to be clear, this revision also includes the changes I've mentioned in the forum over the last few days, namely...

-- I've coded readers for PROD.DAT and RES.DAT. Having read RES.DAT, I now use the resource names from that file when displaying cargo pods. That meant that Util.drawUnitDetails needed access to the res table, for which it needed access to game, which it didn't have. So I added game to its parameters, and modified the calls from these methods to pass it: Util.drawStackDisplay, UnitInfoWindow.drawUnits, and UnitInfoWindow.drawDraggedUnit, and CombatWindow.renderCombatWindow.

-- I moved my "cleanLine" method into Util, as it's used by all 3 of my readers.

-- In Game, I made the following changes:
- Declared an array res_types, read RES.DAT into it, and provided a getter for it.
- Moved the reading in of data files up to the start of the initialisation. I thought that seemed wise, since they aren't going to change, but they might be used by some later initialisation.
- Added "turn" as a parameter to UpdateEconomy. That wasn't strictly necessary, but I thought it made things clearer.

[flowerpot]

OK. I've merged your latest uploaded revision with my latest local one, on new branch rsw2, and pushed that to my fork. Everything seems to be working.

Ok, I checked that. How did you manage with the merge, was it ridden with conflicts, cause when I merged unit building it had big conflicts ? There was one new problem, some files eg. Gui.java may have carriage-return added to line ends and report as whole file modified in commandline git while netbeans diff shows no changes.Do you sometimes use a different computer to work on Phoenix ? If so, does it have "git config core.autocrlf true" set ? I added .gitattributes with "* text" to master, that should automatically set line endings, if only netbeans git integration honors it

Also, my netbeans choked on your repo again. I did, however, find the probable cause https://netbeans.org/bugzilla/show_bug.cgi?id=238858 netbeans git integration (jgit) seems to have transient problems with line endings (CRLF) on windows and mac. On my laptop the error is different than on my desktop.

I think I'm now finally straight about when and how to merge, so let's hope there won't be any more problems.

I may have to do one more file copy merge, cause the EFS.INI is in rsw2 history, but I will try to do some git magic with rsw2 to make the EFS.INI history to disappear.

[tichtich]

How did you manage with the merge, was it ridden with conflicts, cause when I merged unit building it had big conflicts ?

Well, I wasn't merging your unit-building into my version, so much as just adding my latest changes to your version. And I hadn't done very much. So there weren't that many conflicts. Even so, I ran into some problems. I'm hoping things will start to get easier eventually!

There was one new problem, some files eg. Gui.java may have carriage-return added to line ends and report as whole file modified in commandline git while netbeans diff shows no changes.Do you sometimes use a different computer to work on Phoenix ? If so, does it have "git config core.autocrlf true" set ? I added .gitattributes with "* text" to master, that should automatically set line endings, if only netbeans git integration honors it

I only use one computer. Here's the contents of my C:/Program Files/Git/etc/gitconfig file:

Code: Select all

[core]
   symlinks = false
   autocrlf = true
[color]
   diff = auto
   status = auto
   branch = auto
   interactive = true
[pack]
   packSizeLimit = 2g
[help]
   format = html
[http]
   sslCAinfo = /bin/curl-ca-bundle.crt
[sendemail]
   smtpserver = /bin/msmtp.exe

[diff "astextplain"]
   textconv = astextplain
[rebase]
   autosquash = true

You had a problem before with your netbeans reformatting my text. Is that still happening, or did you switch it off? I haven't made any change to that, but I'll switch on auto-formatting if you like.

Also, my netbeans choked on your repo again.

I found today that netbeans wouldn't let me checkout your revision, on the grounds that I had uncommitted changes in my working version, even though I'd just committed. IIRC I either reverted or accepted netbeans' offer to revert before checking out, and then it checked out OK. Still, I doubt your problem is anything as simple as that.

I may have to do one more file copy merge, cause the EFS.INI is in rsw2 history, but I will try to do some git magic with rsw2 to make the EFS.INI history to disappear.

Sorry about that. But I find it hard to imagine that anyone from Holistic will ever find it there! I was wondering generally, is there any way to delete commits from a repo?

[flowerpot]

How did you manage with the merge, was it ridden with conflicts, cause when I merged unit building it had big conflicts ?

Well, I wasn't merging your unit-building into my version, so much as just adding my latest changes to your version. And I hadn't done very much. So there weren't that many conflicts. Even so, I ran into some problems. I'm hoping things will start to get easier eventually!

I just did a file copy commit of rsw2 followed by a merge to master. If you haven't got much new code in I suggest you fetch from Phoenix master and then branch a new branch of from it and start working with that and not copy or merge your sources onto the branch.

There was one new problem, some files eg. Gui.java may have carriage-return added to line ends and report as whole file modified in commandline git while netbeans diff shows no changes.Do you sometimes use a different computer to work on Phoenix ? If so, does it have "git config core.autocrlf true" set ? I added .gitattributes with "* text" to master, that should automatically set line endings, if only netbeans git integration honors it

I only use one computer. Here's the contents of my C:/Program Files/Git/etc/gitconfig file:

Code: Select all

[core]
   symlinks = false
   autocrlf = true


the autocrlf is true so why is it that files in the repository sometimes seem to have extra CRs added to EOLs. A jgit bug ?

You had a problem before with your netbeans reformatting my text. Is that still happening, or did you switch it off? I haven't made any change to that, but I'll switch on auto-formatting if you like.

Netbeans enforces a formatting standard eg. if you write

Code: Select all

if (true) break;

upon pressing shift-alt-f netbeans changes it to

Code: Select all

if (true) {
    break;
}

netbeans has a rule that even one statement code blocks be in curly braces. Actually if you type

Code: Select all

if (true) {

and press enter netbeans autoadds the closing curly brace.

Also, my netbeans choked on your repo again.

I found today that netbeans wouldn't let me checkout your revision, on the grounds that I had uncommitted changes in my working version, even though I'd just committed. IIRC I either reverted or accepted netbeans' offer to revert before checking out, and then it checked out OK. Still, I doubt your problem is anything as simple as that.

Thats just about what happened to me on my laptop. On my desktop the checkout fails and I'm stuck unless I use eg. git bash to checkout. On your latest repo some files seemed to have extra carriage returns at end-of-lines. It has something to do with jgit not handling the git CRLF manipulation properly.

I may have to do one more file copy merge, cause the EFS.INI is in rsw2 history, but I will try to do some git magic with rsw2 to make the EFS.INI history to disappear.

Sorry about that. But I find it hard to imagine that anyone from Holistic will ever find it there! I was wondering generally, is there any way to delete commits from a repo?

Well I may be a bit paranoid, but if I don't distribute any data or code by Holistic then I should be safe agains any copyright claims.

[tichtich]

I just did a file copy commit of rsw2 followed by a merge to master.

I'm not clear what you mean by a "file copy commit".

Netbeans enforces a formatting standard eg. if you write

Code: Select all

if (true) break;

upon pressing shift-alt-f netbeans changes it to

Code: Select all

if (true) {
    break;
}

I never press that.

Actually if you type

Code: Select all

if (true) {

and press enter netbeans autoadds the closing curly brace.

Yes, that's useful. But you can then edit it differently if you want.

Anyway, I'll start pressing shift-alt-f if you think that might help us avoid some problems. Is there a way to make reformatting automatic, so I don't need to remember to press it?

I haven't fully followed your descriptions of the problems you're having with merging. Are they so bad that you would like to give up collaborating? From my side things don't seem too bad.

I've been working hard today, and I've finished making all the changes we've discussed for implementation of a cargo pod list structure. All adding, deleting and moving of units now goes through methods which update the pod list structure (except for your unit building). As you suggested, pods are added to the beginning or end of a list, depending on whether they are in space. I realised I also needed to deal with changes of ownership, resulting from units being captured, as that requires moving a captured pod from one faction's list to another's. That's done. All consumption of resources now uses the pod lists. I decided that, while I was at it, I could maintain a running total of the amount of each resource available, by faction and type (and planet with UW off). So the totals (required for display at the bottom of the screen) are immediately available. I've provided methods for delivering those totals and for checking you have enough resources available to build something. I've also improved my method for feeding units and cities.

Everything seems to be working, but I wouldn't mind doing a bit more testing. In the meantime, here's a list of what I've edited, in case it might affect anything you're working on. But the changes are pretty localised, so I don't think there'll be too much difficulty merging.
- Obviously, major changes to Resources, and significant changes to Economy.
- In Battle: changes to removeDead and resolveGroundBattleFinalize.
- Some new constants in util.C
- In Game:
-- Changes to setUnitCoords, capture, and creatUnitInHex.
-- deleteUnit replaced by deleteUnitInCombat and deleteUnitNotInCombat.

[tichtich]

Hi. I see you've uploaded something to your repo in the last 24 hours. But I'm not sure what I should do with it, if anything. Your master seems to be identical to my last upload (rsw2 a couple of days ago). Is there any advantage in me merging my latest version with that one before pushing, rather than just pushing my own version as it is? Is there any advantage in merging when there's been no change? Am I looking at the wrong branch?

I was planning to start using a new branch name/number for each upload, so my next upload would be rsw3. But, as you're referring to my latest upload (rsw2) as "3rd set of modifications by RSW", I think I'll skip a number and go straight to rsw4. So my rsw4 will be my 4th set of modifications that I've uploaded. Does that sound good?

I've completed secondary resource production, and I'm ready to push. But I'm holding off until you tell me what I should do. Do you think we should push and merge every day that we're coding? Perhaps we should keep each other informed about what we're working on, so we can minimise conflicts.

What I'd like to do next is the following:

- Some minor refactoring of Unit and of initialising units in Game, as already discussed. At the moment I'm putting this off, because I think you may be editing Unit yourself, when you refactor unit-building, and I don't want to conflict with you.

- Setting of unit and city loyalty, and having city loyalty affect production. Before proceeding with that, I'd like to check whether you approve of my proposed way of handling it.


EFS seems to keep a running track of unit loyalty, rather than continually recalculating it from scratch. This is a difficult and error-prone way to do it, and consequently there are a number of bugs. For example, unit loyalty normally starts at 75%. Each 1 point change in pay rate changes loyalty by 1%. If you raise pay by 30 points, loyalty is capped at 100% instead of going to 105%. If you subseqently reduce pay by the same 30 points, loyalty goes down 30%, from 100% to 70%. It doesn't return to the original 75%!!!

I propose that we simply have a method that calculates loyalty from scratch, and call it each time we need to know a unit's loyalty. It's a simple calculation, though it does need to take into account relevant house traits. It means that changes in loyalty will be visible as soon as a relevant change is made. If you increase pay, you will immediately see that your units have a higher loyalty, whereas in EFS there isn't any change until the start of your next turn. I see nothing wrong with having an immediate change.

A reasonable alternative would be to only recalculate loyalty at the start of your turn, and then save it in a unit's loyalty field for use during the rest of the turn. It would still be calculated from scratch each turn, and not kept as a running figure.

A further complication is that the map editor allows you to give units non-standard initial loyalties. If a unit starts the game with 65% loyalty, instead of the standard 75%, its loyalty will always be 10% lower than equivalent units which started at 75%. I would implement this by making the initial loyalty--as read from the galaxy file--a base loyalty (which never changes). Unit loyalty would then be calculated each time as loyalty = base loyalty + (tax_rate - 100) + any other modifiers. You're probably familiar with the fact that Li Halan units start the game with 95% loyalty. But the map editor shows them with only 75%. They get an immediate +20% for house traits. In my terms, their base loyalty is 75%. As far as I can see, all units in the standard galaxy and random galaxies have a base loyalty of 75%. So I need to save base loyalty on a per-unit basis, but only for the benefit of people with galaxies modified by the map editor. I'm assuming that all newly built units also start with a base loyalty of 75%. I have no reason to think otherwise.

Depending on which of the two above options we choose, units will have either one or two loyalty fields: just base loyalty; or base loyalty and this turn's loyalty. I prefer the first option, and it has the advantage of needing one less field in Unit, so it will save us some valuable memory.

In the case of cities, I don't think there's any need for a base loyalty. You can't set a city's loyalty in the map editor. From having a quick look around at the start of a standard game, it looks like all non-house factions automatically have 100% city loyalty. Most likely they don't have a tax rate or pay rate. But I noticed that at least the League and Church do produce respurces (harvesting and secondary).

[flowerpot]

I just did a file copy commit of rsw2 followed by a merge to master.

I'm not clear what you mean by a "file copy commit".

I use git log on rsw2 to find which commit of master you merged with. Then I checkout that commit from master and make a new branch of it. Then I copy rsw2 sources onto that branch. Then I commit that, remembering to set myself as the commiter but you as the author to preserve authorship data. Then I merge that with master. This I do to get rid of the history (commits) of rsw2 which contains eg. copied EFS.INI data and those mysterious files with extra carriage-returns at EOLs which apparently make netbeans git integration go haywire.

Anyway, I'll start pressing shift-alt-f if you think that might help us avoid some problems. Is there a way to make reformatting automatic, so I don't need to remember to press it?

No real problems with that, the only thing is that if I later work on the files and use the semi-automatic formatting it makes formatting alterations on your contributed code and on commit records me as the author of that code although all I did was press shift-alt-f. The very proper procedure I suppose is to before every commit, click select the project in the projects window and then press shift-alt-f. That will recursively format all the files in the project. But I never remember to do that myself. Okay, I just digged netbeans.org and apparently there is format on save feature in tools->options->editor->"on save". I'm gonna turn that on from now on. If there are no problems I keep it on.

I haven't fully followed your descriptions of the problems you're having with merging. Are they so bad that you would like to give up collaborating? From my side things don't seem too bad.

I had one hairy merge, which was my own fault for not regularly merging the mods on master onto my development branch. More of a problem is this nonsense with jgit not working properly with CRs at EOLs and making netbeans git freeze when checking out your remote branches. The filecopy merges are a bit of an extra work for me but it is also an inconvenience that you had to always start with a new clone of master. But this seems to have been mitigated to some extent with our moving to you working on development branches and merging master onto the branches.

The issues with merge are not so bad that I would like give up collaborating, but I find all this shared work management difficult. Eg. we should have discussed project management issues like code formatting and who does what right at the start instead of just diving into coding things, this is especially bad since there is virtually no documentation in Phoenix prior to your coming on board. So apparently my project management skills could be better, among other things. You might also have noticed how I respond late and some things slip past me and are left unanswered. I also find myself preoccupied with worrying about bugs the collaboration might introduce. And I find it hard give up complete control of the project.

This is particularly bad because for a project like this there is no better collaborator than you with your eg. programming skills and in depth knowledge of how EFS works and doesn't work. If I have problems working with you then I would have problems working with anybody and everybody.

I've been working hard today, and I've finished making all the changes we've discussed for implementation of a cargo pod list structure.

Everything seems to be working, but I wouldn't mind doing a bit more testing.

This sounds good, I will wait for your testing to finish. Maybe I should try to add resource display to the planet window in the mean time.

I see you've uploaded something to your repo in the last 24 hours. But I'm not sure what I should do with it, if anything. Your master seems to be identical to my last upload (rsw2 a couple of days ago). Is there any advantage in me merging my latest version with that one before pushing, rather than just pushing my own version as it is? Is there any advantage in merging when there's been no change? Am I looking at the wrong branch?

When I was trying to figure out those problems with netbeans git I did among other things push all my branches to github and reset my local repository from there hoping it would help. This was before I found out about the bug description on netbeans.org. Master is the only branch you should merge from as it is supposed to be the stable deployment branch (if we can have much stability at this point.) Of course you can look at the other branches if you want. I should probably delete most of the other branches from github which are all merged to master anyway except for research_tech which I'm currently working on. Try fetching from master. If your local repo says you are up to date with master then there is no need to merge. In fact a merge with no changes would probably be a no operation.

[tichtich]

I use git log on rsw2 to find which commit of master you merged with. Then I checkout that commit from master and make a new branch of it. Then I copy rsw2 sources onto that branch. Then I commit that, remembering to set myself as the commiter but you as the author to preserve authorship data. Then I merge that with master. This I do to get rid of the history (commits) of rsw2 which contains eg. copied EFS.INI data and those mysterious files with extra carriage-returns at EOLs which apparently make netbeans git integration go haywire.

OK. Thanks for explaining.

I've discovered that I have two config files for git: a general one, \Program Files\git\etc\gitconfig, and a project-specific one, Phoenix\.git\config. I only had "autocrlf = true" in the first one. I've now added it to the second, though I don't expect that will make any diference.

Okay, I just digged netbeans.org and apparently there is format on save feature in tools->options->editor->"on save". I'm gonna turn that on from now on. If there are no problems I keep it on.

I've now switched it on too. I've set it too "All lines".

The filecopy merges are a bit of an extra work for me but it is also an inconvenience that you had to always start with a new clone of master.

I didn't realise you wanted me to clone every time. I thought you meant just once. But, OK, I'll clone each time.

The issues with merge are not so bad that I would like give up collaborating, but I find all this shared work management difficult. Eg. we should have discussed project management issues like code formatting and who does what right at the start instead of just diving into coding things, this is especially bad since there is virtually no documentation in Phoenix prior to your coming on board. So apparently my project management skills could be better, among other things. You might also have noticed how I respond late and some things slip past me and are left unanswered. I also find myself preoccupied with worrying about bugs the collaboration might introduce. And I find it hard give up complete control of the project.

I understand all those concerns. And I find it difficult too. Going from one developer to two does involve a significant extra amount of time spent on communication, and some extra risk of errors arisng through one person not understanding what the other has done. But I hope this will be balanced by the contribution I'm making, and some of my suggestions may help reduce some risks of bugs.

Actually, I was just about to stop making so many suggestions, and get on with more coding. But I'll continue mentioning suggestions and potential problems if you want to hear them. I have a list...

Maybe I should try to add resource display to the planet window in the mean time.

I was thinking that might be a good job for me. It shouldn't take me long to deal with loyalty and money (which I was planning to do next), and then I'll be looking around for something else to do. I think I'll need to start learning how the GUI works at some stage, and that could be a relatively simple first step. But I'm open to other suggestions.