You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(14) |
Oct
(8) |
Nov
(14) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(3) |
Jun
(59) |
Jul
(56) |
Aug
|
Sep
|
Oct
(10) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
(2) |
Mar
(11) |
Apr
(10) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(4) |
Dec
(2) |
2013 |
Jan
(3) |
Feb
(9) |
Mar
(8) |
Apr
(13) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Benoit B. <ben...@gm...> - 2013-07-28 21:11:40
|
Hello, I'm sorry to hear this news. I did not want to hurt your feelings by rewriting some of your code but I understand. It's true that we have a different view of implementation. I believe that although speed is important, code must be understandable by all and if it is too complex to understand, modifying it can be difficult. Every time I modified some of your code, it was only because I needed to add a feature that, in my opinion, would be too difficult to implement in the existing code.Some code is very long and lack some comments, so understanding it is very difficult. I admit it can be taken as rudeness but in no way it was made to feel you dumb. Benoit |
From: Bohdan S. <cha...@ma...> - 2013-07-27 20:08:14
|
Hi All, Freesynd was a good hobby and as every hobby it should give pleasure. Now due to difference in style of programming between me and Benoit and his continuos "perfectioning" of my code I feel dumb and angry. Commit # 924, where a code is written to kill selected agents - previous implementation was simultaniuos and now it is not, agents without mod >= 2 will not drop weapons as they will die before in explosion. Also removal from handleDamage setting is_ignored_=true I don't like at all, range checking should deal with only objects that are permitted to be checked, this removal leads to checking 2 variables instead of 1 which is exactly what I avoided by setting that var. Even though code is smaller but actual execution is longer, as code "to execute" from less became more and I am always trying to avoid this as speed of execution is very important for me. Thank you all. -- Bohdan Stelmakh (chamel) |
From: Bohdan S. <cha...@ma...> - 2013-07-27 18:26:24
|
Hello, Package http://anonscm.debian.org/viewvc/pkg-games/packages/trunk/freesynd/debian/ . Music already removed, don't add it. Yes, original files are holding back freesynd from greater adoption. Still it is an engine and not even at level of original. It is not possible to make it work without original data. -- Bohdan Stelmakh (chamel) |
From: Markus K. <ap...@ga...> - 2013-07-26 12:14:27
|
Hi all, I'm a member of the Debian Games Team and I'm interested in packaging your game for Debian. Although the game isn't finished yet, it looks very promising and I'd be very glad about having one of the greatest games of all time included in Debian and its derivatives. I have successfully built freesynd, there are only two points I'm concerned about. 1. The music Obviously the music files belong to the original Syndicate game but they are encoded in a modern .ogg format. I assume you are not the copyright holders of those files thus I need to remove them if I want to package freesynd for Debian. However if you would split those files in a separate freesynd-music.tar.xz tarball, I could write a plugin for Debian's game-data-packager [1], an installer for game data files which can't be included in Debian because of license restrictions. 2. Contrib vs. Main I would love to see freesynd in Debian main. In its current state the game is only suitable for Debian contrib because the engine is free software but it is lacking free game data. I understand that your main goal is to produce a free software clone of the original Syndicate game using all the original data files. Unfortunately those data files are non-free and can't be really endorsed in any Linux distribution. However if you could create a demo, one single level, or some kind of usable show-case for your game with free game data, it would be possible to include the game in Debian main where it will receive much more attention by fellow developers and users. I sincerely hope you will continue to work on freesynd in the future, it is a great project. Cheers, Markus [1] http://packages.qa.debian.org/g/game-data-packager.html |
From: Bohdan S. <cha...@ma...> - 2013-07-19 14:26:20
|
> About collision detection, are you talking about vehicle collision? I > thought it was clear enough : what should I explain more? The collision detection needs to be present in two different pathfindings, in pre-calculated "precise" and directional. For pre-calculated it is possible to disable tiles where object is located, but problem is vehicles are not same in size and they span few tiles, this will be not natural if we will block all tile instead of making part of it non-walkable. As this pathfinding is fully tile oriented we will still have peds walking through vehicles. We can drop tile oriented movement and use walkable - "surface" created by this algorithm to be able to walk in real-time and avoid obstacles within that surface, still blocking of "main" objects tiles will be necessary. But as objects will change their "main" tiles and those tiles are on our surface it will need to be recalculated again and this will "eat" cpu and who knows whether such algorithm will be fast enough to be used even though collision detection should be high. In few words 50-60% rewrite. Directional pathfinding is not tile based and it can be modified to avoid non-moving vehicle. It already avoids full tiles, add checking for object on route and avoid it. An additional check is needed to make peds avoid(wait) to move to tile they are about to move if vehicle is moving there or moving vehicle is located there, as it happens on crossroads. Also there are other static objects: trash bin, phone booth, mail box, trees, (doors?). Should we avoid them too? In original agents always ignored vehicles on route as result was hit. Vehicles driven by non-agents stopped when someone was on road, but only if object was on some distance from vehicle else was hit, there are missions where guards are driving should be investigated how they behave when peds or our agents are on their way. If vehicle is parked on sidewalk all peds go through it. It had no pre-calculated "precise" pathfinding. How advanced collision detection, avoidance overal should be? If we go full above what needs to be done, if we go "as in original" there is not much to code, but just to code, as there is a mechanism for blocking ped to walk on specified tile or wait to walk on it. > For the icon, a poll would be a good idea. Hoping people will vote... We will know how much people do actually believe in freesynd. I wanted a cyborg for icon :(. > For the music, I already thought about using Dosbox a long time ago. I > looked at their code and it was rather complex so I forgot about it. > I think the best thing to do right now is maybe asked the dosbox team for > help. I already asked them a year or so ago to point me: dbopl.cpp and opl.cpp are the 2 versions of the opl emulation - virtual devices. > for the download rate, I think it's fair. the project has been running for > a long time, there's not many news/releases and it lacks the most : enemy > AI as you said. Discussion of enemy Ai always goes into void. > I believe 2 things can boost it: > - finishing AI (and maybe one or two important things like music) By refering to download rates I meant, less downloads - less possible new dev will appear and will help us. if we will finish ai users will be downloading more, but then will be small need for devs :) > - adding an editor : this could bring new players who could create new > missions. I was looking at http://sourceforge.net/projects/opendungeons/ yesterday. This project has content creators but has no devs. Our problem is almost same. No, that want help. > Finally, maybe we could post something on the forum to ask users to give us > their opinion on what they feel about the game, what should we work on. Indeed, we have forum. It is not listed on website :(. Fixed. Also updated roadmap to link to wiki. Ok, ask. -- Bohdan Stelmakh (chamel) |
From: Benoit B. <ben...@gm...> - 2013-07-18 12:53:11
|
Hi, About the train feature, I will work on it. But as I don't have a lot of time right now, it will take me a few weeks (2-3 I think). About collision detection, are you talking about vehicle collision? I thought it was clear enough : what should I explain more? For the icon, a poll would be a good idea. Hoping people will vote... For the music, I already thought about using Dosbox a long time ago. I looked at their code and it was rather complex so I forgot about it. I think the best thing to do right now is maybe asked the dosbox team for help. for the download rate, I think it's fair. the project has been running for a long time, there's not many news/releases and it lacks the most : enemy AI as you said. I believe 2 things can boost it: - finishing AI (and maybe one or two important things like music) - adding an editor : this could bring new players who could create new missions. Finally, maybe we could post something on the forum to ask users to give us their opinion on what they feel about the game, what should we work on. Benoit |
From: Bohdan S. <cha...@ma...> - 2013-07-18 11:54:03
|
Hi, In our roadmap trains are added as a task for you, Benoit, it is under your name, am I right? If it is so, can you take care of all vehicles and all related stuff? Also about a missing feature - collision detection, please explain it more. Should we do full collision detection or like in original? For this release I did almost all what was in my list, I have to test persuaded behavior and complete testing remaining maps. About our icon, it will not be correct if we will choose it, we should make a poll and let users choose. What do you think? One more thing, the music and ogg files, even though we have no currently solution for correct playback of xmi files, we should take care of it sooner or later. The original "engine" for playback is open source http://www.thegleam.com/ke5fx/misc/AIL2.ZIP which is good, but it is mostly in assembler. My idea is to use virtual midi synth device from DosBox and glue it with "engine" to make library for playback of xmi files. I know that this is technically hard thing, but it probably should be working. There is only one big problem with my idea - who should do this. Also we haven't discussed how enemy Ai should work. We have a very low download rate, I assume that there will no one capable enough to join project, because easiest stuff we already did and only the hardest left. Before release of 1.0 we will probably have 8-12 patches recieved and 4-5 bug reports and I'm optimistic with those numbers, because it can be worth. Seems like closer we get to 1.0 less people are actually interested in project. -- Bohdan Stelmakh (chamel) |
From: Bohdan S. <cha...@ma...> - 2013-04-19 17:11:11
|
Hello, > I was looking at the Mongolia mission : it's really slow on my computer in > debug mode (I didn't check in release mode). Do you have the same problem. I have decreased CPU drain, it should affect all missions. > Among other things, I think we could raise the agent speed. I find them a > little slow. The scrolling speed may need speed also. Problem is in stims implementation, maximum speed for agents with legs+arms v3 446 without stims calculations. The multiplier returned from stims is usually slightly larger then 1, making speed depend on >>all<< amount of injected substance, when white marker will be at lefmost position and you will set adrenaline to maximum it will increase speed x2. If white marker will be at rightmost position and use set to leftmost decrease in speed will be x2. In original it was not dependent on amount it was simplier: to right boost x2, left decrease x2. Amount based is more natural, but it was not in original. We can add some #if and make second implementation like it was in original. > About agents auto firing. Is it something that we keep? It's different from > the original game where the player had to shoot himself. No, we won't keep it, it will be availiable with perception+inteligence boosted or whatever it depends on. Do you think I should add check for any IPA now? > I noticed that agents could fire from inside a car. Do we keep that also? Yes definetely. Not only agents, everyone can. In original only our agents are able to shoot from vehicle: in original, use in first mission vehicle with agent ipas boosted and gun selecte and drive near guy with uzi. -- Bohdan Stelmakh (chamel) |
From: Benoit B. <ben...@gm...> - 2013-04-19 07:21:52
|
Hi, I was looking at the Mongolia mission : it's really slow on my computer in debug mode (I didn't check in release mode). Do you have the same problem. Among other things, I think we could raise the agent speed. I find them a little slow. The scrolling speed may need speed also. About agents auto firing. Is it something that we keep? It's different from the original game where the player had to shoot himself. I noticed that agents could fire from inside a car. Do we keep that also? Benoit 2013/4/16 Bohdan Stelmakh <cha...@ma...> > Hello, > > > It's a good idea. Have you already started to evaluate the missions? > No. > > > We can split the list of missions in two if you want? > Ok. > > > About enemy intelligence, the problem is mainly that we don't know what > > data in game files are used for it. > Partially we know the "scenrios" define programmed behavior, like walk to > position or get into car. Mostly in freesynd were enemy agents are not > moving, > in original they were running to our agents at beginning of mission, that's > all inteligence that was present in original, but there is at least one > mission > were enemy agents should not run and stand (iran evacuation location) they > are > really heavy armed(lasers + miniguns) if they will run with "wave" of other > agents it will be imposible to complete. We can find difference between > agents that should run and those that should stand there. > > > What can we do? Work on those data to figure out how they could be used > or > > add extended files to each mission to define what we want? > I always wanted mission editor as it would permit extending freesynd after > 1.0, but it is too much for two of us. That is why let's find out were that > data might be. > > > What do you mean by "adding old behavior would be enough"? > Will repeat to clarify : enemy agents run to our agents at start of > mission. > > In original enemy agents can do 3 things: > - whatever defined by "scenarios"(ex. Central Europe); > - stand; > - run to our agents (in most cases they just do this). > And they shoot when they see our agents. > > > -- > Bohdan Stelmakh (chamel) > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Freesynd-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freesynd-devel > |
From: Bohdan S. <cha...@ma...> - 2013-04-16 16:16:16
|
Hello, > It's a good idea. Have you already started to evaluate the missions? No. > We can split the list of missions in two if you want? Ok. > About enemy intelligence, the problem is mainly that we don't know what > data in game files are used for it. Partially we know the "scenrios" define programmed behavior, like walk to position or get into car. Mostly in freesynd were enemy agents are not moving, in original they were running to our agents at beginning of mission, that's all inteligence that was present in original, but there is at least one mission were enemy agents should not run and stand (iran evacuation location) they are really heavy armed(lasers + miniguns) if they will run with "wave" of other agents it will be imposible to complete. We can find difference between agents that should run and those that should stand there. > What can we do? Work on those data to figure out how they could be used or > add extended files to each mission to define what we want? I always wanted mission editor as it would permit extending freesynd after 1.0, but it is too much for two of us. That is why let's find out were that data might be. > What do you mean by "adding old behavior would be enough"? Will repeat to clarify : enemy agents run to our agents at start of mission. In original enemy agents can do 3 things: - whatever defined by "scenarios"(ex. Central Europe); - stand; - run to our agents (in most cases they just do this). And they shoot when they see our agents. -- Bohdan Stelmakh (chamel) |
From: Benoit B. <ben...@gm...> - 2013-04-15 07:54:23
|
Hi, It's a good idea. Have you already started to evaluate the missions? We can split the list of missions in two if you want? About enemy intelligence, the problem is mainly that we don't know what data in game files are used for it. What can we do? Work on those data to figure out how they could be used or add extended files to each mission to define what we want? Because, I don't think you can hard code all enemy behaviour mission by mission. We will need some infos from each mission. What do you mean by "adding old behavior would be enough"? Benoit 2013/4/9 Bohdan Stelmakh <cha...@ma...> > Hi, > > I really don't like this part in development, but we need it. Let's add > what > is required for 0.7.5. > > My idea is to make all missions on Eurasia continent to be > completable(14) and > maybe Indonesia + Australia continent(+4), and playable. What needs to be > done > there - is unknown, we need to play them :). For this we can create list of > those maps and evaluate them in roadmap in 1-10 points of completeness. > > One common thing is enemy agents are not running to our agents, to be shot > at the very beginning of mission - its boring that's why I haven't added > it. > I really don't know how to make this to be fun, but maybe adding old > behavior > would be enough? > > -- > Bohdan Stelmakh (chamel) > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Freesynd-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freesynd-devel > |
From: Bohdan S. <cha...@ma...> - 2013-04-09 16:43:07
|
Hi, I really don't like this part in development, but we need it. Let's add what is required for 0.7.5. My idea is to make all missions on Eurasia continent to be completable(14) and maybe Indonesia + Australia continent(+4), and playable. What needs to be done there - is unknown, we need to play them :). For this we can create list of those maps and evaluate them in roadmap in 1-10 points of completeness. One common thing is enemy agents are not running to our agents, to be shot at the very beginning of mission - its boring that's why I haven't added it. I really don't know how to make this to be fun, but maybe adding old behavior would be enough? -- Bohdan Stelmakh (chamel) |
From: Benoit B. <ben...@gm...> - 2013-04-09 07:54:05
|
Hi, How to check whether weapon is researched or not from all game weapons? And the same for mods? Try the WeaponManager and ModManager. There are some methods to list available items. Have you tried creating documentation with doxygen for freesynd? How to do it? On windows, I use the GUI that comes with doxygen with the config file doxygen.conf which is in the src directory. Benoit 2013/4/4 Bohdan Stelmakh <cha...@ma...> > Hi, > > > I've created a Roadmap page on the wiki. Just need to fill it ;-) > For 0.8 - oh no, 0.7.5 will be better should be released within a year. > And we haven't done 0.7.1 yet, enemy agents should be armed. How to check > whether weapon is researched or not from all game weapons? And the same > for mods? > > > About the coding convention, in the naming section, we cannot have 2 > > different rules : camelcase or lowercase with underscore. > > Let's go for lowercase with underscore : it's already described in the > > google style. > Indeed camelCase are not good, and should be avoided, but I it is hard > for me to code in single style, for unknown reasons I name variables > in camelCase sometime, but in lower_case mostly and in some parts of code > lowercase short names because they are faster to type/read and are more > suitable there instead of lower_case or camelCase. I will rename those > camelCases to lower_cases when I see. > > > About the icon, I agree for the add on the news. Can you take care of it? > OK. > > Have you tried creating documentation with doxygen for freesynd? How to > do it? > > > -- > Bohdan Stelmakh (chamel) > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > Freesynd-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freesynd-devel > |
From: Benoit B. <ben...@gm...> - 2013-04-09 07:49:06
|
Hello, Windows release pushed. Benoit 2013/4/8 Benoit Blancard <ben...@gm...> > Hello, > > Ok, I'll make it tonight. > > Benoit > > > 2013/4/7 Bohdan Stelmakh <cha...@ma...> > >> I have added weapons to enemy agents. Tagged 0.7.1 and uploaded version >> for >> linux and set staging, 3 days to add win version. >> >> -- >> Bohdan Stelmakh (chamel) >> >> >> ------------------------------------------------------------------------------ >> Minimize network downtime and maximize team effectiveness. >> Reduce network management and security costs.Learn how to hire >> the most talented Cisco Certified professionals. Visit the >> Employer Resources Portal >> http://www.cisco.com/web/learning/employer_resources/index.html >> _______________________________________________ >> Freesynd-devel mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freesynd-devel >> > > |
From: Benoit B. <ben...@gm...> - 2013-04-08 16:04:28
|
Hello, Ok, I'll make it tonight. Benoit 2013/4/7 Bohdan Stelmakh <cha...@ma...> > I have added weapons to enemy agents. Tagged 0.7.1 and uploaded version > for > linux and set staging, 3 days to add win version. > > -- > Bohdan Stelmakh (chamel) > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > Freesynd-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freesynd-devel > |
From: Bohdan S. <cha...@ma...> - 2013-04-07 11:08:29
|
I have added weapons to enemy agents. Tagged 0.7.1 and uploaded version for linux and set staging, 3 days to add win version. -- Bohdan Stelmakh (chamel) |
From: Bohdan S. <cha...@ma...> - 2013-04-04 10:46:47
|
Hi, > I've created a Roadmap page on the wiki. Just need to fill it ;-) For 0.8 - oh no, 0.7.5 will be better should be released within a year. And we haven't done 0.7.1 yet, enemy agents should be armed. How to check whether weapon is researched or not from all game weapons? And the same for mods? > About the coding convention, in the naming section, we cannot have 2 > different rules : camelcase or lowercase with underscore. > Let's go for lowercase with underscore : it's already described in the > google style. Indeed camelCase are not good, and should be avoided, but I it is hard for me to code in single style, for unknown reasons I name variables in camelCase sometime, but in lower_case mostly and in some parts of code lowercase short names because they are faster to type/read and are more suitable there instead of lower_case or camelCase. I will rename those camelCases to lower_cases when I see. > About the icon, I agree for the add on the news. Can you take care of it? OK. Have you tried creating documentation with doxygen for freesynd? How to do it? -- Bohdan Stelmakh (chamel) |
From: Benoit B. <ben...@gm...> - 2013-04-04 08:22:18
|
Hi, I've created a Roadmap page on the wiki. Just need to fill it ;-) About the coding convention, in the naming section, we cannot have 2 different rules : camelcase or lowercase with underscore. Let's go for lowercase with underscore : it's already described in the google style. About the icon, I agree for the add on the news. Can you take care of it? Benoit 2013/4/2 Bohdan Stelmakh <cha...@ma...> > Hi, > > > What do you think of putting the todo list under the wiki? > It's good idea, still we will need to synchronise it with TODO in svn, > just before > every release should be enough. > > About gode style I have done some editting, what do you think? > > And back to Icon, we can post on our main page a news and ask someone > help us. > > -- > Bohdan Stelmakh (chamel) > > > ------------------------------------------------------------------------------ > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. Compete > for recognition, cash, and the chance to get your game on Steam. > $5K grand prize plus 10 genre and skill prizes. Submit your demo > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > _______________________________________________ > Freesynd-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freesynd-devel > |
From: Bohdan S. <cha...@ma...> - 2013-04-02 14:44:23
|
Hi, > What do you think of putting the todo list under the wiki? It's good idea, still we will need to synchronise it with TODO in svn, just before every release should be enough. About gode style I have done some editting, what do you think? And back to Icon, we can post on our main page a news and ask someone help us. -- Bohdan Stelmakh (chamel) |
From: Benoit B. <ben...@gm...> - 2013-04-02 08:32:00
|
Hi, About the TODO list, it's almost that. I agree that tasks should be more explicit about what need to be done. But I was thinking more about the functional side ie expressing features from the player point of view. Of course, you'll then have to explain how each feature should be done. That's what you did with the vehicle and statics examples. I agree it's a bit fastidious or fussy but I think it's a good way to express a roadmap. What do you think of putting the todo list under the wiki? About the radar, feel free to modify the code if you want. I found the code right there : https://banu.com/blog/7/drawing-circles/ I thought it was more simple than the commented code. Benoit 2013/3/30 Bohdan Stelmakh <cha...@ma...> > Hello, > > > Why making a 0.7.1? I'm not against it but do we have something that > worths > > a release? > No, nothing worth. > > > Or is it just that you want to accelerate the number of release (which is > > fine by me)? > Yes, I think we should release more often, making small improvements, > we have enough stuff to complete and to put there. > > > About the list of functionnalities, it's the other name for roadmap. > > The current todo list has tasks like "Correct identification of object > > types during mission load, includes vehicles, static objects". > > This may be something we have to do but it's a bit too specific. It > doesn't > > help in seeing what has to be done globally to finish the game. > > There should be something more like "implement trains animation" or > > "implement music variations". > As I understand you want those TODO's to be described by smaller things we > need > to add to complete them. In case of "Correct identification of object > > types during mission load, includes vehicles, static objects" needs to > be done: > vehicles - there are different types of them: the gray one - > people/agents drive > them, police cars, ambulance, military heavy vehicle, firefighters, > carbage collector, > train (it is multiple vehichles) should work as one - they need to have > defined: > their type in main_type_, health should be checked to know how much health > we > have per type, their animation should be defined and not loaded as we do > now, > there are destroyed vehicles in game from start, as I use states, they > should > have proper state set if destroyed, the attribute health is good but > states are > easier to check in bulk with one varible single check instead of different > variables > and multiple checks; > statics - I have added hack for advertisement boards to draw them, it > should be removed > and special attribute added to draw them at the end instead of that, > animated > widows are not animated at all need separate class and animation switching, > trash bin/phone booth should be desctrutable with proper animation. > It was long time since I last checked that, but mostly that is required > for > that small task :). > > > We could also look at the different missions. Is every mission playable? > > what need to be done in each mission so it can be played? > Indeed we should check all. Scenarios - the small scripting events are not > all identified, I haven't loaded all missions to do it, without them > missions > are not completable. As you can see from first mission, scenarios defined > there, > make guards "patrol" area, for some unknown reason original game was not > using > them and behavior in Freesynd and Syndicate is different from the start. > No not are playable, but 10-15 should be. > > > So first : what do we put in 0.7.1? > We can add weapons/mods to enemy agents, this will require us: > - to check whether weapon/mod researched; > - check if agent already has weapon/mod and if lower then top researched > remove > and add highest; > - we need to define which weapons we should give them and what is > priority, > we can for example give only bullet damage weapons + time bomb (when > availiable, > will give bomb in persuade/protect missions only?) and use ranks to value > it. > Why? - We have currently 3 missions completable and with gameplay similar > to > original: Western Europe, Scandinavia, Central Europe. Then goes Eastern > Europe, > here enemy agents should run to our agents to kill them, we haven't > discussed > how should it work, I don't like when they just run for our agents we need > only > stand and wait to kill them, althogh this mission is completable. And Urals > enemy agents are completely unarmed there and they too should run to our > agents > - killing enemy agents, when they don't run towards our agent is time > consuming, > it is needed to find where they are located, this mission is completable. > If > we add weapons Urals at least will have some chalenge, instead of killing > unarmed. > > P.S. I have modified commented circle drawing function and added licenses > reference > to it, it is working. The reasons behind your function is not drawing good > circle > are it might be: less precise and you have skipped drawing of 4 points > like in > cimgs function. Still we need to draw arc instead of circle when signal > point is not on > minimap as it is cpu consuming operation. We can find intersection between > circle > and square of minimap and draw required arc. Also radar radius expands > from 0 always, > we might set first value not to 0, when signal point is not on minimap, > and set > it to first possible point of intersection, - this will make radar to be > always > blinking inside of minimap instead of waiting till radius expands to reach > minimap. > > P.S.S. Where did you got your original circle drawing function from? It is > written in C > not C++, I have never seen in your code C-style of coding. I hope its > under some > acceptable license, non-GPL v3. > > -- > Bohdan Stelmakh (chamel) > > > ------------------------------------------------------------------------------ > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. Compete > for recognition, cash, and the chance to get your game on Steam. > $5K grand prize plus 10 genre and skill prizes. Submit your demo > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > _______________________________________________ > Freesynd-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freesynd-devel > |
From: Bohdan S. <cha...@ma...> - 2013-03-30 12:47:55
|
Hello, > Why making a 0.7.1? I'm not against it but do we have something that worths > a release? No, nothing worth. > Or is it just that you want to accelerate the number of release (which is > fine by me)? Yes, I think we should release more often, making small improvements, we have enough stuff to complete and to put there. > About the list of functionnalities, it's the other name for roadmap. > The current todo list has tasks like "Correct identification of object > types during mission load, includes vehicles, static objects". > This may be something we have to do but it's a bit too specific. It doesn't > help in seeing what has to be done globally to finish the game. > There should be something more like "implement trains animation" or > "implement music variations". As I understand you want those TODO's to be described by smaller things we need to add to complete them. In case of "Correct identification of object > types during mission load, includes vehicles, static objects" needs to be done: vehicles - there are different types of them: the gray one - people/agents drive them, police cars, ambulance, military heavy vehicle, firefighters, carbage collector, train (it is multiple vehichles) should work as one - they need to have defined: their type in main_type_, health should be checked to know how much health we have per type, their animation should be defined and not loaded as we do now, there are destroyed vehicles in game from start, as I use states, they should have proper state set if destroyed, the attribute health is good but states are easier to check in bulk with one varible single check instead of different variables and multiple checks; statics - I have added hack for advertisement boards to draw them, it should be removed and special attribute added to draw them at the end instead of that, animated widows are not animated at all need separate class and animation switching, trash bin/phone booth should be desctrutable with proper animation. It was long time since I last checked that, but mostly that is required for that small task :). > We could also look at the different missions. Is every mission playable? > what need to be done in each mission so it can be played? Indeed we should check all. Scenarios - the small scripting events are not all identified, I haven't loaded all missions to do it, without them missions are not completable. As you can see from first mission, scenarios defined there, make guards "patrol" area, for some unknown reason original game was not using them and behavior in Freesynd and Syndicate is different from the start. No not are playable, but 10-15 should be. > So first : what do we put in 0.7.1? We can add weapons/mods to enemy agents, this will require us: - to check whether weapon/mod researched; - check if agent already has weapon/mod and if lower then top researched remove and add highest; - we need to define which weapons we should give them and what is priority, we can for example give only bullet damage weapons + time bomb (when availiable, will give bomb in persuade/protect missions only?) and use ranks to value it. Why? - We have currently 3 missions completable and with gameplay similar to original: Western Europe, Scandinavia, Central Europe. Then goes Eastern Europe, here enemy agents should run to our agents to kill them, we haven't discussed how should it work, I don't like when they just run for our agents we need only stand and wait to kill them, althogh this mission is completable. And Urals enemy agents are completely unarmed there and they too should run to our agents - killing enemy agents, when they don't run towards our agent is time consuming, it is needed to find where they are located, this mission is completable. If we add weapons Urals at least will have some chalenge, instead of killing unarmed. P.S. I have modified commented circle drawing function and added licenses reference to it, it is working. The reasons behind your function is not drawing good circle are it might be: less precise and you have skipped drawing of 4 points like in cimgs function. Still we need to draw arc instead of circle when signal point is not on minimap as it is cpu consuming operation. We can find intersection between circle and square of minimap and draw required arc. Also radar radius expands from 0 always, we might set first value not to 0, when signal point is not on minimap, and set it to first possible point of intersection, - this will make radar to be always blinking inside of minimap instead of waiting till radius expands to reach minimap. P.S.S. Where did you got your original circle drawing function from? It is written in C not C++, I have never seen in your code C-style of coding. I hope its under some acceptable license, non-GPL v3. -- Bohdan Stelmakh (chamel) |
From: Benoit B. <ben...@gm...> - 2013-03-29 20:36:14
|
Hi, Why making a 0.7.1? I'm not against it but do we have something that worths a release? Or is it just that you want to accelerate the number of release (which is fine by me)? About the list of functionnalities, it's the other name for roadmap. The current todo list has tasks like "Correct identification of object types during mission load, includes vehicles, static objects". This may be something we have to do but it's a bit too specific. It doesn't help in seeing what has to be done globally to finish the game. There should be something more like "implement trains animation" or "implement music variations". We could also look at the different missions. Is every mission playable? what need to be done in each mission so it can be played? So first : what do we put in 0.7.1? Benoit 2013/3/29 Bohdan Stelmakh <cha...@ma...> > Hi, > > > Should we add an icon ? > > Isn't there already an icon? There's an icon directory in the trunk. I > > thought someone did the work a time ago, adding an icon for the different > > platforms (apple, unix and windows). > This icon is directly copied from syndicate's logo - very bad thing. We > need to > have our own. > > > I don't like that google code style > > guide promots short functions < 40 lines - I don't want to follow that > rule, > > I will continue to write funcions as large as I think they should be. > > Well, I can't force you if you don't want, it's a free world. But I do > > believe that shorter methods help in understanding the code specially if > > method calls are well organized and method names are well chosen. This > rule > > is commonly adopted now and you will see it in many code analysis tool. > For me, its harder to understand such code, as it needs jumping to see > what is under > function and then go to previous and then again start thinking about > function > I was looking at. I acknowledge that if I would be looking at code first > time > I would have basic idea what it does faster, but in order to know code > more deeply, > it would take more time then large function not broken into single use > functions, > due to jumping to look at those functions. Due to objective programming we > already > create single use(call) functions and now we should be splitting those > into smaller > chunks just to give someone ability of fast "first look" at code, but with > hard > "deep look" at code... It is common for me to see people smoking tobacco > based > products, should I start smoking?... > The complexity human is capable to understand is always dependent on its > size, > abilities and knowledge and will of person. > You think that you decrease size of code to understand, but have you > counted > lines, before and after shortening, of all code? > What about "abilities and knowledge and will of person", is there same > static > condition like "< 40 lines" for those, that will require us to base our > code > on it? Just consider this, no need to answer. > > Be realistic there are 2 of us and random contributers from time to time. > When > I'm not willing to implement something I review code, my, then yours, then > all. > Simplifying logic, removing old unused/never used(prototype code), > optimizing, > adding comments, completing, fix something, there is so much to do. > 0.7 was released after almost a year, 0.7.1 - April?, 0.7.? - when? I'm > not > enthusiastic about coding, as all simple stuff we have already written and > now > the hard part to code remains. If we will not be doing what is actually > needed the 1.0 will be released in 2020 or never. > > > Do we need a lot of changes to release 0.7.1? What needs to be done? I'm > > confused. > > To me, the only reason of a 0.7.1 release was that you wanted to finish > > something that you thought was not complete when we released 0.7 > ("Although > > we can release it now, I will continue improving directional pathfinding > > later."). Other than that, I don't see other important subjects that need > > to be released right now. > I have no idea how to improve dir. pathfinding for peds. I will probably > use > normal pathfinding there, as it can reach required location, but there is > a problem > with Z coordinate. > I thought we will fix style and fix some code, actually we didn't discuss > 0.7.1 > roadmap. > > > But I agree, we need to make a list of functionnalities that need to be > > implemented to finish the game. The current todo list is a bit too > > code-oriented. > Oh - no, not again. We discussed it in past and I don't remember good > results. > How without code we will have features? Or you are refering to, how > required > feature should work, how implement it? > > -- > Bohdan Stelmakh (chamel) > > > ------------------------------------------------------------------------------ > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. Compete > for recognition, cash, and the chance to get your game on Steam. > $5K grand prize plus 10 genre and skill prizes. Submit your demo > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > _______________________________________________ > Freesynd-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freesynd-devel > |
From: Bohdan S. <cha...@ma...> - 2013-03-29 17:04:28
|
Hi, > Should we add an icon ? > Isn't there already an icon? There's an icon directory in the trunk. I > thought someone did the work a time ago, adding an icon for the different > platforms (apple, unix and windows). This icon is directly copied from syndicate's logo - very bad thing. We need to have our own. > I don't like that google code style > guide promots short functions < 40 lines - I don't want to follow that rule, > I will continue to write funcions as large as I think they should be. > Well, I can't force you if you don't want, it's a free world. But I do > believe that shorter methods help in understanding the code specially if > method calls are well organized and method names are well chosen. This rule > is commonly adopted now and you will see it in many code analysis tool. For me, its harder to understand such code, as it needs jumping to see what is under function and then go to previous and then again start thinking about function I was looking at. I acknowledge that if I would be looking at code first time I would have basic idea what it does faster, but in order to know code more deeply, it would take more time then large function not broken into single use functions, due to jumping to look at those functions. Due to objective programming we already create single use(call) functions and now we should be splitting those into smaller chunks just to give someone ability of fast "first look" at code, but with hard "deep look" at code... It is common for me to see people smoking tobacco based products, should I start smoking?... The complexity human is capable to understand is always dependent on its size, abilities and knowledge and will of person. You think that you decrease size of code to understand, but have you counted lines, before and after shortening, of all code? What about "abilities and knowledge and will of person", is there same static condition like "< 40 lines" for those, that will require us to base our code on it? Just consider this, no need to answer. Be realistic there are 2 of us and random contributers from time to time. When I'm not willing to implement something I review code, my, then yours, then all. Simplifying logic, removing old unused/never used(prototype code), optimizing, adding comments, completing, fix something, there is so much to do. 0.7 was released after almost a year, 0.7.1 - April?, 0.7.? - when? I'm not enthusiastic about coding, as all simple stuff we have already written and now the hard part to code remains. If we will not be doing what is actually needed the 1.0 will be released in 2020 or never. > Do we need a lot of changes to release 0.7.1? What needs to be done? I'm > confused. > To me, the only reason of a 0.7.1 release was that you wanted to finish > something that you thought was not complete when we released 0.7 ("Although > we can release it now, I will continue improving directional pathfinding > later."). Other than that, I don't see other important subjects that need > to be released right now. I have no idea how to improve dir. pathfinding for peds. I will probably use normal pathfinding there, as it can reach required location, but there is a problem with Z coordinate. I thought we will fix style and fix some code, actually we didn't discuss 0.7.1 roadmap. > But I agree, we need to make a list of functionnalities that need to be > implemented to finish the game. The current todo list is a bit too > code-oriented. Oh - no, not again. We discussed it in past and I don't remember good results. How without code we will have features? Or you are refering to, how required feature should work, how implement it? -- Bohdan Stelmakh (chamel) |
From: Benoit B. <ben...@gm...> - 2013-03-28 08:58:08
|
Hi, Should we add an icon ? Isn't there already an icon? There's an icon directory in the trunk. I thought someone did the work a time ago, adding an icon for the different platforms (apple, unix and windows). We have agreed to make code have same code style, but still we haven't created clear example/doc of how it should be. I wanted to add a page on the wiki to list all code convention used on the project. My idea was to reference the google code style and write down all rules that were different because I'm not agree either with all their rules. I don't like that google code style guide promots short functions < 40 lines - I don't want to follow that rule, I will continue to write funcions as large as I think they should be. Well, I can't force you if you don't want, it's a free world. But I do believe that shorter methods help in understanding the code specially if method calls are well organized and method names are well chosen. This rule is commonly adopted now and you will see it in many code analysis tool. Do we need a lot of changes to release 0.7.1? What needs to be done? I'm confused. To me, the only reason of a 0.7.1 release was that you wanted to finish something that you thought was not complete when we released 0.7 ("Although we can release it now, I will continue improving directional pathfinding later."). Other than that, I don't see other important subjects that need to be released right now. But I agree, we need to make a list of functionnalities that need to be implemented to finish the game. The current todo list is a bit too code-oriented. Benoit |
From: Bohdan S. <cha...@ma...> - 2013-03-27 14:26:51
|
It's good the we develop code, but Freesynd as of latest code has no official icon for project. Should we add an icon ? For uknown reasons, KDevelop crashed all the time after upgrading. I have started developing in Qt Creator and it works, but it needs setting debug argument for cmake everytime. The good thing about Qt Creator as it has support for valgrind and I don't need to use another gui for testing. We have agreed to make code have same code style, but still we haven't created clear example/doc of how it should be. I don't like that google code style guide promots short functions < 40 lines - I don't want to follow that rule, I will continue to write funcions as large as I think they should be. Also after 2 attempts I have succesfully converted tabs to spaces. As I'm bad at refactoring, I have done some of TODO's around code. Do we need a lot of changes to release 0.7.1? What needs to be done? I'm confused. -- Bohdan Stelmakh (chamel) |