Question for the Developers (Working with original source release)

[Per]

Any good tutorials on how to make a patch?

Look at http://freeciv.wikia.com/wiki/How_to_Contribute for example.

[Giel]

The "diff" application mentioned in the above link can be found as a GNUWin32 package of DiffUtils for windows.

[Per]

Radar.c, DrawRadarExtras().  But if I remember correctly, you guys removed all of the PSX and glide stuff

It is still there, still commented out. I uncommented it all back in, and I can't say I liked what I saw. The stuff on the radar only showed for a brief moment as the scanline passed, and I would have to keep staring at the radar display to see what I wanted. I did not see any radar line, though.

Or, you can wait for me to uncover it and I'd be happy to point you guys to the changes and where to find them if you are interested in any of the PSX-/Glide-unique functionalities as I implement them in my project.

I'd happy to know what you find.

[Chojun]

I wrote up this whole elaborate post last night and somehow my IE window got closed.  So since I'm lazy I'll summarize it.

I fixed what I consider a major gameplay-related bug.  It is a T3 bug that just puts everything at a standstill; a research topic that you would THINK would be beneficial, but instead it is quite annoying.  Some of you (Coyote?  ) may know what I'm talking about.

So, when you research this, units go into this state of euphoric bliss that they won't exit unless they're dead or nothing is going on around them.  This nirvana i'm talking about is called Self-Repair.  Units will sink into this mindless stupor, standing at nothing to be able to blissfully repair themselves while their enemies pound themselves into self-repairing bits.

So, long story short, I fixed the problem.  Here is the nature of the fix:

Structures are unaffected by any of this.  Units now will self repair at all times.  They can be doing anything they want and will still self-repair.  However, self-repair is viewed as repairing damaged critical internal systems.  So units will only self-repair if they are damaged beyond 50% (I'm mulling the 75% level, but we'll see how the game balances out).  VTOLs will now self repair, even in flight.  These changes I've made on my end only affect multiplayer play since Cam3 AI depends heavily on they way self-repair worked before.

Anyway, in short, the reason why self-repair was a nuisance is because it was basically implemented as a hack.  Units that are bieng repaired--whether by themselves or by another repair unit/facility--are given the behavior of not doing anything at all.  In fact, they are explicitly told not to do anything, not even "shuffle" around if another unit needs to get by.  Which is why a few self-repairing units can create a wall of death for your other units that are trying to retreat.

Thoughts?

[Troman]

I use TortoiseSVC for making/applying patches and for access to the repository.

As for the Auto-repair, that thing can be really annoying.
But I would have solved it differently. I would have given it a lower priority, then other commands, so that a unit would only self-repair if it is idle.

Allowing unit to always self-repair makes vanish any strategical element about this feature. The player should have a choice: to let the units use their guns or to put them on hold and self-repair instead.

[Per]

I use TortoiseSVC for making/applying patches and for access to the repository.

As for the Auto-repair, that thing can be really annoying.
But I would have solved it differently. I would have given it a lower priority, then other commands, so that a unit would only self-repair if it is idle.

Allowing unit to always self-repair makes vanish any strategical element about this feature. The player should have a choice: to let the units use their guns or to put them on hold and self-repair instead.

I agree. What needs to be changed to implement this?

BTW, I reported this recently as bug https://gna.org/bugs/?9665

[themousemaster]

I use TortoiseSVC for making/applying patches and for access to the repository.

As for the Auto-repair, that thing can be really annoying.
But I would have solved it differently. I would have given it a lower priority, then other commands, so that a unit would only self-repair if it is idle.

Allowing unit to always self-repair makes vanish any strategical element about this feature. The player should have a choice: to let the units use their guns or to put them on hold and self-repair instead.

But changing it to that method would still cause the Repair Facility Overload issue:  If 2 untis retreat for repair, the first to make it to the facility will be repaired by the facility, while the 2nd would stand around and auto-repair... with the problem being, once the first tank is done, the 2nd would NOT then start using the faster facility.

[Troman]

I agree. What needs to be changed to implement this?

BTW, I reported this recently as bug https://gna.org/bugs/?9665

Probably some additional if's to check if a droid has any orders/actions of a higher priority than auto-repairing.

But changing it to that method would still cause the Repair Facility Overload issue:  If 2 untis retreat for repair, the first to make it to the facility will be repaired by the facility, while the 2nd would stand around and auto-repair... with the problem being, once the first tank is done, the 2nd would NOT then start using the faster facility.

I see no reason why this couldn't be fixed.

[themousemaster]

I see no reason why this couldn't be fixed.

Don't let me stop ya then ;p

[Chojun]

Quick update:

I was successful in implementing the State Manager that I had spoken of earlier.  It needs a little performance tweaking but it is mostly finished.  Warzone's state is now handled purely by a stack-based system (actually for testing I had it working more like a queue, but this will change in like 5 minutes, hehe).  All states are mutually exclusive, so one state doesn't have to be on the stack in order for another state to be pushed, and vice-versa.

In my project, Warzone has now 3 (4 with one unused) states:  Title screen, Save game load, and Normal Gameplay mode.  I will be adding a pause state and a video playback state as well.  Adding the state manager was a little tricky but in the end it paid off, as it cleaned up the source, and it also improved the performance a little.

The big thing is that the system is purely modular, so if a new state would need to be added it would be extremely easy to do so ;D  The same can be said for removing a state.  So, for the non-retail CD owners, you can simply remove the video playback state at runtime and the videos (that you don't have) won't play.  I have plans that may exploit said modularity sometime in the future...    BTW where is the "EvilGrin" smiley from the NEWST forums?  These smileys 'round here just don't do justice.

[Per]

Allowing unit to always self-repair makes vanish any strategical element about this feature. The player should have a choice: to let the units use their guns or to put them on hold and self-repair instead.

This is apparently the way it was meant, too, but a bug in the original code that I fixed in revision r2369 stopped it from working that way. Now it should work as intended.

[Troman]

This is apparently the way it was meant, too, but a bug in the original code that I fixed in revision r2369 stopped it from working that way. Now it should work as intended.

I don't know if that fixed it, haven't checked, but I'd be surprised if it did, since all the code you edited was added not that long ago and the problem with autorepairing was even in the original game before the release of the source.

[Per]

I don't know if that fixed it, haven't checked, but I'd be surprised if it did, since all the code you edited was added not that long ago and the problem with autorepairing was even in the original game before the release of the source.

Well, that is odd, because it is fixed as far as I can tell. Maybe someone fixed it earlier by accident, then it got bugged again in another part of the code later on? Please try it out and see if it works for you...

[Troman]

Well, that is odd, because it is fixed as far as I can tell. Maybe someone fixed it earlier by accident, then it got bugged again in another part of the code later on? Please try it out and see if it works for you...

The problem is still there, I just tested with SVN head.

[Per]

The problem is still there, I just tested with SVN head.

How strange. I test by entering skirmish on Rush, cheating with "research all", and park a droid up at the closest enemy oil derrick stronghold. Before the patch, it would just sit there healing itself while being shot at, now it shoots at the enemy instead. How can I duplicate the bug you (still) see?