[Contest] BotWars

[NDF82]

Een ander probleem wat betreft de bereikbaarheid van de wiki server is de netwerkkaart daarvan. Deze is best brak dus ik moet af en toe de kabel er opnieuw insteken

[Verwijderd]

Woei! Er lopen nu vier van mijn botjes rond op de bosselaar server ... mijn UI begint ook langzaam gestalte te krijgen ...

[Creepy]

NDF82 schreef op dinsdag 02 augustus 2005 @ 10:58:
Een ander probleem wat betreft de bereikbaarheid van de wiki server is de netwerkkaart daarvan. Deze is best brak dus ik moet af en toe de kabel er opnieuw insteken

Wat heb je nodig om die wiki te draaien? PHP en/of MySQL? Anders kan ik eens kijken of ik dat kan hosten om de crew server o.i.d.

[Ricvdp]

PHP und MySQL.

[Soultaker]

Ik kan de Wiki er ook wel bij hosten in principe; liefst zou ik 'm dan converteren naar van Mediawiki naar Trac (ivm. integratie met de SVN repository browser en de andere Trac features die wel handig zijn).

[Great-Storm]

Even een vlug vraagje :
Op welke server wordt het meeste gspeeld/getest?
Want ik zit nu zelf op hell.student.utwente.nl:1666, maar die was gister toch erg leeg...
Ik zou best meer bots willen draaien maar dat komt niet goed uit met hoe ik mijn bot heb gemaakt (en het gebruikt veel te veel geheugen..) dus heb ik wel tegenstanders nodig.

Voor de rest over de wiki, ik heb daar nog niks van gemerkt eigenlijk?
Bij mij doet ie het gewoon altijd.

[Toiletman]

Mooi dat het weer loopt inderdaad! Ik ga vanavond ook weer eens verder met m'n botje. Z'n intelligentie bestaat op het moment uit het versturen van het QUIT commando als hij geraakt wordt .
Ik weet niet precies hoe de discussie op de wiki loopt en om nou zomaar het scheiden van energie en schild te gaan editen leek me ook een beetje ruig, vandaar hier mijn visie op dat verhaal:
In plaats van het scheiden van de energie van beide delen lijkt het me handiger om de energiekosten van bepaalde acties pas vanaf een bepaald niveau te gaan rekenen.
Dus bijvoorbeeld moves kosten pas energie als je meer dan 10 vakjes beweegt, dus 11 units moven kost 1 energy, 20 units, 10 energy. Op die manier kan je ofwel veel energie uitgeven om te vluchten, of je gaat een beetje rondrijden en terugschieten. Dit lijkt me ook eenvoudiger te implementeren omdat je wat extra worldinfo dingen zou kunnen meesturen en verder wat server-based dingen moet veranderen, het verplicht je botje niet om er ook direct gebruik van te maken in de AI.
Ennuh, hoe zit het nou met dat starten op volledige energie, op hell.student.utwente.nl begin ik nog steeds met 85 ipv 150. Is het in de officiele serversoftware al wel veranderd?

[PS]M'n botje staat ook in de WiKi[/PS]

[Blue2k]

Ik ben zo vrij geweest om mijn botje ook toe te voegen aan de Wiki (user Blue2k). Lijkt me ook wel leuk om er een stukje neuraal netwerk in te verwerken, heb dat al ooit geprogged in C# voor het vak neurale netwerken. Alleen is mijn probleem dat ik overal mee begin maar niet afmaak

[Verwijderd]

Toiletman schreef op dinsdag 02 augustus 2005 @ 15:01:
[...]
Ik weet niet precies hoe de discussie op de wiki loopt en om nou zomaar het scheiden van energie en schild te gaan editen leek me ook een beetje ruig,

Is het ook, maar da's een kwestie van wennen. De discussie en besluiten staan dan wel op 1 plaats.

vandaar hier mijn visie op dat verhaal:
In plaats van het scheiden van de energie van beide delen lijkt het me handiger om de energiekosten van bepaalde acties pas vanaf een bepaald niveau te gaan rekenen.
Dus bijvoorbeeld moves kosten pas energie als je meer dan 10 vakjes beweegt, dus 11 units moven kost 1 energy, 20 units, 10 energy. Op die manier kan je ofwel veel energie uitgeven om te vluchten, of je gaat een beetje rondrijden en terugschieten. Dit lijkt me ook eenvoudiger te implementeren omdat je wat extra worldinfo dingen zou kunnen meesturen en verder wat server-based dingen moet veranderen, het verplicht je botje niet om er ook direct gebruik van te maken in de AI.

Maar dit is weer ontzettend niet intuitief. Ik zie alleen maar voordelen voor mensen die simpele AI maken en er geen rekening mee houden. Voor alle andere mensen wordt het juist een heleboel extra rekenwerk en de serverimplementatie is niet eens zoveel makkelijker dan mijn voorstel.

Ennuh, hoe zit het nou met dat starten op volledige energie, op hell.student.utwente.nl begin ik nog steeds met 85 ipv 150. Is het in de officiele serversoftware al wel veranderd?
[...]

Er is hier wel gediscussierd, maar ik heb geen change request gezien op de Wiki met deze strekking. Dat is volgens mij wel de manier om een change request op de server road map te krijgen. Sowieso duurt zoiets altijd even om te ontwikkelen. Op zich zou dit ook wel interessant zijn als serversetting, evt. op te nemen in worldinfo.

Wat wel jammer is is dat de versies van de diverse servers verschillen. Ik gebruik bosselaar omdat deze het meest up to date lijkt te zijn. Nadeel is dat de accu een lage capaciteit heeft en de afmetingen erg groot zijn, en bovendien lijken er maar weinig mensen van deze server gebruik te maken.

@Great-Storm: Ik gebruik dus meestal de bosselaar server. Voordeel is ook dat je daar aan de USERENTERs en -EXITs kan zien of er bots aanwezig zijn.

Als mijn bot stabiel genoeg is zal ik eens kijken of ik er een paar dag en nacht kan laten draaien.

De wiki heeft bij mij ook altijd goed gewerkt, maar als het op een meer stabiele (crew)server zou kunnen draaien met evt. meer features zou dat mooi zijn.

[ Voor 11% gewijzigd door Verwijderd op 02-08-2005 17:17 ]

[VisionMaster]

* VisionMaster zit meestal op Hell, maar zit daar alleen tijdens de tests en dev momenten.

[Toiletman]

Ok, ik heb de Wiki changerequest geupdate. Ik heb de twee spawnverhalen maar bij elkaar gegooid, het lijkt me dat de uitkomst van de discussie zo onderhand wel duidelijk is daar. De changerequest voor de spawnenergie is ook toegevoegd.
Wat betreft het scheiden van schild en acties reageer ik ook wel op de WiKi.
Het userenter en userexit gebeuren ben ik nu ook aan het testen op de bosselaar server.

Toch nog maar wat discussie hier in plaats van op de Wiki:
Een groot aantal van de changerequests die nu zijn ingediend gaan over maatregelen om intelligent/actief gedrag te belonen. Het ziet er naar uit dat de wereld waar onze botjes in moeten leven hen niet de mogelijkheden biedt om het gedrag (intelligentie) te vertonen dat we willen.
Vandaar wil ik voorstellen dat we eens een lijstje maken van wat voor soort intelligentie we nu precies willen zien, dan kunnen we dat daarna eens vertalen naar serversettings, of wellicht een heel anders vormgegeven wereld.

Ik heb het idee dat we een beetje in de 'game' setting zitten en dat dat op zich ook wel zo leuk is ook: dus bewegen, schieten en doodgaan.
Op het moment zijn de mogelijkheden tot interactie in de wereld beperkt tot interactie met andere bots. Om een bot te kunnen doden bestaat de benodigde intelligentie uit 'voorspellingskracht' & een piepklein beetje pathfinding, je moet immers zorgen dat je kan schieten op de plek waar je voorspelt dat de andere robot zal zijn.
Om goed te kunnen voorspellen zal je voldoende informatie kunnen krijgen over de andere robots, wat in de huidige wereld zou moeten betekenen dat scannen erg eenvoudig en goedkoop zou moeten zijn. Verder is iets waar je aan kan denken om de voorspelbaarheid te vergroten een zekere massatraagheid: in principe beweegt je robot zich rechtlijnig, je zal moeten sturen of gasgeven of remmen om van richting/snelheid te veranderen. Dus niet zoals het nu is dat de bots plots van richting kunnen veranderen.

Iets wat misschien ook leuk is om te testen is pathfinding, wat zou moeten betekenen dat we onze wereld van obstakels zouden moeten voorzien, of van bepaalde doelen, zoals powerups of mijnen.

Ten slotte is er nog zoiets als Team-AI, waarmee dus meerdere bots in een team zouden moeten samenwerken. Hier zou je dan moeten beslissen of we dit uiteindelijk willen gaan doen, en of dat dan tussen bots van verschillende mensen zou moeten gaan, of om een vast aantal bots per persoon.

[ Voor 85% gewijzigd door Toiletman op 02-08-2005 20:08 ]

[Ricvdp]

Ik zit altijd op bosselaar aangezien die de nieuwste server draait, eerst gebruikte ik gotbot.no-ip.net.

[Verwijderd]

@Toiletman: wat ik geweldig zou vinden mbt AI is het voorspellen van de bewegingen van andere bots en nauwkeurig aanvallen. Daarvoor moet je veel goedkoper kunnen scannen, nog steeds een beperkte schietrange hebben en moet de max blast radius kleiner worden, of anders afhankelijk van de afstand tot de point of impact. Ik zie wel 1 nadeel hiervan, en dat is dat bepaalde bots alleen maar gaan vluchten, omdat ze je lang van te voren zien aankomen en omdat er geen echte grenzen zijn aan het speelveld. Dat is alleen maar te voorkomen door de wedstrijdvorm slim te kiezen.

Ik ben geen voorstander van allerlei obstakels of powerups, aangezien het schrijven van een goed geoptimaliseerde AI zonder deze elementen al lastig zat is. Team AI is wel een leuk idee, maar ook bijzonder complex. Ik geloof dat het primaire doel van deze competitie juist was om individuele bots te maken, dus misschien is dit leuk voor later.

Ik denk dat ook de competitievorm vastgelegd moet gaan worden, want dan kan ik mijn AI daarvoor gaan opzetten. Zelf heb ik wel een voorstel:
- Voor een tournooi wordt een datum en aanvangsttijd afgesproken en een hostname en portnummer bekend gemaakt. De server is minimaal een uur voor het toernooi open voor testen, maar zal vanaf 15 minuten vooraf resetten en vanaf dan tot het begin van het toernooi geen newturns meer toelaten.
- De organisatie zet een server op met vaste serverwaardes die vooraf bekend zijn. Afhankelijk van het aantal spelers heeft de server een bepaalde speelveldgrootte, die ook vantevoren is vastgelegd. Ook wordt een time out per beurt afgesproken.
- Alle spelers moeten zich inschrijven met een botnaam en krijgen een password van de organisatie. Er mag slechts 1 bot per developer meedoen. De bots moeten minimaal 1 minuut vooraf ingelogd zijn om mee te kunnen doen.
- Bots moeten individueel meedoen en mogen onder geen beding samenwerken door elkaars data te delen of elkaar te ontzien in confrontaties om andere dan ppur tactische redenen. De organisatie kan deelnemers uitsluiten wanneer ze hier duidelijke aanwijzingen voor hebben.
- De spelers krijgen spelen 3 rondes van ieder 30 minuten. De aanvangsttijd van een tournooi
Binnen een ronde hebben ze 3 levens (dus ze kunnen 2 keer terug komen). Daarna moeten ze wachten tot een volgende ronde. Een disconnect door netwerkstoring of andere oorzaak telt ook als dood.
- Tijdens de ronde krijgen de bots wel informatie over alle kills (wie door wie). Er is een apart kanaal beschikbaar voor toeschouwers (BotTV) die met een vertraging van minimaal 5 beurten alle akties zichtbaar maakt, maar geen van de bots mag hiervan gebruik maken.
- AI mag tussen de rondes door getuned worden door de developer, maar niet tijdens de ronde. Interactie met de bot tijdens een ronde is dus verboden.
- Een robot krijgt 2 punten voor een kill en 1 punt aftrek als hij / zij sterft. De robots die aan het einde van de ronde leven krijgen voor ieder niet gebruikt leven ook nog 1 punt.
- De bot met de meeste punten wint. Bij een gelijk spel telt het meeste aantal kills. Bij alsnog gelijk spel telt wie het snelste de eerste kill scoorde.
- Achteraf worden alle acties openbaar gemaakt, zodat eventuele verdachtmakingen uit de wereld geholpen kunnen worden.

Hoe klinkt dat als opzet? Ja, het is best streng, maar mijn ervaring met clanmatches met online games heeft me geleerd dat duidelijke en nauwkeurige regelgeving en afspraken belangrijk zijn.

[ Voor 32% gewijzigd door Verwijderd op 02-08-2005 23:30 ]

[Belgar]

Ik dacht helemaal geen tijd te hebben ivm verhuizing, maar mischien kan ik nog wel ergens wat tijd uitpersen.

Ik heb een soort hybride change request die hopelijk niet al te veel development vraagd aan de serverkant:

Voorstel:

Afgezien dat damage af zou moeten nemen vanaf het centrum, zou de basis damage ook hoger kunnen worden naar mate de radius van de blast kleiner wordt. Hierdoor kunnen statische bots makkelijker worden aangepakt.

Uitleg:

Het probleem met blast radius in de huidige versie is dat het werkelijk ontzettend "goedkoop" is. een blast met een radius 10 is tien keer zo duur als met radius 1, echter het oppervlak is 100 maal zo groot! Als de "blast cost" wordt verhoogd in de server settings is dit echter weer vaak in het voordeel van, relatief, passieve bots. De schietende bot verliest dan namelijk net zoveel energie als het doel.
Als de damage afneemt naar de randen, maar er wordt verder niets aangepast, is er nog steeds geen goede reden om een kleinere blastrange te nemen omdat het zo goedkoop is.

Indien de damage echter afhangt van de radius zou zelfs de energie cost voor radius kunnen vervallen. Men kan dan kiezen voor een grote radius met relatief weinig schade (wat vervolgens wel je positie aan de vijand bekend maakt) of proberen met een aantal gerichte schoten de vijand te verrassen en te vernietigen.

Reden:

Een bot die stilstaat en als ie geraakt wordt 10 plaatsen moved in een semi-random hoek weg van de schutter is namelijk onvernietigbaar in de huidige setting. Voordat de aanvaller de bot weer gevonden heeft is de energie al weer naar 100. De energie van de aanvaller zal echter veel lager staan, omdat de aanvaller heeft moeten schieten, scannen, moven, scannen enz.

Alternatief

Een redelijk alternatief, wat echter wel een protocol aanpassing vereist, is bij het scannen de laatst bekende richting van de tegenstander meegeven.

[VisionMaster]

RunningCow !!! You basterd
Ik scande 5 van je bots voor dat ik dood ging

edit
I'll kill you ... when I make my Bot smarter !

[ Voor 32% gewijzigd door VisionMaster op 03-08-2005 00:34 ]

[CrazyA]

Ontzettend gaaf dit, ik weet niet of ik mijzelf wel echt deelnemer kan gaan noemen, maar de eerste wazige poging staat op papier (nouja, harddisk).
Ik kan tenminste verbinding maken, hopelijk heb ik de tijd om hier verder mee te gaan.

[Verwijderd]

@VisionMaster: volgens mij ligt de kracht van RunningCow meer in het aantal bots dan iets anders. Als ik 20 DaDutchBotjes online gooi die niet op elkaar maar wel op al het andere schieten, dan is het al snel afgelopen als een eenzame bot zich daartussen mengt, hoewel mijn AI echt niet goed is.

Edit: Zijn er problemen met de bosselaar server? Ik krijg rare error meldingen ...

Edit 2: Alles werkt nu naar behoren, het kan eerlijk gezegd aan mij gelegen hebben.

[ Voor 24% gewijzigd door Verwijderd op 03-08-2005 12:55 ]

[Creepy]

Verwijderd schreef op woensdag 03 augustus 2005 @ 12:01:
Edit: Zijn er problemen met de bosselaar server? Ik krijg rare error meldingen ...

Nope. server lijkt nog prima te draaien. Ik kan hem wel ff een restart geven zo..

[VisionMaster]

Verwijderd schreef op woensdag 03 augustus 2005 @ 12:01:
@VisionMaster: volgens mij ligt de kracht van RunningCow meer in het aantal bots dan iets anders. Als ik 20 DaDutchBotjes online gooi die niet op elkaar maar wel op al het andere schieten, dan is het al snel afgelopen als een eenzame bot zich daartussen mengt, hoewel mijn AI echt niet goed is.

Edit: Zijn er problemen met de bosselaar server? Ik krijg rare error meldingen ...

Edit 2: Alles werkt nu naar behoren, het kan eerlijk gezegd aan mij gelegen hebben.

Dat zat ik ook te bedenken, maar toch ben ik wel van plan om mijn Botje wat nieuwe tricks te leren, zodatie er ondanks dat nog wel wat langer mee doet om ze 1 voor 1 af te slachten

[bennierex]

Even een hele stomme vraag waarschijnlijk;
Hoe lang duurt 1 turn? Ik bedoel, de server wacht lijkt me niet tot alle clients eindelijk eens hun commands gestuurd hebben voor iedere beurt. Hoeveel tijd heeft mijn bot dan om iets terug te sturen voordat alles afgehandeld wordt op de server?

[Ricvdp]

Is instelbaar op de server, standaart 2 sec.

[Verwijderd]

Ik denk dat het change request voor death zonder disconnect iets herschreven moet worden om ook een protocoluitbreiding met RESET te omvatten, want ik ben het wel met Janoz eens dat dat nuttig zou zijn.

Misschien is het ook handig om een nieuwe pagina op de Wiki aan te maken voor een discussie over de competitievorm. Zie een paar posts terug mijn voorstel, waar jammer genoeg nog niemand op gereageerd heeft.

Ricvdp schreef op woensdag 03 augustus 2005 @ 14:32:
Is instelbaar op de server, standaart 2 sec.

Eerlijk gezegd vind ik deze instelling bar ondoorzichtig.

Hoewel het met 1 bot en mijn doodsimpele AI nu geen issue is, kan ik me voorstellen dat je vooraf wilt weten hoeveel denktijd je hebt voor je AI per turn. Ik denk dat het dan ook nuttig is om een TURN_TIME parameter in de WORLDINFO opnemen met een tijd in secondes die je hebt om je acties te versturen.

[Belgar]

Even een vraag voor de zekerheid:

Opdrachten zoals SCAN zijn in energie eenheden, toch?

Dat betekend dat als ENERGY_COST_SCAN_RADIUS op 2 staat en ik:

SCAN x 20

dat ik dan een radius van 10 scan?

[Verwijderd]

@Belgar: Yupz!

[Toiletman]

Naar aanleiding van de changerequests ook even een vraag betreffende de roadmap:
Wie beheert die, en wie voert de wijzigingen door in de server? Ik meen nu overal DaCoTa te zien, maar ik vroeg me af of het gewenst is dat anderen zich er ook mee bemoeien?

Als ik de changerequests zo bekijk dan kunnen de volgende dingen wel naar de roadmap:

• Hitby schade afhankelijk maken van point of impact
• Respawn zonder reconnect (2
• Spawn Energie

Volgens mij kunnen deze voorstellen verwijderd/samengevoegd worden:

• NUMBER_OF_FOLLOW_UP_MESSAGES
• Logging -> GotBotTV
• Formattering Floating point getallen
• Interpretatie van 0
• Protocol voor wedstrijden -> GotBotTV/Respawn zonder reconnect

(2 Ik zal het voorstel zo wel even herschrijven, maar het lijkt me dat zo onderhand wel duidelijk is dat men een oplossing wil hebben.

Als hier niet al te grote bezwaren worden opgeworpen tegen bovenstaande wijzigingen zal ik deze in de loop van de week doorvoeren (als anderen al dingen willen doen is dat natuurlijk welkom).

Nog even een quote uit m'n toevoeging over de WORLDINFO limieten:

Ten slotte stel ik ook voor om eens te gaan experimenteren met deze worldsettings, wellicht is het een goed idee om een dagelijks/wekelijks test-uurtje in te voeren waarbij mensen die hun bot al goed voor mekaar hebben kunnen gaan kijken wat voor effecten het veranderen van de WORLDINFO heeft. Misschien is dit het meest nuttig als er al zoiets als GotBotTV/logging is zodat we ook kunnen bekijken wat voor gevolgen de settings nou daadwerkelijk hebben.

[Verwijderd]

Verwijderd schreef op woensdag 03 augustus 2005 @ 16:02:
Hoewel het met 1 bot en mijn doodsimpele AI nu geen issue is, kan ik me voorstellen dat je vooraf wilt weten hoeveel denktijd je hebt voor je AI per turn. Ik denk dat het dan ook nuttig is om een TURN_TIME parameter in de WORLDINFO opnemen met een tijd in secondes die je hebt om je acties te versturen.

Het is niet echt nodig om te weten hoe lang je heb. Je kan telkens je huidige beste set doorsturen en kijken of er al nieuwe gegevens zijn van de server. De daadwerkelijke tijd de je heb zal ook nooit hetegeen zijn wat de server zegt door de tijd die het duurt de gegevens te versturen. Daarintegen is het wel nuttig als je bot verschillende algoritme of model grote kan gebruiken.

[Verwijderd]

Verwijderd schreef op woensdag 03 augustus 2005 @ 20:47:
[...]


Het is niet echt nodig om te weten hoe lang je heb. Je kan telkens je huidige beste set doorsturen en kijken of er al nieuwe gegevens zijn van de server. De daadwerkelijke tijd de je heb zal ook nooit hetegeen zijn wat de server zegt door de tijd die het duurt de gegevens te versturen. Daarintegen is het wel nuttig als je bot verschillende algoritme of model grote kan gebruiken.

Hmmmm ... ja, ik dacht ergens gelezen te heben dat bij het versturen van meerdere commando's alleen de laatste versie wordt gebruikt. Da's dan waarschijnlijk voldoende ja ... hoewel je dan niet 100% zeker weet welke je laatste verzonden commando's zijn wanneer die rond de newturn vallen.

Toiletman schreef op woensdag 03 augustus 2005 @ 20:11:
Naar aanleiding van de changerequests ook even een vraag betreffende de roadmap:
Wie beheert die, en wie voert de wijzigingen door in de server? Ik meen nu overal DaCoTa te zien, maar ik vroeg me af of het gewenst is dat anderen zich er ook mee bemoeien?

De projectleiding ligt een beetje bij Soultaker heb ik begrepen, dus ik neem aan dat hij samen met de server devs beslissingen neemt over de road map en ook de change requests opschoont. Als ik het mis heb, dan hoor ik dat graag ...
/me pokes Soultaker gently between the ribs ...

Ten slotte stel ik ook voor om eens te gaan experimenteren met deze worldsettings, wellicht is het een goed idee om een dagelijks/wekelijks test-uurtje in te voeren waarbij mensen die hun bot al goed voor mekaar hebben kunnen gaan kijken wat voor effecten het veranderen van de WORLDINFO heeft. Misschien is dit het meest nuttig als er al zoiets als GotBotTV/logging is zodat we ook kunnen bekijken wat voor gevolgen de settings nou daadwerkelijk hebben.

Ik denk dat een theoretische discussie meer inzicht geeft dan een testdagje, aangezien daar eerder uit zal komen wie zijn huidige AI goed werkt met welke serverinstellingen ipv welke serverinstellingen goed werken.

[ Voor 47% gewijzigd door Verwijderd op 03-08-2005 22:59 ]

[Lukse]

Verwijderd schreef op woensdag 03 augustus 2005 @ 22:53:Hmmmm ... ja, ik dacht ergens gelezen te heben dat bij het versturen van meerdere commando's alleen de laatste versie wordt gebruikt. Da's dan waarschijnlijk voldoende ja ... hoewel je dan niet 100% zeker weet welke je laatste verzonden commando's zijn wanneer die rond de newturn vallen.

Als je 2de commando te laat komt, krijg je een error terug van de server, omdat je dan het verkeerde turn-id gebruikt. Daar zou je op kunnen checken.

[Verwijderd]

Lukse schreef op woensdag 03 augustus 2005 @ 23:03:
[...]

Als je 2de commando te laat komt, krijg je een error terug van de server, omdat je dan het verkeerde turn-id gebruikt. Daar zou je op kunnen checken.

D'oh .... natuurlijk, heb je helemaal gelijk in ....

[Belgar]

Goed,

Ik heb mijn oude vertrouwde "weapon of choice" maar weer van stal gehaald: Borland C++ Builder. De volledige interface en communicatie is nu af.

In principe moet nu alleen de AI nog even

[VisionMaster]

Belgar schreef op woensdag 03 augustus 2005 @ 23:28:
Goed,

Ik heb mijn oude vertrouwde "weapon of choice" maar weer van stal gehaald: Borland C++ Builder. De volledige interface en communicatie is nu af.

In principe moet nu alleen de AI nog even

Ik ben armed and ready met Borland Delphi 5 Enterprise
AI slimmer maken en dan ... bring it on

edit2:
edit: als ik ergens in eens echt te veel tijd heb herschrijf ik het in een taal die linux machines eenvoudiger begrijpen en dan misschien met overkill aan cpu power proberen mijn bot te laten winnen (Grid computing!).

offtopic:
ain't gonna happen I think...

Idee, misschien is het grappig voor de statistieken om tijdens de connectfase wat gegevens van jou systeem door te geven wat interessant is, zoals:
- Ontwikkelomgeving
- OS
- Wat voor hardware (lijkt me alleen dat je type CPU en geheugen capacititeit interessant is)

Misschien ook aan het eind van de game (optioneel):
- CPU time used
- avarage/max memory used

Gewoon leuk
Uhmmmm ja, je kan dit natuurlijk ook zelf in een Wiki pagina zetten, das ook voldoende eigenlijk.

[ Voor 59% gewijzigd door VisionMaster op 04-08-2005 01:42 ]

[Ricvdp]

@Toiletman: Soultaker heeft de leiding over het contest, DaCoTa werkt aan de server, en NDF soms ook, maar die had momenteel geen pc dacht ik?

[VisionMaster]

Ricvdp schreef op donderdag 04 augustus 2005 @ 08:21:
@Toiletman: Soultaker heeft de leiding over het contest, DaCoTa werkt aan de server, en NDF soms ook, maar die had momenteel geen pc dacht ik?

Ik leef simpatiek mee met de gevoelens van NDF dat je als tweaker en devver geen pc hebt...
Afschuwelijk!

[supakeen]

Ik ga vanavond eens kijken of ik nog iets kan maken

[DaCoTa]

Ricvdp schreef op donderdag 04 augustus 2005 @ 08:21:
@Toiletman: Soultaker heeft de leiding over het contest, DaCoTa werkt aan de server, en NDF soms ook, maar die had momenteel geen pc dacht ik?

Ik ben serverdev-af, gezien ik midden in een verhuizing zet en mijn i-netverbinding al over is maar mijn pc (en de rest van mijn leven) nog niet. Daarnaast heb ik geen tijd om er de komende weken iets aan te doen, hoewel ik wel dit topique volg (op mijn werk).

[Verwijderd]

Dus feitelijk zijn er nu geen serverdevs ... geen actieve in ieder geval. Soultaker heb ik ook al een tijdje niet gezien.

Edit: Ik ga even een mailtje richting Soultaker sturen ...

Edit 2:

offtopic:
Ik was op zoek naar een pagina over geometrie, want ik merk dat mijn kennis behoorlijk is weggezakt, en kwam toen op deze site van een stel kwakzalvers uit: http://www.organum.nl/geometrie.htm
/me lacht zich suf

Iemand nog wat goede geometrie sites?

Edit3:
Goniometrie dus eigenlijk: http://nl.wikipedia.org/wiki/Goniometrie
/me heeft voor het eerst sinds eeuwen weer deze kennis nodig, maar schaamt zich dood dat het zo ver is weggezakt ....

[ Voor 84% gewijzigd door Verwijderd op 04-08-2005 15:49 ]

[Toiletman]

Verwijderd schreef op donderdag 04 augustus 2005 @ 14:27:
Iemand nog wat goede geometrie sites?

Edit3:
Goniometrie dus eigenlijk: http://nl.wikipedia.org/wiki/Goniometrie
/me heeft voor het eerst sinds eeuwen weer deze kennis nodig, maar schaamt zich dood dat het zo ver is weggezakt ....

http://mathworld.wolfram.com/

Dees kwam ik tegen op zoek naar Analyse C spul.... erg goede site.

[Jegorex]

Het enige wat ik daar nog van weet is SosCasToa.
Tot nu toe red ik me daar redelijk mee

[Lukse]

Jegorex schreef op donderdag 04 augustus 2005 @ 21:41:
SosCasToa.

Ha, die kende ik nog niet. Is best wel handig

[Verwijderd]

Jegorex schreef op donderdag 04 augustus 2005 @ 21:41:
Het enige wat ik daar nog van weet is SosCasToa.
Tot nu toe red ik me daar redelijk mee

/me hoort de bel ergens in de verte luiden maar is even vergeten waar de klepel hang
Da's een ezelsbruggetje voor ... Sinus ... Cosinus ... Tangus ... en dan komt op de puntjes?

[knopper]

Sinus = overstaande / schuine zijde
Cosinus = aanliggende / schuine zijde
Tangens = overstaande / aanliggende zijde

Dacht ik...;)

[maddog_rvo]

knopper schreef op donderdag 04 augustus 2005 @ 23:21:
Sinus = overstaande / schuine zijde
Cosinus = aanliggende / schuine zijde
Tangens = overstaande / aanliggende zijde

Dacht ik...;)

Yup dat ezelsbruggetje gebruikte ik ook al om alle botjes e.d. op m`n map te kunnen plaatsen

[Ricvdp]

Op de IRC zijn we hier een paar weken geleden ook mee bezig geweest.

quote: Logs

<Korben|werk> om het om te zetten in gotbot termen
<Korben|werk> direction = Math.Atan2(y, x);
<Korben|werk> distance = Math.Sqrt(x*x + y*y)

'
In C#:)

Is dus van x/y naar 2pi, en om van 2pi naar x/y te gaan:
http://gandalf.lekkerknag...dex.php/Wiskunde_functies
De functies GetXFromDistanceDirection en GetYFromDistanceDirection.

En dan weet je genoeg.

[Scorpion1984]

Ik zal deze post nog maar eens een keer posten:

Hoe kan ik de source code met SVN downloaden, want als ik dat probeer vraagt hij om een password en een username, en die staat nergens vermeld.

Dus wat zijn de username en password om de source via SVN te downloaden?

[Creepy]

Er is geen username en password voor nodig om te downloaden. Waarschijnlijk probeer je met je SVN client ook schrijf toegang te krijgen waarvoor je wel een username en password nodig hebt.

[Scorpion1984]

Creepy schreef op vrijdag 05 augustus 2005 @ 14:54:
Er is geen username en password voor nodig om te downloaden. Waarschijnlijk probeer je met je SVN client ook schrijf toegang te krijgen waarvoor je wel een username en password nodig hebt.

Mmh, nu krijg ik geen vraag van username/password: Als ik probeer te downloaden kom ik nu al verder
maar als ik een paar bestanden heb gedownload krijg ik ALTIJD het volgende:

Error: REPORT request failed on '/svn/!svn/vcc/default'
Error: REPORT of '/svn/!svn/vcc/default': Could not read status line: connection was closed
Error: by server. (http://hell.student.utwente.nl)

[Creepy]

Ik heb geen idee wat je allemaal probeert uit te checken maar heel de /svn dir is niet goed. Dat zijn alle SVN repositories daar en sommigen zijn beveiligd met een password. Je moet /svn/GotBot-server/trunk/ ophalen. En dat is prima bereikbaar. (En dat had je geweten als je de wiki ff doorgelezen had en een SVN tutorialtje had gelezen ).

[Scorpion1984]

Creepy schreef op zaterdag 06 augustus 2005 @ 10:52:
Ik heb geen idee wat je allemaal probeert uit te checken maar heel de /svn dir is niet goed. Dat zijn alle SVN repositories daar en sommigen zijn beveiligd met een password. Je moet /svn/GotBot-server/trunk/ ophalen. En dat is prima bereikbaar. (En dat had je geweten als je de wiki ff doorgelezen had en een SVN tutorialtje had gelezen ).

Ik probeer gewoon heel simpel die directory die jij daar zegt te downloaden. Ik heb vanalles doorgelezen op de SVN website (van Subversion zelf en van tortoiseSVN). Ik heb het met beide programma's geprobeerd, allerlei dingen.

Met subversion zelf:

G:\downloads\javaserver\sub>svn checkout http://hell.student.utwente.nl/svn/GotBot-server/trunk
svn: REPORT request failed on '/svn/!svn/vcc/default'
svn: REPORT of '/svn/!svn/vcc/default': Could not read status line: connection w
as closed by server. (http://hell.student.utwente.nl)

--------

G:\downloads\javaserver\sub>svn checkout http://hell.student.utwente.nl/svn/GotBot-server/trunk/nl
A nl\ndf
A nl\ndf\gotbot
A nl\ndf\gotbot\protocol
A nl\ndf\gotbot\protocol\Operation.java
A nl\ndf\gotbot\protocol\NEWTURN.java
A nl\ndf\gotbot\protocol\WORLDINFO.java
A nl\ndf\gotbot\protocol\MOVE.java
A nl\ndf\gotbot\protocol\USEREXIT.java
A nl\ndf\gotbot\protocol\USERENTER.java
A nl\ndf\gotbot\protocol\USER.java
A nl\ndf\gotbot\protocol\HITBY.java
A nl\ndf\gotbot\protocol\ProtocolException.java
A nl\ndf\gotbot\protocol\QUIT.java
A nl\ndf\gotbot\protocol\SCANRESULT.java
A nl\ndf\gotbot\protocol\SCAN.java
A nl\ndf\gotbot\protocol\FIRERESULT.java
A nl\ndf\gotbot\protocol\AbstractOperation.java
svn: REPORT request failed on '/svn/!svn/vcc/default'
svn: REPORT of '/svn/!svn/vcc/default': Could not read chunk size: connection was closed by server. (http://hell.student.utwente.nl)

[ Voor 34% gewijzigd door Scorpion1984 op 06-08-2005 13:55 ]

[Soultaker]

Blijkbaar crashte webserver op een illegal instruction (wat op zich al vaag is) als mod_python in de server geladen is; dubbel vaag want die module heeft echt helemaal niets met Subversion te maken. Ik heb 'm er uitgegooid en nu lijkt het te werken.

Bedankt voor de melding; voor dit soort servergerelateerde dingen kun je me ook altijd e-mailen natuurlijk (anderen kunnen het toch niet verhelpen namelijk).

[Scorpion1984]

Soultaker schreef op zaterdag 06 augustus 2005 @ 16:15:
Blijkbaar crashte webserver op een illegal instruction (wat op zich al vaag is) als mod_python in de server geladen is; dubbel vaag want die module heeft echt helemaal niets met Subversion te maken. Ik heb 'm er uitgegooid en nu lijkt het te werken.

Bedankt voor de melding; voor dit soort servergerelateerde dingen kun je me ook altijd e-mailen natuurlijk (anderen kunnen het toch niet verhelpen namelijk).

Ok, ja ik wist niet dat dit aan de server lag. Ik heb namelijk nog nooit met subversion gewerkt en dacht dat ik gewoon iets fout deed.

Maar hij werkt nu wel.

[ Voor 3% gewijzigd door Scorpion1984 op 06-08-2005 18:22 ]

[Verwijderd]

Opzich is het een leuk project, heb er wel even van genoten. Maar ik heb het op het moment wel een beetje druk (moet mijn project PHPMyServer even afmaken, kost even wat tijd. en vakantie enzo). Dus ik hoop dat de contest nog redelijk kang open blijft, dan kan ik misschien nog verder gaan aan mijn eigen bot

[Sijmen]

Ik ga nu twee weken op vakantie, dus jullie zullen je kanonvoer Sijmen_FirstBot moeten missen. Heel veel plezier met jullie eigen bots, en tot over twee weken!

[Ricvdp]

Sijmen schreef op zondag 07 augustus 2005 @ 10:53:
Ik ga nu twee weken op vakantie, dus jullie zullen je kanonvoer Sijmen_FirstBot moeten missen. Heel veel plezier met jullie eigen bots, en tot over twee weken!

Veel plezier Sijmen, en ik kan wel een oude versie van Sijmen_FirstBot voor je draaien, maar die mist de AI . We zullen je bot missen:P.

[Verwijderd]

Ik ben nu al een paar dagen een beetje begonnen met het maken van een bot. Maar het mij niet geheel duidelijk hoe de beurtvolgende is en wat er mogelijk is. De beurtvolgorde in wiki is anders dan ik hier en daar begrepen heb , en ook anders als ik in een change request poll gezien heb mbt de beurtvolgorde.

iemand die mij dat even duidelijk kan maken , of op wiki duidelijk kan maken voor iedereen.

[Webgnome]

Beste mensen,

na een kleine onderbreking wil ik nu eindelijjk weer verder gaan aan mijn botje. Op dit moment kan de bot niet veel meer dan connecten ecter het ophalen van gegevens is bij deze geen probleem. Wat echter wel een probleempje zal zijn is de AI . zoals eerder al aangegeven heb ik hier geen kaas van gegeten en leek het mij een goed idee om dat via deze contest te doen. Echer zijn er mensen in de zaal die mij plekken po het internet aan kunnen wijzen waar veel info staat over AI programming en / of weten jullie maybe boeken die ik gelezen moet hebben voordat ik er ook maar aan denk te gaan beginnen?

[Ricvdp]

Voor gewone AI zonder ANN's, genetische algoritmes, e.d. heb je geen boeken nodig hoor.:)
Je kan zit soort code bijvoorbeeld krijgen (pseudo):

code:

if(battery < 80)
  Recharge
else
  if(enemy scanned in previous turn)
    fire at enemy
  else
    scan with radius 10

Let op, het is zomaar een voorbeeld:).

[Webgnome]

Ricvdp schreef op dinsdag 09 augustus 2005 @ 07:59:
Voor gewone AI zonder ANN's, genetische algoritmes, e.d. heb je geen boeken nodig hoor.:)
Je kan zit soort code bijvoorbeeld krijgen (pseudo):

code:

if(battery < 80)
  Recharge
else
  if(enemy scanned in previous turn)
    fire at enemy
  else
    scan with radius 10

Let op, het is zomaar een voorbeeld:).

Op iets als dat was ik ook nog wel gekomen maar dat is dan toch geen 'leuke' ai ? Dat is gewoon een als dat en dat en dat doe dat ..

[Janoz]

Een 'echtere' ai bestaat eigenlijk ook een als dat dan dat dat en dat. In het voorbeeldje wordt het gebaseerd op 2 inputs (scan en battery level). Hier kun je natuurlijk nog veel meer mee doen. Je zou bv ook een history als input kunnen gebruiken. De 'outputs' kun je ook nog wat slimmer maken. Niet alleen fireAtEnemy, maar hoe er geschoten wordt en bij meerderen op welke bot.

Zou je gebruik gaan maken van neurale netwerken, dan houdt het trainen van dat netwerk eigenlijk (kort door de bocht mode) niks anders in dan het aanpassen van de (mate van) afhankelijkhe(i/den) tussen die inputs en de outputs.

[.oisyn]

Janoz schreef op dinsdag 09 augustus 2005 @ 13:39:
Zou je gebruik gaan maken van neurale netwerken, dan houdt het trainen van dat netwerk eigenlijk (kort door de bocht mode) niks anders in dan het aanpassen van de (mate van) afhankelijkhe(i/den) tussen die inputs en de outputs.

Een bijkomend probleem (en het grootste imho) is het vinden van een goed netwerk. Zonder goed netwerk kun je trainen wat je wilt, maar er zal weinig uit komen. En een goed netwerk is meestal niet hand-crafted, maar tot stand gekomen door gewoon dingen te proberen. Een genetische algoritme is een goede manier om een goed netwerk te vinden, kijk maar naar het leven hier op aarde . Punt is dat het allemaal nogal wat tijd vergt. Een enkel netwerk kun je alleen op 'slimheid' testen door flink te trainen en dan de resultaten te vergelijken met andere netwerken. En dan nog, waarmee ga je 'm trainen? Tegen een menselijke speler lijkt me het effectiefst, met het nadeel dat het veel te lang duurt. En voor een automatische trainer heb je een goed werkende bot nodig. En zelfs als je dan uiteindelijk een goed en getraind netwerk hebt dan zal de bot voornamelijk goed kunnen spelen tegen de bots met wie het getraind heeft.

Al met al niet echt een approach die je hier zou willen nemen dus, hoewel een (goed) neuraal netwerk in the long run uiteindelijk wel zal kunnen winnen van een voorgeprogrammeerde bot.

[Verwijderd]

/me is ook bezig met het proggen van een botsje...

Ik ben momenteel bezig in delphi om het botje te maken. En gister heb ik het "frame" al afgemaakt, nu moet ik alleen nog meer gegevens zien te verzamelen, en de ai hierop bouwen.

Hier is overigens de source te vinden van het framewerk, als het goed is werkt de communicatie hier helemaal, en hoeft er alleen nog een 'ai' gemaakt te worden...

[Ricvdp]

Hioxz, wil je zo vriendelijk zijn om je linkje ook ff op deze pagina te zetten.
http://gandalf.lekkerknag...index.php/Opensource_Bots

Dat is verzamelplaats voor opensource bots (of stukjes opensource bot).

Verder wil ik dit eigenlijk aan iedereen vragen, als je je bot opensource wil stellen, of een stukje ervan, post het dan even op die pagina. Binaries van bots (voorgecompilleerd dus, evt. zonder dat je source openstelt) kun je daar ook posten.

[ Voor 1% gewijzigd door Ricvdp op 09-08-2005 15:18 . Reden: Closetag vergeten ;) ]

[Janoz]

Neuraal had ik sowieso al afgeschreven hoor . Ik heb nog wel even nagedacht over hoe het eventueel zou kunnen. Je zou een heleboel logs van games kunnen verzamelen en dan telkens 1 beurt trainen.

Dafinieer enkele inputs, en enkele mogelijke acties (run, explore, attack enz enz). Vervolgens ga je een waarde bepalen die je wilt maximaliseren (combinatie van energy level en schade toegebracht aan anderen oid) en vervolgens ga je telkens 1 beurt draaien. Telkens neem je een willekeurige beurt uit het log. Laat een actie bepalen en kijk wat het resultaat zou zijn. Op dat moment ben je niet afhankelijk van implementaties van anderen die je moet doorrekenen, omdat dat al gebeurt is (hun beurt acties staan immers in dat log)

Ubergrote nadeel van deze manier is naast dat je de acties nog steeds zelf moet implementeren, dat je bot maar 1 beurt vooruit leert denken. Nergens worden immers de effecten van de beurt erna meegenomen in het trainen.

[Verwijderd]

Ricvdp schreef op dinsdag 09 augustus 2005 @ 15:18:
Hioxz, wil je zo vriendelijk zijn om je linkje ook ff op deze pagina te zetten.
http://gandalf.lekkerknag...index.php/Opensource_Bots

Ik heb m op de page gezet. Ik dacht m eerst ff hier te posten, ivm als er nog problemen waren met de bot. Maar dat hoor ik nu dan vanzelf ook wel

[Gerco]

Ik heb mijn bot ook Open Source gemaakt, de code is af te halen op de wiki: Opensource_Bots

[zwippie]

Is de servercode van NDF eigenlijk Open Source? Ik heb voor mijn bot namelijk gebruik gemaakt van het protocol package van de server.
Zo ja, dan post ik mijn java code ook op de opensource pagina.

[Gerco]

Ja, de server is ook Open Source, zie hier: Download server

De source code van de server is opgeslagen in een Subversion repository, onder deze URL: http://hell.student.utwente.nl/svn/GotBot-server

[ Voor 38% gewijzigd door Gerco op 10-08-2005 12:55 ]

[zwippie]

Ok dan, in dat geval staat dan hier mijn GPL Java code voor GotBot. De AI moet je zelf nog schrijven, net als een fancy GUI.

[Ricvdp]

Tuurlijk is hij open-source, anders had jij die protocol-code toch niet kunen hebben?

[zwippie]

Nou, ik weet uit mijn hoofd niet precies hoe het nou zit met alle verschillende licentie mogelijkheden, maar je kan ook ergens de code van hebben zonder dat het open source is.

[zwippie]

Oeps, de door mij hierboven en op de wiki geposte code was van een zeer brakke kwaliteit. Dit kwam doordat ik de rar had samengesteld uit de verkeerde (oude) bestanden.
Je mag zelf beslissen of het niet lag aan mijn brakke programmeer-skills, een overmatig gebruik van verdovende middelen, de kater van vorige week of de kater van morgen.

Anyway, een fatsoenlijke versie is nu te vinden op hetzelfde adres: gotbot_zwippie

[glashio]

Leuk Topic
Gridwars is een shareware versie van jullie battle.

[.oisyn]

Zo, gisteravond een C++ frameworkje in elkaar gefrutseld om te connecten naar de server en die de binnenkomende info om zet naar datastructures. Binnenkort zul je een oisynbot zien roamen op een van de servers

('t Heeft even geduurd omdat we nog altijd niet klaar zijn met ons nieuwe huis, m'n vriendin is op vakantie en ik heb even m'n PC half opgezet in de woonkamer. Heb alleen helaas nog geen adsl, dus 't moet met een old-fashioned modem )

[.oisyn]

Ik stuitte trouwens op een vervelend puntje tijdens het afronden van m'n framework, namelijk de errorafhandeling. Er is totaal geen manier om te bepalen op welk commando je error nou eigenlijk slaat, aangezien een goed commando geen reactie krijgt. Je kunt dan wel gaan wachten op een error, en als je die niet krijgt dan zal er wel geen error zijn, maar dat betekent dat je voor elk afzonderlijk FIRE, MOVE en SCAN commando een maximale roundtriptime kan wachten totdat je kan concluderen dat er idd geen error is. En als je alle factoren meeweegt (lag in het netwerk, drukke server, etc.) lijkt een timeout van ergens tussen de 500 en 1000 ms een goede thresshold, maar dat is natuurlijk veel te veel. Het zou handiger zijn als je bij een goed commando een OK oid terug krijgt. Want dit schiet natuurlijk niet op:

code:

MOVE 0.2 500
SCAN 6
- ERROR 201

Is die error nou voor de scan of voor de move? Het is hier natuurlijk obviously de move omdat je niet 500 units kan bewegen. En nou kun je uiteraard helemaal zelf bepalen of een commando dat je gegeven hebt goed gaat of niet, maar het maakt de errors er niet nuttiger op.

Er zitten ook nog wat onduidelijkheden in de beurtvolgorde. Zo staat er dat je eerst moved voordat je schiet, maar schiet je dan vanaf je nieuwe locatie of je oude? En geldt hetzelfde voor je scan? Ik zou het zo willen voorstellen: je schiet en scant vanaf je huidige locatie, dus nog voordat je de move doet. Pas na de move komt het schot op de locatie aan en krijg je het resultaat van de scan binnen. Dit zorgt ervoor dat je altijd naar de oude locatie van een bot schiet zodat hij kans heeft om weg te komen, maar dat je wel de mogelijkheid hebt om de nieuwe positie van de speler te zien (zodat je 'm eventueel kunt achtervolgen). Ook betekent het dat je wat minder je hoofd hoeft te breken om de vuurpositie aan te passen aan de hand van je move commando, omdat je gewoon kunt schieten in de richting van je scanresultaat.

(Heb de laatste alinea ook aan http://gandalf.lekkerknag...ex.php/Talk:Beurtvolgorde toegevoegd. Wat is het idee van twiki precies, ben er niet zo heel erg bekend mee (het discussiegedeelte bedoel ik dan). Gaan de discussies gewoon hier of kunnen die beter op twiki geplaatst worden? Indien dat laatste, waar zou ik mijn opmerking over die errors dan kwijt kunnen?)

[ Voor 35% gewijzigd door .oisyn op 19-08-2005 01:53 ]

[Jegorex]

.oisyn schreef op vrijdag 19 augustus 2005 @ 01:35:

code:

MOVE 0.2 500
SCAN 6
- ERROR 201

Is die error nou voor de scan of voor de move? Het is hier natuurlijk obviously de move omdat je niet 500 units kan bewegen. En nou kun je uiteraard helemaal zelf bepalen of een commando dat je gegeven hebt goed gaat of niet, maar het maakt de errors er niet nuttiger op.

In je voorbeeldje zijn ze allebij fout, omdat de turnid vergeten is

Als je een goed code en een fout code terug krijgt hoe weet je dan welke code bij welke opdracht hoort?

[.oisyn]

Als je ook goede terugkrijgt betekent dat automatisch dat je voor ieder commando 1 reactie krijgt. Het lijkt me dan niet bijzonder moeilijk om te bepalen om te bepalen wat bij wat hoort . Eventueel zou je erop kunnen wachten ipv je commando's te batchen. Het is natuurlijk wel noodzaak dat de antwoorden in dezelfde volgorde worden teruggestuurd, maar ik ga er vanuit dat de server ze ook in volgorde afhandelt.

[ Voor 38% gewijzigd door .oisyn op 19-08-2005 02:03 ]

[zwippie]

Ik denk dat het protocol in eerste instantie maar zo simpel mogelijk moet blijven hoor.

Als je al een error terug krijgt dan is dat meestal omdat je:
- een ongeldige turnid hebt meegegeven (programmeerfout of lag)
- een ongeldige parameter hebt meegegeven (programmeerfout)
- dood bent (fout in je ai )

Oftwel, als je veel errors terug krijgt betekent dat gewoon dat je een brakke bot hebt geschreven.

[Toiletman]

Staat de boel een beetje stil? Vakantie en introductie snoepen bij mij iig een hoop tijd... veel verder dan een eerste testje met het opslaan van de moves van m'n bot ben ik nog niet.

[.oisyn]

zwippie schreef op vrijdag 19 augustus 2005 @ 03:41:
- een ongeldige turnid hebt meegegeven (programmeerfout of lag)

Precies, dus als je scan en een move doet, en geen results krijgt van de scan en de move valt net buiten de tijd, krijg je dus een error en weet je niet voor welk commando hij gold. En lag is nou eenmaal iets waar je rekening mee moet houden, en dat kan nu dus niet echt.

[Sijmen]

Ik ben nu ook terug van vakantie, en de introductie van school is nu voorbij - het echte schoolleventje begint. Ik ben van plan verder te gaan met m'n bot, maar hard zal het niet gaan.

Good luck verder iedereen

[Scorpion1984]

zwippie schreef op vrijdag 19 augustus 2005 @ 03:41:
Ik denk dat het protocol in eerste instantie maar zo simpel mogelijk moet blijven hoor.

Als je al een error terug krijgt dan is dat meestal omdat je:
- een ongeldige turnid hebt meegegeven (programmeerfout of lag)
- een ongeldige parameter hebt meegegeven (programmeerfout)
- dood bent (fout in je ai )

Oftwel, als je veel errors terug krijgt betekent dat gewoon dat je een brakke bot hebt geschreven.

Ik denk dat het voorstel .oisyn het protocol juist makkelijker maakt. Ik liep tegen hetzelfde probleem aan. Het zou veel makkelijker zijn als je gewoon kunt wachten op een reactie, die reactie verwerkt en dan het volgende commando verstuurd.

[Verwijderd]

Ik probeer dus ook een botje te schrijven om zo mee te doen, en tot zover gaat het aardig.
Toch heb ik een paar vraagjes.

• Na een NEWTURN kunnen er een x aantal berichten komen. Zijn dit alle berichten die van de server kunnen komen (error's, userenter of exit's, hitby's)? En is de volgorde van deze berichten in een vaste volgorde, of kan ik er voor zorgen dat ze in een vaste volgorde komen (door b.v. de fire voor de scan te doen, of net andersom)?
• Komen er wedstrijden, zo ja wanneer komen deze dan. En moet ik mij dan ook ergens aanmelden als ik er klaar voor ben?
• Kan er bij de testserver hell.student.utwente.nl:1666 ook de nieuwe implementatie van de userenters bij komen (dus bij het binnenkomen van een server het verkrijgen van een lijst met alle gebruikers)

[Toiletman]

Ondanks de introductie en het leren van een hertentamen heb ik vandaag toch maar weer wat tijd in m'n botje gestoken.
Er hangt nu een mySQL database achter de PHP bot, waarin nu alleen nog de lijst met bezochte servers en de gemaakte sessies worden opgeslagen. Binnenkort wordt de hele communicatie tussen bot en server ook nog opgeslagen en dan kan ik beginnen met een pagina die deze informatie grafisch weergeeft... nou jah, morgen eerst maar weer met dynamica2 bezig...

Verwijderd schreef op zaterdag 27 augustus 2005 @ 23:37:
Ik probeer dus ook een botje te schrijven om zo mee te doen, en tot zover gaat het aardig.
Toch heb ik een paar vraagjes.

• Na een NEWTURN kunnen er een x aantal berichten komen. Zijn dit alle berichten die van de server kunnen komen (error's, userenter of exit's, hitby's)? En is de volgorde van deze berichten in een vaste volgorde, of kan ik er voor zorgen dat ze in een vaste volgorde komen (door b.v. de fire voor de scan te doen, of net andersom)?

Er kunnen ook nog FIRERESULTS of SCANRESULTS binnenkomen, als het goed is staat over de volgorde waarin die commando's binnenkomen een artikel op de wiki, maar je bent toch niet gebonden aan een vaste volgorde? Je weest sowieso al niet of de berichten uberhaupt komen.

• Komen er wedstrijden, zo ja wanneer komen deze dan. En moet ik mij dan ook ergens aanmelden als ik er klaar voor ben?

Voorlopig is het allemaal nog behoorlijk freewheelen... tegen de tijd dat alle serveradmins en devs weer alive zijn hiero komt er misschien wat meer schot in de zaak.

• Kan er bij de testserver hell.student.utwente.nl:1666 ook de nieuwe implementatie van de userenters bij komen (dus bij het binnenkomen van een server het verkrijgen van een lijst met alle gebruikers)

Ben ik helemaal voor... en trouwens, ik vind eigenlijk ook dat we voortaan bij protocolchanges het versienr moeten veranderen, nu is het idd irritant dat de ene server dingen niet ondersteund die wel in het protocol zitten.

[Verwijderd]

Toiletman schreef op zondag 28 augustus 2005 @ 00:44:

Er kunnen ook nog FIRERESULTS of SCANRESULTS binnenkomen, als het goed is staat over de volgorde waarin die commando's binnenkomen een artikel op de wiki, maar je bent toch niet gebonden aan een vaste volgorde? Je weest sowieso al niet of de berichten uberhaupt komen.

Echt gebonden aan een vaste volgorde ben ik niet, maar het zou iets handiger zijn geweest. Gelukkig kreeg ik vanmorgen een ingeving over een oplossing hoe het ook zou kunnen. Dus dat komt denk ik wel goed.

Voorlopig is het allemaal nog behoorlijk freewheelen... tegen de tijd dat alle serveradmins en devs weer alive zijn hiero komt er misschien wat meer schot in de zaak.

Ok, we horen wel wanneer het zover is

Ben ik helemaal voor... en trouwens, ik vind eigenlijk ook dat we voortaan bij protocolchanges het versienr moeten veranderen, nu is het idd irritant dat de ene server dingen niet ondersteund die wel in het protocol zitten.

Dat is inderdaad wel handig.

[zwippie]

.oisyn schreef op donderdag 25 augustus 2005 @ 18:48:
[...]

Precies, dus als je scan en een move doet, en geen results krijgt van de scan en de move valt net buiten de tijd, krijg je dus een error en weet je niet voor welk commando hij gold. En lag is nou eenmaal iets waar je rekening mee moet houden, en dat kan nu dus niet echt.

Misschien dat het door de server verstuurde error commando aangevuld kan worden met de door de client verstuurde opdracht die niet verwerkt is, dus dan wordt een error iets als:

code:

// move verstuurd met verkeerde turnid:
ERROR 202 MOVE

of met de turnid er nog achter:

code:

// scan verstuurd in beurt 63 met verkeerde parameter:
ERROR 204 SCAN 63

of met de hele foutieve opdracht erbij:

code:

// fire verstuurd in beurt 64 met verkeerde parameter:
ERROR 204 FIRE 64 60.0 boem 5.0

Als je geen error terug krijgt dan kun je er van uitgaan dat je commando is uitgevoerd.
Krijg je wel een fout terug dan is het commando na de errorcode niet uitgevoerd.

In geval van lag krijg je dus je verstuurde commando's terug als error 202.
De laatste variant is waarschijnlijk het makkelijkst omdat deze het hele commando meestuurt.
In het geval dat je dus 10 fire commando's per beurt stuurt, waarvan uiteraard alleen de laatste uitgevoerd zal worden, dan weet je in ieder geval welke er niet uitgevoerd zijn.

Nogmaals, het versturen van verkeerde parameters is eigenlijk je eigen fout en hoeft dus niet door de server 'gecorrigeerd' te worden. Aangezien alle opdrachten van alle clients tegelijkertijd worden uitgevoerd, heb je ook nooit de tijd om daarna nog snel een 'verbeterde' opdracht te versturen.

Lag is inderdaad relevanter, als je bijvoorbeeld je eigen move-geschiedenis bij wilt houden, is het handig om te weten dat er een move niet is uitgevoerd. Agree.

Over de versienummers die mee moeten veranderen met het protocol: Helemaal mee eensch.
Net als dat iedereen die een publieke server draait gewoon de laatste versie moet draaien. Je kunt je verouderde client altijd nog op een lokale server proberen.

[Ricvdp]

Toiletman schreef op zondag 28 augustus 2005 @ 00:44:
[...]

Ben ik helemaal voor... en trouwens, ik vind eigenlijk ook dat we voortaan bij protocolchanges het versienr moeten veranderen, nu is het idd irritant dat de ene server dingen niet ondersteund die wel in het protocol zitten.

Waar slaat dit nou op? Die server is van Soultaker, en zijn bot ondersteunt nog geen USERENTER/USEREXIT. Vandaar dat de oude daar draait. Als je de nieuwe server implementatie wil moet je naar bosselaar.xs4all.nl connecten. Of zelf een server draaien.

[zwippie]

Ricvdp schreef op zondag 28 augustus 2005 @ 20:04:
[...]

Waar slaat dit nou op? Die server is van Soultaker, en zijn bot ondersteunt nog geen USERENTER/USEREXIT. Vandaar dat de oude daar draait. Als je de nieuwe server implementatie wil moet je naar bosselaar.xs4all.nl connecten. Of zelf een server draaien.

Nou, ik vind juist dat alle public servers (public als in: vermeld op de wiki) het nieuwste protocol moeten voeren. Als je zelf wil testen met je oude clientbot dan kun je ook lokaal even een servertje laten draaien. (dat schrijf ik ook hierboven).

Oftwel, Soultaker moet gewoon zijn server een update geven en eens aan zijn client gaan werken.

[H!GHGuY]

ik heb heimwee naar dit project...

m'n bot staat ergens te demagnetiseren op een plakje HD...
ik heb helaas geen tijd, en de vooruitzichten...

blij echter dat Botwars is blijven leven!

[ Voor 15% gewijzigd door H!GHGuY op 29-08-2005 00:00 ]

[.oisyn]

zwippie schreef op zondag 28 augustus 2005 @ 17:37:
[...]

Misschien dat het door de server verstuurde error commando aangevuld kan worden met de door de client verstuurde opdracht die niet verwerkt is, dus dan wordt een error iets als:

code:

// move verstuurd met verkeerde turnid:
ERROR 202 MOVE

of met de turnid er nog achter:

code:

// scan verstuurd in beurt 63 met verkeerde parameter:
ERROR 204 SCAN 63

of met de hele foutieve opdracht erbij:

code:

// fire verstuurd in beurt 64 met verkeerde parameter:
ERROR 204 FIRE 64 60.0 boem 5.0

Als je geen error terug krijgt dan kun je er van uitgaan dat je commando is uitgevoerd.
Krijg je wel een fout terug dan is het commando na de errorcode niet uitgevoerd.

Maar het punt is nou juist dat je niet wéét of er geen error is verstuurd als er geen wordt verstuurd, je ontvangt immers niets. Je kunt pas uitsluiten dat er geen error is verstuurd nadat de roundtrip time en een bepaalde server lag verstreken is, een tijd die sowieso niet vast ligt en waar je ook niet op wilt wachten. Als je gewoon meteen een OK krijgt oid, of een OK MOVE voor mijn part, dan kun je makkelijk wachten op een antwoord.

Nogmaals, het versturen van verkeerde parameters is eigenlijk je eigen fout en hoeft dus niet door de server 'gecorrigeerd' te worden. Aangezien alle opdrachten van alle clients tegelijkertijd worden uitgevoerd, heb je ook nooit de tijd om daarna nog snel een 'verbeterde' opdracht te versturen.

Als je een commando net buiten je beurt stuurt dan wil je daarvan op de hoogte zijn, zodat je daar rekening mee kunt houden in je AI. Als je een andere bot achtervolgt, en je doet een MOVE en een SCAN waarvan de een net buiten de beurt is, dan wil je wel graag weten of je positie nou geupdate is of niet, en of de scan nou gewoon is mislukt of dat je vijand niet meer binnen je scanbereik valt.

[zwippie]

.oisyn schreef op maandag 29 augustus 2005 @ 11:00:
[...]


Maar het punt is nou juist dat je niet wéét of er geen error is verstuurd als er geen wordt verstuurd, je ontvangt immers niets. Je kunt pas uitsluiten dat er geen error is verstuurd nadat de roundtrip time en een bepaalde server lag verstreken is, een tijd die sowieso niet vast ligt en waar je ook niet op wilt wachten. Als je gewoon meteen een OK krijgt oid, of een OK MOVE voor mijn part, dan kun je makkelijk wachten op een antwoord.


[...]

Als je een commando net buiten je beurt stuurt dan wil je daarvan op de hoogte zijn, zodat je daar rekening mee kunt houden in je AI. Als je een andere bot achtervolgt, en je doet een MOVE en een SCAN waarvan de een net buiten de beurt is, dan wil je wel graag weten of je positie nou geupdate is of niet, en of de scan nou gewoon is mislukt of dat je vijand niet meer binnen je scanbereik valt.

Ik snap je probleem niet meer. Gaat dit nou alleen over lag?
Als je commando te laat aankomt op de server en je krijgt een error terug met daarbij het commando dat niet uitgevoerd kon worden, dan ben je er toch? Je kan dan je AI op de hoogte stellen dat bv een move niet is uitgevoerd.

En wat betekent een OK MOVE nu precies? Dat de move op tijd is aangekomen maar nog niet is verwerkt? Of dat de move op tijd is aangekomen en de juiste parameters heeft maar nog niet is verwerkt? Of dat de move op tijd is aangekomen, juist is en verwerkt is?

En dan nog: als je geen OK MOVE ontvangt (maar deze wel verwacht), en de tijd is inmiddels verstreken, dan heb je tóch geen tijd meer om een nieuwe MOVE te sturen.

>> De server stuurt (nu al) direct een ERROR terug als je opdracht te laat komt, veel sneller kan imho niet.

Het gaat hier niet over een super-fail/fool-proof protocol voor nucleair-bewapende robots, maar er wordt verwacht dat je bot de juiste opdrachten op tijd stuurt. Maar misschien dat ik dat te eenvoudig zie.

[.oisyn]

zwippie schreef op maandag 29 augustus 2005 @ 12:24:
[...]

Ik snap je probleem niet meer. Gaat dit nou alleen over lag?

Nou ja dat is een voorbeeld waarbij het geen programming error is, ik kan zo snel geen andere voorbeelden bedenken maar dat wil niet zeggen dat die er niet zijn.

Als je commando te laat aankomt op de server en je krijgt een error terug met daarbij het commando dat niet uitgevoerd kon worden, dan ben je er toch?

Mijn hele punt is, als je geen error terugkrijgt weet je niet of je wel of geen error terug gekregen hebt, omdat je niets terugkrijgt als alles ok is. En dát wil ik graag veranderd zien, want wat er niet is kun je immers niet bewijzen.

Stel ik doe een MOVE, hoe lang moet ik dan volgens jou wachten tot ik de conclusie kan trekken dat hij gelukt is?

[zwippie]

.oisyn schreef op maandag 29 augustus 2005 @ 12:44:
Mijn hele punt is, als je geen error terugkrijgt weet je niet of je wel of geen error terug gekregen hebt, omdat je niets terugkrijgt als alles ok is. En dát wil ik graag veranderd zien, want wat er niet is kun je immers niet bewijzen.

Stel ik doe een MOVE, hoe lang moet ik dan volgens jou wachten tot ik de conclusie kan trekken dat hij gelukt is?

Stel, je verstuurt een MOVE in turn 25.

Je weet dat deze op tijd is aangekomen als:
- je geen ERROR terug krijgt, en
- je de volgende NEWTURN 26 krijgt (je krijgt dus wél altijd iets terug)

Je weet dat deze niet op tijd is aangekomen als:
- je een ERROR terugkrijgt

Waar ligt volgens jou het grote voordeel van het ontvangen van een OK na het versturen van de MOVE? Gaat het er dan om dat je zo door kan krijgen dat een door jou verstuurd correct commando ergens verloren is gegaan in cyberspace (en dus niet is aangekomen op de server)? Het wachten op de OK lijkt mij juist een tijdverspillende bezigheid in dat geval.

We kunnen hier lang over door discussiëren, maar waar het volgens mij om gaat is dat het protocol is opgezet onder het mom van: fire-and-forget en zo weinig mogelijk communicatie tussen server en cliënts. In een andere implementatie van het protocol zou je er voor kunnen kiezen om de server zoveel mogelijk verantwoordelijk te laten zijn voor de staat van de cliënt, maar daar is hier bewust niet voor gekozen.

Doch, ik ben geen protocollen-expert. Misschien heb je wel helemaal gelijk dus, maar ik probeer nog even te beredeneren waarom het nu gaat zoals het gaat.
Mijn inziens komen veel change-requests en vragen namelijk voort uit het feit dat iemand zijn/haar bot op een bepaalde manier heeft geschreven die (net) niet lekker werkt met het protocol. De vraag is dan of er een denkfout/onvolmaaktheid in het protocol zit of in de eigen code.

Maar nogmaals, mocht hier meer vraag naar zijn, dan ben ik de laatste om een OK implementatie tegen te houden. OK.

[Woy]

Je zou ook nog kunnen overwegen om naast een TurnID ook nog een CommandID mee te sturen. Dit zou dan niet meer zijn dan een Nummertje wat je bij elk bericht wat je verstuurd ophoogt. Er hoeft verder op de server niets mee gedaan te worden behalve het terug meesturen met een Error/Ok berichtje

[.oisyn]

zwippie schreef op maandag 29 augustus 2005 @ 13:32:
[...]

Stel, je verstuurt een MOVE in turn 25.

Je weet dat deze op tijd is aangekomen als:
- je geen ERROR terug krijgt, en
- je de volgende NEWTURN 26 krijgt (je krijgt dus wél altijd iets terug)

Right, dus na een commando moet ik altijd gaan zitten wachten op een NEWTURN, en ik kan mijn AI ook niet verder laten gaan aangezien ik niet weet of de move nou gaat lukken of niet. Ik vind het allemaal maar onpraktisch, en de "ingewikkeldheid" om een OK oid toe te voegen ontgaat me even .

Gaat het er dan om dat je zo door kan krijgen dat een door jou verstuurd correct commando ergens verloren is gegaan in cyberspace (en dus niet is aangekomen op de server)? Het wachten op de OK lijkt mij juist een tijdverspillende bezigheid in dat geval.

Nee, het gaat me erom dat je snel uitsluitsel hebt of een commando goed is of niet. Nou heb ik het niet nodig, momenteel negeer ik alle errors zelf, maar een ideaal protocol vind ik het niet echt.

We kunnen hier lang over door discussiëren, maar waar het volgens mij om gaat is dat het protocol is opgezet onder het mom van: fire-and-forget en zo weinig mogelijk communicatie tussen server en cliënts. In een andere implementatie van het protocol zou je er voor kunnen kiezen om de server zoveel mogelijk verantwoordelijk te laten zijn voor de staat van de cliënt, maar daar is hier bewust niet voor gekozen.

Ik vraag me persoonlijk af hoeveel er nou daadwerkelijk over na is gedacht. De meeste hindernissen kom je pas tegen als je een werkelijke implementatie hebt, we kunnen dan wel vast blijven klampen aan de oorspronkelijke opzet maar daar is eigenlijk geen echte reden toe; het protocol kan prima aangepast worden, we zitten immers niet met een al definitief ingevoerd systeem wat backwards compatible moet blijven. En om diezelfde reden lijkt het me daarom ook noodzaak al die kinderziektes er zo snel mogelijk uit te halen, voordat het protocol definitief is. Persoonlijk zie ik alleen maar voordelen en geen nadelen aan een OK notificatie. En omgekeerd zie ik geen voordelen maar wel nadelen aan de huidige opzet. De keuze is voor mij dan ook vrij duidelijk .

Mijn inziens komen veel change-requests en vragen namelijk voort uit het feit dat iemand zijn/haar bot op een bepaalde manier heeft geschreven die (net) niet lekker werkt met het protocol. De vraag is dan of er een denkfout/onvolmaaktheid in het protocol zit of in de eigen code.

Terecht dat je je zoiets afvraagt. Nou ben ik professioneel gamedeveloper en heb de network code van een racegame geschreven. Ik ben zeker niet onfeilbaar maar dit geeft je wellicht een ruwe schatting welke van de twee opties hier van toepassing is .

[Belgar]

.oisyn schreef op maandag 29 augustus 2005 @ 13:48:
Right, dus na een commando moet ik altijd gaan zitten wachten op een NEWTURN, en ik kan mijn AI ook niet verder laten gaan aangezien ik niet weet of de move nou gaat lukken of niet. Ik vind het allemaal maar onpraktisch, en de "ingewikkeldheid" om een OK oid toe te voegen ontgaat me even .

1) de OK kan ook verloren gaan
2) in de praktijk werkt het huidige protocol perfect

Mijn bot draait nu al bijna een maand en ik geloof niet dat er ooit een commando verloren is gegaan. De huidige implementatie van het protocal voldoet gewoon. Het enige wat ik zou doen met de "OK" is >/dev/null, dus schaden doet het me nu ook weer niet

[.oisyn]

Belgar schreef op maandag 29 augustus 2005 @ 14:00:

1) de OK kan ook verloren gaan

De OK kan net zo min verloren gaan als de ERROR of elk ander commando, het is gebouwd op TCP, daarin gaat niets verloren.

2) in de praktijk werkt het huidige protocol perfect

Als je errors negeert ja

[zwippie]

Ik onderschat je kennis van dit onderwerp zéker niet hoor, .oisyn. Dat je hier beter in thuis bent dan menig ander op dit forum (lees: dan ik ) geloof ik direct.

Het zal inderdaad wel te maken hebben met de manier waarop jouw bot werkt en het verschil met de mijne. Mijn bot is vrij simpel en gaat direct na het binnenkomen van een newturn zijn acties bedenken in een methode processTurn(), deze acties worden daarna meteen verstuurd. Een fatsoenlijke time-out zit hier nog niet eens in, ik ga er vanuit dat mijn pc en code snel genoeg zijn om dit binnen 1 seconde te doen.
Misschien heeft jouw bot wel een AI die continue optimale acties aan het berekenen is, op elk moment input kan krijgen, en zijn ouput pas verstuurt als hij daar zin in heeft, dus niet direct na de newturn.

Misschien een vreemd/verkeerd voorbeeld, maar ik bedoel hiermee dat iedere bot anders werkt.

Als een OK en (uitgebreidere) ERROR (toch wel vrij standaard commando's idd) het voor iedereen makkelijker kunnen maken, dan ben ik om en moet dit worden toegevoegd.
Dus, om maar een voorstel te doen:

1. De server stuurt na iedere binnengekomen actie MOVE, FIRE of SCAN een OK <actie> commando terug als:
- de client nog leeft, en
- de actie een juiste turnId heeft, en
- de actie geen constraint violation met betrekking tot de worldinfo in de parameters heeft.
Een OK respons van de server betekent dat de actie gebruikt zal worden voor verwerking. Het betekent niet dat de actie al is uitgevoerd, dat zal pas gebeuren aan het einde van de huidige beurt (of aan het begin van de volgende beurt, het is maar hoe je het bekijkt), wanneer alle acties van alle bots worden verwerkt.
De OK respons zegt niets over de uitkomst van de actie. Als de actie bijvoorbeeld meer energie kost dan de client heeft dan geeft de server alsnog een OK respons.

Voorbeeld:

code:

S->C: NEWTURN 25 0 70.0
C->S: SCAN 25 10.0
S->C: OK SCAN 25 10.0
S->C: NEWTURN 26 1 70.0

2. Het ERROR commando wordt uitgebreid met de actie die de error veroorzaakte.
Voorbeeld:

code:

S->C: NEWTURN 27 0 70.0
C->S: SCAN 30 10.0                               // verkeerde turnId
S->C: ERROR 202 SCAN 30 10.0
C->S: SCAN 27 50.0                               // scanrange te groot
S->C: ERROR 204 SCAN 27 50.0

Andere suggesties zijn uiteraard welkom.

<sub>quote:
2) in de praktijk werkt het huidige protocol perfect

Als je errors negeert ja</sub>

[Verwijderd]

Ricvdp schreef op zondag 28 augustus 2005 @ 20:04:
[...]

Waar slaat dit nou op? Die server is van Soultaker, en zijn bot ondersteunt nog geen USERENTER/USEREXIT. Vandaar dat de oude daar draait. Als je de nieuwe server implementatie wil moet je naar bosselaar.xs4all.nl connecten. Of zelf een server draaien.

Oftoewel, wanneer de server van Soultaker version 2 draait en jij wilt connecten met de nieuwste versie (b.v. 3 met userenter na binnenkomen van server), krijg je op zijn server dus een error. Je kunt dan twee dingen doen: een andere server zoeken die wel met de nieuwste versie werkt of wel naar deze server connecten, maar dan met de gedachte dat je geen userenters krijgt bij het binnenkomen van de server.

Het is dus een groot voordeel wanneer je weet welke versie een server draait, en welke protocol bij welke versie hoort.

[.oisyn]

zwippie schreef op maandag 29 augustus 2005 @ 16:03:
Het zal inderdaad wel te maken hebben met de manier waarop jouw bot werkt en het verschil met de mijne. Mijn bot is vrij simpel en gaat direct na het binnenkomen van een newturn zijn acties bedenken in een methode processTurn(), deze acties worden daarna meteen verstuurd. Een fatsoenlijke time-out zit hier nog niet eens in, ik ga er vanuit dat mijn pc en code snel genoeg zijn om dit binnen 1 seconde te doen.

Mijn bot werkt zo ongeveer exact hetzelfde, met het subtiele verschil dat mijn functie onTurn heet

Misschien heeft jouw bot wel een AI die continue optimale acties aan het berekenen is, op elk moment input kan krijgen, en zijn ouput pas verstuurt als hij daar zin in heeft, dus niet direct na de newturn.

Begrijp me niet verkeerd, ik heb een prima werkende bot en het terugsturen van de volgende commando's gaat zo goed als instantaneous. Ik wilde m'n framework alleen uitbreiden met error reporting, alleen bleek dat nog best lastig aangezien ik niet wist waar de error nou bij hoorde (aangezien ik steeds meerdere commando's tegelijk verstuurde), en ik ook niet echt kon uitsluiten of een actie nou goed geweest is aangezien er niets komt als er geen error is (wat dus net zo goed kan betekenen dat er wel een error is, alleen dat het wat langer duurt door lag e.d.).

Ik ondervind zelf dus momenteel, aan de bot-kant, nog niet echt "last" van het protocol, ik heb alleen ontdekt dat er wat kinderziektes in zitten. In je voorstel kan ik me helemaal vinden, maar als je iets doet waarvoor je geen energie hebt, ga je dan niet gewoon dood? Dit is op een oude versie 2 server die ik op m'n PC heb staan wel het geval namelijk

[Verwijderd]

Ik zal eens kijken of ik volgende week weer tijd heb voor dit project, was erg cool en verheug me er al weer op om het systeem weer eens te bekijken. Begin meteen met het compleet herschrijven van mijn bot, wat dingen verbeteren

[Verwijderd]

.oisyn schreef op maandag 29 augustus 2005 @ 16:21:

Ik ondervind zelf dus momenteel, aan de bot-kant, nog niet echt "last" van het protocol, ik heb alleen ontdekt dat er wat kinderziektes in zitten. In je voorstel kan ik me helemaal vinden, maar als je iets doet waarvoor je geen energie hebt, ga je dan niet gewoon dood? Dit is op een oude versie 2 server die ik op m'n PC heb staan wel het geval namelijk

Dat is toch ook logisch dat je dood bent wanneer je zelf al je energy opgebruikt. Het is namelijk aan de bot om dat zelf in de gaten te houden, dit maakt het schrijven van de bot iets leuker. Je kunt namelijk ook je zelf beschieten, maar dat moet je zelf dus ook zien te voorkomen