[Contest] BotWars

[DaCoTa]

De locatie waar de server je neerzet is irrelevant. De kaart heeft idd een rand, maar dat is alleen in de server, de clients merken niks van de rand. Of je er nu overheen loopt, overheen schiet, overheen scanned, alles is transparant. Voor de client ziet het eruit als een oneindig groot veld. Om niet iedereen te laten verdwalen, word iedereen binnen een bepaalde veldgrootte gewrapped, maar ook dat merk je niet omdat de grootte van het veld veel groter is dan de maximale scan/schiet/loop afstand.

Kortom: je kan jezelf dus gewoon in het midden van de wereld plaatsen.

[frickY]

In principe sta je altijd in het midden van de map, er zijn namelijk geen randen.
Als je aan de linker kant de map 'uitloopt', kom je er aan de rechter kant wee rin. Je kunt de map dus zien als een bol waar iedereen opstaat. Het maakt verder niet uit waar op die bol je bent.
Alleen afstanden tot vijanden zijn interessant om te weten


Op welke server zit jij? Ik ben aan het testen op hell.student.utwente.nl dus misschien dat we elkaar zo tegen komen

edit:
DaCoTa, hou eens op met sneller typen

[ Voor 10% gewijzigd door frickY op 02-07-2005 18:36 ]

[Soultaker]

frickY schreef op zaterdag 02 juli 2005 @ 18:35:
In principe sta je altijd in het midden van de map, er zijn namelijk geen randen.
Als je aan de linker kant de map 'uitloopt', kom je er aan de rechter kant wee rin. Je kunt de map dus zien als een bol waar iedereen opstaat. Het maakt verder niet uit waar op die bol je bent.
Alleen afstanden tot vijanden zijn interessant om te weten

Het idee klopt maar topologisch gezien is het een torus (donut, of koffiekopje voor topologen) en geen bol.

[phYzar]

frickY schreef op zaterdag 02 juli 2005 @ 14:38:
Overigens nog een keer over de beurt-volgorde. Deze is nu FireMoveScan en zou MFS worden. Is het niet leuker om dit open te houden? Dat je zelf bepaald of je eerst wilt vuren, lopen of scannen? Dat dat gewoon afhankelijk is van de volgorde waarop je die berichten instuurt.

Dan zul je misschien zeggen dat het dan erg makkelijk wordt om eerst te scannen, en vervolgens te schieten op degene die je hebt gescant.
Maar als deze potentiele target als eerste actie ook scant, of vuurt, en in zijn 2de actie loopt, mis je toch nog..

Belangrijkste in de discussie was: hoe handeld de server het af. Stel, je hebt de situatie zoals jij het beschrijft. Nu besluit jij te beginnen met een schot en ik met lopen. Wij doen dit allebij tegelijk als 1e actie. Wie krijgt er voorrang? Gaan alle moves eerst (en ben ik dus al van mijn plek af) of gaan de fires eerst (en raak jij mij nog). Bij een vaste volgorde heb je dit probleem niet. Dus heeft de server intern toch weer een vaste volgorde wat betekend dat elke actie apart wordt doorgevoerd wat betekend dat je eigenlijk gewoon 1 actie per beurt hebt.

Overigens lijkt me wel erg handig om bij de follow-up-messages ook meldingen te krijgen wanneer mensen joinen of weggaan, zodat je kunt bijhouden hoeveel vijanden er zouden moeten zijn...

Zeker handig

[Gerco]

Woohoo, ik heb zojuist mijn allereerste ingame encounter gehad. Klaas93 bedankt!

Je moet alleen wel je bot wat handiger maken, de mijne staat momenteel volkomen stil (scant niet eens) en nog maar 1x raken??

[Soultaker]

DaCoTa schreef op zaterdag 02 juli 2005 @ 13:38:
Tot slot: SoulTaker: heb je mijn bericht over het SVN wachtwoord gekregen?

Nee, ik heb niets gezien; wat was de afzender? Zou kunnen dat 'ie gespamfiltert is (maar dat is raar, want dat gebeurt praktisch nooit met legitieme mail afaik.)

Soultaker/NDF: Ook heb ik inmiddels redelijk wat wijzigingen ivm het deadlock probleem, kan dat zomaar de repo in of moet ik een patch sturen?

Ik zou zeggen, merge 'm met de code in de repository; dat kan door de laatste revisie uit te checken, jouw bestanden er overheen te zetten (niet vergeten nieuwe bestanden te registreren met 'svn add') en vervolgens te comitten. Als er conflicten zijn dan wijst subversion je daar vanzelf op.

Overigens heb ik ook geen lock-ups meer gehad sinds ik zelf wat dingen gewijzigd had, dus ik hoop dat je werk niet voor niets was.

[Soultaker]

frickY schreef op zaterdag 02 juli 2005 @ 14:38:
Overigens nog een keer over de beurt-volgorde. Deze is nu FireMoveScan en zou MFS worden. Is het niet leuker om dit open te houden? Dat je zelf bepaald of je eerst wilt vuren, lopen of scannen? Dat dat gewoon afhankelijk is van de volgorde waarop je die berichten instuurt.

Ik heb de volgorde aangepast naar Move-Fire-Scan, volgens de poll. Maar eigenlijk had de optie "2 acties per beurt: fire of move (en altijd scan)" meer stemmen. Ik ben nu nogal in de war, omdat ik niet helemaal zie hoe die optie het bestaande probleem oplost.

[StefSybo]

Volgens mij was het de bedoeling dat je in een beurt alleen een move of een fire mocht doen (en een scan) en dat de server dat dan uitvoert in de volgorde move-fire-scan. Op die manier kunnen bots dus ervoor kiezen om voor iemand te vluchten of om op hem te schieten, maar niet allebei.

Dus als een bot zegt

code:

MOVE 1000 0.3424 6.0
SCAN 1000 4.0

En een andere zegt

code:

FIRE 1000 4.23493 5.0 3.0
SCAN 1000 6.0

Dan doet de server eerst de move van speler 1, dan de fire van speler 2 en dan beide scans.

[ Voor 21% gewijzigd door StefSybo op 02-07-2005 22:14 ]

[phYzar]

Soultaker schreef op zaterdag 02 juli 2005 @ 21:43:
[...]

Ik heb de volgorde aangepast naar Move-Fire-Scan, volgens de poll.

Dus nu is de server aangepast? Vanaf nu moeten we voorspellen waar de tegenstander heengaat willen we raakschieten? Is er al een server draaiend met de nieuwe beurtvolgorde?

Maar eigenlijk had de optie "2 acties per beurt: fire of move (en altijd scan)" meer stemmen. Ik ben nu nogal in de war, omdat ik niet helemaal zie hoe die optie het bestaande probleem oplost.

De stemmen lagen dicht bij elkaar voor deze 2 opties, ik stem ervoor om eerst eens de huidige MFS optie te gebruiken en als dat bevalt hoeft er niet meer iemand de server weer te verbouwen naar M/F+S

[Verwijderd]

Waarom dan nog stemmen als men uiteindelijk toch iets anders doet? Dit is één van de belangrijkste zaken in het protocol. Schieten of bewegen per beurt en elke beurt scannen was er als beste uitgekomen en moet dan ook gevolgd worden. Het is de meest realistische oplossing en biedt bovendien interessante tactische mogelijkheden.
Het is niet makkelijk om overeenstemming te bereiken over alle punten van de server, maar begin aub niet met bestaande beslissingen terug te draaien of er opnieuw over te discusieren want dan komt men nooit tot een volledig werkende server.

[phYzar]

Verwijderd schreef op zaterdag 02 juli 2005 @ 22:36:
Waarom dan nog stemmen als men uiteindelijk toch iets anders doet? Dit is één van de belangrijkste zaken in het protocol. Schieten of bewegen per beurt en elke beurt scannen was er als beste uitgekomen en moet dan ook gevolgd worden. Het is de meest realistische oplossing en biedt bovendien interessante tactische mogelijkheden.
Het is niet makkelijk om overeenstemming te bereiken over alle punten van de server, maar begin aub niet met bestaande beslissingen terug te draaien of er opnieuw over te discusieren want dan komt men nooit tot een volledig werkende server.

Iemand moet het ook nog uitvoeren. Als een kleine wijziging zo is doorgevoerd terwijl een grote wijziging betekend dat geen serverdevver het poogd aan te pakken of op de lange baan schuift dan is de keus liever de kleine wijziging, maar als de serverdevvers even graag de grote wijziging doorvoeren: graag natuurlijk.

_{niet om iemand met werk op te zadelen of te commanderen ofzo, maar wie is er (momenteel) bezig met de ontwikkeling van de server (NDF, Soultaker en Dacota?) en zijn er plannen/is er een planning/taakverdeling over het doorvoeren van de wijzigingen in beurtvolgorde en andere punten op de roadmap? In een project waar nu al veel mensen inzitten (zie botlijst!! ) is overzicht en duidelijkheid wel belangrijk.}

[Soultaker]

Verwijderd schreef op zaterdag 02 juli 2005 @ 22:36:
Waarom dan nog stemmen als men uiteindelijk toch iets anders doet? Dit is één van de belangrijkste zaken in het protocol. Schieten of bewegen per beurt en elke beurt scannen was er als beste uitgekomen en moet dan ook gevolgd worden. Het is de meest realistische oplossing en biedt bovendien interessante tactische mogelijkheden.
Het is niet makkelijk om overeenstemming te bereiken over alle punten van de server, maar begin aub niet met bestaande beslissingen terug te draaien of er opnieuw over te discusieren want dan komt men nooit tot een volledig werkende server.

Dit is alleen dat deze volgorde veel meer stemmen had dan de huidige situatie en heel makkelijk te implementeren is, dat in tegenstelling tot het alternatief. Dit is dus niet de eindoplossing, maar het is beter dan de oude situatie.

[frickY]

phYzar schreef op zaterdag 02 juli 2005 @ 19:19:
Belangrijkste in de discussie was: hoe handeld de server het af. Stel, je hebt de situatie zoals jij het beschrijft. Nu besluit jij te beginnen met een schot en ik met lopen. Wij doen dit allebij tegelijk als 1e actie. Wie krijgt er voorrang? Gaan alle moves eerst (en ben ik dus al van mijn plek af) of gaan de fires eerst (en raak jij mij nog). Bij een vaste volgorde heb je dit probleem niet. Dus heeft de server intern toch weer een vaste volgorde wat betekend dat elke actie apart wordt doorgevoerd wat betekend dat je eigenlijk gewoon 1 actie per beurt hebt.

Dan zou ik zeggen dat een afgevuurd schot pas de erop volgende beurt inslaat.
De server kan dus van elke bot de eerste acties uitvoeren.
Bij de 2de beurt slaan alle in beurt 1 afgevuurde kogels in, en wordt de 2de actie uitgevoerd
Bij de 3de beurt slaan alle in beurt 2 afgevuurde kogels in, en wordt de 3de actie uitgevoerd, waarna de in de 3de beurt afgevuurde kogels inslaan....

Anders heeft het geen nut omdat de in je 3de actie gescande target de volgende beurt bij je eerste actie nog steeds die positie heeft, en je dus altijd raakt...

Elke beurt zou dus in 3 stappen ingedeelt moeten worden, welke op zichzelf ook weer uit 4 stappen bestaan;
Alle kogels van voorgaande stap vurende bots slaan in
Alle kogels van vurende bots worden afgevuurd
Alle stappen van bewegende bots worden gezet
Alle scans worden gedaan

Als jij dus kiest voor een FMS, en ik voor een SFM;
Jij schiet mijn richting op, ik scan jou
Jij beweegt, ik vuur (en mis, je bent de vorige stap immers verplaatst). Tevens wordt ik geraakt door jouw schot
Jij scant, en krijgt mijn huidige positie binnen. Ik beweeg, jouw gescande positie klopt niet meer.

Wordt het wel érg tactisch

[ Voor 11% gewijzigd door frickY op 02-07-2005 23:39 ]

[LauPro]

DIt is een leuk project, ben meteen even aan de slag gegaan en dan C++ QT/Designer based. Inmiddels heb ik het allemaal zover dat ik een verbinding op kan zetten en dat weer kan geven in de lay-out .

Ik heb even een screenshot toegevoegd voor de liefhebbers
:

Maar ik heb volgens mij een methode gevonden om dik te cheaten . Stel dat je met 50 bots connect en ze allemaal laat 'campen'. Indien ze gekickt of gestaft worden dan herconnect je. Doordat die bots min of meer random over het veld zijn verdeeld is het mogelijk om te bepalen waar de meeste tegenstanders zijn (aangezien die 50 bots eigenlijk allemaal samen spelen). En dan laat je de bots die het dichtst bij een tegenstander zijn aanvallen. Je kan ervoor zorgen dat er bijvoorbeeld maar 10 bots zijn die daadwerkelijk aanvallen om nog een beetje een leuke score over te houden.

Is hier al een beveiling tegen? Want ik wilde dat even uit gaan proberen .

[Verwijderd]

Ik heb een vage foutmelding, die ik niet krijg weggewerkt op een of andere manier

Ik ben bezig om te reconnecten zodra ik dood ben (battery van 0), daarvoor close ik de socket binnen een while. Daardoor gaat hij op zn bakkes. Ik ga even kijken of ik het anders kan oplossen (break geven).

code:

<b>Warning</b>:  feof(): 3 is not a valid stream resource in...

PHP:

while(!feof($pr->b_sock)) {

LauPro schreef op zondag 03 juli 2005 @ 02:06:
Maar ik heb volgens mij een methode gevonden om dik te cheaten . Stel dat je met 50 bots connect en ze allemaal laat 'campen'. Indien ze gekickt of gestaft worden dan herconnect je. Doordat die bots min of meer random over het veld zijn verdeeld is het mogelijk om te bepalen waar de meeste tegenstanders zijn (aangezien die 50 bots eigenlijk allemaal samen spelen). En dan laat je de bots die het dichtst bij een tegenstander zijn aanvallen. Je kan ervoor zorgen dat er bijvoorbeeld maar 10 bots zijn die daadwerkelijk aanvallen om nog een beetje een leuke score over te houden.

Opzich vrij moeilijk, je moet ze laten samenwerken en dan moeten ze onderling hun positie nog gaan bepalen. Je weet nl niet waar je op het veld staat (toch?). Ik was hier btw ook al op gekomen, maar nog niet toe aan uitwerking. Ik wou 20 "SCAN bots" maken, die verder niets doen als scannen.

[ Voor 7% gewijzigd door Verwijderd op 03-07-2005 03:25 ]

[phYzar]

LauPro schreef op zondag 03 juli 2005 @ 02:06:
Is hier al een beveiling tegen? Want ik wilde dat even uit gaan proberen .

Euhh juist
2 foute aannames:
1: Jij mag 50 bots spawnen
2: Een ander doet dat niet

[LauPro]

Verwijderd schreef op zondag 03 juli 2005 @ 03:24:
Opzich vrij moeilijk, je moet ze laten samenwerken en dan moeten ze onderling hun positie nog gaan bepalen. Je weet nl niet waar je op het veld staat (toch?). Ik was hier btw ook al op gekomen, maar nog niet toe aan uitwerking. Ik wou 20 "SCAN bots" maken, die verder niets doen als scannen.

Valt wel mee, ik heb een bot nu als een Object. Zodoende kan ik een array van bots maken en ze dan een type meegeven (bot->setScanbot() oid). Elke bot zorgt zelf middels een ander object voor de verbinding e.d., dus op den duur zal het misschien wel veel geheugen nodig hebben oid .

[LauPro]

phYzar schreef op zondag 03 juli 2005 @ 03:26:
[...]
Euhh juist
2 foute aannames:
1: Jij mag 50 bots spawnen
2: Een ander doet dat niet

Ik vat het niet helemaal? Door samen te werken zouden mijn bots een evolutionair voordeel hebben en dus overwinnen . Iedereen die dat niet doet zal in de minderheid zijn en dus in het nadeel. Ik neem aan dat hier wel een beveiliging tegen gaat komen, anders heb je straks duizenden bots bij elkaar en krijg je een beetje de mass attacks uit LORD .

[Verwijderd]

LauPro schreef op zondag 03 juli 2005 @ 03:32:
[...]
Ik vat het niet helemaal? Door samen te werken zouden mijn bots een evolutionair voordeel hebben en dus overwinnen . Iedereen die dat niet doet zal in de minderheid zijn en dus in het nadeel. Ik neem aan dat hier wel een beveiliging tegen gaat komen, anders heb je straks duizenden bots bij elkaar en krijg je een beetje de mass attacks uit LORD .

Opzich is het wel een leuk idee, maar dan moet de server bepalen of er teaming mag plaatsvinden (als waarde), dan kan je een bot bouwen die het wel ondersteund, maar mensen die hier geen zin in hebben hoeven het dan niet.

Mijn bot werkt weer goed, probleem is opgelost. Nou gaan we proberen te lopen

[DaCoTa]

Soultaker schreef op zaterdag 02 juli 2005 @ 21:21:
Ik zou zeggen, merge 'm met de code in de repository; dat kan door de laatste revisie uit te checken, jouw bestanden er overheen te zetten (niet vergeten nieuwe bestanden te registreren met 'svn add') en vervolgens te comitten. Als er conflicten zijn dan wijst subversion je daar vanzelf op.

Overigens heb ik ook geen lock-ups meer gehad sinds ik zelf wat dingen gewijzigd had, dus ik hoop dat je werk niet voor niets was.

Ik heb het oude locking mechanisme verwijderd en vervangen door goed gebruik van de synchronizedMap structuur. Daarmee gaat alles vanzelf, mits _over_ goed gebruik van die methode gemaakt wordt. Ik probeer het er wel in te zetten. Daarnaast heb ik de spawn op een leeg stuk van de map geimplementeerd.

Helaas heb ik wel conflicten, maar die ga ik nu niet meer oplossen, komt morgen wel ofzo

[Verwijderd]

Is hier al een beveiling tegen? Want ik wilde dat even uit gaan proberen .

Men ging er van uit dat iedereen wel zo fair zou zijn om volgens de regels te spelen. Het is een programmeerwedstrijd en toch geen kindertuin. Wie wil er trouwens zo'n contest winnen door te cheaten?

[frickY]

Probeer maar 2 bots met dezelfde username te laten spawnen; Kan niet
En als de echte wedstrijd is begonnen neem ik aan dat op username/password combo wordt gecontroleerd, en je maar gewoon 1 login hebt.
Helaas voor jou, je zult op een echte manier moeten winnen


Is het trouwen zo dat als ik op een target schiet welke niet beweegt, ik altijd raak. Of komt je shot niet altijd precies op de plek waar je mikt, en moet je dat afvangen met een grotere blast-radius?

[ Voor 28% gewijzigd door frickY op 03-07-2005 11:35 ]

[Gerco]

Ik plaats ook maar eens een screenshot, schijnt populair te zijn De bot kan al lopen en scannen. Doodgaan lukt ook nog weleens, maar terugschieten valt nog buiten zijn/haar capaciteiten.



LauPro, aangezien jij ook met C++/Qt werkt, hoe communiceer jij tussen je Bot en je Network? Ik gebruik signals & slots, leek me wel handig, maar is dat ook de beste manier?

[ Voor 18% gewijzigd door Gerco op 03-07-2005 12:01 ]

[frickY]

Ik heb een paar TARGET-botjes online gegooit, omdat ik steeds maar niet de kans kreeg aan de slag te gaan met mijn schiet-techniek
PierreDev1, PierreDev2, DUH, DaCoTaV2_22 en Zerot0 zijn ze al tegen gekomen

Enige wat ze doen is stilziten en scannen. Het scannen zet ik nu uit zodat ze hun battery sparen en ze wat langer online blijven

Ik krijg soms overigens opeens een ERROR 202 terug als ik de NEWTURN wil binnen halen. Wat houd dat in?

[ Voor 17% gewijzigd door frickY op 03-07-2005 13:08 ]

[LauPro]

Verwijderd schreef op zondag 03 juli 2005 @ 11:01:
[...]
Men ging er van uit dat iedereen wel zo fair zou zijn om volgens de regels te spelen. Het is een programmeerwedstrijd en toch geen kindertuin. Wie wil er trouwens zo'n contest winnen door te cheaten?

Het is niet zozeer cheaten, het is gewoon je bot zo mogelijk optimaliseren zodat hij beter is dan anderen. Natuurlijk heeft dan elke bot een eigen username. Wanneer je meerdere bots laat samen werken kan je een groter gebied bedekken en als er een tegenstander komt die sneller neer halen.

@Gerco: idd met slots en signals. Nu heb ik het ook zo ver dat hij de listview vult.

[phYzar]

frickY schreef op zondag 03 juli 2005 @ 12:56:
Ik krijg soms overigens opeens een ERROR 202 terug als ik de NEWTURN wil binnen halen. Wat houd dat in?

ILLEGAL_TURN_ID 202

[Sijmen]

Ik ben gisteren ook begonnen aan mijn bot:

Ochtend:

Middag:


Heb een heel layer-based frameworkje geschreven, met Client, Protocol, en Interface. De bots gebruiken de interface, en die heeft de methoden als Scan, Fire, en Login natuurlijk.

Oja, geschreven in C# 2.0

Morgen ga ik een beginnetje maken aan een TreeView met de spelinformatie, bijvoorbeeld de locatie van andere bots, de wereldvariabelen en dergelijken. En dus scannen natuurlijk!

[martijnve]

leuk plan.
ik ga morgen naar een vriend en dan gaan we samen ook een bot maken. (er aan beginnen iig)

dus eh "scan you later"

[danslo]

Ok ik doe mee! 'k zal wel iets in elkaar knutselen met VB

[Sijmen]

martijnve schreef op zondag 03 juli 2005 @ 14:55:
dus eh "scan you later"

[Verwijderd]

Zoals ik nou merk zijn er meer mensen bezig om IRC bots te maken binnen het kanaal #pwcontest.bot. Echter begint het daar een onoverzichterlijke zooi te worden.

Ik heb zelf de keuze genomen dat ik alleen een berichtje stuur zodra er iemand aanmeld. Dan kunnen ze via het commando !status kingofdos_bot verbinden met mijn bot (dan stuurt hij een prive bericht). De verdere afhandeling (hitby, hit, move, etc) laat ik dus niet meer zien binnen #pwcontest.bot maar binnen een privemsg.
Alle bot's die verbinden bij mij met 1 IRC bot, die het doorstuurt. Dus je ziet AL mijn bots in 1 prive venster. Niet dat je op een gegeven moment kingofdosbot1 tm kingofdosbot500 hebt
^{Ik verstuur dus niet bij een JOIN een privemsg, maar een msg naar de channel. Stel dat iedereen een privemsg zou sturen bij een JOIN, dan heb je kan op 50 berichten.}

Ik hoop dat iedereen zoiets in elkaar zet, dan blijft het kanaal tenminste een "beetje" schoon.

[ Voor 12% gewijzigd door Verwijderd op 03-07-2005 20:10 ]

[martijnve]

YAY
we hebben net onze eerste kill gemaakt
tnx marlov

[ Voor 9% gewijzigd door martijnve op 04-07-2005 20:39 ]

[LouisXV]

Hoi,

Ik heb niet het hele topic gevolgd maar het idee van bots die met elkaar vechten deed me erg denken aan een andere website die ik een keer gezien heb, en dat op vergelijkbare wijze werkte. Misschien staan hier leuke ideeen op voor het maken van bots of het ontwikkelen van het gevechtssysteem.

http://www.tacticalneuronics.com/

[jelmervos]

Sijmen schreef op zondag 03 juli 2005 @ 14:28:
[..]

Heb een heel layer-based frameworkje geschreven, met Client, Protocol, en Interface. De bots gebruiken de interface, en die heeft de methoden als Scan, Fire, en Login natuurlijk.
[..]

Zou ik misschien de source kunnen bekijken?

[Verwijderd]

Tot hoelang loopt de contest eigenlijk?

[Sijmen]

Kaassoevlee schreef op maandag 04 juli 2005 @ 21:36:
[...]

Zou ik misschien de source kunnen bekijken?

Sure, ik zal het vanavond even zippen. Merk wel op dat het nog (lang) niet af is, en ik nu ook druk bezig ben met World of Warcraft en school, dus misschien lukt het vanavond niet

[compufreak88]

Verwijderd schreef op dinsdag 05 juli 2005 @ 11:27:
Tot hoelang loopt de contest eigenlijk?

Tot zover ik weet is dat nog onbekend..

[Ricvdp]

Sijmen schreef op dinsdag 05 juli 2005 @ 12:25:
[...]


Sure, ik zal het vanavond even zippen. Merk wel op dat het nog (lang) niet af is, en ik nu ook druk bezig ben met World of Warcraft en school, dus misschien lukt het vanavond niet

Zou ik hem ook mogen zien? Ik ben sinds een kleine tijd met C# bezig, en dit ziet er wel mooi uit, ik denk dat ik er nog wel veel van zou kunnen leren:).

[Verwijderd]

compufreak88 schreef op dinsdag 05 juli 2005 @ 12:32:
Tot zover ik weet is dat nog onbekend..

Ik hoop lang

offtopic:
Ik hoop ook dat we hier mee verder gaan buiten de contest, eigenlijk wel een vet project

[FireFly3k]

Verwijderd schreef op dinsdag 05 juli 2005 @ 14:06:
[...]

Ik hoop lang

offtopic:
Ik hoop ook dat we hier mee verder gaan buiten de contest, eigenlijk wel een vet project

Ik hoop dat de contest nog wel even loopt want ik ben bezig veel dingen aan het uit te vinden. Dit is het eerste project waar ik aan mee doe, tot nu toe vind ik het erg leuk .

Zou het idd ook wel leuk vinden om hiermee na het project nog door te gaan.

[DRAFTER86]

Ik probeer mijn bot het moven te leren, maar krijg vaak een 204 (CONSTRAINT_VIOLATION) error. Wat betekent dit precies?

[zwippie]

Misschien is de afstand die je probeert te bewegen te groot? (zie worldinfo)

[DRAFTER86]

zwippie schreef op dinsdag 05 juli 2005 @ 17:08:
Misschien is de afstand die je probeert te bewegen te groot? (zie worldinfo)

Jep dat was hem! Dan nog iets, ik prog in C#, nu trekt mijn botje continu ongeveer 80% cpu. Dat is niet echt de bedoeling. Volgens mij komt dat omdat ik in een while(true) loop (zoals in het C# voorbeeld) kijk of de server al nieuwe data in de aanbieding heeft. Dit lijkt mij niet de beste manier...

[zwippie]

Ik programmeer in Java en daar doe ik zoiets:

Java:

while ((input = is.readLine()) != null) {
...
}

Dit trekt minimale cpu, het lijkt me dat dat in C# ook wel moet kunnen, maar dat ken ik niet.

[.oisyn]

Verwijderd schreef op dinsdag 05 juli 2005 @ 11:27:
Tot hoelang loopt de contest eigenlijk?

Aangezien het nu 2005 is, en we elk jaar streven een contest te houden, zou ik zeggen: t/m 31 december 2005?

Overigens voor de mensen die source willen: allemaal best natuurlijk, maar doe dat even via e-mail ipv deze topic

[Ricvdp]

Dat kan.

[Salandur]

ik doe mits ik tijd heb en dat is vrij weinig jammer genoeg

[Ricvdp]

@.oisyn: Sijmen heeft geen mailadres op zijn profiel.

[frickY]

zwippie schreef op dinsdag 05 juli 2005 @ 17:23:
Ik programmeer in Java en daar doe ik zoiets:

Java:

while ((input = is.readLine()) != null) {
...
}

Dit trekt minimale cpu, het lijkt me dat dat in C# ook wel moet kunnen, maar dat ken ik niet.

Het verschil met deze constructie, en met een while(true), is dat je bij deze constructie wacht op antwoord van de server, terwijl je met while(true) zo hard als je maar kunt aan het kijken bent of er al antwoord is.

Kijk eens of je iets kunt vinden over het in BLOCKS lezen van data vanuit je socket.

[VinShady]

Gaaf idee! Ik ga ook zeker wel meedoen. Alleen heb ik dus een noobvraag; ik script zelf PHP en kan online met GD etc. plaatjes outputten, maar als ik via PHP-CLI werk, zit ik m'n command (windows) schermpje..? Iemand een idee?

Alvast bedankt

[ Voor 38% gewijzigd door VinShady op 05-07-2005 23:48 ]

[Ramon]

Ik ben bezig in C#, heb het scriptje van de wiki als basis gebruikt. Maar nu loop ik constant tegen ERROR 202 aan, zie code:

code:

SERVER: NEWTURN 90613 2 99 
SERVER: SCANRESULT 90613 0 0 Tampie 
SERVER: SCANRESULT 90613 0.555927 1.720525 dArtBot_964 
_CLIENT: FIRE 90613 0.555927 18 1.720525 
SERVER: NEWTURN 90614 0 109 
_CLIENT: SCAN 90614 10 
SERVER: ERROR 202

202 betekent illegal_turn_id, daar ben ik inmiddels wel achter, maar ik gebruik toch de goede turn_id's? Of moet ik ergens +1 of -1 doen ofz?

Als iemand wat duidelijkheid kan verschaffen graag

[DRAFTER86]

Ramon de Jesus schreef op dinsdag 05 juli 2005 @ 23:25:
Ik ben bezig in C#, heb het scriptje van de wiki als basis gebruikt. Maar nu loop ik constant tegen ERROR 202 aan, zie code:

code:

SERVER: NEWTURN 90613 2 99 
SERVER: SCANRESULT 90613 0 0 Tampie 
SERVER: SCANRESULT 90613 0.555927 1.720525 dArtBot_964 
_CLIENT: FIRE 90613 0.555927 18 1.720525 
SERVER: NEWTURN 90614 0 109 
_CLIENT: SCAN 90614 10 
SERVER: ERROR 202

202 betekent illegal_turn_id, daar ben ik inmiddels wel achter, maar ik gebruik toch de goede turn_id's? Of moet ik ergens +1 of -1 doen ofz?

Als iemand wat duidelijkheid kan verschaffen graag

Ik heb precies hetzelfde, maar is het bij jou meteen bij de tweede turn of na een poosje? Bij mij duurt het soms wel een paar minuten voor hij komt...

[Webgnome]

Ik denkdat ik ook mee ga doen. Al is mijn kennis van alles een beetje en dus dingen als ai scripting en stuff nooit gedaan,. Deze contest is daar een goede training voor

count me in

[frickY]

Ik krijg soms ook opeens een 202, altijd pas na een poosje. Mn script skipt dan gewoon die turn en daarna gaat het weer goed...

@VinShady
Ik ben zelf ook in PHP-CLI bezig. Een grafische weergave maken is daarbij lastig.
Wat je kunt doen is PHP gewoon GD-plaatjes laten maken, en deze in je browser openen. Een jaavscriptje laat je elke seconde het venster vernieuwen.
Ook zou je PHP een XML-file kunnen laten maken met alle info, welke je uitleest met bijvoorbeeld Flash.

[Ricvdp]

VinShady schreef op dinsdag 05 juli 2005 @ 22:39:
Gaaf idee! Ik ga ook zeker wel meedoen. Alleen heb ik dus een noobvraag; ik script zelf PHP en kan online met GD etc. plaatjes outputten, maar als ik via PHP-CLI werk, zit ik m'n command (windows) schermpje..? Iemand een idee?

Alvast bedankt

IEmand die ik ken gaat een programma maken dat de output van de console pakt en opent in FF.

[The-MeLLeR]

Ik ben ook begonnen
Nog nooit iets met AI gedaan maar dit lijkt me een leuke uitdaging en kans om daar eindelijk eens iets mee te doen!

[curry684]

Leuk idee, als ik tijd kan vinden zal ik de C++ of C# compilers wel weer eens uit de kast trekken

De Wiki geeft overigens een gateway timeout atm?

[eghie]

frickY schreef op dinsdag 05 juli 2005 @ 21:58:
[...]

Het verschil met deze constructie, en met een while(true), is dat je bij deze constructie wacht op antwoord van de server, terwijl je met while(true) zo hard als je maar kunt aan het kijken bent of er al antwoord is.

Kijk eens of je iets kunt vinden over het in BLOCKS lezen van data vanuit je socket.

Waarom zou je onnodig een loop doorlopen? Bij die constructie van while(server.ReadLine()) wacht hij inderdaad op server output, maar je moet daar toch op wachten. Dit scheelt je dan alleen maar CPU tijd, dus dit vind ik zelf een stuk mooier. Ik ga er dan wel van uit dat je een blocking socket gebruik.

[LauPro]

Een blocking socket vind ik tamelijk vies eigenlijk. Het lijkt me veel beter om het event driven te doen. Dus zodra er iets in de socket staat, dat middels een event afvangen en aan de slag. Naar mijn idee is de tijd met main-loops echt wel voorbij.

[eghie]

LauPro schreef op woensdag 06 juli 2005 @ 11:03:
Een blocking socket vind ik tamelijk vies eigenlijk. Het lijkt me veel beter om het event driven te doen te doen. Dus zodra er iets in de socket staat, dat middels een event afvangen en aan de slag. Naar mijn idee is de tijd met main-loops echt wel voorbij.

Ik kan me alleen geen code voorstellen hoe je dat zou kunnen doen, zonder loop, ook al doe je het event driven. Ik denk dat je dan nog steeds onder water een loopje hebt waarbij je controleerd of er wat in staat en zo ja, dan event aanroepen. Dus zo:

C#:

while ((serveroutput = server.ReadLine()) != null)
{
    OnRecieveData(serveroutput); //dit is dan een event
}

Als jij een andere methode kent, vertel die, want ik ben wel benieuwd. Maar ik kan zelf geen andere manier bedenken hoe ik dat zou oplossen. Je hebt toch altijd wel iets van een polling methode nodig om te kijken of er data in staat en dat doe je met een loop neem ik aan.

En waarom ik voor een blocking socket ben, staat in de reactie boven je.

[ Voor 14% gewijzigd door eghie op 06-07-2005 11:42 . Reden: code ff iets aangepast en een typevoutje weggewerkt ;) ]

[Daspeed]

Nou, ik ben ook maar met een botje begonnen. Doe het vooral voor de fun en om een beetje Python te leren.

Screen


Hij is nog niet zo slim:
- hij moved random
- scant (nog te kleine) gebieden
- als'ie iets heeft gescand dan vuurt'ie (behalve als het te dichtbij is)

Maar goed, aan de AI moet dus nog wel wat gesleuteld worden. Ook de GUI is nog niet helemaal af.

[ Voor 9% gewijzigd door Daspeed op 06-07-2005 12:02 . Reden: Thumbnail ]

[Soultaker]

Je kunt in Windows bijvoorbeeld events laten genereren wanneer data binnenkomt op een socket. Maar dan heb je dus een Windows message loop nodig en dat is óók een lusje.

Zo'n while-lus is trouwens absoluut geen polling; de executie van het proces wordt onderbroken tot er weer data beschikbaar is. Als je de socket non-blocking zou maken zou het wel polling worden, maar eghie heeft gelijk dat dat zinloos is.

Het protocol is juist zo ontworpen dat je nooit onverwachte data van de server krijgt. In het begin van de beurt lees je alle beschikbare data voor die beurt, dan bereken je jouw acties en die stuur je naar de server, waarna er niets rest dan op het einde van de beurt te wachten (er is geen reden om later een andere zet te doen, want je krijgt toch geen nieuwe informatie binnen waarmee je je beslissing zou moeten herzien).

[Verwijderd]

VinShady schreef op dinsdag 05 juli 2005 @ 22:39:
Gaaf idee! Ik ga ook zeker wel meedoen. Alleen heb ik dus een noobvraag; ik script zelf PHP en kan online met GD etc. plaatjes outputten, maar als ik via PHP-CLI werk, zit ik m'n command (windows) schermpje..? Iemand een idee?

Alvast bedankt

Je pakt de extended pre-compiled versie voor Windows, dat is incl Extensions directory, je zet in je PHP.ini dat hij die directory als Extension dir moet gebruiken en je zet GD aan. Daarna laat je het PHP script gewoon naar een bestand wegschrijven (in bv de dir van je webserver), dan kan je er bij via HTTP. Zo ga ik iig mijn radar/etc maken.

[Gerco]

DrClearbottom schreef op woensdag 06 juli 2005 @ 12:00:
Nou, ik ben ook maar met een botje begonnen. Doe het vooral voor de fun en om een beetje Python te leren.

Off-topic: Wat gebruik je voor die GUI in Python en op welk OS ?

[Webgnome]

offtopic:
is het gewenst om een gui te maken of mag die bot ook alles zelf doen? voor pythonzou ik pygtk gebruiken

[Genoil]

Verwijderd schreef op woensdag 06 juli 2005 @ 12:21:
[...]

Je pakt de extended pre-compiled versie voor Windows, dat is incl Extensions directory, je zet in je PHP.ini dat hij die directory als Extension dir moet gebruiken en je zet GD aan. Daarna laat je het PHP script gewoon naar een bestand wegschrijven (in bv de dir van je webserver), dan kan je er bij via HTTP. Zo ga ik iig mijn radar/etc maken.

Waarom zou je je CLI botscript de GD acties laten uitvoeren? Mijn radar haalt z'n gegevens uit de log-db waar de bot alles naartoe schrijft en wordt gewoon via HTTP getriggerd. Of bedoel je dat juist?

[Verwijderd]

Webgnome schreef op woensdag 06 juli 2005 @ 12:50:

offtopic:
is het gewenst om een gui te maken of mag die bot ook alles zelf doen? voor pythonzou ik pygtk gebruiken

De bot MOET alles zelf doen. Er mag geen enkele vorm van menselijke interactie zijn eenmaal de bot zich in het strijdveld bevindt. Een GUI is dus niet noodzakelijk en heeft als enige nut het visualiseren van de toestand om het 'leuker' te maken voor de programmeur.

[Webgnome]

Verwijderd schreef op woensdag 06 juli 2005 @ 13:00:
[...]

De bot MOET alles zelf doen. Er mag geen enkele vorm van menselijke interactie zijn eenmaal de bot zich in het strijdveld bevindt. Een GUI is dus niet noodzakelijk en heeft als enige nut het visualiseren van de toestand om het 'leuker' te maken voor de programmeur.

ok. Dat stukje heb ik dus gemist. MAar dan is het nog leuker.. ga ik eerst ff die bot aan de praat krijgen en dan daarna doe ik wel een stukje gui erbij

offtopic:
heb connectie !

[LauPro]

eghie schreef op woensdag 06 juli 2005 @ 11:17:
Ik kan me alleen geen code voorstellen hoe je dat zou kunnen doen, zonder loop, ook al doe je het event driven.

Hoe je precies in C# een dergelijke constructie maakt zou ik zo 1-2-3 niet weten. Maar ik kan me niet voorstellen dat je een geen functie kan maken die je vervolgens verbind met data-arrivatie op het socket.

En waarom ik voor een blocking socket ben, staat in de reactie boven je.

Dit gaat een beetje technische discussie worden, maar hoe dan ook. Er zijn imo tegenwoordig genoeg mogelijkheden om te werken met event en zodoende geen 'mainloop' meer nodig te hebben. Het event-based verhaal wordt afgehandeld door het platform waar je alles op draait en niet door het programma. Het lijkt mij geen taak van een programma om dit soort handelingen te doen netzoals beheer van geheugen. Dat is ook al tijden iets waar een programma zich niet meer mee bezig hoeft te houden (enkel beperkt tot de hoeveelheid van ..).

Daarbij is een blocking socket ook niet multi-cpu compatibel. En daarmee eigenlijk al een achterhaalde techniek. Aangezien in de toekomt er veel meer aandacht besteed moet worden aan het multi-cpu (core) geschikt maken van programmatuur.

[curry684]

LauPro schreef op woensdag 06 juli 2005 @ 11:03:
Een blocking socket vind ik tamelijk vies eigenlijk. Het lijkt me veel beter om het event driven te doen. Dus zodra er iets in de socket staat, dat middels een event afvangen en aan de slag. Naar mijn idee is de tijd met main-loops echt wel voorbij.

C:

    // Start the message loop. 
    while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
    { 
        if (bRet == -1)
        {
            // handle the error and possibly exit
        }
        else
        {
            TranslateMessage(&msg); 
            DispatchMessage(&msg); 
        }
    } 

?

[Daspeed]

Gerco schreef op woensdag 06 juli 2005 @ 12:37:
[...]

Off-topic: Wat gebruik je voor die GUI in Python en op welk OS ?

wxPython met behulp van PythonCard (dan kun je tenminste echt snel een GUI in elkaar slepen)
Dit alles onder WinXP

[jelmervos]

LauPro schreef op woensdag 06 juli 2005 @ 11:03:
Een blocking socket vind ik tamelijk vies eigenlijk. Het lijkt me veel beter om het event driven te doen. Dus zodra er iets in de socket staat, dat middels een event afvangen en aan de slag. Naar mijn idee is de tijd met main-loops echt wel voorbij.

Delphi (TApplication.Run):

code:

      repeat
        try
          HandleMessage;
        except
          HandleException(Self);
        end;
      until Terminated;

?

[Webgnome]

offtopic

Heb de connectie class klaar. Echter moet ik nu zelf hier een instance van maken ( x = gnomeConnect() etc ) en dat is niet de bedoeling..

code:

import socket

class gnomeSocket:
    # Connect to the server and receive/send data

    def __init__(self, sock=None):
        if sock is None:
            self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        else:
            self.sock = sock

    def connect(self):
        try:
            self.sock.connect(("hell.student.utwente.nl", 1666))
            print "connect"
        except:
            print "connection failed"

    def sendCommand(self, command):
        try:
            self.sock.send(command)
        except:
            print "something went wrong"

    def receiveStatus(self):
        try:
            data = self.sock.recv(1024)
            print data
        except:
            print "whoops?"

    def socketClose(self):
        try:
            self.sock.close()
        except:
            print "cant close the damn connection?"

als dit gewoon prutscode is laat het me weten Ik zit een beetje in de maag met het oop gedeelte. Ik wil het dus oop houden maar weet zo niet hoe ik de meuk ga indelen. Mijn idee is om een battlestation class te maken die aan de hand van de variabelen van receivestatus zijn werkt doet maar is dat eignelijk wel slim ?

[ Voor 58% gewijzigd door Webgnome op 06-07-2005 14:54 ]

[redpen]

ziet er schattig uit


ben zelf nu ook bezig in php heb ik het verbind / verstuur gedeelte ook af alleen het ontvangen moet ik ff nader bekijken


ps bij deze meld ik me ook aan als contestant ( of hoe je dat schrijft:))

[StefSybo]

Ik heb even een vraag over de server

Ik zat wat in de source te kijken en ik kwam dit tegen bij het uitvoeren van de MOVEs van de clients:

code:

double xNew = GotBotMath.targetX(x, distance, direction, Constants.WIDTH);
double yNew = GotBotMath.targetY(y, distance, direction, Constants.HEIGHT);

Daarbij lijkt het dus dat er geen rekening wordt gehouden met de richting waarin de client "kijkt" (dat lijkt mij de richting waarin hij de laatste keer gemoved heeft). Dat betekent dus dat een move met direction 0.0 altijd omhoog gaat in de wereld zoals de server die ziet. Voor de client heeft de wereld eigenlijk geen boven of onder, het idee was juist dat het voor de client niet uitmaakt hoe hij ten opzichte van de wereld staat.

Vanuit de client zou het dus naar mijn menig logischer zijn als een MOVE (en ook SCAN, FIRE en de results) ten opzichte van zijn vorige move zijn, dus een move met direction 0.0 zou dan in dezelfde richting zijn als de vorige move en niet per se naar boven.

Is dit een bug of een feature?

[frickY]

eghie schreef op woensdag 06 juli 2005 @ 10:40:
[...]
Waarom zou je onnodig een loop doorlopen? Bij die constructie van while(server.ReadLine()) wacht hij inderdaad op server output, maar je moet daar toch op wachten. Dit scheelt je dan alleen maar CPU tijd, dus dit vind ik zelf een stuk mooier. Ik ga er dan wel van uit dat je een blocking socket gebruik.

Dat is toch precies wat ik vertel? Ook ik vind dit de beste manier, en doe het zelf ook zo

LauPro schreef op woensdag 06 juli 2005 @ 11:03:
Een blocking socket vind ik tamelijk vies eigenlijk. Het lijkt me veel beter om het event driven te doen. Dus zodra er iets in de socket staat, dat middels een event afvangen en aan de slag. Naar mijn idee is de tijd met main-loops echt wel voorbij.

Wat is er vies aan een blocking socket? Als het eenmaal draait zou je het verschil met een event-driver systeem niet eens merken. De loop blijft namelijk hangen tot er een antwoord van de server binnen komt -> trigger.
Events/triggers heb je niet in PHP..

@StefSybo
Ik hoop een feature. Volgens mij wordt het een stuk ingewikkelder, en voor de server zwaarder, als van de 'kijkrichting' van de bot zou worden uitgegaan.

[ Voor 8% gewijzigd door frickY op 06-07-2005 16:22 ]

[StefSybo]

Dat zwaarder valt wel mee, hij hoeft alleen de huidige richting steeds bij de richting van de actie op te tellen.
Het zou me niks uitmaken als het een feature is, maar dan wil ik het wel weten, dan weet ik tenminste hoe ik mijn bot in een rechte lijn laat lopen

offtopic:
Ik zie het trouwens ook wel zitten om er na de contest mee verder te gaan

[ Voor 16% gewijzigd door StefSybo op 06-07-2005 16:33 ]

[Fl4sh3r]

StefSybo schreef op woensdag 06 juli 2005 @ 16:20:
Ik heb even een vraag over de server

Ik zat wat in de source te kijken en ik kwam dit tegen bij het uitvoeren van de MOVEs van de clients:

code:

double xNew = GotBotMath.targetX(x, distance, direction, Constants.WIDTH);
double yNew = GotBotMath.targetY(y, distance, direction, Constants.HEIGHT);

Daarbij lijkt het dus dat er geen rekening wordt gehouden met de richting waarin de client "kijkt" (dat lijkt mij de richting waarin hij de laatste keer gemoved heeft). Dat betekent dus dat een move met direction 0.0 altijd omhoog gaat in de wereld zoals de server die ziet. Voor de client heeft de wereld eigenlijk geen boven of onder, het idee was juist dat het voor de client niet uitmaakt hoe hij ten opzichte van de wereld staat.

Vanuit de client zou het dus naar mijn menig logischer zijn als een MOVE (en ook SCAN, FIRE en de results) ten opzichte van zijn vorige move zijn, dus een move met direction 0.0 zou dan in dezelfde richting zijn als de vorige move en niet per se naar boven.

Is dit een bug of een feature?

Voor mij was het eerst een bug, ik ging uit van de kijkrichting.
Nu denk ik dat het wiskundig (iig voor de server) wat eenvoudiger is.

[zwippie]

StefSybo schreef op woensdag 06 juli 2005 @ 16:20:
Voor de client heeft de wereld eigenlijk geen boven of onder, het idee was juist dat het voor de client niet uitmaakt hoe hij ten opzichte van de wereld staat.

Volgens mij gaat dit over de positie van de client. De richting is voor zowel client als server hetzelfde.

[Verwijderd]

Webgnome schreef op woensdag 06 juli 2005 @ 14:48:
offtopic

Heb de connectie class klaar. Echter moet ik nu zelf hier een instance van maken ( x = gnomeConnect() etc ) en dat is niet de bedoeling..

Waarom niet, als ik vragen mag?

[Webgnome]

Het is toch de bedoeling dat de bot nadat ie is geconnect zichzelf een baan maakt door het servertje etc? Nou op dit moment gaat dat dus niet lukken..

Het connecten is geenprobleemamar het receiven / versturen vain input / ouput gaat niet automatisch

Oh even iets over mijn idee van het botje.

Ik heb de volgende classes in gedachte:

gnomeConnect() : deze zorgt voor de connectie en het versturen / ontvangen van data
gnomeMain(): trapt de connect aan en bevat de functies voor het vechten , bewegen scannen ( ai dus)

is dit een goede opstelling of

p.s. gui kmot er nog niet in

[Daspeed]

Nou, 't is al aardig druk op hell.student.utwente.nl en mijn stomme bot wordt dan ook al flink ingemaakt



Als ik het goed zie heeft mijn bot net voordat'ie doodging nog net iemand anders kunnen killen (eerste kill en met geluk waarschijnlijk, bijna alle bots zijn beter dan die van mij)

[eghie]

Webgnome schreef op woensdag 06 juli 2005 @ 17:26:
Het is toch de bedoeling dat de bot nadat ie is geconnect zichzelf een baan maakt door het servertje etc? Nou op dit moment gaat dat dus niet lukken..

Het connecten is geenprobleemamar het receiven / versturen vain input / ouput gaat niet automatisch

Oh even iets over mijn idee van het botje.

Ik heb de volgende classes in gedachte:

gnomeConnect() : deze zorgt voor de connectie en het versturen / ontvangen van data
gnomeMain(): trapt de connect aan en bevat de functies voor het vechten , bewegen scannen ( ai dus)

is dit een goede opstelling of

p.s. gui kmot er nog niet in

Zoek eens een tutorial over OOP op het internet, ik denk dat het je dan een stuk duidelijker wordt.

[VinShady]

frickY schreef op woensdag 06 juli 2005 @ 09:02:
@VinShady
Ik ben zelf ook in PHP-CLI bezig. Een grafische weergave maken is daarbij lastig.
Wat je kunt doen is PHP gewoon GD-plaatjes laten maken, en deze in je browser openen. Een jaavscriptje laat je elke seconde het venster vernieuwen.
Ook zou je PHP een XML-file kunnen laten maken met alle info, welke je uitleest met bijvoorbeeld Flash.

Ik zou idd GD-Plaatjes kunnen maken en ben dat ook van plan, maar hoe kan ik deze dan in m'n browser sturen? zit namelijk in mn msdos schermpje

[Webgnome]

eghie schreef op woensdag 06 juli 2005 @ 17:43:
[...]

Zoek eens een tutorial over OOP op het internet, ik denk dat het je dan een stuk duidelijker wordt.

done it. Maar zoals gezegd nooit echt verder mee gegaan. Maar ik ga wel weer ff verder kijken

[frickY]

Webgnome schreef op woensdag 06 juli 2005 @ 17:26:
is dit een goede opstelling of

Ikzelf roep mn Connect() class aan, welke mn Bot opstart indien er een verbinding is gemaakt.

VinShady schreef op woensdag 06 juli 2005 @ 17:55:
Ik zou idd GD-Plaatjes kunnen maken en ben dat ook van plan, maar hoe kan ik deze dan in m'n browser sturen? zit namelijk in mn msdos schermpje

Maak een HTML pagina, bijvoorbeed C:\GotBot\GUI.html, en start in het vervolg je Bot op met een bat-file
[bat]
start c:\GotBot\GUI.html
cmd /k C:\GotBot\botje.php
[/bat]

De eerste regel zou je standaard browser moeten openen met die HTML pagina. Zo niet moet je even opzoeken hoe je dat wel juist doet. In die HTML pagina toon je gewoon het plaatje dat je met je PHP script hebt gemaakt, en refresh je het venster elke x seconden met een javascriptje. Anders open je gewoon handmatig je browser

Ik ben nu eindelijk eens begonnen met het schieten op tegenstanders. Heb gemerkt dat een aantal anderen al redeljk ver zijn met betrekking tot schieten. Veel AI heb ik echter nog niet kunnen ontdekken. Geen enkel botje lijkt te hebben verzonnen dat het minder energy kost om dichter naar je target te moven, indien je nog vaker dan 2x moet schieten. (tip van de dag ).

[ Voor 4% gewijzigd door frickY op 06-07-2005 21:51 ]

[VinShady]

ahh, ik snap het van die HTML, thnx!! Nog newbie vraagje;
door de NEWTURN krijg ik binnen dat ik meerdere messages heb, hoe kan ik die uitlezen..? (PHP)

[DaCoTa]

Op gotbot.no-ip.info:1666 draait testcode waarin de USERENTER en USEREXIT meldingen zijn geimplementeerd. Voor de liefhebbers zal ik maar zeggen Zie http://gandalf.lekkerknag...#Weergeven_aanwezige_bots voor meer info.

Verder heb ik - voor test - de scanresult van jezelf eruit gehaald. Text en uitleg hier: http://gandalf.lekkerknag...sts#Scanresult_van_jezelf, met een oproep aan SoulTaker/NDF om er ook wat over te roepen

[ Voor 33% gewijzigd door DaCoTa op 07-07-2005 01:37 ]

[Soultaker]

Zoals ik ook op de wiki schreef: het is tegenintuïtief en levert geen bruikbare nieuwe informatie, dus wat mij betreft gaat het er uit. Ik neem aan dat bestaande bots niet stukgaan als het er uit gaat (waarschijnlijk filteren ze het er al expliciet uit). Als er iemand is die er voor pleit dan wil ik wel een poll starten; als het niemand wat kan schelen dan denk ik dat het er dus gewoon uit kan.

(Argumentatie op de wiki s.v.p.)

[NDF82]

Mooi dat de ontwikkeling van de server door gaat. Ik wil zelf ook wel weer meehelpen (heb inmiddels ook een username en password van de repository). Zal kijken of ik deze week kan beginnen aan een score systeem.

[Ramon]

Misschien stom idee hoor maar het lijkt me leuk als er wat meer elementen in de gameplay zouden worden verwerkt. Het lijkt me leuk om bijvoorbeeld resources zoals kogels apart van energy te introduceren. Deze kan je dan random in het speelveld plaatsen( wel met een zekere afstand van elkaar dan...) zodat het stil blijven staan niet meer loont omdat je uiteindelijk zonder kogels/energy komt te staan.

Een bot moet dan naast energy management ook kogel management doen en af en toe langs de beide resources rijden om nieuwe voorraad op te halen.

Dan is nog de vraag of je de locatie van de resources al opgeeft of dat we ze moeten scannen eerst? Misschien kan je er een soort van beacons van maken die een bepaalde range uitstralen waar ze ongeveer staan.

Zo dat was ff een brainstormpje van mij. Reacties?

[Janoz]

Powerups zijn op zich best een leuk idee, maar in eerste instantie lijkt het me handiger om eerst de huidige voorstellen te implementeren. Brainstormen en nieuwe implementaties bedenken gaan altijd sneller dan het daadwerkelijk implementeren ervan. Laten we eerst zorgen dat er een flink aantal bots is dat met de huidige situatie om kan gaan.

Maar om op je voorstel in te gaan:
Verschil in kogels en andere energie lijkt mij niks. Mooi is nu dat je je resources strategisch moet verdelen. Anders krijg je "if kogels < x then setRoamMode". Het is misschien mooier om energy packs, en eventueel accu upgrades her en der te verspreiden. Nadeel is dat, naarmate je langer in het veld staat, je meer voordeel hebt tov mensen die net binnen komen. Dit is op te lossen door 'rounds' te gebruiken. Voordeel is dat rondlopen gunstiger is dan stilstaan.

[DaCoTa]

NDF82 schreef op donderdag 07 juli 2005 @ 09:54:
Mooi dat de ontwikkeling van de server door gaat. Ik wil zelf ook wel weer meehelpen (heb inmiddels ook een username en password van de repository). Zal kijken of ik deze week kan beginnen aan een score systeem.

Mag ik een voorstel doen en vragen of jij naar de beurtvolgorde wilt kijken? Jij bent verreweg het vloeiendst in de server code (goh, logisch ) en die vind ik nog lastig om goed aan te pakken. Ook denk ik dat die change een hogere prio heeft dan het scoresysteem, gezien daar het ei al een hele lange tijd geleden over gelegd is en het client-technisch een vrij grote wijziging is.

[DRAFTER86]

Ik probeer nu mijn C# botje meerdere bots te laten spawnen maar de connecties raken door elkaar. Zo krijg ik bijvoorbeeld de respons op een USER commando op de stream van de andere bot. Ik gebruik het streamreader-principe van de wiki....
Iemand een idee?

[Soultaker]

Ik ben er zelf nog steeds wel voor om de accu en het schild te scheiden. Het is jammer dat actief gedrag (rondrijden, shieten, scannen) nu direct bestraft wordt door de bot schade toe te brengen (want dat is wat er feitelijk gebeurt). Om actief gedrag te belonen zou de capaciteit van de accu ook wat kleiner moeten zijn (misschien twee tot drie keer de stroomtoevoer per beurt) zodat het niet nuttig is om steeds stil te staan en bij te tanken.

[DaCoTa]

Soultaker schreef op donderdag 07 juli 2005 @ 15:56:
Ik ben er zelf nog steeds wel voor om de accu en het schild te scheiden. Het is jammer dat actief gedrag (rondrijden, shieten, scannen) nu direct bestraft wordt door de bot schade toe te brengen (want dat is wat er feitelijk gebeurt). Om actief gedrag te belonen zou de capaciteit van de accu ook wat kleiner moeten zijn (misschien twee tot drie keer de stroomtoevoer per beurt) zodat het niet nuttig is om steeds stil te staan en bij te tanken.

Klinkt logisch. Bedoel je dan in de vorm dat de accu en het schild separaat opgeladen worden per beurt, of dat je energie moet besteden om je schild te repareren? Die 2e lijkt me op zich logischer, maar dan moet denk ik opnieuw bekeken worden wat de penalty is als je met een lege batterij komt te staan.

[The-MeLLeR]

Ik hoor steeds meer mensen zeggen dat ze proberen om meerde bots te spawnen.
Is dit eigenlijk wel de bedoeling? Is dan het hele AI-idee weg maar word een "ik heb de meeste bots dus ik win"-idee?

Misschien dat er een beveiliging aan de hand van het ip in de server komen...

[Verwijderd]

The-MeLLeR schreef op donderdag 07 juli 2005 @ 18:02:
Ik hoor steeds meer mensen zeggen dat ze proberen om meerde bots te spawnen.
Is dit eigenlijk wel de bedoeling? Is dan het hele AI-idee weg maar word een "ik heb de meeste bots dus ik win"-idee?

Misschien dat er een beveiliging aan de hand van het ip in de server komen...

Zover ik weet zijn er twee mogelijkheden, je speelt op een "normale" server, daar mag / kan je doen wat je wil doen. En je hebt een War Server / Contest Server, daar kan je met 1 bot andere bots bevechten. Omdat het gewoon een stuk sneller gaat kwa leermethode door meerdere bots te plaatsen is het wel erg handig. Mijn bot's kunnen samenwerken, maar ook geheel afzonderlijk opereren (dus ook 1 bot, of een team (komen mischien ooit)).

De bots leren door vallen en opstaan. Als één bot valt dan lederen de andere xxxx er van. Iedere bot zal wel ooit ergens tegen aan lopen waardoor hij valt, dus de anderen leren door de van van die bot.

Maar gezien het kwa regels lekker onduidelijk is wat dat betreft laat ik het liever open. Op WarServers / ContestServers moet je zoiets wel verbieden (niet leuk), of een maximum van bijvoorbeeld 2 of 3 bots per speler per IP.

[ Voor 12% gewijzigd door Verwijderd op 07-07-2005 18:38 ]

[Verwijderd]

Het opzet van deze contest is dus wel degelijk dat er slechts 1 botje per persoon zich op een server mag bevinden. Het ging over de AI van één botje. Wanneer je met meerdere bots kan werken spreken we hier over een multi agent system en dan gaat het over het samenwerken en informatie delen tussen de verschillende bots. 2 totaal verschillende contests dus. Een professor van mij noemde een Multi Agent System trouwens 99% architectuur en slechts 1% AI.
Maar ik merk zelf ook dat er een aantal mensen bezig zijn met samenwerkende botjes te maken. Eigenlijk was dit dus niet de bedoeling, maar mss kunnen we in de contest een nevencategorie oprichten ofzo voor teamwars. MAAR, en ik val in herhaling, dit was niet de bedoeling Dus probeer eerst maar een botje te maken dat in zijn eentje onoverwinnelijk is.

Trouwens, het is niet zo leuk als je uw enige botje op een server plaatst waar het plots tussen 100 samenwerkende botjes komt. Op die manier is het onmogelijk om een enkel botje deftig te testen. Dus mss een aparte server opzetten voor het testen van deze teams van botjes?

[Soultaker]

DaCoTa schreef op donderdag 07 juli 2005 @ 16:44:
Klinkt logisch. Bedoel je dan in de vorm dat de accu en het schild separaat opgeladen worden per beurt, of dat je energie moet besteden om je schild te repareren? Die 2e lijkt me op zich logischer, maar dan moet denk ik opnieuw bekeken worden wat de penalty is als je met een lege batterij komt te staan.

Het probleem met een lege accu zie ik niet zo: die wordt vanzelf weer bijgevuld immers. Het effect van de accu moet imo ook niet te groot worden; het model van NDF82 is naar mijn idee een beetje te ver doorgeschoten, omdat je zoveel energie mee kunt nemen dat je 'm in 1 beurt niet leeg kunt maken als je overal maximale energie in steekt.

Hoe je het schild oplaadt weet ik niet precies, als dat met energie gebeurt dan is de situatie misschien weer vergelijkbaar met hoe het nu is: met passief gedrag heb je meer energie en dus meer hitpoints. Ik zou het schild dan liever ook laten regeneren, net zoals de accu; daar heb je als bot dus weinig invloed op en je moet je bot dus zo programmeren dat 'ie zijn accu gebruikt om schade te voorkomen, in plaats van dat ontwijken (bewegen) en informatie verzamelen (scannen) juist 'schade' veroorzaakt.