project-navigation
Personal tools

Author Topic: Money: "Patch" included, but tester needed.  (Read 9334 times)

Rei

  • Guest
Money: "Patch" included, but tester needed.
« on: August 07, 2006, 10:12:17 pm »
Another issue that's come up: money.  There are a few issues with it.

1) As has already been mentioned, the battle rewards rarely even pay for the battle.

2) Battle rewards (and missed battle penalties) are miniscule compared to everything else (construction costs, foreign-country income, etc).  They're almost irrelevant.  Is there even a point to keeping battle rewards?  Shouldn't battles just be the "cost of business" of keeping your country sponsors happy?

3) Countries don't seem to care what you do.  Perhaps it was just me, but it seems that you can be rolling in the cash without ever going to a mission.  Shouldn't countries that you don't protect get sick of you sitting around doing nothing, or become happy if you help out a lot?

UPDATE: Nope, I guess it's not me.  From cl_campaign.c (code checked out yesterday evening):

Code: [Select]

/**
  * @brief
  *
  * if expires is true a mission expires without any reaction
  * this will cost money and decrease nation support for this area
  * TODO: Use mis->pos to determine the position on the geoscape and get the
  * TODO: Use colors for nations
  */
static void CL_HandleNationData(qboolean expires, actMis_t * mis)
{

}


That function is supposed to make them happy/unhappy with you, but it's blank.  One problem with filling it in is that nation_t has a funding level, but not a happiness level or "original funding" level; if you change funding, it'd be hard to know what range to allow it to change in.  I'd propose changing the struct (in client/cl_campaign.h) to:

Code: [Select]

typedef struct nation_s {
        char id[MAX_VAR];
        char name[MAX_VAR];
        int funding;
        float happiness;
        vec4_t color;
        float alienFriendly;
        int soldiers;
        int scientists;
        char names[MAX_VAR];
} nation_t;

Modifying the initialization in client/cl_campaign.c to start them out at half maximum happiness:

Code: [Select]

value_t nation_vals[] = {
        {"name", V_TRANSLATION_STRING, offsetof(nation_t, name)}
        ,
        {"color", V_COLOR, offsetof(nation_t, color)}
        ,
        {"funding", V_INT, offsetof(nation_t, funding)}
        ,
        {"happiness", V_FLOAT, 0.5}
        ,
        {"alien_friendly", V_FLOAT, offsetof(nation_t, alienFriendly)}
        ,
        {"soldiers", V_INT, offsetof(nation_t, soldiers)}
        ,
        {"scientists", V_INT, offsetof(nation_t, scientists)}
        ,
        {"names", V_INT, offsetof(nation_t, names)}
        ,

        {NULL, 0, 0}
        ,
};


Modifying mission_t in cl/cl_campaign.h to have a nation string in it:

Code: [Select]

typedef struct mission_s {
        char *text;
        char name[MAX_VAR];
        char map[MAX_VAR];
        char param[MAX_VAR];
        char location[MAX_VAR];
        char nation[MAX_VAR];
        char type[MAX_VAR];
        char music[MAX_VAR];
        char alienTeam[MAX_VAR];
        char alienEquipment[MAX_VAR];
        char alienArmor[MAX_VAR];
        char civTeam[MAX_VAR];
        char cmds[MAX_VAR];
        char onwin[MAX_VAR];
        char onlose[MAX_VAR];
        int ugv;                                        /* uncontrolled groun
        qboolean active;                        /* aircraft at place? */
        qboolean onGeoscape;            /* already on geoscape - don't add it
        qboolean storyRelated;          /* auto mission play disabled when tr
        vec2_t pos;
        byte mask[4];
        int aliens, civilians;
        int recruits;
        int cr_win, cr_alien, cr_civilian;
} mission_t;


Modifying the associated missions.ufo to have that as well.  One example:

Code: [Select]

mission stadium
{
        location        "_New York"
        nation         "ua"
        type            "_Terror Attack"
        text            "_Damn it, you've let some of them get\away again! Re
        map                     stadium06
        music           mission3
        pos                     "74 41"
        aliens          4
        alienteam       alien
        alienequip      stage3_soldiers
        civilians       2
        civteam         european
        recruits        4
        $win            400
        $alien          250
        $civilian       200
        onlose          ""
        onwin           ""
        storyrelated    true
}


Then modifying client/cl_campaign.c to fill out that field:

Code: [Select]
value_t mission_vals[] = {
        {"location", V_TRANSLATION_STRING, offsetof(mission_t, location)}
        ,
        {"type", V_TRANSLATION_STRING, offsetof(mission_t, type)}
        ,
        {"text", V_TRANSLATION_STRING, 0} /* max length is 128 */
        ,
        {"nation", V_STRING, offsetof(mission_t, nation)}
        ,
        {"map", V_STRING, offsetof(mission_t, map)}
        ,
        {"param", V_STRING, offsetof(mission_t, param)}
        ,
        {"music", V_STRING, offsetof(mission_t, music)}
        ,
        {"pos", V_POS, offsetof(mission_t, pos)}
        ,
        {"mask", V_RGBA, offsetof(mission_t, mask)} /* color values from map
        ,
        {"aliens", V_INT, offsetof(mission_t, aliens)}
        ,
        {"maxugv", V_INT, offsetof(mission_t, ugv)}
        ,
        {"commands", V_STRING, offsetof(mission_t, cmds)} /* commands that ar
        ,
        {"onwin", V_STRING, offsetof(mission_t, onwin)}
        ,
        {"onlose", V_STRING, offsetof(mission_t, onlose)}
        ,
        {"alienteam", V_STRING, offsetof(mission_t, alienTeam)}
        ,
        {"alienarmor", V_STRING, offsetof(mission_t, alienArmor)}
        ,
        {"alienequip", V_STRING, offsetof(mission_t, alienEquipment)}
        ,
        {"civilians", V_INT, offsetof(mission_t, civilians)}
        ,
        {"civteam", V_STRING, offsetof(mission_t, civTeam)}
        ,
        {"recruits", V_INT, offsetof(mission_t, recruits)}
        ,
        {"storyrelated", V_BOOL, offsetof(mission_t, storyRelated)}
        ,
        {"$win", V_INT, offsetof(mission_t, cr_win)}
        ,
        {"$alien", V_INT, offsetof(mission_t, cr_alien)}
        ,
        {"$civilian", V_INT, offsetof(mission_t, cr_civilian)}
        ,
        {NULL, 0, 0}
        ,
};


Then we fill out the empty function with something like:

Code: [Select]

static void CL_HandleNationData(qboolean expires, actMis_t * mis)
{
        int i;
        mission_t* mission=mis->def;
        char* nation_name=mission->nation;

        for (i=0; i<numNations; i++)
        {
                nation_t* nation=&nations[i];
                if (expires)
                {
                        if (!strcmp(nation->name, nation_name))
                        {  //Strong negative reaction
                                nation->happiness*=(nation->alienFriendly);
                        }
                        else
                        {  //Minor negative reaction
                                nation->happiness*=1-pow(1-nation->alienFriendly,5);
                        }
                }
                else
                {
                        if (!strcmp(nation->name, nation_name))
                        {  //Strong positive reaction
                                nation->happiness/=(1-nation->alienFriendly);
                                nation->happiness+=nation->alienFriendly/10;
                        }
                        else
                        {  //Minor positive reaction
                                nation->happiness/=pow((1-nation->alienFriendly),0.2);
                                nation->happiness+=nation->alienFriendly/50;
                        }
                        if (nation->happiness > 1.0)
                        {  //Can't be more than 100% happy with you.
                                nation->happiness=1.0;
                        }
                }
        }
}


And we must make sure that it gets called properly, not just on loss (client/cl_campaign.c):
Code: [Select]

       /* give reward */
        if (won)
        {
                CL_UpdateCredits(ccs.credits + mis->cr_win + (mis->cr_alien * mis->aliens));
                CL_HandleNationData(false, mis)
        }
        else
        {
                CL_UpdateCredits(ccs.credits + mis->cr_win - (mis->cr_civilian * mis->civilians));
                CL_HandleNationData(true, mis)
        }

Same thing, further down:

        /* check for win */
        if (Cmd_Argc() < 2) {
                Com_Printf("Usage: game_results <won>\n");
                return;
        }
        won = atoi(Cmd_Argv(1));
        CL_HandleNationData(true, selMis)


Lastly, we need to adjust the funding that they give you in client/cl_campaign.c by their happiness and get rid of the random nonpayments since they're no longer needed:

Code: [Select]

/**
  * @brief
  *
  * Update the nation data from all parsed nation each month
  * give us nation support by:
  * * credits
  * * new soldiers
  * * new scientists
  * Called from CL_CampaignRun
  * @sa CL_CampaignRun
  */
static void CL_UpdateNationData(void)
{
        int i;
        char message[1024];
        nation_t *nation;

        for (i = 0; i < numNations; i++) {
                float funding;
                nation = &nations[i];
                funding=nation->funding * nation->happiness;
                Com_sprintf(message, sizeof(message), _("Gained %i credits from nation %s"), funding, _(nation->name));
                MN_AddNewMessage(_("Notice"), message, qfalse, MSG_STANDARD, NULL);
                CL_UpdateCredits(ccs.credits + funding);
        }
}


Anyone want to try this out?

 - Karen Pease (meme@daughtersoftiresias.org)

Rei

  • Guest
Money: "Patch" included, but tester needed.
« Reply #1 on: August 08, 2006, 05:29:34 am »
UPDATE:

Well, I implemented and debugged it myself.  It works great  :)  The only problem, though: I can't commit code.  

Either I need commit access, or I need to know how you would like me to create a patch (I'm a linux user -- is a diff okay?)

Offline Mattn

  • Administrator
  • PHALANX Commander
  • *****
  • Posts: 4831
  • https://github.com/mgerhardy/vengi
    • View Profile
    • Vengi Voxel Tools
Money: "Patch" included, but tester needed.
« Reply #2 on: August 08, 2006, 08:57:53 am »
a diff is ok - just type
Code: [Select]
svn diff > patch.diff
and submit the patch to the patch tracker at sourceforge.

we can get svn access after your your patchtracker submission. just leave me a note if you are interested in contributing more.

Offline Bandobras

  • Captain
  • *****
  • Posts: 586
    • View Profile
Money: "Patch" included, but tester needed.
« Reply #3 on: August 08, 2006, 02:01:29 pm »
NIce idea but this is some more work for mission script-writers (the nation field). Wouldn't it be better if nation was determined by the posion? To make it simple, assign "center" postion to each nation and measure which nation has the closes centre to the mission coordinates. If we ever have country borders layer on the geoscape, then this can be done more accurately...

Rei

  • Guest
Money: "Patch" included, but tester needed.
« Reply #4 on: August 08, 2006, 05:26:13 pm »
That wouldn't work.  For example, Egypt would almost certainly be part of any unified arab state (they *founded* the United Arab Republic in an attempt to bring Arab states together and didn't give up on it until 1971).  Libya, too, has had (and still has) strong pan-arab sentiments.  In all likelyhood, all of North Africa (which is quite different from sub-saharan Africa) would want to be in the state.  Yet the western, North African states would be closer to Europe and Africa than the Arab state, unless you make the arab state so huge that it includes most of Europe and western Asia.

The nation field is pretty darn tiny compared to the rest of the mission text, and after all, I'm the one offering to write hundreds of mission script files here once you get autogenerated maps working better.  :)  I already added it to all of the extant missions in missions.ufo.

In the future, when we actually have maps of our future-nations and code to deal with that, the nation field can be obsoleted.  But for now, it is by far the easiest solution.

Patch created; I'll submit it right away.  And yes, I would like SVN access because I may randomly feel like contributing more whenever I encounter a bug that's bothering me or want to implement some requested features.  ;)

New issue: Civilians.  Currently I'm just dealing with win/loss conditions.  Should we also take into account the number of civilians killed vs. the number that survived (and for that matter, aliens killed vs. survivors if there's a mission in which they can escape)?

Old issue, resurfacing: Combat rewards are pretty pathetic.  So are penalties for failing to go to a mission.  With countries adjusting their payment to you based on how you perform, shouldn't we just remove those altogether?

Offline Bandobras

  • Captain
  • *****
  • Posts: 586
    • View Profile
Money: "Patch" included, but tester needed.
« Reply #5 on: August 08, 2006, 09:05:00 pm »
Quote from: "Rei"
That wouldn't work.

 
You are right. With this setup some missions on the territory of a state will not bother it, but erroneously bother a neighbouring state.

What about affecting happiness of all countries that have capital city in a given radius from the mission spot? On the premises that states are worried about close missions, even if not on their territory.

Quote
The nation field is pretty darn tiny compared to the rest of the mission text,


This is not the main problem. Problem is in maintanance. There would be two fields with related information: position and nation. This is bad, beause they are likely to get out of sync. There is no much problem if you accidentaly move a mission form Beijing to New York (perhaps it happens in China Town?). But there is a problem if you send aircrafts to China and the game insists they are just flying to US. And there is a problem if US told you about the mission (based on nation field), but the game spawns it in China (based on position field). Then Chinese shoot your uncalled for aircrafts and US sends nukes at your base for ignoring them.

Moreover if the field is likely to be removed in the future, I would rather fix other bugs, than do this. In a complicated client-server application, such as q2, adding and removing fields is a horrible coding work --- you have to change lots of code sending, receiving, initializing, reading, writing, formats, order of sent bytes, etc. And even after that you get bugs and you don't now what they come from. For example, I have no clue if the fields you add need writing/reading between client and server, or on save/load game, and it's not that easy to see that (rgrep not always helps).

Quote
and after all, I'm the one offering to write hundreds of mission script files here once you get autogenerated maps working better.  :) I already added it to all of the extant missions in missions.ufo.


Great! This file needs a lot of urgent work (I will be glad to answer your questions why some things there look as they look, thought for most the answer is: because nobody had the time to fix it :) ). But don't be so quick with changing things --- this is a team effort and we try hard to respect others' work:  to read and understand their code and discuss before we change things. There is so much work to do, we can't afford to waste anybody's work, or introduce chaos into the code. I think, by submitting without discussing the existing code, you risk that most of your patch will not be used, and I would be very sorry to see that happen... Fortunately there are some changes in the patch that look safe and nice, so not all will be lost... :)

Quote
And yes, I would like SVN access because I may randomly feel like contributing more whenever I encounter a bug that's bothering me or want to implement some requested features.  ;)


I really hope you will contribute and I very kindly invite you to our open IRC channel. I do not have the power to grant you SVN access, and, I guess it's granted only after the contributor has proven himself able to reasonably discuss things he want's to change/add/remove. Mattn is the boss, but he is very busy, so IRC is a real help.

Quote
New issue: Civilians.  Currently I'm just dealing with win/loss conditions.  Should we also take into account the number of civilians killed vs. the number that survived (and for that matter, aliens killed vs. survivors if there's a mission in which they can escape)?


Good points. Isn't it already implemented? I think at the end of a mission it tells you how many you rescued... Oh, you mean, afffect the state happiness by this? Sure! After we discuss the "happiness" flag...

Quote
Old issue, resurfacing: Combat rewards are pretty pathetic.  So are penalties for failing to go to a mission.  With countries adjusting their payment to you based on how you perform, shouldn't we just remove those altogether?


A very important thing. I'm for doing as you say, but this is too serious (removing somebody's work) too discuss just between us. Please come to our IRC channel, or I can tell about it there but, frankly, I would rather not work as your proxy. :)

Offline Bandobras

  • Captain
  • *****
  • Posts: 586
    • View Profile
Money: "Patch" included, but tester needed.
« Reply #6 on: August 08, 2006, 09:36:09 pm »
I'm just reading your patch, the "happiness" part (that I think is likely to get in-game soon), more closely. I don't quite get the meaning of the various flags. What do you thing, what is the difference between funding, alienFriendly and happiness? Aren't they the same? Are funding and alienFriendly used in the SVN trunk, already? How? Do you use them in your patch?

For whatever reason, we don't use "fprintf(stderr", but other prints. Don't ask me why...

More questions will come...

Rei

  • Guest
Money: "Patch" included, but tester needed.
« Reply #7 on: August 09, 2006, 12:34:54 am »
I'll try to get on IRC at some point, although I can't say when.  Is there a specific time that's best?

Are there any plans to have a "coordinate to nation lookup" function implemented any time soon?  Because I'd hate to see such a critical feature as nations actually caring whether you sit on your duff all day (vs actually fight the aliens) not get implemented simply because some day, some time in the unknown future, people plan to implement the nation lookup feature.  But if that code does get implemented, I promise to take care of modifying the game to use it in terms of nation happiness.  :)  It only took me about 15 minutes to update the missions.ufo file to add that field in.

As for the flags:

Funding: max funding provided by a nation.  If they're 100% happy with you, they'll give you 100% of that money.  If they're 50% happy with you, they'll give you 50% of that money.
Happiness: How happy the nation is with your work at any given point in time.
AlienFriendly: How much a nation tolerates alien activity.  The higher the alienFriendly value, the slower they will be to get upset with you for missing a mission and the faster they'll become thankful for you succeeding in a mission.  

As an example of how this goes:

The United Americas provides a base level funding of 110000, starts out at half happiness, and is 40% alien friendly.  If nothing happened between the start of the game and the first payday, you would get 110,000 * 0.5 = 55,000 credits from the United Americas.

Now lets say that Russia was attacked and  you succeeded in your mission.  The United Americas get the following positive reaction:

            nation->happiness /= pow(1 - nation->alienFriendly/100, 0.2);
            nation->happiness += nation->alienFriendly/100 / 50;

Lets look at what this does.  nation->alienFriendly/100 normalizes the percentage (i.e., 40% becomes 0.4, which is what you generally need to work with percents mathematically).  So this becomes:

            nation->happiness /= pow(1 - 0.4, 0.2);
            nation->happiness += 0.4 / 50;

Lets look at the first line.  One minus a percentage will always be between zero and one.   So here, the more alien friendly they are, the closer the difference is to zero, which means a lot of change.  The closer it is to one (i.e., alien unfriendly), the closer to one it is, which means the less it will change.  Raising that to a >1 power would make the number approach zero, while raising it to a <1 power makes it approach 1.  Since we're raising it to the 0.2 power, that pow() statement makes us not change as much in happiness as the "strong positive reaction" formula, which is the same but missing the pow statement.  

The second line is pretty simple: it's a constant increment, based on the alienFriendly value.  Adding this in makes it easier to recover from completely ticking off a nation.  If their happiness got down to, say, 0.00001, trying to recover it with /= statements alone would take forever.

So, what does this work out to?  

            nation->happiness /= pow(0.6, 0.2);
            nation->happiness += 0.008;

Which is:

            nation->happiness = 0.5 / pow(0.6, 0.2) + 0.008;

Which equals ~0.56.  Even for reasonably alien-tolerant America, Attacks in other peoples' countries don't change attitudes very quickly.  Now your pay from the United Americas would be 110,000 * 0.56 = 61,600 credits.  

Now, lets say that New York was attacked and you didn't defeat the aliens.  Well, that would be a "strong negative reaction":

              nation->happiness *= nation->alienFriendly/100;

This is pretty straightforward: we convert alienFriendly to a decimal value, then we multiply that value times the happiness.  In this case:

              nation->happiness = 0.56 * 0.4;

This equals ~0.26.  Thus, your new pay from recently-angered America will be 110,000 * 0.26 = 28,600.

Now, what if this had been the arabs watching you save another country and then having one of their cities hit?  They'll judge you more harshly.  So, after the first attack, their opinion of you is only up to ~0.53.  After having an arabian city hit, however, it would go all the way down to 0.13.

Of course, even for the arabs, who don't recover happiness at your failure very well, a success at stopping a raid in one of their countries will still significantly help their happiness rating -- boosting it to 0.20.  A success in America after your failure would get you all the way back up to 0.49 -- right near your starting happiness level.

The consequence of this system is that you need to make careful calls on your base placement (or at least will, once you don't see every mission that pops onto the map  ;)  ).  Do you build near the players that will get upset with you more easily and risk alienating your bigger, more tolerant funders?  Or vice versa?

Anyways, feel free to ask any other questions or favors you have; this is my first patch for this game, so I expect to be grilled.  ;)

Offline Bandobras

  • Captain
  • *****
  • Posts: 586
    • View Profile
Money: "Patch" included, but tester needed.
« Reply #8 on: August 09, 2006, 02:01:15 am »
Quote from: "Rei"
I'll try to get on IRC at some point, although I can't say when.  Is there a specific time that's best?


Middle-European time. :)
Perhaps try around 18:00 UTC.

Quote
Are there any plans to have a "coordinate to nation lookup" function implemented any time soon?


You mean, with nation borders data? I guess not. This is a lot of data to dig out, store in-game, look up. We are still trying to freeze thing and get 2.0 out (not much success with the freezing part).

Quote
Because I'd hate to see such a critical feature as nations actually caring whether you sit on your duff all day (vs actually fight the aliens) not get implemented


You are totally right. What about my proposal to affect nations based on the distance from mission to capital? Having capitals on map in game will be fun, regardless of happiness, and it's much easier to implement than borders. If that's not OK then, based on your patch, we will make all nations equally caring, wherever the mission happens. This is minimalistic, but with such code we should actually start, let others review it, test it, and only then move to bigger changes... Believe me, this code is very brittle...

As for the flags:

Quote
Funding: max funding provided by a nation.  [...]


Oh, I see, this is based on economy and fixed (unless we implement economies crumbling due to alien invasion). So this is not a dublet of happiness, good.

Quote
Happiness: How happy the nation is with your work at any given point in time.
AlienFriendly: How much a nation tolerates alien activity.
[...lots of fine ideas and reasonable pseudocode...]


You didn't say if alienFriendly is actually used anywhere in the current code, but a quick rgrep shows it is not. Then, based on the KISS principle, especially when touching a long forgotten part of code, and especially before 2.0, I propose to merge happiness and alienFriendly, under the name alienFriendly (we can even change the name to "happiness", that should be safe). In other words I propose to make the alien-friendliness in your calculations a constant for all nations, or perhaps base it on soldiers, scientists or funding fields --- there is enough to choose from. Perhaps funding is the simplest choice, as the soldiers and scientists may well disappear in future versions...

So, for instance, the welthier the nation is, the more careful you have to be to please it. Not totally trivial, but simple enough for most players to notice after a dozen of games. What do you think?

If we get this, we (or you) can move to having this in savegames (is it there already?), then taking into account saved civilians, and then --- who knows, capitals, borders, or even your nation fields in missions.ufo, though I will voice my doubts again when we get to that point.

Quote
this is my first patch for this game, so I expect to be grilled.  ;)


Not my intention, really. :D I'm just trying to help you (I was a UFO:AI newbie a month ago, too) and to get you hacked for this project by accepting your patch, without getting us stoned by an angry mob of coders and testers. ;> I also hope, if there are any old ideas, either in some forgotten docs, or on the forum, about e.g. how saved civilians should affect happiness or what "soldiers" and "scientists" mean, they can emerge due to this thread...

Rei

  • Guest
Money: "Patch" included, but tester needed.
« Reply #9 on: August 09, 2006, 04:59:34 am »
That's a tough time for me to get on IRC -- I'm at work then  :P  This weekend would work.  I'm on now, if that counts   ;)

All great ideas; we should discuss them as a group.  I'm not so sure about the capitals idea; there are so many national capitals out there, and how we'd list them on a 800x600 default map... and what about, say, Russia, whose capital is a third of the way around the world from its east coast?

On the other hand, your ideas for replacing alienFriendly are all quite reasonable and workable.  Lets chat on IRC and see if that's what others want.  I didn't want to take out/coopt a variable that another person wanted to use to be happiness, so I added a new field and used alienFriendly to mean... well, how much they tolerate the aliens  :).

Offline Bandobras

  • Captain
  • *****
  • Posts: 586
    • View Profile
Money: "Patch" included, but tester needed.
« Reply #10 on: August 09, 2006, 11:01:14 am »
Quote from: "Rei"
I'm on now, if that counts   ;)


Cool. :)

Quote
I'm not so sure about the capitals idea


I meant only capitals of the few huge countries we have. Of course that will be a tough choice...

Quote
I didn't want to take out/coopt a variable that another person wanted to use


A valid point. I hope alienFriendly was to mean the overall happiness about you, together with happiness about aliens. I like that, this agrees with KISS, and I'm against too much parameters, so that player does not perceive the nation behaviour as a complete chaos. But let's make sure if anybody that put  alienFriendly in is still alive and remembers... :) I insist on replacing an existing variable, because with the same number of fields we are safe agains byte-size difference errors. I'm paranoid, I know, but a month of fixing UFO:AI bugs makes this  to oneself. :)

Offline Bandobras

  • Captain
  • *****
  • Posts: 586
    • View Profile
Money: "Patch" included, but tester needed.
« Reply #11 on: August 10, 2006, 01:46:33 pm »
Some nitpicking, as I go throught the patch:

client/cl_basemanagement.c:

Code: [Select]
+        baseCurrent = &(gd.bases[i]);

I can't see where it's needed. BTW, I will try, when the code is stable again, to remove baseCurrent as often as possible.

Code: [Select]
             if (newBuilding)
+ {
  /*update the building-list */
  B_BuildingInit();
+ }


The maintainer is very serious about the coding guidlines (see the wiki). This formatting is illegal. :)

cl_campaign.c:

I've included (with some formatting changed), but disabled, most of the cl_campaign.c changed code, so that you can revert to pure SVN trunk, when I'm done with the patches, if you wish (but please upload diff of base/ufos/ first!). When you are done discussing it, it'll be easy to use the disabled code (and your src/ patch) to make the final version.

po/:

Wow, what is Isomer Emission Power, Supermagnets, Plasma Explosives, Plasma Supermagnets, Tachyon Device,
Tachyon Physics, etc., etc.? If you want my advice, such things are better to write down and discuss on the wiki talk pages about techs or weapons... BTW, you have lots of fuzzy messages in en.po and most of your patch are the other pos. I'd make svn revert -R src/po, after moving en.po somewhere safe, if you made any changes by hand to it...

I can't see the weapon scripts in the diff. I guess they are in the tarfile? No, not there. Did you make svn diff on the src/ level, instead of the toplevel? Could I have svn diff in base/ this time? ;P

Rei

  • Guest
Money: "Patch" included, but tester needed.
« Reply #12 on: August 10, 2006, 06:14:49 pm »
Quote

+           baseCurrent = &(gd.bases);
 
 I can't see where it's needed. BTW, I will try, when the code is stable again, to remove baseCurrent as often as possible.


Yes, an example of many patches merging together because I can't commit and it's taking so long to manually add in what I've done  :P  This fixed a crash I was getting in which baseCurrent was null but the game was trying to access a member variable.

Quote

      if (newBuilding)
 +   {
        /*update the building-list */
        B_BuildingInit();
 +   }

 The maintainer is very serious about the coding guidlines (see the wiki). This formatting is illegal.  


I just checked the coding guidelines, and I don't see what you're talking about.  It says "Always use braces in if-else blocks."  It describes having "one line" without brackets as "Okay", but the more lines you do without brackets, the worse it is.  It also doesn't discuss bracket placement.  Is the wiki page misleading?
 
Quote
I've included (with some formatting changed), but disabled, most of the cl_campaign.c changed code, so that you can revert to pure SVN trunk, when I'm done with the patches, if you wish (but please upload diff of base/ufos/ first!). When you are done discussing it, it'll be easy to use the disabled code (and your src/ patch) to make the final version.


So it's committed, right now?
 
Quote
Wow, what is Isomer Emission Power, Supermagnets, Plasma Explosives, Plasma Supermagnets, Tachyon Device,
 Tachyon Physics, etc., etc.? If you want my advice, such things are better to write down and discuss on the wiki talk pages about techs or weapons... BTW, you have lots of fuzzy messages in en.po and most of your patch are the other pos. I'd make svn revert -R src/po, after moving en.po somewhere safe, if you made any changes by hand to it...


Something I've been toying around with that, like everything else, all got merged into one big patch  :P.  This was something that  I expected would be controversial and might not get included, but I wanted to have a working version of before I proposed it.  The current tech tree has *v ery* few "intermediary research steps" -- one on lasers, one on "ufo tech", etc.  I think there are only four or five; the rest are all research on specific objects.

 I wanted to try flushing it out and adding realism at the same time.  For example, in reality, there are two things that would be needed for an effective handheld plasma weapon that we don't have: small, extremely intense axial magnetic fields and an extremely high power density power source.  Currently, the problem is not in our understanding of plasma -- just the limitations on creating and accelerating it.  You'd basically have a tiny magnetoplasma thruster on steroids.  

Of course, those technologies have applications elsewhere.  A halbach array of crazy-powerful magnets (say, millions of gauss) could get you enough repulsion off of earth's magfield to hover -- say, Phoenix.  Incredibly dense power supplies (for example, stimulated hafnium isomer decay with gammavoltaics) could provide a vehicle with enough power to, say, develop a shield when combined with a shield-generating tech.

Not only do I include such techs, but I've been attempting to give them realistic descriptions of how they work.  For example, hafnium isomer decay is stimulated by a boson condensate laser (we already have atom lasers that fire coherent atom beams instead of photon beams; such a condensate laser would fire Bose-Einstein condensates, which are supercooled structures that act like massive atoms).  This method plays off the real, proposed (and disproven) method for stimulating such decay with X-rays (and the primary weakness in that proposal: lack of interaction of X-rays with the nucleus).  

Anyways, it's something I'm toying with, but not something that I expect to see included soon.  But, because of the diffs, everything got merged in at once to the same patch.  :P

Quote
I can't see the weapon scripts in the diff. I guess they are in the tarfile? No, not there. Did you make svn diff on the src/ level, instead of the toplevel? Could I have svn diff in base/ this time? ;P


Whoops!  My bad.  I'll get that up today.

Rei

  • Guest
Money: "Patch" included, but tester needed.
« Reply #13 on: August 10, 2006, 06:22:14 pm »
UPDATE: New patch uploaded, this time made from trunk instead of trunk/src.

Rei

  • Guest
Money: "Patch" included, but tester needed.
« Reply #14 on: August 10, 2006, 11:34:33 pm »
Ah, I just figured out where it says how to do the braces: it doesn't, but it says "Use K&R style of coding (what, you DON'T own a copy?)".

Well, no, I don't.  Nor do I traditionally code in that style A) at home on personal projects, B) in other community projects I've worked on, C) at work, and nor did I back in D) college.  

I actually had to look it up to see what it entails.  It's apparently that style that was invented to save printing space in books and save lines on 24-line terminals, sacrificing readability as a consequence by not having the braces line up in pairs.

That said, while I dislike K&R from a stylistic standpoint, if it's your standard, it's obviously what I'll use.  :)  I'll actually probably just use the suggested "indent" command in the future to take care of it for me.

Oh, also, how do we get a review of the code going so that it can be enabled and I can move on to other projects?  At such a time, could we get discussion of what effect killed civilians and surviving aliens should have on country pay so I can code that?  Is there a time when this discussion can happen, or should I randomly check into IRC every day and hope that enough people will be there to discuss it?