[Alg] Nieuwe GoT contest?

[NDF82]

phYzar schreef op maandag 25 april 2005 @ 15:40:

code:

//connection data
Connecting...
Connected
Client: VERSION 1
Client: USER phYzar
Server: VERSION 1
Server: USER phYzar
Worldinfo received
WORLDINFO WIDTH=750 HEIGHT=750 MAX_BATTERY=100 TURN_ENERGY=10 MAX_ENERGY_MOVE_DISTANCE=10 MAX_ENERGY_FIRE_DISTANCE=10 MAX_ENERGY_FIRE_BLAST_RADIUS=10 MAX_ENERGY_SCAN_RADIUS=10 ENERGY_COST_MOVE_DISTANCE=1 ENERGY_COST_FIRE_DISTANCE=1 ENERGY_COST_FIRE_BLAST_RADIUS=1 ENERGY_COST_SCAN_RADIUS=1 HIT_DAMAGE=25
Field dimensions 750x750
Battery is 100% max
Hit damage is 25% per hit
New turn
Turn: 112588
Battery: 60%
No followup
Client: MOVE 112588 0 10
Client: SCAN 112588 1
New turn
Turn: 112589
Battery: 0%
I'm dead! :*( 
Client: QUIT
Disconnecting...

alle waardes in het protocol zijn absoluut hoor, ik snap niet hoe je aan die percentages komt.

MAX_BATTERY=100 --> je battery kan maximaal 100 energy units bevatten.
HIT_DAMAGE=25 --> wanneer je je in de blast radius van een granaat bevind verlies je 25 energy units. Dus wanneer je battery 75 is en je wordt geraakt hou je nog 50 over.

Dat je battery nog maar 0 is na een scan van 1 duidt op een bug. Ik zal vanavond eens kijken. Overigens moeten alle waarden in de worldinfo nog geconfigureerd worden, ik heb nu zomaar wat ingevuld.

Nog even een voorbeeldje van een MOVE met ENERGY_COST_MOVE_DISTANCE=0.5

MOVE 1234 0 10

1234 = turn_id
0 = direction (in radialen)
10 = de energy die voor de move gebruikt moet worden.

Om je 1 unit (unit zou meter kunnen zijn) in de wereld te kunnen bewegen moet je ENERGY_COST_MOVE_DISTANCE aan energy betalen. Dus met 10 energy units kun je een afstand van 10/0.5=20 meter afleggen.

[phYzar]

NDF82 schreef op maandag 25 april 2005 @ 16:15:
[...]

alle waardes in het protocol zijn absoluut hoor, ik snap niet hoe je aan die percentages komt.

(Die percentages zijn gewoon de opgegeven waardes met een % teken erachter, niks aan omgerekend ofzo.)

MAX_BATTERY=100 --> je battery kan maximaal 100 energy units bevatten.
HIT_DAMAGE=25 --> wanneer je je in de blast radius van een granaat bevind verlies je 25 energy units. Dus wanneer je battery 75 is en je wordt geraakt hou je nog 50 over.

Dat je battery nog maar 0 is na een scan van 1 duidt op een bug. Ik zal vanavond eens kijken. Overigens moeten alle waarden in de worldinfo nog geconfigureerd worden, ik heb nu zomaar wat ingevuld.

Duidelijk

Nog even een voorbeeldje van een MOVE met ENERGY_COST_MOVE_DISTANCE=0.5

MOVE 1234 0 10

1234 = turn_id
0 = direction (in radialen)
10 = de energy die voor de move gebruikt moet worden.

Om je 1 unit (unit zou meter kunnen zijn) in de wereld te kunnen bewegen moet je ENERGY_COST_MOVE_DISTANCE aan energy betalen. Dus met 10 energy units kun je een afstand van 10/0.5=20 meter afleggen.

Bedankt voor je uitleg. Als ik het goed begrijp zal ik, doorgaand op jouw voorbeeld, wanneer de server aangeeft dat het veld 750 breed is dus (750*0,5) 375energy nodig hebben om het veld over/rond te rijden.

//edit:
Ik blijf lastig
Is het feit dat de server een move van 15 pikt ondanks max_energy_move_distance van 10 en energy_cost_move_distance van 1 niet ook een bug in de server?

code:

//connection data
Connecting...
Connected
Client: VERSION 1
Client: USER phYzar
Server: VERSION 1
Server: USER phYzar
Worldinfo received
WORLDINFO WIDTH=750 HEIGHT=750 MAX_BATTERY=100 TURN_ENERGY=10 MAX_ENERGY_MOVE_DISTANCE=10 MAX_ENERGY_FIRE_DISTANCE=10 MAX_ENERGY_FIRE_BLAST_RADIUS=10 MAX_ENERGY_SCAN_RADIUS=10 ENERGY_COST_MOVE_DISTANCE=1 ENERGY_COST_FIRE_DISTANCE=1 ENERGY_COST_FIRE_BLAST_RADIUS=1 ENERGY_COST_SCAN_RADIUS=1 HIT_DAMAGE=25
Field dimensions 750x750
Battery is 100 max
Hit damage is 25 energy per hit
New turn
Turn: 114633
Battery: 60%
No followup
Client: MOVE 114633 0 15
New turn
Turn: 114634
Battery: 55%
No followup
Client: MOVE 114634 0 15
New turn
Turn: 114635
Battery: 50%
No followup
Client: MOVE 114635 0 15
.
.
~etc
.
.
Client: QUIT
Disconnecting...
Disconnected

[ Voor 28% gewijzigd door phYzar op 25-04-2005 16:48 ]

[dotnetter]

Ik heb nog even een wat algemenere vraag,

Eerder in het topic (weet niet meer precies waar) is gezegd dat de bot totaal geen output mag geven op de pc, dus bijvoorbeeld in een console, nu we een nieuwe projectleider hebben en een nieuwe server-devver zou ik graag van jullie willen horen welke output mijn bot mag geven.

Mag hij bijvoorbeeld, alsie dood is, mij een email sturen of iets in de console waarin hij draait afdrukken?

De voornaamste reden waarom ik gegevens nodig heb is dat wanneer er regelmatig fouten optreden ik dit wel graag wil weten, als ik geen input van de bot krijg weet ik ook niet of er fouten optreden en kan het zijn dat de bot maar een beetje om zich heen staat te kijken op de server (of telkens dood gaat).

[Voutloos]

Ik zou niet weten waarom je geen output mag zien. Zolang je bot maar niet profiteert van extra input.

[dotnetter]

Nou ik dus ook niet echt, echter denk ik wel dat je er altijd van zult profiteren, als je erachter komt dat je strategie niet goed werkt doordat je bot je om de 3 seconden mailt dattie dood is kun je daar zeker weten van profiteren lijkt me..

Daarnaast wil ik ook nog eens even de vraag die ik hierzo stelde aan het daglicht brengen, als hier meer mensen problemen mee hebben laat dat dan even weten, ik heb nu een timeout van 50ms moeten inbouwen na iedere scan/fire/move, het lijkt me toch een stuk makkelijker om even een "OK" of "ERROR" terug te sturen.

Als hier niet meteen een beslissing over gemaakt kan worden kunnen we misschien even een poll aanmaken om na te gaan wie er nog meer zo over denkt.

[Verwijderd]

dotnetter schreef op maandag 25 april 2005 @ 19:00:
Daarnaast wil ik ook nog eens even de vraag die ik hierzo stelde aan het daglicht brengen, als hier meer mensen problemen mee hebben laat dat dan even weten, ik heb nu een timeout van 50ms moeten inbouwen na iedere scan/fire/move, het lijkt me toch een stuk makkelijker om even een "OK" of "ERROR" terug te sturen.

Het is wel een programmeerwedstrijd; je zorgt er maar voor dat je bot geen domme dingen doet

[NDF82]

Is het feit dat de server een move van 15 pikt ondanks max_energy_move_distance van 10 en energy_cost_move_distance van 1 niet ook een bug in de server?

Ik heb even gekeken en deze feature is helaas nog niet ingebouwd . Maar we moeten even nadenken of het niet houden aan dit soort regels de dood tot gevolg heeft, dat er een error gestuurd wordt of dat er helemaal niks gebeurd.

Persoonlijk vind ik dat je dan je tank overbelast en dood gaat.

[phYzar]

NDF82 schreef op maandag 25 april 2005 @ 19:52:
[...]


Ik heb even gekeken en deze feature is helaas nog niet ingebouwd . Maar we moeten even nadenken of het niet houden aan dit soort regels de dood tot gevolg heeft, dat er een error gestuurd wordt of dat er helemaal niks gebeurd.

Persoonlijk vind ik dat je dan je tank overbelast en dood gaat.

Netjes zou zijn om gewoon waardes die over max heen gaan gewoon afhakken, dus een move van 15 bij max 10 wordt gewoon 10. Streng zou zijn een "boete" te geven, bijvoorbeeld beurt ongeldig/overslaan, geen turn_energy, oid. Kicken/dood gaan is wel erg streng denk ik.

Over die serverresponse na een actie: Er zijn 3 delen: de server, de client, en de verbinding. De client maakt geen fouten als je goed programmeerd (das nou de wedstrijd) en als de server/verbinding iets fout doet heb je grotere problemen dan dat je binnen je turn kan oplossen.

[Asperientje]

ik zou iig graag wel een specificatie willen van NDF's server of de code, want dan kan ik iig een bot bouwen voor zijn server.

ik heb nu wel een communicatie ding voor mn bot in elkaar geknutseld, maar mij is niet egt bekend wat alle commando's doen en hoe, en dat zou k graag willen weten...
ook welke commando's er zijn bij zijn server-implementatie bijvoorbeeld

verder wil k graag weten of er ook wat gedaan gaat worden met de server die ik gebakken heb (SoulTaker???)

[phYzar]

Asperientje schreef op maandag 25 april 2005 @ 20:18:
ik zou iig graag wel een specificatie willen van NDF's server of de code, want dan kan ik iig een bot bouwen voor zijn server.

ik heb nu wel een communicatie ding voor mn bot in elkaar geknutseld, maar mij is niet egt bekend wat alle commando's doen en hoe, en dat zou k graag willen weten...
ook welke commando's er zijn bij zijn server-implementatie bijvoorbeeld

deze?

[LAN]

Kan ik ook mijn huidige locatie opvragen?
Of moet ik die zelf bijhouden? Zo ja, waar begin ik dan? (ook met het oog op een war straks, ik neem aan dat 2 bots niet allebei op locatie 0,0 starten)

Worden de documenten ook bijgewerkt/gecentraliseerd m.b.t. pwcontest.nl? Of wordt die site niet meer gebruikt.

Waar begint 0,0? Links boven? Links onder?

[ Voor 7% gewijzigd door LAN op 25-04-2005 21:22 ]

[dotnetter]

@LAN
Goeie vraag, als ik wil schieten naar de hand van scan-results moet ik precies weten waar ik sta op het veld, van scanresult krijg ik coordinaten door en ik neem aan dat die niet gerelateerd zijn aan mijn huidige positie.

Als ik echter wil schieten moet ik Direction en Distance opgeven, die zal ik dan toch eerst moeten berekenen adhv mijn huidige coordinaten. Overigens weet ik nog niet precies hoe..

Wat is de Direction bij het schieten?
In de specs staat

code:

<direction>  ::= [0<=x<=2pi]

dit betekend volgens mij dat 2*Pi == 360 graden, dus als ik naar het noorden wil schieten moet ik mikken op 2*Pi , als ik naar het zuiden wil mikken 1*Pi westen 1,5*Pi etc..

Klopt dit?

[NDF82]

Goeie vraag, als ik wil schieten naar de hand van scan-results moet ik precies weten waar ik sta op het veld, van scanresult krijg ik coordinaten door en ik neem aan dat die niet gerelateerd zijn aan mijn huidige positie.

Deze zijn relatief. Er is echter al een voorstel geweest om dit te veranderen naar distance en directions (van _J_R_R volgens mij).

Wat je zei van die richting (noord is 0 of 2pi) klopt.

[dotnetter]

NDF82 schreef op maandag 25 april 2005 @ 21:51:
Deze zijn relatief. Er is echter al een voorstel geweest om dit te veranderen naar distance en directions (van _J_R_R volgens mij).

Lijkt me een strak plan, dat bespaart het nodige rekenwerk iig, en als het makkelijk te implementeren is waarom niet .

[ Voor 2% gewijzigd door dotnetter op 25-04-2005 22:12 . Reden: @NDF82 weggehaald. ]

[H!GHGuY]

dotnetter schreef op maandag 25 april 2005 @ 21:58:
[...]


Lijkt me een strak plan, dat bespaart het nodige rekenwerk iig, en als het makkelijk te implementeren is waarom niet .

hoe ik m'n implementatie wil is het een pain in the ass...
ik zal me'n kop er nog wel over breken

[zwippie]

LAN schreef op maandag 25 april 2005 @ 20:59:
Kan ik ook mijn huidige locatie opvragen?
Of moet ik die zelf bijhouden? Zo ja, waar begin ik dan? (ook met het oog op een war straks, ik neem aan dat 2 bots niet allebei op locatie 0,0 starten)

Worden de documenten ook bijgewerkt/gecentraliseerd m.b.t. pwcontest.nl? Of wordt die site niet meer gebruikt..

Waar begint 0,0? Links boven? Links onder?

Voor zover ik het begrijp maakt dat laatste niks uit. Het veld heeft een grootte die je doorkrijgt via WORLDINFO, de randen van het veld lopen door naar de andere kant, dus als je er rechts uitrijdt kom je links het veld weer binnen.
Als je er vanuit gaat dat je zelf op (0,0) begint, dan kun je bijhouden wanneer je het veld rond bent gegaan.
Dan moet je trouwens wel weten hoe de server de coordinaten afrondt als je niet precies in een richting nozw rijdt of gewoon maar een halve eenheid naar links beweegt. NDF82?

[Woy]

De startlocatie haalt inderdaad niks uit als alle coordinaten relatief zijn. Tuurlijk houdt de server de locaties wel absoluut bij maar je begint gewoon op een locatie en je kan er van uit gaan dat het veld gewoon een soort bol is ( Dat will zeggen een rechthoek die doorloopt in zichzelf ) dan haalt je absolute positie voor je bot niet zoveel uit.

[dotnetter]

Dus in principe kunnen we ervan uit gaan dat alle locatie-gegevens die je bot binnenkrijgt relatief zijn aan je huidige positie en nooit absoluut op het speelveld, ook bij latere aanpassingen aan de server en het protocol.
Toch NDF82?

[azteke]

phYzar schreef op maandag 25 april 2005 @ 19:59:
[...]


Netjes zou zijn om gewoon waardes die over max heen gaan gewoon afhakken, dus een move van 15 bij max 10 wordt gewoon 10. Streng zou zijn een "boete" te geven, bijvoorbeeld beurt ongeldig/overslaan, geen turn_energy, oid. Kicken/dood gaan is wel erg streng denk ik.

Over die serverresponse na een actie: Er zijn 3 delen: de server, de client, en de verbinding. De client maakt geen fouten als je goed programmeerd (das nou de wedstrijd) en als de server/verbinding iets fout doet heb je grotere problemen dan dat je binnen je turn kan oplossen.

Precies zoals je zelf zegt: De client maakt geen fouten. Het zou hetzelfde zijn als je teveel buskruit in je kanon zou stoppen, hij zal uit elkaar knallen. Het minste wat je eigenlijk wel mag doen is bepalen of je genoeg energie hebt om iets te doen, zodra je meer gebruikt is je tank overbelast, IMHO.

[phYzar]

Azteke schreef op dinsdag 26 april 2005 @ 12:52:
[...]


Precies zoals je zelf zegt: De client maakt geen fouten. Het zou hetzelfde zijn als je teveel buskruit in je kanon zou stoppen, hij zal uit elkaar knallen. Het minste wat je eigenlijk wel mag doen is bepalen of je genoeg energie hebt om iets te doen, zodra je meer gebruikt is je tank overbelast, IMHO.

Juist

De vraag wordt dan dus ook: Hoe zwaar bestraf je zoiets? De server laten corrigeren voor de fout? Een boete geven in de vorm van beurt overslaan of tijdelijk niet opladen van battery, of hoe verder je de max overschrijdt hoe meer damage je zelf krijgt als gevolg, zodat het zelfs een spelelement zou kunnen worden om het risico te nemen.

[Verwijderd]

De server hoort te controleren of je niet meer gebruikt dan is toegestaan, dus dan is het een kleine moeite om 'af te kappen' zoals eerder aangegeven. Een 'boete' geven zou ik kinderachtig vinden aangezien het toch niet als cheat gebruikt kan worden als de server sowieso de waarden controleert.

[Mithrandir]

Errr, waarom is de draaihoek die je stuurt tussen 0 en 2pi? Dan krijg je allemaal floats binnen... Is het niet simpeler om daar gewoon 0 tot 360 graden van te maken?

[MisterData]

Mithrandir schreef op dinsdag 26 april 2005 @ 17:24:
Errr, waarom is de draaihoek die je stuurt tussen 0 en 2pi? Dan krijg je allemaal floats binnen... Is het niet simpeler om daar gewoon 0 tot 360 graden van te maken?

Dan heb je ook maar een precisie van 1 graad als je die in een integer stopt... float's oversturen lijkt me geen probleem? En daarnaast werken in de meeste programmeertalen functies als sin en cos liever met radialen in plaats van graden (en radialen is dus meestal tussen 0 en 2pi, hoewel daarbuiten natuurlijk ook kan, zelfs negatief)

[dotnetter]

Wat ik graag wil weten if of het FIRE commando nog gaat veranderen en wanneer we kunnen scannen, kzit nu een beetje te kijken met men bot, maar ik kom zonder scannen niet veel verder.
En ik heb geen zin om die hele berekening te gaan proggen terwijl we later gewoon op distance en direction kunnen schieten..

[phYzar]

dotnetter schreef op dinsdag 26 april 2005 @ 18:39:
Wat ik graag wil weten if of het FIRE commando nog gaat veranderen en wanneer we kunnen scannen, kzit nu een beetje te kijken met men bot, maar ik kom zonder scannen niet veel verder.
En ik heb geen zin om die hele berekening te gaan proggen terwijl we later gewoon op distance en direction kunnen schieten..

Ik stem voor om de scangegevens te houden zoals ze zijn, dus gewoon relatieve locaties zonder directions. En ik stem voor om het overschreiden van max-waardes door de server te laten afkappen zonder verdere gevolgen. En als bovengenoemde bug ook gefixt is kunnen de verschillende bot-bouwers ook verder. Zo komen er tenminste ook andere zaken aan het licht waar dan weer over nagedacht kan worden/gefixt kan worden.

Dus het is aan Soultaker/NDF om even wat knoopjes te hakken/kreukjes te strijken.

//edit
Het lijkt me ook wel een idee om met de scanresult de username van de gescande bot mee te geven. Zo kun je bij een scan met veel results de bots en hun positie tov de vorige scan goed uit elkaar houden, anders is het maar een beetje prijsschieten op het dichtstbijzijnde slachtoffer.

[ Voor 14% gewijzigd door phYzar op 26-04-2005 19:23 ]

[dotnetter]

phYzar schreef op dinsdag 26 april 2005 @ 19:11:
[...]

Ik stem voor om de scangegevens te houden zoals ze zijn, dus gewoon relatieve locaties zonder directions.

Waarom wil je het zo houden, waarom niet dezelfde parameters als bij MOVE en FIRE?? Dat is toch veel eenvoudiger, waarom zou je met twee verschillende waarden werken als je net zo goed gewoon alles hetzelfde kan houden.

Ik zeg, of ALLES X,Y of ALLES direction,distance.

Als je die allebei door elkaar gaat gebruiken en telkens moet gaan omrekenen vind ik het gewoon verspilde CPU-tijd.

[Verwijderd]

phYzar schreef op dinsdag 26 april 2005 @ 19:11:

En ik stem voor om het overschreiden van max-waardes door de server te laten afkappen zonder verdere gevolgen.

Tegen! Dit is een programmeerwedstrijd, dat houdt in dat je mag verwachten dat dat soort dingen niet gebeuren. Natuurlijk kan iedereen een foutje maken, maar alsnog is dit een slecht idee, omdat:

1. Je kan ook gemakkelijk client-side een checkje inbouwen die de waardes afkapt. Zo hebben de mensen die dit niet willen er geen last van.
2. Je bot gaat dingen doen die je niet verwacht. Ik heb liever dat ik een error terugkrijg (dan kan ik overnieuw proberen) of dat ik eruit geschopt wordt (dan had ik maar geen fouten moeten maken), dan dat er opeens dingen gebeuren die je niet verwacht.

Dus: of een error terug, of eruit schoppen. 'Afkappen' is nergens goed voor.

[phYzar]

dotnetter schreef op dinsdag 26 april 2005 @ 19:38:
[...]


Waarom wil je het zo houden, waarom niet dezelfde parameters als bij MOVE en FIRE?? Dat is toch veel eenvoudiger, waarom zou je met twee verschillende waarden werken als je net zo goed gewoon alles hetzelfde kan houden.

Ik zeg, of ALLES X,Y of ALLES direction,distance.

Als je die allebei door elkaar gaat gebruiken en telkens moet gaan omrekenen vind ik het gewoon verspilde CPU-tijd.

Een move/fire is een actie van jou naar een bepaalde richting, met een bepaalde kracht. Een scan is dat niet, maar puur jouw radar. Als die jou gaat uitleggen hoe je je doel moet raken wordt het al minder een sport om dat te doen. En voor het gemak: als je 1vs1 speelt en je wilt direct gaan schieten is het handig om gelijk de juiste data te hebben. Als het XvsX is en je zou willen ontwijken/achtervolgen is het hebben van een coördinaat misschien wat handiger om voor jezelf een beeld te vormen van het slachtgveld.

Verwijderd schreef op dinsdag 26 april 2005 @ 20:00:
Dus: of een error terug, of eruit schoppen. 'Afkappen' is nergens goed voor.

Als dat de keus is dan kies ik voor een error.

[mocean]

Scans teruggeven in een X en Y (en identificatie) maakt het eenvoudiger om bots te volgen. (zonder identificatie wordt het een stukje moeilijker)

Schieten is logischer in een richting met snelheid. Het is tenslotte geen zeeslag

Ik ben wel voor van het afkappen van te grote waardes. vergelijk het met een FPS, als je tegen een muur loopt en je blijft op een pijltje drukken, dan loop je gewoon niet, klaar. Misschien kan je wel ook de energie aftrekken voor het stuk dat je niet kan/mag lopen, dat is dan een soort van boete.

[NDF82]

Ik vind dat er niet afgehakt moet worden en dat je dood gaat. Het is een programmeer wedstrijd en de bedoeling is dat er slimme bots gemaakt worden. Die moeten er dus zelf voor zorgen dat ze niet overbelast raken en dood gaan.

[mr.inno]

code:

<<< NEWTURN 40903 0 60
<<< NEWTURN 40904 0 70
<<< NEWTURN 40905 0 80
<<< NEWTURN 40906 0 90
<<< NEWTURN 40907 0 100
<<< NEWTURN 40908 0 0
<<< NEWTURN 40909 0 0
<<< NEWTURN 40910 0 0

is het de bedoeling dat waneer ik dood hoor te zijn ik nog niewe turns krijg?

[NDF82]

In deze implementatie wel. Maar omdat je dood bent krijg je USER_IS_DEAD (203) als je een actie probeert uit te voeren. Kan eventueel veranderd worden, maar denk niet dat dat op dit moment prioriteit heeft.

Op dit moment is het aan de project leider om een implementatie van de server te kiezen. Daarna zien we wel weer verder.

[Asperientje]

NDF82, ik had een vraagje over het scancommando op jouw serverinplementatie, want die werkt volgens mij niet helemaal compleet..
als ik namelijk scan, en volgens het protocol ok en geen error krijg, dan ben k dood...
er gebeurt het volgende bij mn client:

code:

VERSION 1
USER Asperientje
WORLDINFO WIDTH=750 HEIGHT=750 MAX_BATTERY=100 TURN_ENERGY=10 MAX_ENERGY_MOVE_DISTANCE=10 MAX_ENERGY_FIRE_DISTANCE=10 MAX_ENERGY_FIRE_BLAST_RADIUS=10 MAX_ENERGY_SCAN_RADIUS=10 ENERGY_COST_MOVE_DISTANCE=1 ENERGY_COST_FIRE_DISTANCE=1 ENERGY_COST_FIRE_BLAST_RADIUS=1 ENERGY_COST_SCAN_RADIUS=1 HIT_DAMAGE=25
NEWTURN 44756 0 60
NEWTURN 44757 0 70
NEWTURN 44758 0 80
NEWTURN 44759 0 90
MOVE 44759 0 26
NEWTURN 44760 0 74
SCAN 44760 26
NEWTURN 44761 0 0
NEWTURN 44762 0 0

(het kan zijn dat ik iets over het hoofd gezien heb hoor )

[phYzar]

Asperientje schreef op woensdag 27 april 2005 @ 19:19:
(het kan zijn dat ik iets over het hoofd gezien heb hoor )

Ja, een paar eerdere posts over hetzelfde probleem

[Mischa_NL]

Woei, Gelukt om met de server te connecten in c#. Ik denk laat ik het ook maar eens proberen.
Redelijk simpel opzich .

Maar ik heb toch een vraag. Misschien is hij al gesteld maar om nou 30 pagina's te gaan lezen...
Waarom moet ik in godsnaam een turnid invoeren bij scan en fire?
Is dat omdat ik acties kan instellen voordat de turn is aangebroken?

Bijvoorbeeld:
turn=1
SCAN 5 10

Zodat hij op beurt 5 pas gaat scannen??

[Asperientje]

helaas zit dit nog niet in de server van NDF82, ik heb dit zelf maar clientside geimplementeerd.
ik denk dat het eerder is om te voorkomen dat de client meerdere dingen tegelijkertijd probeert te doen, en hij zo bugs probeert te voorkomen....

verder vind ik het wel handig als je bijv. 8 (oid) commando's vooruit kan cachen op de server

[dotnetter]

@NDF82,

Wanneer denk je dat je die scan-bug eruit gaat halen? Ik wil graag testen met men bot. Ik kan nu niet echt veel verder...

[DaCoTa]

Als een bot niks doet, gaat die dan ook dood door een battery overflow? Wat ik zie is nml. dat ik met battery 60 begin, er per beurt 10 bij krijg maar de beurt na 100 ben ik dood. Een batterij die een laadstop heeft, lijkt me toch niet zo hightech dat je daar zelf voor moet zorgen, of wel?

edit:
Ik heb het over de server op gotbot.lekkerknagen.nl:666

[ Voor 11% gewijzigd door DaCoTa op 28-04-2005 01:15 ]

[NDF82]

Wanneer denk je dat je die scan-bug eruit gaat halen? Ik wil graag testen met men bot. Ik kan nu niet echt veel verder...

Hij is eruit. Echter, je scant jezelf nu ook. Ik laat dit even zo zodat je ziet dat de Scan daadwerkelijk iets doet Ik voeg straks wel een check toe.

[phYzar]

NDF82 schreef op donderdag 28 april 2005 @ 19:37:
[...]

Hij is eruit. Echter, je scant jezelf nu ook. Ik laat dit even zo zodat je ziet dat de Scan daadwerkelijk iets doet Ik voeg straks wel een check toe.

Getest en het werkt Nu kan ik weer lekker verder rommelen met mn GotBot (nu nog een tegenstander als test )

//edit: nou doetie het niet meer dotnetter/mocean/mr.inno/asperientje/Mischa_NL (wat een lijst met testers al ) zelfde probleem?

//edit 2: server reageerd ook sneller, krijg nu vaak bevestiging van username+worldinfo+1e turn tegelijk (niks mis mee, maar viel me op)

//edit 3: Ik weet nog steeds niet wie ik scan, zou er ook de username bij de scanresults vermeld kunnen worden?

[ Voor 36% gewijzigd door phYzar op 28-04-2005 20:41 ]

[WAcKiN]

Oh hey, leuk, dit topic had ik al eens eerder gezien maar zo te zien zit er nu weer voortgang in. Ik heb een beetje teruggelezen, maar op een gegeven moment is de 'signal-to-noise ratio' niet bijster groot meer. Het is moeilijk hier op pagina 26-ofzo nog de complete status te achterhalen voor iemand die het terugleest of er later bij komt, zoals ik.

Het lijkt me het beste een website of nog beter een Wiki (wat al gesuggereerd was) ergens neer te zetten met de huidige status en alle relevantie informatie (regels van het spel/server en het protocol) en eventueel links naar een bruikbare test-server? Ook lijkt het me handig wat generieke test-tegenstanders te maken, aangezien je graag wel dingen hebt om op te schieten ...

P.S. Hey Soultaker, ik zie dat ze jou verkozen hebben tot 'project leider', ocharme!

[Verwijderd]

WAcKiN schreef op donderdag 28 april 2005 @ 20:30:
Het lijkt me het beste een website .... enz...

Er was eerst www.pwcontest.nl, maar die doet het niet meer (de website iig niet op het moment, server en domein bestaan nog wel)

[DaCoTa]

phYzar schreef op donderdag 28 april 2005 @ 19:46:
//edit: nou doetie het niet meer dotnetter/mocean/mr.inno/asperientje/Mischa_NL (wat een lijst met testers al ) zelfde probleem?

Hier is het scan=dood, ook al scan ik een radius van 1. En heeft iemand wat te zeggen over een laadstop voor de batterij? Lijkt me nogal een domme manier om dood te gaan, of is dat een manier van een automatische timeout?

Daarnaast, krijg je bij een nieuwe beurt eerst de energie erbij, worden eerst de acties uitgevoerd, of worden de kosten van de acties gedisconteerd van de nieuwe energie en daarna het batterijnivo bijgewerkt? Dat laatste lijkt met nml. het meest logisch.

[phYzar]

DaCoTa schreef op vrijdag 29 april 2005 @ 00:46:
[...]

Hier is het scan=dood, ook al scan ik een radius van 1. En heeft iemand wat te zeggen over een laadstop voor de batterij? Lijkt me nogal een domme manier om dood te gaan, of is dat een manier van een automatische timeout?

Een laadstop is wel een goed plan, maar ik zou eerst eens willen zien hoe de huidige situatie verloopt in een battle. Ik weet niet of het echt storend is als je af en toe eens in het wilde weg schiet of een grote scan uitvoert om onder de grens te blijven, het blijft een spelelement.

Daarnaast, krijg je bij een nieuwe beurt eerst de energie erbij, worden eerst de acties uitgevoerd, of worden de kosten van de acties gedisconteerd van de nieuwe energie en daarna het batterijnivo bijgewerkt? Dat laatste lijkt met nml. het meest logisch.

Volgens mij werkt het op de huidige server op de laatste manier.

Hmmz, de laatste pagina's zijn erg veel dingen voorbij gekomen. Om het niet te laten verzanden in een debugthread een overzichtje:

Scan:
- werkt niet Gefixt (geeft ook je eigen locatie als scanresult, als test)
- uitbreiden met weergeven van username
- coördinaat of direction/distance?

Batterij:
- Laadstop?

Turns:
- Vooruit plannen/doorsturen acties
- Na dood worden er nog nieuwe turns gestuurd

Acties:
- Bevestiging acties
- Overschreiden max_waardes bestraffen/afkappen?
- Zien of je iemand hebt geraakt

[ Voor 5% gewijzigd door phYzar op 29-04-2005 01:30 ]

[RobIII]

Verwijderd schreef op donderdag 28 april 2005 @ 20:43:
[...]


Er was eerst www.pwcontest.nl, maar die doet het niet meer (de website iig niet op het moment, server en domein bestaan nog wel)

*kuch*
Ook Raid5 kan crashen
Ik ben het momenteel aan 't fixen. Over 5 minuten terug

Mocht iemand nog zin hebben een mooie leuke site te devven: Ik heb een HD voor je (voor de hosting) en het domein. Het enige wat je moet doen is uploaden. IIS (asp is dus mogelijk) met MSSQL. Ik doe (liever) niet aan Apache/PHP/MySQL maar verder is bijna alles mogelijk.

[ Voor 29% gewijzigd door RobIII op 29-04-2005 01:23 ]

[NDF82]

zo, nu is de scan bug opgelost. De radius werd verkeerd gezet. Die was hetzelfde als de turnId.

[DaCoTa]

NDF82 schreef op vrijdag 29 april 2005 @ 01:21:
zo, nu is de scan bug opgelost. De radius werd verkeerd gezet. Die was hetzelfde als de turnId.

Yep, wat ik nu nog zie is dat er een scanresult terugkomt (idd van mezelf) voor er een newturn ontvangen is. En in die newturn zou - volgens de specs - juist het aantal scanresult meldingen staan.

[NDF82]

DaCoTa schreef op vrijdag 29 april 2005 @ 08:25:
[...]

Yep, wat ik nu nog zie is dat er een scanresult terugkomt (idd van mezelf) voor er een newturn ontvangen is. En in die newturn zou - volgens de specs - juist het aantal scanresult meldingen staan.

Denk dat er een foutje in je code zit. Ik heb het getest en alles lijkt ok.

code:

>> VERSION 1
<< VERSION 1
>> USER niels
<< USER niels
<< WORLDINFO WIDTH=750 HEIGHT=750 MAX_BATTERY=100 TURN_ENERGY=10 MAX_ENERGY_MOVE
_DISTANCE=10 MAX_ENERGY_FIRE_DISTANCE=10 MAX_ENERGY_FIRE_BLAST_RADIUS=10 MAX_ENE
RGY_SCAN_RADIUS=10 ENERGY_COST_MOVE_DISTANCE=1 ENERGY_COST_FIRE_DISTANCE=1 ENERG
Y_COST_FIRE_BLAST_RADIUS=1 ENERGY_COST_SCAN_RADIUS=1 HIT_DAMAGE=25
<< NEWTURN 30148 0 60
>> MOVE 30148 0 10
<< NEWTURN 30149 0 60
>> MOVE 30149 0 10
<< NEWTURN 30150 0 60
>> MOVE 30150 0 10
<< NEWTURN 30151 0 60
>> MOVE 30151 0 10
<< NEWTURN 30152 0 60
>> SCAN 30152 10
<< NEWTURN 30153 1 60
<< SCANRESULT 30153 0 0
>> SCAN 30153 10
<< NEWTURN 30154 1 60
<< SCANRESULT 30154 0 0
>> SCAN 30154 10
<< NEWTURN 30155 1 60
<< SCANRESULT 30155 0 0
>> QUIT

[maurad3r]

Ten eerste hulde voor alle mensen die dit contest van de grond hebben geholpen!, prachtig idee!

Ik en een vriend van me hebben de middag gespendeerd met het bouwen van een basis voor een bot voor de wedstrijd en dit ging ondanks onze geringe programmeerkennis op het gebied van VB erg goed!! Ik kijk al uit naar de toevoeging van een test-bot zodat ik verder kan experimenteren.

DaCoTa schreef op vrijdag 29 april 2005 @ 08:25:
[...]

Yep, wat ik nu nog zie is dat er een scanresult terugkomt (idd van mezelf) voor er een newturn ontvangen is. En in die newturn zou - volgens de specs - juist het aantal scanresult meldingen staan.

Heb ik geen last van iig, kijk maar

code:

C: QUIT
S: SCANRESULT 31611 0 0
C: SCAN 31611 10
S: NEWTURN 31611 1 10
C: MOVE 31610 2 20
S: SCANRESULT 31610 0 0
C: SCAN 31610 10
S: NEWTURN 31610 1 30
S: SCANRESULT 31609 0 0
C: SCAN 31609 10
S: NEWTURN 31609 1 30
S: SCANRESULT 31608 0 0
C: SCAN 31608 10
S: NEWTURN 31608 1 30
S: SCANRESULT 31607 0 0
C: SCAN 31607 10
S: NEWTURN 31607 1 30
S: SCANRESULT 31606 0 0
C: SCAN 31606 10
S: NEWTURN 31606 1 30
C: MOVE 31605 2 30
S: SCANRESULT 31605 0 0
C: SCAN 31605 10
S: NEWTURN 31605 1 60
S: SCANRESULT 31604 0 0
C: SCAN 31604 10
S: NEWTURN 31604 1 60
S: SCANRESULT 31603 0 0
C: SCAN 31603 10
S: NEWTURN 31603 1 60
C: SCAN 31602 10
S: NEWTURN 31602 0 60
S: WORLDINFO WIDTH=750 HEIGHT=750 MAX_BATTERY=100 TURN_ENERGY=10 MAX_ENERGY_MOVE_DISTANCE=10 MAX_ENERGY_FIRE_DISTANCE=10 MAX_ENERGY_FIRE_BLAST_RADIUS=10 MAX_ENERGY_SCAN_RADIUS=10 ENERGY_COST_MOVE_DISTANCE=1 ENERGY_COST_FIRE_DISTANCE=1 ENERGY_COST_FIRE_BLAST_RADIUS=1 ENERGY_COST_SCAN_RADIUS=1 HIT_DAMAGE=25
S: USER Maurad3r
S: VERSION 1
Connected to: gotbot.lekkerknagen.nl

Ik heb trouwens nog een vraagje voor zover het nu werkt: ik krijg namelijk soms 2 dingen in 1 lijn van de server teruggestuurd, hoort dit zo of is dit een fout ?

[ Voor 20% gewijzigd door maurad3r op 29-04-2005 18:59 ]

[phYzar]

Maurad3r schreef op vrijdag 29 april 2005 @ 18:58:
Ik heb trouwens nog een vraagje voor zover het nu werkt: ik krijg namelijk soms 2 dingen in 1 lijn van de server teruggestuurd, hoort dit zo of is dit een fout ?

Heb ik ook af en toe. Vooral het stuk username/worldinfo/1e newturn zitten vaak aan elkaar vast. Ik check nu gewoon op linebreaks in de serverresponse en hak desgewenst de response in stukken die ik los afhandel _{(wat mij weer het volgende probleem geeft dat wanneer een newturn followup messages heeft ik die newturn-afhandeling moet laten wachten tot de listenthread de scanresults heeft ontvangen en verwerkt)}

[mr.inno]

phYzar schreef op vrijdag 29 april 2005 @ 19:09:
[...]

Heb ik ook af en toe. Vooral het stuk username/worldinfo/1e newturn zitten vaak aan elkaar vast. Ik check nu gewoon op linebreaks in de serverresponse en hak desgewenst de response in stukken die ik los afhandel _{(wat mij weer het volgende probleem geeft dat wanneer een newturn followup messages heeft ik die newturn-afhandeling moet laten wachten tot de listenthread de scanresults heeft ontvangen en verwerkt)}

ik heb hier geen last van
maar toen ik tot 10 minuten gelden een aantal bots voor 20 minuten liet draaine
liepen ze stuk op

code:

<<< NEWTURN 32884 0 70
>>> MOVE 32884 0.14 10.0
<<< ERROR 202
ILLEGAL_TURN_ID
>>> QUIT

is dit te verklaren?

[DaCoTa]

NDF82 schreef op vrijdag 29 april 2005 @ 18:10:
[...]
Denk dat er een foutje in je code zit. Ik heb het getest en alles lijkt ok.

Correct, ik ging er vanuit dat op scan en move ook een confirmation zou komen, maar dat is niet zo, in tegenstelling tot version en user. Nu is het gefixed.

[dotnetter]

Ik begrijp toch niet zo goed hoe het zit met die scanresults..

code:

<< SCAN 36324 10
>> SCANRESULT 36324 0 0
>> NEWTURN 36325 1 70
>> NEWTURN 36326 0 80

Hier scan ik in een beurt en krijg het resultaat meteen terug, en in de volgende beurt zegtie dat er 1 followup komt, maar die komt er niet... Komt dit gewoon doordat de scanresultaten gewoon te vroeg verzonden worden door de server, of komt het doordat ik een ben?

[ Voor 51% gewijzigd door dotnetter op 01-05-2005 17:09 ]

[maurad3r]

mr.inno schreef op vrijdag 29 april 2005 @ 19:52:
[...]


ik heb hier geen last van
maar toen ik tot 10 minuten gelden een aantal bots voor 20 minuten liet draaine
liepen ze stuk op

code:

<<< NEWTURN 32884 0 70
>>> MOVE 32884 0.14 10.0
<<< ERROR 202
ILLEGAL_TURN_ID
>>> QUIT

is dit te verklaren?

kan het zijn dat het getal turn_id te groot is voor een integer ??
Ik kreeg namelijk net een overflow melding en heb dit opgelost door Integer te veranderen in Long.

[mr.inno]

Maurad3r schreef op vrijdag 29 april 2005 @ 23:56:
[...]


kan het zijn dat het getal turn_id te groot is voor een integer ??
Ik kreeg namelijk net een overflow melding en heb dit opgelost door Integer te veranderen in Long.

zo ver ik weet kan java toch wel groterre getallen aan in een int ?

en weer na een hel tijd draaien.

code:

<<< NEWTURN 41430 0 60
>>> MOVE 41430 0.14 10.0
<<< NEWTURN 41431 0 70
>>> MOVE 41431 0.14 10.0
<<< ERROR 202
ILLEGAL_TURN_ID
>>> QUIT

ik denk dat komt omdat ik te laat ben met versturen van mijn move. en dat er dus al een niewe turn aan de gang is.. maar dat weet ik niet zeker.


ps: merk ook op dat energy 10 te veel is bij turn 41431

[ Voor 43% gewijzigd door mr.inno op 30-04-2005 00:30 ]

[Voutloos]

Bij die ILLEGAL_TURN_ID melding kan de server ook net zo goed het turn id zelf mee teruggeven. Debugt wat makkelijker.

[Verwijderd]

Er was toch standaard algoritme om priemgetellen te maken.
Ik dacht zelf iets van:
2^{(2 tot de macht k)} + 1

Dit is terug te vinden in het het boek van Allan Weis, Algoritmen & Datastructures

[Mithrandir]

Verwijderd schreef op zaterdag 30 april 2005 @ 10:39:
Er was toch standaard algoritme om priemgetellen te maken.
Ik dacht zelf iets van:
2^{(2 tot de macht k)} + 1

Dit is terug te vinden in het het boek van Allan Weis, Algoritmen & Datastructures

Nee, dan heb je een speciaal soort priemgetal, een Mersenne Prime (http://en.wikipedia.org/wiki/Mersenne_prime).

[yade]

Interessant. Op zich wil ik hier ook wel aan mee doen. Alleen blijft dit principe oneerlijk omdat niet iedereen dezelfde verbinding en rekenkracht heeft, en dus valt er niets te zeggen over de programmeerkwaliteiten van de programmeur van bot x. Of was daar al iets op gevonden?

Volgens mij ligt ook de server implementatie nog niet vast?

[Verwijderd]

yade schreef op zaterdag 30 april 2005 @ 11:29:
Interessant. Op zich wil ik hier ook wel aan mee doen. Alleen blijft dit principe oneerlijk omdat niet iedereen dezelfde verbinding en rekenkracht heeft, en dus valt er niets te zeggen over de programmeerkwaliteiten van de programmeur van bot x.

Daar ben ik het niet mee eens. Natuurlijk spelen zaken als de snelheid van de computer een rol, maar dat speelt de keuze van een programmeertaal ook. Dat is dus ook al niet "eerlijk". De verbinding zal met deze kleine hoeveelheden data zo weinig uitmaken dat het verwaarloosbaar is. Maar uiteindelijk is het absoluut niet zo dat de snelste pc wint (zeker ook omdat je ruim de tijd krijgt); de kwaliteit van de algorithmes is veel belangrijker!

[maurad3r]

yade schreef op zaterdag 30 april 2005 @ 11:29:
Interessant. Op zich wil ik hier ook wel aan mee doen. Alleen blijft dit principe oneerlijk omdat niet iedereen dezelfde verbinding en rekenkracht heeft, en dus valt er niets te zeggen over de programmeerkwaliteiten van de programmeur van bot x. Of was daar al iets op gevonden?

Volgens mij ligt ook de server implementatie nog niet vast?

Het spel werkt met beurten, je bot moet om dus steeds om een x aantal seconden zijn acties doorsturen. In die tijd kan zelfs een 500mhz processor makkelijk zijn berekingen doen. Dit contest gaat dus echt wel alleen om de AI van je bot.

[ Voor 5% gewijzigd door maurad3r op 30-04-2005 11:51 ]

[yade]

Maar je kan toch nooit voorspellen welk algorithme iemand gaat implementeren? Stel dat er twee mensen mee doen die in staat zijn een dusdanig algorithme te bedenken welke bij meer rekentijd beter presteert (ivm met analyses en voorspellingen), dan wint diegene met de meeste rekenkracht. Niet dat ik er een goede oplossing voor weet. Behalve dan een server die de bots als plugins (evt. op basis van COM) laad en ze sequentieel van evenveel rekenkracht/clockcycles laat genieten. Ik ben alleen bang dat je dan inderdaad bepaalde programmeertalen uitsluit.

[Voutloos]

Als je voor het 'boekhoudwerk' van deze game een programma moet schrijven dat niet lekker draait op een oude bak doe je echt iets fout.

Alle mogelijk zetten over 10 beurten doorrekenen bij deze game is ondoenlijk en bovendien niet nuttig.

[maurad3r]

Ik snap het MOVE commando nog niet helemaal,
turn_id lijkt me logisch, maar de distance en direction.
Is de direction over de x-as ?, dus -30 = naar links?
En wat doet de direction?, hij gaat tot 2pie, dat is dus een draaiing van 360graden, maar ik snap niet waar die voor dient bij het bewegen, je kunt toch niet de lucht in?

code:

MOVE
----
operation    ::= MOVE<delimiter><turn_id><delimiter><direction><delimiter><distance>
<delimiter>  ::= " "
<turn_id>    ::= [0<=x<=999999]
<direction>  ::= [0<=x<=2pi]
<distance>   ::= <energy>
<energy>     ::= [0<=x<=999999.999999]

FIRE vind ik nog onduidelijker, het lijkt me logisch dat je met een bepaalde energie een kogel in een bepaalde hoek wegschiet maar deze variabelen kan ik niet allemaal terugvinden in het protocol. Kan iemand dit een beetje ophelderen

code:

FIRE
----
operation      ::= FIRE<delimiter><turn_id><delimiter><direction><delimiter><distance><delimiter><blast_radius>
<delimiter>    ::= " "
<turn_id>      ::= [0<=x<=999999]
<direction>    ::= [0<=x<=2pi]
<distance>     ::= <energy>
<blast_radius> ::= <energy>
<energy>       ::= [0<=x<=999999.999999]

[ Voor 30% gewijzigd door maurad3r op 30-04-2005 12:45 ]

[Voutloos]

Maurad3r schreef op zaterdag 30 april 2005 @ 12:44:
En wat doet de direction?, hij gaat tot 2pie, dat is dus een draaiing van 360graden, maar ik snap niet waar die voor dient bij het bewegen, je kunt toch niet de lucht in?

Het speelveld is een vlak, het is immers geen koorddansen. Zelfde antwoord voor de fire vraag.

[zwippie]

@Maurad3r: zie ook deze posting: http://gathering.tweakers.net/forum/view_message/23258897
Je rijdt/schiet in een richting over een bepaalde afstand, daarbij doet een kogel bij ontploffing ook nog eens damage over blast_radius hokjes.


Verder heb ik mijn (simpele) client de hele nacht laten draaien, er waren geen errors, hij liep nog toen ik wakker werd. In mijn log kan ik alleen de laatste 700 beurten terugbekijken, de rest is afgekapt door het console venster, maar hij heeft iig 14388 beurten gedaan voor ik hem afkapte. Voor zover ik kan zien heb ik geen andere bots gescand.

Een puntje over de energiehuishouding:
MAX_BATTERY = 100 en TURN_ENERGY = 10, dus je zou verwachten dat als je batterij 90 energie bevat dat je dan veilig zit als je een move van 10 units maakt om op 90 te blijven. Maar de server telt eerst de 10 punten bij de huidige batterij op, ziet dan dat je dood bent (100 energie) en verwerkt de move dan niet meer.
Je moet dus nu al voldoende actie ondernemen als je batterij op <90 staat, want zodra de batterij op 90 staat ben je gegarandeerd dood de volgende beurt. Misschien is het een idee om de volgorde van uitvoeren/controleren iets te veranderen?

[mr.inno]

zwippie schreef op zaterdag 30 april 2005 @ 13:06:
Een puntje over de energiehuishouding:
MAX_BATTERY = 100 en TURN_ENERGY = 10, dus je zou verwachten dat als je batterij 90 energie bevat dat je dan veilig zit als je een move van 10 units maakt om op 90 te blijven. Maar de server telt eerst de 10 punten bij de huidige batterij op, ziet dan dat je dood bent (100 energie) en verwerkt de move dan niet meer.
Je moet dus nu al voldoende actie ondernemen als je batterij op <90 staat, want zodra de batterij op 90 staat ben je gegarandeerd dood de volgende beurt. Misschien is het een idee om de volgorde van uitvoeren/controleren iets te veranderen?

Wat jij dus zecht is als ik

code:

newturn 111 90

krijg
en ik dan

code:

move 111 0.14 10

doe
ik doood ga ?

[mocean]

>>> VERSION 1
<<< VERSION 1
>>> USER MOCEAN
<<< USER MOCEAN
<<< WORLDINFO WIDTH=750 HEIGHT=750 MAX_BATTERY=100 TURN_ENERGY=10 MAX_ENERGY_MOVE_DISTANCE=10 MAX_ENERGY_FIRE_DISTANCE=10 MAX_ENERGY_FIRE_BLAST_RADIUS=10 MAX_ENERGY_SCAN_RADIUS=10 ENERGY_COST_MOVE_DISTANCE=1 ENERGY_COST_FIRE_DISTANCE=1 ENERGY_COST_FIRE_BLAST_RADIUS=1 ENERGY_COST_SCAN_RADIUS=1 HIT_DAMAGE=25
<<< NEWTURN 74678 0 60
<<< NEWTURN 74679 0 70
<<< NEWTURN 74680 0 80

Yes baby

(ik test trouwens op gotbot.lekkerknagen.nl)

[ Voor 29% gewijzigd door mocean op 30-04-2005 19:38 ]

[zwippie]

Hm, mijn voorbeeld klopt inderdaad niet. Het gaat niet goed vanaf battery >= 91 ipv >= 90, dus mijn puntje van kritiek blijft staan, zie het volgende voorbeeld:

code:

energie is 90, 10 bewegen, dit gaat goed::
<< NEWTURN 76722 0 90
   Beurt: 4 Batterij: 90
   Geen scan uitgevoerd.
>> MOVE 76722 0.785398 10.0
<< NEWTURN 76723 0 90
   Beurt: 5 Batterij: 90
   Geen scan uitgevoerd.
>> MOVE 76723 0.785398 10.0
<< NEWTURN 76724 0 90       Enz enz


energie is 91, 10 bewegen, dit gaat niet goed:
<< NEWTURN 76963 0 91
   Beurt: 31 Batterij: 91
   Geen scan uitgevoerd.
>> MOVE 76963 0.785398 10.0
<< NEWTURN 76964 0 0                   << Hier had ik battery = 91 verwacht
   Beurt: 32 Batterij: 0
   Geen scan uitgevoerd.
>> MOVE 76964 0.785398 9.0
<< ERROR 203
Error ontvangen, stoppen. ERROR 203 USER_IS_DEAD

[ Voor 8% gewijzigd door zwippie op 30-04-2005 20:14 ]

[maurad3r]

Voutloos schreef op zaterdag 30 april 2005 @ 13:06:
[...]
Het speelveld is een vlak, het is immers geen koorddansen. Zelfde antwoord voor de fire vraag.

ok , dan is het me opeens allemaal heel erg duidelijk.

Hopen dat er snel een testbot online komt

[ Voor 11% gewijzigd door maurad3r op 30-04-2005 20:24 ]

[mocean]

zwippie schreef op zaterdag 30 april 2005 @ 20:13:
Hm, mijn voorbeeld klopt inderdaad niet. Het gaat niet goed vanaf battery >= 91 ipv >= 90, dus mijn puntje van kritiek blijft staan, zie het volgende voorbeeld:

code:

...

Is volgens mij geen bug, je krijgt gewoon eerst 10 energy, dan ga wat doen.
En je mag gewoon niet boven de 100.

Ik loop inmiddels rond af en toe:

code:

<<< NEWTURN 77335 0 60
>>> MOVE 77335 1.92 10
<<< NEWTURN 77336 0 60
>>> MOVE 77336 0.69 10
<<< NEWTURN 77337 0 60

[ Voor 19% gewijzigd door mocean op 30-04-2005 20:25 ]

[zwippie]

Ik loop nu ook al scannende rond, wie weet wordt je getroffen door een toevalstreffer van mij, al zou ik al blij zijn eens iemand tegen te komen

Ik ga wel even een stilstaande bot maken, als lokaas, zodat er tenminste iets te beleven valt op het slagveld.

[mocean]

zwippie schreef op zaterdag 30 april 2005 @ 20:42:
Ik loop nu ook al scannende rond, wie weet wordt je getroffen door een toevalstreffer van mij, al zou ik al blij zijn eens iemand tegen te komen

Ik ga wel even een stilstaande bot maken, als lokaas, zodat er tenminste iets te beleven valt op het slagveld.

Ik moet even wat handigs bedenken, om deze 'domme' bot van mij zeg 10 keer te starten of zo. Dan kan ik verder met een wat inteligenter wezen, deze loopt random in een richting tussen de 0 en de pi

[zwippie]

Ok, er staat nu een dom lokaas stilletjes te scannen. Hij/het beweegt niet, dus misschien vind je em wel door random rond te lopen.
Zelf krijg ik een melding indien er meer dan 1 scanresult terugkomt, ik kan niet wachten!

EDIT:

First Contact!

code:

Beurt: 119 Batterij: 60
   2 van de 2 scans ontvangen:
   Scan 0: X = 0 Y = 0
   Scan 1: X = 8 Y = 2
   Beurt: 120 Batterij: 60
   2 van de 2 scans ontvangen:
   Scan 0: X = 0 Y = 0
   Scan 1: X = 0 Y = 7
   Beurt: 121 Batterij: 60
   2 van de 2 scans ontvangen:
   Scan 0: X = 0 Y = 0
   Scan 1: X = 8 Y = 1

[ Voor 45% gewijzigd door zwippie op 30-04-2005 21:09 ]

[mocean]

Cool :-)

Maar jij zit dus ook op gotbot.lekkerknagen.nl?
Ik heb er nu 2 rondlopen, ze kunnen alleen nog niet schieten

Jammer dat je geen Nick krijgt van degene die je ziet.

Voeg me anders ff toe op msn, kunnen wat sneller werken met testen (ben[at]mocean.nl)

EDIT: we vinden wat!


EDIT2:
Er gebeurt wat raars:
Als 2 bots elkaar tegenkomen, krijgen ze hetzelfde scanresult:
Bot van Zwippie:
Scan 0: X = 7 Y = 2
Scan 0: X = 6 Y = 7

Mijn Bot:
SCANRESULT 81171 7 2
SCANRESULT 81173 6 7

We krijgen dus allebei dezelfde x & y. De vraag is of nu de richting te bepalen is. Volgens mij moet het teken van de X en de Y van mijn bot het tegengestelde teken hebben tov die van Zwippie.

[ Voor 51% gewijzigd door mocean op 30-04-2005 22:40 ]

[DaCoTa]

zwippie schreef op zaterdag 30 april 2005 @ 13:06:
Je moet dus nu al voldoende actie ondernemen als je batterij op <90 staat, want zodra de batterij op 90 staat ben je gegarandeerd dood de volgende beurt. Misschien is het een idee om de volgorde van uitvoeren/controleren iets te veranderen?

Het lijkt mij logischer om de acties en de energietoename eerst te verwerken en pas daarna de batterijstatus. Als je eerst acties doet en dan 10 energie erbij krijgt, krijg je weer problemen als je een bijna lege batterij hebt.

[mocean]

Ik krijg sinds eventjes mn scanresults raar binnen:
<<< SCANRESULT 100721 0 0NEWTURN 100722 0 60

Zonder newline ertussen...

[mr.inno]

zwippie schreef op zaterdag 30 april 2005 @ 20:13:
Hm, mijn voorbeeld klopt inderdaad niet. Het gaat niet goed vanaf battery >= 91 ipv >= 90, dus mijn puntje van kritiek blijft staan, zie het volgende voorbeeld:

code:

energie is 90, 10 bewegen, dit gaat goed::
<< NEWTURN 76722 0 90
   Beurt: 4 Batterij: 90
   Geen scan uitgevoerd.
>> MOVE 76722 0.785398 10.0
<< NEWTURN 76723 0 90
   Beurt: 5 Batterij: 90
   Geen scan uitgevoerd.
>> MOVE 76723 0.785398 10.0
<< NEWTURN 76724 0 90       Enz enz


energie is 91, 10 bewegen, dit gaat niet goed:
<< NEWTURN 76963 0 91
   Beurt: 31 Batterij: 91
   Geen scan uitgevoerd.
>> MOVE 76963 0.785398 10.0
<< NEWTURN 76964 0 0                   << Hier had ik battery = 91 verwacht
   Beurt: 32 Batterij: 0
   Geen scan uitgevoerd.
>> MOVE 76964 0.785398 9.0
<< ERROR 203
Error ontvangen, stoppen. ERROR 203 USER_IS_DEAD

dit zou idd niet mogen gebeuren.
in tegen stelling tot

mocean schreef op zaterdag 30 april 2005 @ 20:24:
Is volgens mij geen bug, je krijgt gewoon eerst 10 energy, dan ga wat doen.
En je mag gewoon niet boven de 100.

[/code]

vind ik juist dat het en bug is

mijn uit leg :

code:

<< NEWTURN 76963 0 91
   Beurt: 31 Batterij: 91
   Geen scan uitgevoerd.
>> MOVE 76963 0.785398 10.0

deze move krijgt zelfde turn_id mee als die new turn en dus hoort ie ook bij die turn. Dus moet ie uit gevoert worden voor dat je een niewe turn krijgt en meer energy.
dus zelfs als je op 99 energy staat kun je niet dood gaan als je 10 of meer energy verbruikt.


scan result
het zou een hele verbeterring zijn als je op een scan resultaat . (indien nog niet van toepassing)
1) altijd je zelf terug krijgt
2) bot namen bij de resultaten staan.

[ Voor 10% gewijzigd door mr.inno op 01-05-2005 12:40 ]

[dotnetter]

Kheb de hele nacht 3 bots laten draaien (terwijl ik sliep ), ze hebben aan een stuk door gescanned en gemoved, echter viel me op dat na een tijdje de bots gewoon dood gingen omdat de batterij volliep terwijl ze toch gewoon opdrachten bleven geven.

Ten tweede viel me het volgende op, ik heb de bots in een logfile laten schrijven wanneer ze meer dan 1 scanresult terugkregen, dit is dan ook een aantal keer gebeurt, en meestal zag dat er zo uit:

code:

SCANRESULT 88242 x: 0 y: 0
SCANRESULT 88242 x: 0 y: 0
SCANRESULT 88242 x: 0 y: 0

In een beurt drie scanresults met dezelfde waarden, is het mogelijk dat 3 bots exact dezelfde positie hebben op het speelveld, of ligt het aan mijn brakke netwerkcode??

[edit]
Inmiddels ook mijn eigen first contact!!

code:

SCANRESULT 86676 x: 1 y: 2

[ Voor 7% gewijzigd door dotnetter op 01-05-2005 15:17 ]

[NDF82]

zozo, jullie zijn druk bezig geweest. De log file van de server is opeens 300 MB! Moet wel zeggen dat ik veel log

Maargoed, ik denk dat het tijd wordt voor een wiki oid. Mensen moeten bugs kunnen rapporteren en er moet een inventarisatie gemaakt worden wat mensen anders willen hebben.

Is volgens mij geen bug, je krijgt gewoon eerst 10 energy, dan ga wat doen.
En je mag gewoon niet boven de 100.

klopt

Verder zal ik de naam van de user toevoegen aan de SCANRESULT en eventueel een FIRERESULT introduceren met daarin de users die je geraakt hebt.

Die first contact vind ik erg goed, het veld is op dit moment 750*750!! Die drie SCANRESULTS op hetzelfde coordinaat is helemaal sterk!

[DaCoTa]

Ik vind het doodgaan door een overflow toch wel een beetje onzinnig.Als je nu op 90 komt, ben je zowiezo dood. Er is geen enkele manier om energie erbij te krijgen, dus wil ik de optie van een laadstop nog een keer voorstellen.

En ik heb ook vannacht een aantal keer firstcontact gehad. Ben benieuwd naar namen als dat geimplementeerd is. Dan gaan we nu maar eens bewegen en schieten, kijken wat dat brengt.

[mocean]

Goed om weer van je te horen NDF

Als je weer aan de slag gaat, deze bug vind ik nu het vervelenst:
<<< SCANRESULT 100721 0 0NEWTURN 100722 0 60

En misschien zou het veld wat kleiner kunnen, om wat meer contact te krijgen? Nu moet ik een aantal bots de lucht in schoppen en dan maar hopen op contact

EDIT:
Bugje van mezelf

[ Voor 9% gewijzigd door mocean op 01-05-2005 16:51 ]

[NDF82]

Ok, ff een restart van de server. Wat is er veranderd:
• speelveld is 100*100
• aan scanresult is een username toegevoegd. Zie protocolspec hier
• bij een battery overflow ga je niet dood maar wordt je battery MAX_BATTERY

[dotnetter]

Te gek, goed bezig NDF82!!
Ben erg benieuwd naar men 'second contact'!!

[ Voor 10% gewijzigd door dotnetter op 01-05-2005 16:01 . Reden: *dn gaat meteen zijn classes aanpassen!!* ]

[NDF82]

woeii! Check m'n testbot!

code:

First contact! x=8 y=5 user=flat_5f2c70f6662241a8
First contact! x=8 y=5 user=flat_5f2c70f6662241a8
First contact! x=8 y=5 user=flat_5f2c70f6662241a8
First contact! x=8 y=5 user=flat_5f2c70f6662241a8
First contact! x=8 y=5 user=flat_5f2c70f6662241a8
First contact! x=8 y=5 user=flat_5f2c70f6662241a8
First contact! x=8 y=5 user=flat_5f2c70f6662241a8
First contact! x=8 y=5 user=flat_5f2c70f6662241a8

[DaCoTa]

Het is druk:

code:

SCAN 185 90.0
TURN_ID: 186 BATTERY: 10
X: -7 Y: 24
X: 26 Y: -58
X: -31 Y: -23

edit:
Nu nog drukker:

code:

SCAN 222 90.0
TURN_ID: 223 BATTERY: 10
X: -36 Y: 48
X: -11 Y: 26
X: 23 Y: 20
X: -43 Y: 6
X: 47 Y: 40

En ik merk wel dat het ERG nodig is om namen bij een scanresult te zien. Je kan nu niemand tracken.

Laatste edit:

Ik zie nu dat er een laadstop op zit:

code:

TURN_ID: 323 BATTERY: 70
TURN_ID: 324 BATTERY: 80
TURN_ID: 325 BATTERY: 90
TURN_ID: 326 BATTERY: 100
TURN_ID: 327 BATTERY: 100

Ik zag al een server reset, vroeg me al af wat er zou gaan gebeuren, maar dit is wel erg cool! Nou moet ik echt iets gaan bedenken wat slim is

[ Voor 86% gewijzigd door DaCoTa op 01-05-2005 16:10 ]

[flat]

Mijn bot is inmiddels zo ver dat 'ie kan schieten. Dus wanneer iemand z'n health ineens onverklaarbaar afneemt...

[mocean]

WOEI:

BOT2-283SCANRESULT 283 -2 -97 niels
BOT2-291SCANRESULT 291 -5 -3 DaCoTa

EDIT
Misschien is het leuk om je GOT naam te gebruiken.... mijne heten nu
MOCEAN (1,2,3,4)

Voorheen Bot1 ook maar dat is irritant

[ Voor 46% gewijzigd door mocean op 01-05-2005 16:12 ]

[DaCoTa]

mocean schreef op zondag 01 mei 2005 @ 16:08:
WOEI:

BOT2-283SCANRESULT 283 -2 -97 niels
BOT2-291SCANRESULT 291 -5 -3 DaCoTa

code:

SCAN 411 45.0
TURN_ID: 412 BATTERY: 55
X: 24 Y: -12  niels
X: 38 Y: 17  BOT3
X: 39 Y: -1  BOT2

Jaja, laten we nu eens een bot gaan tracken:)

[mocean]

DaCoTa schreef op zondag 01 mei 2005 @ 16:13:
[...]

code:

SCAN 411 45.0
TURN_ID: 412 BATTERY: 55
X: 24 Y: -12  niels
X: 38 Y: 17  BOT3
X: 39 Y: -1  BOT2

Jaja, laten we nu eens een bot gaan tracken:)

Ben benieuwd of je kan zien waarom ie loopt zoals ie loopt (is 1 regel code hoor...)

[zwippie]

Super, NDF82! Leuk om te zien dat je nieuwe dingen toevoegt!

Misschien wel een idee om het versienummer op te hogen als er iets veranderd is in het protocol. Ik vroeg me net al af waarom m'n bot het niet meer deed. Anyway, ik ga em nu eerst toch nog eens flink herverbouwen.

[mocean]

Een vraag over het volgende:

code:

>>> SCAN 2049 10 (MOCEAN3)
<<< NEWTURN 2050 2 65
>>> MOVE 2050 2.23 10 (MOCEAN3)
<<< SCANRESULT 2050 0 0 MOCEAN3
<<< SCANRESULT 2050 8 -95 FLAT
MOCEAN3-2050SCANRESULT 2050 8 -95 FLAT
<<< NEWTURN 2051 0 65

Ik doe een scan (2049), krijg een newturn (2050), waar ik wat mee kan doen. maar daarna krijg ik pas de scanresult van de beurt ervoor, maar wel met buertnr 2050.

Is dit een keuze? en wordt de move van 2050 nog meegenomen, of krijg je de situatie na 2049 te zien?

Zie ook [rml]dotnetter in "[ Alg] Nieuwe GoT contest?"[/rml]

[ Voor 15% gewijzigd door mocean op 01-05-2005 17:10 ]

[NDF82]

En weer een server restart. De FIRERESULT opperation is toegevoegd. Zie protocolspec hier. Ik hoor het wel als er bugs in zitten

[flat]

Heeft iemand enig idee wat er hier fout gaat? Na m'n FIRE komt er niets meer terug vanaf de server.
Ik ben 't probleem al een aantal keer tegen gekomen, maar kan het niet echt reproduceren.

code:

<<< NEWTURN 2129 0 59
>>> SCAN 2129 29

<<< NEWTURN 2130 2 40
<<< SCANRESULT 2130 0 0 flat_f103b3242
<<< SCANRESULT 2130 14 13 MOCEAN3
~~~ enemy spotted
>>> FIRE 2130 0.822418 19 18

nog een keer:

code:

<<< NEWTURN 74 0 58
>>> SCAN 74 29

<<< NEWTURN 75 3 39
<<< SCANRESULT 75 -5 1 MOCEAN4
<<< SCANRESULT 75 15 10 MOCEAN2
<<< SCANRESULT 75 0 0 flat_75e04d8af
~~~ enemy spotted
>>> FIRE 75 0.982794 18 17

Verder excuses aan alle mensen die ik raak
Misschien is het handig/prettig om aparte fire- en no-fire servers te gebruiken, terwijl iedereen nog aan het bouwen is?

[ Voor 24% gewijzigd door flat op 01-05-2005 17:24 ]

[NDF82]

zonder FIRERESULT:
gotbot.lekkerknagen.nl:666

met FIRERESULT:
gotbot.lekkerknagen.nl:667

@flat Ik heb mijn testcode nog niet compleet. Zal daar volgende week eens mee verder gaan.

[Verwijderd]

NDF82 schreef op zondag 01 mei 2005 @ 15:58:
• bij een battery overflow ga je niet dood maar wordt je battery MAX_BATTERY

Ik vraag me af of dit wenselijk is; dit zou ervoor kunnen zorgen dat je erg passieve bots krijgt. Misschien moeten we het eerst even aankijken, maar als je dood gaat als je MAX_BATTERY overschrijft, zorg je er iig wel voor dat er altijd actie is.

[mocean]

NDF82 schreef op zondag 01 mei 2005 @ 17:23:
zonder FIRERESULT:
gotbot.lekkerknagen.nl:666

met FIRERESULT:
gotbot.lekkerknagen.nl:667

@flat Ik heb mijn testcode nog niet compleet. Zal daar volgende week eens mee verder gaan.

Is het wel handig nu al naar 2 servers te gaan?
Als je FIRERESULT nog niet geimplementeerd hebt, dan negeer je dat toch?

EDIT: Flat bedoelde trouwens "fire- en no-fire servers"

[ Voor 7% gewijzigd door mocean op 01-05-2005 17:54 ]

[flat]

mocean schreef op zondag 01 mei 2005 @ 17:54:
[...]
EDIT: Flat bedoelde trouwens "fire- en no-fire servers"

Inderdaad, een server waarop wel geschoten mag worden, en eentje waarop dat niet de bedoeling is.
Zelf ben ik nu vooral aan het schieten, en voor mijn bots is het geen probleem als ze beschoten worden. Maar voor de mensen die net begonnen zijn met hun bot is het prettig om in een rustige omgeving te kunnen testen, zonder beschoten te worden enzo.

Overigens lijkt de server op poort 667 niet veel te doen:

code:

~/sbot$ telnet gotbot.lekkerknagen.nl 667
Trying 145.99.138.17...
telnet: connect to address 145.99.138.17: Connection refused

[ Voor 3% gewijzigd door flat op 01-05-2005 18:03 ]

[mocean]

Je kan ook de hit damage op 0 zetten (eventueel alleen op de no-fire server).

[H!GHGuY]

w00t

vanmiddag voor de eerste keer in kunnen loggen... version, user en quit commando's zijn al geimplementeerd ook een klein deeltje van m'n AI is al af...

PS: waar is soultaker btw?? al in geen 100 posts te bekennen...