Season objective

Discussions about the internal structures of the game. You can also post here if you'd like to know how things really work (and don't know how to read C code).

Season objective

Postby GeoVah » Sun Dec 19, 2004 8:17 pm

In order to discover more and more bygfoot code,
I'be started to add season objective at bygfoot ( maybe objective is not the good word).
So I add objective struct which contains two integer, one for the objective type, one for extra data :
Code: Select all
struct _objective {
   gint type; /* The objective type */
   gint extradata; /* extradata for the objective */   
};
And
/**
 * Objective for current season
 */
enum
{
   OBJ_NONE =0, /**< no Objective */
   OBJ_WIN_CUP, /**< Win a cup, extra data contains cup ID */
   OBJ_PROMOTED, /**< Promoted */
   OBJ_POSITION, /**< Make better than a position, extra data contains position */
   OBJ_NO_RELEGATED, /**< Your team must not be relegated */
};
.

Each time you start the Week 3, new objective are compute.
At this point, I have only implemented simple objective:
I sort all team in current league with the average skill of the team (all player)
- question : how to retrieve how many player in current team, I see only a 20 player in struct team ?-.
After, I have a theoric position of the team so :
- if we are in position 1-3, objective is "to be promoted"
- in the last tree position, the objective is "not relegated"
In other case, it's a "position objective" with the position we compute..

What do you think about this ?

What need to be done : display correctly objective compute (at this stage, it display the text with show_popup_message), add info in save file, and compute a cup objective, check if the objective is ok or not at end?

Do i continue to work on it ?
Geovah - geovah@jabber.sk- (yes i'm french...)
GeoVah
 
Posts: 50
Joined: Sat Dec 18, 2004 10:38 am
Location: Sophia Antipolis - France

Re: Season objective

Postby gyboth » Sun Dec 19, 2004 9:22 pm

GeoVah wrote:In order to discover more and more bygfoot code,
I'be started to add season objective at bygfoot ( maybe objective is not the good word).

'objective' seems ok.

So I add objective struct which contains two integer, one for the objective type, one for extra data :
Code: Select all
struct _objective {
   gint type; /* The objective type */
   gint extradata; /* extradata for the objective */   
};
And
/**
 * Objective for current season
 */
enum
{
   OBJ_NONE =0, /**< no Objective */
   OBJ_WIN_CUP, /**< Win a cup, extra data contains cup ID */
   OBJ_PROMOTED, /**< Promoted */
   OBJ_POSITION, /**< Make better than a position, extra data contains position */
   OBJ_NO_RELEGATED, /**< Your team must not be relegated */
};
.

nice! i think this sounds like a very good idea :-)
Each time you start the Week 3, new objective are compute.

i'd say wait until week 6 or so. 3 is a bit too early to draw conclusions.
- question : how to retrieve how many player in current team, I see only a 20 player in struct team ?-.

there's a function 'players_in_team(void)' in 'player.c' that returns the players in the user's team (cpu teams always contain 20).
After, I have a theoric position of the team so :
- if we are in position 1-3, objective is "to be promoted"
- in the last tree position, the objective is "not relegated"
In other case, it's a "position objective" with the position we compute..

What do you think about this ?

i think it's a great idea.
Do i continue to work on it ?

well.. now that's the difficult question. i'm currently working on 1.9, which wouldn't be a problem normally. but 1.9 will be a rather newly written Bygfoot, because i'm applying all the glib-things (and other things) i've learned while doing versions 1.0 to 1.7. so new features in 1.7 will likely not be transferable to 1.9 easily :-(

and i've got to confess that only a little part of 1.9 is done; it'll take months to get a first version done. so others won't be able to work on it for a long time.

nevertheless i'd say you continue to work; this way we'll have some 1.7 releases to bide the user's time until 1.9 is out; and well, it won't be that much work to transfer things from 1.7 to 1.9 hopefully ;-).

gyözö
Press any key to continue or any other key to quit.
gyboth
Site Admin
 
Posts: 1421
Joined: Sat Dec 18, 2004 8:42 am
Location: Passau, Germany

Re: Season objective

Postby Guest » Sun Dec 19, 2004 10:03 pm

well.. now that's the difficult question. i'm currently working on 1.9, which wouldn't be a problem normally. but 1.9 will be a rather newly written Bygfoot, because i'm applying all the glib-things (and other things) i've learned while doing versions 1.0 to 1.7. so new features in 1.7 will likely not be transferable to 1.9 easily :-(

and i've got to confess that only a little part of 1.9 is done; it'll take months to get a first version done. so others won't be able to work on it for a long time.

nevertheless i'd say you continue to work; this way we'll have some 1.7 releases to bide the user's time until 1.9 is out; and well, it won't be that much work to transfer things from 1.7 to 1.9 hopefully ;-).

gyözö

How do you use SourceForge CVS ? I only see a bygfoot-unstable, I'm surprise there is no CVS tag ?
Can you explain glib-things or coding style to use ?
Guest
 

Re: Season objective

Postby gyboth » Mon Dec 20, 2004 7:16 am

Anonymous wrote:How do you use SourceForge CVS ? I only see a bygfoot-unstable, I'm surprise there is no CVS tag ?
Can you explain glib-things or coding style to use ?

guess that was you, geovah ? :-)

the cvs version is the current version i also have on my system. so it's the version that will lead to 1.7.4. the stable branch doesn't have a cvs version.

what's a cvs tag?

for the glib stuff, have a look here: http://developer.gnome.org/doc/API/2.0/glib/. most important are GArrays and GStrings (and of course the standard types like gint, gfloat etc.), and the glib xml parser. i'm going to use them because they allocate memory for themselves automatically which makes them comfortable and safe.

gyözö
Press any key to continue or any other key to quit.
gyboth
Site Admin
 
Posts: 1421
Joined: Sat Dec 18, 2004 8:42 am
Location: Passau, Germany

Re: Season objective

Postby GeoVah » Mon Dec 20, 2004 12:51 pm

gyboth wrote:
Anonymous wrote:How do you use SourceForge CVS ? I only see a bygfoot-unstable, I'm surprise there is no CVS tag ?
Can you explain glib-things or coding style to use ?

guess that was you, geovah ? :-)

Yes ...

gyboth wrote:the cvs version is the current version i also have on my system. so it's the version that will lead to 1.7.4. the stable branch doesn't have a cvs version.

what's a cvs tag?

It's only a label : you apply label/tag "1.7.4" when you deliver version "1.7.4" so after if you need to retrieve code use in 1.7.4 it's more easy, but unlike branch, you can't edit code.

Maybe you can create a branch for the 1.9 version ? Works can continue on 1.7.x and 1.9.x ?
Becayse I want to proposed you new "architecture" :-P for week action endling ..., and I think it's place is more in 1.9.x than 1.7.x.
Just for explain :
- have functions who work at week's end, all function have same prototype :
void weekAction(int weekNumber), and you have a weekAction pointer table who contains all functions to execute each week.
- Idea : you don't have to change code in gui or somewhere, just add a pointer into the table for week action.
- This weekAction function can do what she want : void weekAction_SeasonObjective(int week) {if (week==6) { createnewobjective;display;}}. So can add easily week action for event, for old player, for what you want...), and priority of action is in table order.
- The GUI only know the table of function to execute and parse/execute it.

gyboth wrote:for the glib stuff, have a look here: http://developer.gnome.org/doc/API/2.0/glib/. most important are GArrays and GStrings (and of course the standard types like gint, gfloat etc.), and the glib xml parser. i'm going to use them because they allocate memory for themselves automatically which makes them comfortable and safe.
gyözö


Thanks,I think it can help me due to i'm a beginner with glib/gnome
Geovah - geovah@jabber.sk- (yes i'm french...)
GeoVah
 
Posts: 50
Joined: Sat Dec 18, 2004 10:38 am
Location: Sophia Antipolis - France

Re: Season objective

Postby gyboth » Mon Dec 20, 2004 7:00 pm

what's a cvs tag?

It's only a label : you apply label/tag "1.7.4" when you deliver version "1.7.4" so after if you need to retrieve code use in 1.7.4 it's more easy, but unlike branch, you can't edit code.

hm.. that's still rather cryptic. what does it mean to 'apply the label "1.7.4"'?

Maybe you can create a branch for the 1.9 version ? Works can continue on 1.7.x and 1.9.x ?

that's not a bad idea. but i must say that 1.9 is still non-functional, not even the teams get generated. i'm currently working on the new country/league/cup xml file formats (with the glib xml parser).

- have functions who work at week's end, all function have same prototype :
void weekAction(int weekNumber), and you have a weekAction pointer table who contains all functions to execute each week.

i guess i don't get what you mean... :-? what kind of table would you like to have? could you maybe give a short example?

- Idea : you don't have to change code in gui or somewhere, just add a pointer into the table for week action.
- This weekAction function can do what she want : void weekAction_SeasonObjective(int week) {if (week==6) { createnewobjective;display;}}. So can add easily week action for event, for old player, for what you want...), and priority of action is in table order.
- The GUI only know the table of function to execute and parse/execute it.

sounds like reasonable structure... i just don't understand it ;-)

Thanks,I think it can help me due to i'm a beginner with glib/gnome

mostly the reference manual is enough to work with the functions... using glib functions and data types, you never have to work with memory allocation directly :-) which is wonderful, isn't it?

gyözö
Press any key to continue or any other key to quit.
gyboth
Site Admin
 
Posts: 1421
Joined: Sat Dec 18, 2004 8:42 am
Location: Passau, Germany

Re: Season objective

Postby GeoVah » Mon Dec 20, 2004 10:12 pm

gyboth wrote:
what's a cvs tag?

It's only a label : you apply label/tag "1.7.4" when you deliver version "1.7.4" so after if you need to retrieve code use in 1.7.4 it's more easy, but unlike branch, you can't edit code.

hm.. that's still rather cryptic. what does it mean to 'apply the label "1.7.4"'?

It's just a link for saying label "1.7.4" is for file toto.c revision 1.10, for file titi revision 1.11 which can help if you need to work on a special version.
If was just a question so forget...
gyboth wrote:
Maybe you can create a branch for the 1.9 version ? Works can continue on 1.7.x and 1.9.x ?

that's not a bad idea. but i must say that 1.9 is still non-functional, not even the teams get generated. i'm currently working on the new country/league/cup xml file formats (with the glib xml parser).

Yes, but it's the aim of tools such CVS ? give access on developping branch ?:-P
gyboth wrote:
- have functions who work at week's end, all function have same prototype :
void weekAction(int weekNumber), and you have a weekAction pointer table who contains all functions to execute each week.

i guess i don't get what you mean... :-? what kind of table would you like to have? could you maybe give a short example?

- Idea : you don't have to change code in gui or somewhere, just add a pointer into the table for week action.
- This weekAction function can do what she want : void weekAction_SeasonObjective(int week) {if (week==6) { createnewobjective;display;}}. So can add easily week action for event, for old player, for what you want...), and priority of action is in table order.
- The GUI only know the table of function to execute and parse/execute it.

sounds like reasonable structure... i just don't understand it ;-)


Yes, i don't explain very well :oops:
So this is a dummy example:

Code: Select all
in week.h :
void executeWeekAction(int week);

in week.c
//we use function hanlder
typedef void(*WeekActionHandler)(int week);

void weekAction_SeasonObjective(int week) {if (week==6) { createnewobjective;display;}}
void weekAction_oldPlayer(int week) {if(week==43) {....}}

WeekActionHandler weekActions[]={
weekAction_SeasonObjective,weekAction_oldPlayer,NULL};


void executeWeekAction(int week) {

WeekActionHandler * handler=WeekAction;
while(handler!=NULL) { (*handler)(week);handler++;}
}

And your GUI code, call executeWeekAction(..) before changing week.

So if you want to add one weekAction (for event, for what you want), you only need to add a pointer to weekActions table :
All week actions are in week.c you can reuse it/call it where you want.
Geovah - geovah@jabber.sk- (yes i'm french...)
GeoVah
 
Posts: 50
Joined: Sat Dec 18, 2004 10:38 am
Location: Sophia Antipolis - France

Re: Season objective

Postby gyboth » Tue Dec 21, 2004 11:20 am

GeoVah wrote:If was just a question so forget...

ah.. good. that's what i'll do then :-)
Maybe you can create a branch for the 1.9 version ? Works can continue on 1.7.x and 1.9.x ?

yes, that's what i'm gonna do. as soon as i'm done with doxygenizing the code.
Yes, i don't explain very well :oops:
So this is a dummy example:

Code: Select all
in week.h :
void executeWeekAction(int week);

in week.c
//we use function hanlder
typedef void(*WeekActionHandler)(int week);

void weekAction_SeasonObjective(int week) {if (week==6) { createnewobjective;display;}}
void weekAction_oldPlayer(int week) {if(week==43) {....}}

WeekActionHandler weekActions[]={
weekAction_SeasonObjective,weekAction_oldPlayer,NULL};


void executeWeekAction(int week) {

WeekActionHandler * handler=WeekAction;
while(handler!=NULL) { (*handler)(week);handler++;}
}

And your GUI code, call executeWeekAction(..) before changing week.

So if you want to add one weekAction (for event, for what you want), you only need to add a pointer to weekActions table :
All week actions are in week.c you can reuse it/call it where you want.

ah.. that's better. now i see what you mean. yes, this sounds reasonable. i'm going to follow your advice :-D

gyözö
Press any key to continue or any other key to quit.
gyboth
Site Admin
 
Posts: 1421
Joined: Sat Dec 18, 2004 8:42 am
Location: Passau, Germany

Postby vector » Wed Dec 22, 2004 3:57 am

This new coder(GeoVah) is great news and negates my uselessness (lack of "c" programming)So ill not try implementing anything myself(tried the finance wish and failed miserably)

What I can still do is beta test. so Either explain the best way for me to do this with either gyboth or GeoVah sending me code.

Remeber im running source and can test it on 3 different PC setups.
So what way do i get the new code so I can test it?

My last day at work here so coms will be patchy but Ill still be about in the next few weeks and have net at home.
"There are two ways to score. Dribble it over the line or smash it into the back of the net."
What type are you?
vector
 
Posts: 449
Joined: Sat Dec 18, 2004 11:26 pm
Location: Australia, Victoria

Postby GeoVah » Wed Dec 22, 2004 8:37 am

vector wrote:This new coder(GeoVah) is great news and negates my uselessness (lack of "c" programming)So ill not try implementing anything myself(tried the finance wish and failed miserably)


No !!!!! Continue and try :-).
If you need help and have some problem in "C" programming, help can come to you...

"C" code is not enough, Some good algorithm need to be create for finance, for old player, for young player, for lot of stuff... (I think Gyboth agree with this...)
Work on it, show you result in "english" code and try to implement this in C !!!.

Starts to make "C" code is not enough if you don't resolve your problem on paper.
Geovah - geovah@jabber.sk- (yes i'm french...)
GeoVah
 
Posts: 50
Joined: Sat Dec 18, 2004 10:38 am
Location: Sophia Antipolis - France

Postby gyboth » Wed Dec 22, 2004 5:05 pm

vector wrote:What I can still do is beta test. so Either explain the best way for me to do this with either gyboth or GeoVah sending me code.

i'm going to post the latest bygfoot-update script here soon. you'll be able to get the latest cvs version then, which will be best for beta testing. thank you for your offer :-) though i must say that fixing bugs in 1.7 and working on 1.9 might prove a bit much for me :-?

GeoVah wrote:
vector wrote:This new coder(GeoVah) is great news and negates my uselessness (lack of "c" programming)So ill not try implementing anything myself(tried the finance wish and failed miserably)

No !!!!! Continue and try :-).
If you need help and have some problem in "C" programming, help can come to you...
i couldn't agree more. though it might be better to start working on something simple. and of course you should figure out more or less how things work in the code, otherwise your new code is bound to have unwanted consequences.
"C" code is not enough, Some good algorithm need to be create for finance, for old player, for young player, for lot of stuff... (I think Gyboth agree with this...)
Work on it, show you result in "english" code and try to implement this in C !!!.
i do agree, sure, but it isn't this simple, unfortunately. first one has to know exactly what he wants to implement; second, one has to know the existing code to be able to make the new code fit in smoothly; and third, one has to be able to do it technically.

you'll have to sort out the first item yourself, vector ;-) but i'll answer any questions concerning the second and third ones; and i'm sure that geovah will help with them (notably with item three), too.

on the other hand, as you might have noticed reading some other posts, the code of 1.7 isn't very homogenous :roll: this is because i've been learning new (and better) techniques all the time while working on new versions. so there are parts in the code which are rather bad style and there are parts of breathtaking ingenuity :-D this is why i'm writing most of the code anew for 1.9, and this is also why it might prove a bad idea for you (vector, i mean) to tamper with the 1.7 code: you might learn some bad coding style from it or make bad parts even worse. but as 1.7 seems to evolve as a playground anyway, don't let me deter you :-) you're welcome to continue your efforts and you can count on my help.

gyözö
Press any key to continue or any other key to quit.
gyboth
Site Admin
 
Posts: 1421
Joined: Sat Dec 18, 2004 8:42 am
Location: Passau, Germany

Postby gyboth » Wed Dec 22, 2004 8:33 pm

vector wrote:What I can still do is beta test. so Either explain the best way for me to do this with either gyboth or GeoVah sending me code.

here's the link to the current bygfoot-update script. you can use it to download the cvs version (call it with the -b switch or choose the appropriate item in the tiny menu).

gyözö
Press any key to continue or any other key to quit.
gyboth
Site Admin
 
Posts: 1421
Joined: Sat Dec 18, 2004 8:42 am
Location: Passau, Germany

Postby vector » Wed Dec 22, 2004 9:19 pm

Yep I understand all the above and recognised that playing with code can upset the apple cart downstream so best to leave it alone. I do program in "c" on microcontrollers so I recognise the syntax. But micros dont use lots of arrays and in depth C (micros have very limited resources ie memory and program space) Its more of matter of turn this on if thats hot sorta thing.

Watching 1.9 is probably a better bet. ill go the link and see what i get.

BTW another worry for me was that looking at the code in certain parts I cant help but think it would be better off, smaller, in Python. Alot of it is text manipulation and allthough you are using Glib python really lends itself to this sort of work. as well as great partnership with GTK. However I am young at python too and we dont want to take a step back into "learning another language" so "c" it is.
Is there an online reference for the "flavour" of C and its dependants you are using?

Into the valley of C rode the 3 wise men..
"There are two ways to score. Dribble it over the line or smash it into the back of the net."
What type are you?
vector
 
Posts: 449
Joined: Sat Dec 18, 2004 11:26 pm
Location: Australia, Victoria

Postby gyboth » Wed Dec 22, 2004 11:39 pm

vector wrote:Yep I understand all the above and recognised that playing with code can upset the apple cart downstream so best to leave it alone.

that's not a problem as long as you test your code enough and correct the nastier bugs. but testing is really a time-swallowing task, i didn't test thoroughly myself for the last 2-3 development versions. fortunately there are people like you sending bug reports. (on the other hand i don't test a lot also because i don't like playing Bygfoot; i simply had enough of it; probably it wouldn't be so boring to for you to test some new feature thoroughly).

Watching 1.9 is probably a better bet. ill go the link and see what i get.

erm... 1.9 isn't in the cvs yet. you'll get the 1.7 branch currently. i'm going to put 1.9 into the cvs soon. but it won't help you much because basically i'm writing everything from scratch, so there isn't a lot to see yet; however, that might even be interesting for you to see how things evolve from the beginning.

BTW another worry for me was that looking at the code in certain parts I cant help but think it would be better off, smaller, in Python. Alot of it is text manipulation and allthough you are using Glib python really lends itself to this sort of work. as well as great partnership with GTK. However I am young at python too and we dont want to take a step back into "learning another language" so "c" it is.

i definitely won't learn a new programming languate within the next few years :roll: so better forget python ;-)

Is there an online reference for the "flavour" of C and its dependants you are using?

erm.. it's the simple ANSI C. as far as i know. the best reference for anyone who's not a complete newbie (which you aren't) are the linux manuals (provided you know what you're looking for). so if you'd like to know how strcpy works, you simply type man strcpy in a console; if there's also a shell function with the same name, like with free, you have to type man 3 free.

an exception are of course the GLib and GTK functions. those you find here (GLib) and here (GTK). and here's a tutorial for GTK 2.

gyözö
Press any key to continue or any other key to quit.
gyboth
Site Admin
 
Posts: 1421
Joined: Sat Dec 18, 2004 8:42 am
Location: Passau, Germany

Postby vector » Thu Dec 23, 2004 11:25 am

I downloaded the bygfoot-update ontop of the current ver 5.0 that i had.
ran it with ./bygfoot-update -b
recieved this error but it seem to get the files afterwards ok

cvs checkout: warning: failed to open /home/mark/.cvspass for reading: No such file or directory

I then make all-recursive
then make install(as root)
renamed .bygfoot
and ran bygfoot.

im just not sure how to check if anything has changed?
Its coming up as 1.7.3 as expected.
but after looking thru various files I couldnt find a 'whats changed"
ChangeLog was still 11/23/2004: v1.7.3

In my code I have a little file called ver.c which is generally a bunch of notes I write to myself.
1) to remind me of what im working on
2) to use as a history when someone says ver 3.4 worked but 3.6 didnt. I check my ver (which has even the slightest changes noted) and realise that in 3.5 I did such n such which has made an effect elswhere.

Do you have such a file?

Please excuse me as I get up to speed and we produce a system that I can target testing and report on changes.
"There are two ways to score. Dribble it over the line or smash it into the back of the net."
What type are you?
vector
 
Posts: 449
Joined: Sat Dec 18, 2004 11:26 pm
Location: Australia, Victoria

Next

Return to Code discussions

Who is online

Users browsing this forum: No registered users and 1 guest

cron