Menu
▾
▴
Re: [Speed-dreams-devel] Moving forward from Beta1
|
From: kilo a. G. K. <kg...@gm...> - 2011-10-29 09:10:16
|
Hi Wolf-Dieter, short questions: 1) If I delete the. tkk. tkr. tkl files from my home SD config folder, do your robots work fine? 2) Do we ship these files in a downloadable version? 3) Is there any parameter you have to change in the shipping config XML files to make them accommodate to the changed finish straight of Karwada? BTW the more I think about it the more I think we are heading an incredibly confusing system if we go the modular race engine way... cheers kilo On Oct 29, 2011 10:39 AM, "Wolf-Dieter Beelitz" <wd...@wd...> wrote: > Hello Simon, > > > If I was a tuner I would not test these 'stupid' combinations. > So do I, but again it is my subjective decision what track and what car is > to be tested and some of our customers will think different here. And > another thing is, why do we have so much of these stupid tracks > (speedways)? > > > Perhaps some test mode where the position of the cars was randomised > > around the track and a race could be started 'part way done'. Test a few > > laps just to confirm 'normal' behaviour. > If a robot uses learning (and even only the brake calibration), it is not > possible to shorten this process and get a similar result. The robots are > not used in the stable range but at the limits to get faster opponents. > Driving the car at the limit means to use the increasing drivable speed > resulting from the decreasing fuel as well. Therefore testing is time > consuming. > > What can be used is to let the robots race over night and have a look to > the > results. If you know the lap times the robots should reach, this helps to > find critical combinations, but changes to basic parameters can destroy > theses references, and you cannot use the historic data to shrink the > really > watched training. > > > The Beta (in my mind) is a feature freeze > Correct, this was decided long ago. > > > now we have to make it work properly as we move to RC1. > And yes, that is the target, bug fixing, no new features or new basic > parameters. > > > Note this discussion started with 'stick grass', however a change to the > > body shape/boundary or even spring stiffness could also throw off the > > ability of a robot to drive a car. > To be honest, the discussion was started because a well known, long time > used, published track was changed (unintentionally). And instead of fixing > the bug as fast as possible we discuss about changing the rest of the game. > But in fact we did not decide in a democratic way that we want to change > the > track at all. So this is why I cannot understand the process here. Instead > of working in the natural order (Do we want to change it? If not fix the > local texture changed and use the old parameters or if yes, what has to be > prepared to make it happen without issues. Make a plan, work and use the > new > features to get the wanted result) we discuss about effort of robot > testing. > > I assume that we all have the same view here, the current robots need too > much work for tuning the setups. We should work on better robots. This is > work in progress but what we know already is, that we will need changes to > the race engine to allow such robots to handle the learning in an automatic > mode. We do not want a unique SD robot (as TORCS having as target to have > only one robot to reduce work load), because this results in stupid races. > To get a different behavior we want to have different robots. This means > the > robots will have different skills to learn, means they will have different > requirements while learning. The work on better robots is something for > years, but the release cycle should be shorter (as planned in the past). > Therefore we have to make the race engine be a module (as the simulation) > and allow to select the wanted to customers/developers. This way we can > work > in parallel, keep the game playable over new releases as well but still are > able to rework things in the new race engine if we learn more about the > needed skills here. > > Instead of working on the ideas for this next release features we discuss > about more realistic textures for the sides of a track. Remember, this > change was made unintentionally! > > > > that is not practical in a open project running on SVN. You can only take > > the landmark releases (ie. 1.4 and 2.0). > It is not practicable to start always at zero, we have to start at the top > of the last release, not at the bottom. Means a track published in a > release > will not be changed in the parameters later. If wanted, the artwork can be > reworked, but nothing else. Same for cars. A car published in a release > should not get changes to the relevant parameters in a next release. > Creating a new simulation as a selectable module means to create new setups > for all the cars, but is does not mean, that we have to destroy the old > setups. This is, what is going wrong here. Not the target is wrong, but the > way we work on make it happen. We have to make the cars/robots know about > different versions of setups for different versions of simulation modules. > This way, all are happy, the new customers and the old. AND we do have much > less work load. We can have both here! And it is realistic as well. In > reality you have a racing car xyz version 2010 and a year later you have > another version. And in some series the cars drive in on race, old and new > together. So if we find we could make a car drive better, we can do it by > creating a new version, but we should not delete the old version. This > would > not cause additional work, because we do not change published things later, > so we do not have to test it again and again. This will increase the will > to > work on SD because we can work on new things instead of repairing again and > again. > > > If there is something which can be done to improve testability please > raise a bug and we'll try to get it working ... > In fact we did decide long time ago to not change/add features (and this > means no parameter changes as well). > So let us keep this decision and work instead of looping again and again > planning new features or changes for the current release. It is not a > question of democracy, it is avoiding chaos and managing the project. > > What we have to do is work in the natural order, basics first, then next > step on top. This means that some of us have to wait before they can work > on > their favorite subjects, but this is the only way we can avoid looping > again > and again. > > Cheers > > Wolf-Dieter > > > > -----Ursprüngliche Nachricht----- > Von: si...@mu... [mailto:si...@mu...] > Gesendet: Freitag, 28. Oktober 2011 18:45 > An: Wolf-Dieter Beelitz > Cc: Speed-Dreams Dev; ba...@ne... > Betreff: Moving forward from Beta1 > > Wolf-Dieter, > Thank you for the insight to the work you do and the amount of time and > effort it takes, often one does not appreciate the 'scope of work' that is > required in the project.... just thinking about ensuring that all the > previews are done (and up to date with models/skins) is making my head > spin. > > However your description does highlight that there is something wrong with > the approach. The coders among us should be making the artists/tuners/etc > work as easy a possible, it is clear that it is not practical to perform > that level/amount of testing each time 'something' is changed. > > If there is something which can be done to improve testability please > raise a bug and we'll try to get it working.... > > > Some time ago I asked to reduce the complexity by do not allow all cars > > for > > all tracks. But it was decided to allow a F1 car on a track like Dirt2. > So > > what is the consequence of this decision? To check the function of the > > gamers opponents we have to race each car with each robot on each new > > track. > > I don't believe that we're asking you to tune the F1 cars on the dirt > tracks, I think we just stated that we wouldn't prevent the end user > selecting that car/track combination - in the same way I could drive my RL > car around a bumpy field if I really wanted to (and would probably break > it). > > If I was a tuner I would not test these 'stupid' combinations. > > > > At least we have to race an endurance race with a pit stop per car to be > > sure it works fine with much and with less fuel. > > Perhaps some test mode where the position of the cars was randomised > around the track and a race could be started 'part way done'. Test a few > laps just to confirm 'normal' behaviour. > > > The extract is: If we do not work in the natural order and implement > > things > > step by step, one after the other in the correct order we will have to > > repeat a lot of work. This will result in a never ending story. > > > The Beta (in my mind) is a feature freeze, now we have to make it work > properly as we move to RC1. This includes tweaking parameters and tuning > the cars. Obviously 'we' have to be on top of the tuning before this > stage, but I don't think we can consider it 'stable' until the RC. > > Note this discussion started with 'stick grass', however a change to the > body shape/boundary or even spring stiffness could also throw off the > ability of a robot to drive a car. > > > ..., will be to follow the principle "Never change published content" > > that is not practical in a open project running on SVN. You can only take > the landmark releases (ie. 1.4 and 2.0). > > Simon. > > > > > > > > ------------------------------------------------------------------------------ > Get your Android app more play: Bring it to the BlackBerry PlayBook > in minutes. BlackBerry App World™ now supports Android™ Apps > for the BlackBerry® PlayBook™. Discover just how easy and simple > it is! http://p.sf.net/sfu/android-dev2dev > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > |