[alg] botwar Bespreking *

[wacco]

En vervolgens gaan we gewoon door...

Wat dit topic nodig heeft is wat gezonde discussiestof. Like, code van een server. (ja, ik weet het, ik zeur me het apelazerus ) Laat nou eens wat zien mietje, ik verveel me en wil coden!

[MisterData]

wacco schreef op 29 november 2002 @ 17:22:
En vervolgens gaan we gewoon door...

Wat dit topic nodig heeft is wat gezonde discussiestof. Like, code van een server. (ja, ik weet het, ik zeur me het apelazerus ) Laat nou eens wat zien mietje, ik verveel me en wil coden!

* MisterData agrees

Status JS Framework: Ik heb inmiddels uitgevogeld hoe ik die JS parser aan de praat krijg in C++. Verder heb ik de code om verbinding te maken met de server al staan, daarbij gebruikmakend van JNetLib (www.nullsoft.com). Volgens de makers werkt het ook onder Linux, dus als er iemand is die een Linux bak tot z'n beschikking heeft, dan moet diegene het maar es proberen te compilen. Verder heb ik een hoop wiskundige-dingen als sin, cos, tan, tanh, sinh, asin, atan enz. gemapped zodat ze ook in JS werken. Zodra het protocol er is is het gewoon een kwestie van een kleine twee uur en dan werkt het

Niks te doen atm dus

[wacco]

Je kan natuurlijk een tut gaan schrijven hoe je in dat JS Framework een bot moet schrijven
* wacco wil wel een voorbeeldbot erin proggen als je me verteld hoe...

[MisterData]

wacco schreef op 29 november 2002 @ 17:33:
Je kan natuurlijk een tut gaan schrijven hoe je in dat JS Framework een bot moet schrijven
* wacco wil wel een voorbeeldbot erin proggen als je me verteld hoe...

Moet ik eerst weten wat een bot allemaal kan En daarvoor wachten we nog even op Mietje. Maar ik wil wel alvast docs schrijven over hoe het er ongeveer uit gaat zien

[Creepy]

farlane schreef op 29 november 2002 @ 17:15:
Volgens mij kun je van tevoren ( zeker niet bij grote projecten ) niet alle ontwerpbeslissingen maken, omdat je niet alles kunt voorzien.

Gelukkig niet

_{Dit was echt de laatste van mij hier hoor}

[Verwijderd]

wacco schreef op 29 November 2002 @ 17:12:
D'r valt (nog) niets te coden


[...]

Bedoel je niet dat protocol dat ik tikte? Ik heb mietje geen protocol zien tikken, alleen maar regels van het spel.
Protocol staat dus vast? (hoofdlijnen)

360 graden is leuker. Houd het een beetje complex. Het moet niet te simpel worden.

/me zoekt naar een protocol van mietje...

Gevonden

Verwijderd schreef op 29 November 2002 @ 12:57:
Mijn protocolvoorstel: keep it simple! Dus voorstel general specs:

• elk commando beinhoudt een cleartext regel, afgesloten door '\n'.
• verschillende velden in een commando worden gescheiden door een of meer spaties en/of tabs.
• Elk commando begint met één letter die het commandotype aangeeft.
• Verdere velden zijn double precision waardes met een precisie van 12 cijfers achter de komma.

Client protocol:

• G <richting> <energie> // Beweeg de tank
• S <energie> // Meer energie naar het schild
• V <richting> <energie> <energie> // Vuur een projectiel af
• R <energie> // Doe een radarscan

<richting> is daarbij een een double van -Pi tot Pi (radialen)

Over he serverprotocol wordt nog niet veel gesproken, en heb ik ook nog niet echt nagedacht. Er moet bv. een deelprotocol komen om de spelers te identificeren.

Maar dit is ook maar een voorstel natuurlijk. Goed lijkt me dat het protocol zo snel mogelijk vastligt, ik wil alvast een (natuurlijk voor iedereen beschikbare) interface voor PHP maken

[MisterData]

Verwijderd schreef op 29 november 2002 @ 17:44:
[...]


* MisterData zoekt naar een protocol van mietje...

Gevonden


[...]


Maar dit is ook maar een voorstel natuurlijk. Goed lijkt me dat het protocol zo snel mogelijk vastligt, ik wil alvast een (natuurlijk voor iedereen beschikbare) interface voor PHP maken

Deze reply had ik ook over het hoofd gezien Ik stel voor dat we dit dan maar gelijk als standaard zullen uitroepen. De functies die hierboven zijn voorgesteld kunnen we natuurlijk altijd nog uitbreiden Ik ga dit maar eens implementeren

[Verwijderd]

Ik snap niet waarom je de servercode nodig hebt om de basis van je client te implementeren. Een groot gedeelte van je client zal (net als de server) bestaan uit positie- en snelheidsberekeningen, en daar kun je al aan beginnen. Voorbeeldje: het speelveld is in zich gesloten (als je er aan een kant uitrijdt kom je er aan de overliggende kant weer in), schrijf een functie die de (minimale) afstand tussen twee objecten berekent, aangenomen dat het speelveld D * D groot is...

Het lijkt me averechts te werken als ik nu mijn code publiceer. Er gaan gegarandeerd nog physics-constanten veranderen. Wie dus nu begint met een client te bouwen gebaseerd op de servercode heeft kans dat een groot deel van zijn werk voor niets is.

[MisterData]

Verwijderd schreef op 29 November 2002 @ 17:51:
Ik snap niet waarom je de servercode nodig hebt om de basis van je client te implementeren. Een groot gedeelte van je client zal (net als de server) bestaan uit positie- en snelheidsberekeningen, en daar kun je al aan beginnen. Voorbeeldje: het speelveld is in zich gesloten (als je er aan een kant uitrijdt kom je er aan de overliggende kant weer in), schrijf een functie die de (minimale) afstand tussen twee objecten berekent, aangenomen dat het speelveld D * D groot is...

Het lijkt me averechts te werken als ik nu mijn code publiceer. Er gaan gegarandeerd nog physics-constanten veranderen. Wie dus nu begint met een client te bouwen gebaseerd op de servercode heeft kans dat een groot deel van zijn werk voor niets is.

Ik ga gewoon het protocol implementeren, de rest van de logica moet dan in de JavaScript

[MisterData]

Owwjah ik stel voor dat de server op poort 1337 draait

[wacco]

Leuk dat je em voor standaard wilt uitroepen, maar ik vind em verre van compleet. Zie mijn protocol voor wat ik bedoel (ze verschillen btw ook geen donder, alleen dat de waardes dubble precision zijn en dat de commando's zijn ingekort )
Over die extreem korte commando's, ik vind het niet echt veilig. Stel dat de connectie ff brak is, parity bit filterd er niet uit, en de V veranderd in een G. Dan gaan er een paar bots crashen die drie extra letters, wat maakt dat nou uit (zolang het maar geen hele xml regel wordt )

edit:

Ik moet m'n venster vaker verversen dit was dus als reactie op [rml]MisterData in "[ alg] botwar Bespreking *"[/rml]
poort 1337, ach, waarom ook niet?

[ Voor 17% gewijzigd door wacco op 29-11-2002 18:03 ]

[MisterData]

wacco schreef op 29 November 2002 @ 17:59:
Leuk dat je em voor standaard wilt uitroepen, maar ik vind em verre van compleet. Zie mijn protocol voor wat ik bedoel (ze verschillen btw ook geen donder, alleen dat de waardes dubble precision zijn en dat de commando's zijn ingekort )
Over die extreem korte commando's, ik vind het niet echt veilig. Stel dat de connectie ff brak is, parity bit filterd er niet uit, en de V veranderd in een G. Dan gaan er een paar bots crashen die drie extra letters, wat maakt dat nou uit (zolang het maar geen hele xml regel wordt )

Ik dacht niet dat de tekst zomaar kon veranderen als je TCP/IP kon gebruiken? Volgens mij is TCP/IP daar juist op voorbereid (itt tot UDP, dat helemaal geen foutcorrectie kent)

[.oisyn]

wacco schreef op 29 November 2002 @ 17:59:
Leuk dat je em voor standaard wilt uitroepen, maar ik vind em verre van compleet. Zie mijn protocol voor wat ik bedoel (ze verschillen btw ook geen donder, alleen dat de waardes dubble precision zijn en dat de commando's zijn ingekort )
Over die extreem korte commando's, ik vind het niet echt veilig. Stel dat de connectie ff brak is, parity bit filterd er niet uit, en de V veranderd in een G. Dan gaan er een paar bots crashen die drie extra letters, wat maakt dat nou uit (zolang het maar geen hele xml regel wordt )

ya right, hoe vaak heb jij ontdekt dat de data die over het net verstuurd werd niet juist was?

Het is niet puur die pariteitsbit (zijn er meerdere), en daar is heus wel over nagedacht hoor! Dat soort fouten komen zo goed als niet voor, sterker nog, ik durf er wel geld op in te zetten dat het gewoon NIET voorkomt

[wacco]

Whatever... niet echt boeiend. Wat ik wil zeggen is dat het verschil tussen mietje's protocol en die van mij vrijwel niet verschilt. Ik wil alleen weten wat we nu gaan doen. Ik kan wel gaan coden, maar zolang ik niet weet wat de server terugspuugt na een commando ga ik niet beginnen. En ja, dat hakt flink in m'n design van m'n code. En nee, ik ga niet alvast een paar loze functietjes schrijven.

[.oisyn]

MisterData schreef op 29 November 2002 @ 18:01:
(itt tot UDP, dat helemaal geen foutcorrectie kent) )

zowel UDP als TCP kennen geen foutcorrectie, dat is iets wat eventueel door een laag eronder geregeld kan worden. Maar foutieve pakketjes worden over het algemeen gewoon gedropped, jij zal nooit een UDP of TCP pakketje binnenkrijgen (op applicatieniveau bedoel ik dan) wat niet klopt

[Thijsch]

Je kan WEL alvast coden.

Wat ik doe is dit:

een header file genaamt protocol.h

code:

#define FIRE ""
#define MOVE ""
#define TURN ""

#define CHECK ""
#define MY_HP ""
#define IFHIT ""

dan kan je vast met FIRE enzo code en vul je de rest later in.

[MisterData]

ParaDot schreef op 29 november 2002 @ 18:19:
Je kan WEL alvast coden.

Wat ik doe is dit:

een header file genaamt protocol.h

code:

#define FIRE ""
#define MOVE ""
#define TURN ""

#define CHECK ""
#define MY_HP ""
#define IFHIT ""

dan kan je vast met FIRE enzo code en vul je de rest later in.

Great minds think alike Zoiets wilde ik ook doen. Het zo maken dus, dat de implementatie van de bot altijd veranderd kan worden.

[MisterData]

Dit bericht is vooral voor mietje
Ben bezig met het schrijven van wat algemene docs over GPCScript (heb m'n JS framework maar een naam gegeven ) en ik had een ideetje:

Opbouw van het spel
Iedere robot heeft een energie-buffer. In die buffer zit de energie opgeslagen die de robot gebruikt, om te bewegen, te schieten en te draaien. Die buffer wordt iedere beurt voller, maar als 'ie 'overloopt' explodeert je bot. Zoals gezegd kost het rijden, schieten en draaien energie. De hoeveelheid energie in de buffer wordt in GPCScript aangegeven in een getal van 0 tot honderd (een kommagetal).


Iedere bot heeft ook een vast aantal HP (Hit Points) waarmee hij begint. Wordt de bot beschoten, dan gaan er (afhankelijk van de kracht van het schot) een aantal HP's af. Echter, je kunt energie in de buffer omzetten in HP's. Je kunt je eigen bot dus repareren. Denk er wel aan dat repareren erg veel energie kost.

Het gaat mij vooral om dat laatste stukje. Ik wilde even weten wat jullie vinden om een Repair-functie in te bouwen, waarmee 5 energy-punten kunnen worden omgewisseld tegen 1 HP ofzo. Laat me weten hoe je hier over denkt.

[MisterData]

Even een paar dingen:
• Ik heb de docs voor GPCScript bijna klaar, kijk met me mee via dit adres

• We moeten nog steeds een keer bepalen hoever je kan rijden met x energiepunten. Moet dit at-runtime worden bepaald (dwz moeten we deze waarden van de server opvragen) of kunnen we ze gewoon hardcoded in onze progsels zetten (of in dit geval, coderen in het script)

• Een snapshot van wat ik aan het maken ben is nu ook te downloaden Voor de mensen die mij blindelings vertrouwen (ahum ) is hier de binary-zip te downloaden. Voor de mensen die graag zelf het zootje controleren (en niet terguschrikken van een bestand met een paar honderd regels code, want dat is het dus geworden, ik ga het nog een keer onderverdelen in files) is hierhet zippie met source te downloaden De sources zijn in C++ en er zit een .dws/.dsp bij voor VC++ Zip 1 is 272KB groot, en de zip met alleen de sources 82 KB.

edit:

.oisyn: sorry voor de vele posts hierboven....

[ Voor 50% gewijzigd door MisterData op 29-11-2002 19:33 ]

[wacco]

Ik ben morgen weer thuis achter m'n vertrouwde peeceetje, en zal dan een basic bot in c bouwen.
Misschien is het handig om een nette post te maken (die straks ook als openingspost gebruikt kan worden voor nieuwe draadje) waarin alles staat.
* wacco gaat dat dus doen!
Maar heb ik morgenmiddag waarschijnlijk pas af, omdat ik nu niet thuis ben

[Verwijderd]

Ik heb het (overigens knap lange) topic gelezen en het allemaal een beetje aangekeken, maar nu toch besloten dat ik graag mee wil doen (gezien de specs).
Moet ik me nog ergens aanmelden? Of loopt het hele zaakje gewoon via GoT?

[MisterData]

Verwijderd schreef op 30 November 2002 @ 02:34:
Ik heb het (overigens knap lange) topic gelezen en het allemaal een beetje aangekeken, maar nu toch besloten dat ik graag mee wil doen (gezien de specs).
Moet ik me nog ergens aanmelden? Of loopt het hele zaakje gewoon via GoT?

Ligt eraan wanneer de wedstrijd begint en wie de jury is. Wat mij betreft mag je nu al beginnen met je bot, maar ga dan niet zeuren als het protocol tussendoor nog veranderd. Zodra we met alles klaar zijn begint de wedstrijd 'officieel'. Je hoeft je dan niet aan te melden, aangezien we op de server kunnen zien wie er allemaal inlogt

[wacco]

MisterData schreef op 30 november 2002 @ 08:43:
[...]

Ligt eraan wanneer de wedstrijd begint en wie de jury is. Wat mij betreft mag je nu al beginnen met je bot, maar ga dan niet zeuren als het protocol tussendoor nog veranderd. Zodra we met alles klaar zijn begint de wedstrijd 'officieel'. Je hoeft je dan niet aan te melden, aangezien we op de server kunnen zien wie er allemaal inlogt

My words exactly. Wacht ff tot d'r een nieuw draadje wordt geopend met alle info op een rijtje.
Hoe gek het ook klinkt, nu al vast standaard functies schrijven (en defines enzow) is geen goed idee. Protocol kan flinke impact hebben op de info die je krijgt, dat kan weer flink je tactiek onderuit halen, wat weer ervoor kan zorgen dan sommige functies nét niet lekker werken, waardoor je die dus moet gaan zitten aanpassen.
En believe me, dat is een heidens karweitje.

[MisterData]

wacco schreef op 30 november 2002 @ 10:01:
[...]


My words exactly. Wacht ff tot d'r een nieuw draadje wordt geopend met alle info op een rijtje.
Hoe gek het ook klinkt, nu al vast standaard functies schrijven (en defines enzow) is geen goed idee. Protocol kan flinke impact hebben op de info die je krijgt, dat kan weer flink je tactiek onderuit halen, wat weer ervoor kan zorgen dan sommige functies nét niet lekker werken, waardoor je die dus moet gaan zitten aanpassen.
En believe me, dat is een heidens karweitje.

Ach, heb toch niks te doen Draadje met info moet toch eigenlijk pas komen als alles rond is??

[Verwijderd]

Protocol kan flinke impact hebben op de info die je krijgt

Ehm, nee? Het protocol specificieert HOE je data verstuurt, niet wat de inhoud van die data is... En welke data verstuurt gaat worden is toch al bekend? Dat is gewoon afhankelijk van de game rules...

[Verwijderd]

als je echt ongeduldig bent, kan je al beginnen coden hoor, denk maar aan

* sockets
* GUI ontwerp (ik ga een eenvoudige 2d weergave maken)
* ...

ik ga er vandaag ook mee beginnen, gewoon wat aan de layout kloten , het oog wil ook wat

[MisterData]

Verwijderd schreef op 30 november 2002 @ 15:24:
als je echt ongeduldig bent, kan je al beginnen coden hoor, denk maar aan

* sockets
* GUI ontwerp (ik ga een eenvoudige 2d weergave maken)
* ...

ik ga er vandaag ook mee beginnen, gewoon wat aan de layout kloten , het oog wil ook wat

Ik ben er nu mee bezig Ik zit een paar functies in te bouwen voor de echte wiskunde-n00bs om uit te rekenen hoever een punt van de robot afligt, welke hoek de robot moet maken om naar een bepaald punt te gaan enz. Daarnaast ga ik dadelijk nog een en ander aan GUI maken (zoals debugging-schermen enzo). Alleen de console is ook zo saai

[Verwijderd]

Misschien een wat meer praktische vraag:
heeft iemand al een programma dat de stdin/stdout van een ander programma naar een socket kan redirecten?

[ Voor 6% gewijzigd door Verwijderd op 30-11-2002 15:43 . Reden: practisch schrijf je met een k ]

[MisterData]

Verwijderd schreef op 30 november 2002 @ 15:42:
Misschien een wat meer pracktische vraag:
heeft iemand al een programma dat de stdin/stdout van een ander programma naar een socket kan redirecten?

Ehm.... waarom wil je dit doen? Zodat je geen moeilijke socket-code hoeft te schrijven? Tsja, daar moeten we dan even een progsel voor schrijven. Misschien dat wacco tijd heeft? Ik zal hem es mailen.

[Verwijderd]

Ehm.... waarom wil je dit doen? Zodat je geen moeilijke socket-code hoeft te schrijven? Tsja, daar moeten we dan even een progsel voor schrijven. Misschien dat wacco tijd heeft? Ik zal hem es mailen.

Ik kan het schrijven van een redirect naar socket zelf ook wel hoor
Maar voor het geval dat iemand dat ondertussen al gedaan heeft...

[ Voor 6% gewijzigd door Verwijderd op 30-11-2002 15:47 . Reden: erg ambigue zin ]

[MisterData]

Verwijderd schreef op 30 November 2002 @ 15:46:
[...]

Ik kan het schrijven van een redirect naar socket zelf ook wel hoor
Maar voor het geval dat iemand dat ondertussen al gedaan heeft...

Hmm had dat eerder gezegd, nu heb ik wacco al gemaild Ik kan het zelf ook maar ben bezig met GPCScript, een laagje rond een JS-interpreter zodat je een bot in JS kan coden. Wat mij betreft kun jij wel zo'n prog maken

[wacco]

Mailtjuh recieved
Redirren kan denk ik alleen als je het proggie ernaast laat draaien, en dan communicatie tussen die twee. Ook zou je je stdin/stdout moeten gebruiken in runtime, socket moet open blijven staan, om een lang verhaal kort te maken, dat ga ik niet uitpluizen
* wacco is met een IRC bot bezig in php @ the moment, ga met de botwar beginnen als botwar begint
+- over een weekje?

[MisterData]

wacco schreef op 30 november 2002 @ 15:54:
Mailtjuh recieved
Redirren kan denk ik alleen als je het proggie ernaast laat draaien, en dan communicatie tussen die twee. Ook zou je je stdin/stdout moeten gebruiken in runtime, socket moet open blijven staan, om een lang verhaal kort te maken, dat ga ik niet uitpluizen
* wacco is met een IRC bot bezig in php @ the moment, ga met de botwar beginnen als botwar begint
+- over een weekje?

Dan mag Infinitve het redirect-prog maken. Volgens mij is het het slimst als je vanuit je redirect-prog je andere prog aan te roepen. Zie ook www.cppreference.com

[Verwijderd]

Onder unix is dit process recht-door-zee:

1 maak vier pipes
2 fork()
3 connect stdin/stdout van parent en client met de pipes
4 client: exec het te runnen programma (klaar wat client betreft)
5 server: connect met server
6 luister aan stdin/stdout en sockets via de select calls
7 indien data beschikbaar, read & write
8 repeat 6

Onder windows zal stap 1-4 nog wel wat uitzoekwerk worden (geen fork onder windows) en stap 6 (met de select functie kunnen niet tegelijkertijd aan sockets en pipes geluisterd worden - tenminste, niet met de select functie).

[ Voor 9% gewijzigd door Verwijderd op 30-11-2002 16:35 ]

[MisterData]

Verwijderd schreef op 30 November 2002 @ 16:32:
Onder unix is dit process recht-door-zee:

1 maak vier pipes
2 fork()
3 connect stdin/stdout van parent en client met de pipes
4 client: exec het te runnen programma (klaar wat client betreft)
5 server: connect met server
6 luister aan stdin/stdout en sockets via de select calls
7 indien data beschikbaar, read & write
8 repeat 6

Onder windows zal stap 1-4 nog wel wat uitzoekwerk worden (geen fork onder windows) en stap 6 (met de select functie kunnen niet tegelijkertijd aan sockets en pipes geluisterd worden - tenminste, niet met de select functie).

Onder Windows moet je eerst zorgen dat je een stream (istream?) naar stdin en (ostream?) naar stdout van het programma. Volgens mij kun je daar met peek kijken of er iets staat te wachten. Hetzelfde geldt voor sockets. Stap 6 is dus op te lossen door in plaats van read gewoon een peek te doen op een istream

Beetje duidelijk wat ik bedoel?

[Verwijderd]

Wat pipes betreft, heb denk ik documentatie gevonden:

Creating a Child Process with Redirected Input and Output

Trouwens, zo'n pipe is een HANDLE en een socket kan ook zo gezien worden (als ik dat tenminste correct herinner), dus misschien dat zo'n WaitForMultipleObjects erop toepasbaar is.

[ Voor 9% gewijzigd door Verwijderd op 30-11-2002 16:44 ]

[Sjaaky]

Zo'n redirect programma is toch netcat?

[MisterData]

Voor de mensen die nog nooit een AI hebben gemaakt: http://www.gamedev.net/reference/list.asp?categoryid=18#1

Dit is een lijst met ontzettend veel artikelen over het maken van een AI. Ik ga het zeker es doorlezen

[MisterData]

edit:
Nieuwe schreenshot

ouwe screenshot

Zoals je ziet kun je bovenaan Disconnecten, en kun je zien met welke server er verbinding is. Daaronder zie je de script-output (voor debug-output uit het script zelf). Daaronder komt straks weer de informatie over de bot (heading, energie, x, y enzovoort). De optie om GPCScript gewoon weer als console-programma te compileren is ingebouwd. Je kunt door in de preprocessor CONSOLE te definieren weer terug naar de ouwe trouwe DOS-console. De console-versie maakt alleen maar gebruik van de standaard C-library en de STL, dus dat is vrij portable.

[ Voor 13% gewijzigd door MisterData op 02-12-2002 19:28 ]

[wacco]

Laat ik ook maar weer eens wat zeggen. MIETJUH! HOE ZIT DAT NOU MET DIE SERVERT VAN JUH?!
En begint dat protocol nou al een beetje vorm te krijgen? En en en...
wordt dit nog wat?
ik ben trouwens wat tactics dingetjes aan het uitdenken, misschien dat ik het als documentje online zet (ben ik nog niet helemaal unaniem over uit met mezelf)

[MisterData]

wacco schreef op 02 December 2002 @ 18:45:
Laat ik ook maar weer eens wat zeggen. MIETJUH! HOE ZIT DAT NOU MET DIE SERVERT VAN JUH?!
En begint dat protocol nou al een beetje vorm te krijgen? En en en...
wordt dit nog wat?
ik ben trouwens wat tactics dingetjes aan het uitdenken, misschien dat ik het als documentje online zet (ben ik nog niet helemaal unaniem over uit met mezelf)

Misschien is het handig als je even een documentje met daarin 'AI coden voor beginners' ofzo Verder heb ik nu eea veranderd in de GUI, screenshot coming up

[Verwijderd]

/me is druk bezig

Onderschat het niet, het is behoorlijk veel werk die server te bouwen. Ik ben nu eindelijk tevreden over de engine (na 2 rewrites), die loopt nu volledig continue en is zo nauwkeurig dat je er naar van wordt Ik ben nu bezig met het spelersinterface, maar dat moet ik anders aanpakken dan normaal serverinterface (je kunt geen lees/schrijf-thread aan een socket hangen omdat je vanuit de parent exact moet bepalen hoe lang een spelbeurt duurt, en dat wordt verdomd lastig asynchroon...)

[Verwijderd]

hier is mijn eerste wipje van mij bot

nog geen AI, ik ben gewoon een GUI aan het maken zodat ik de war ook zelf kan volgen

[MisterData]

Ik ben er op dit moment niet meer actief aan bezig, ik wacht nog steeds op het protocol....

[cobratbq]

De hele topic is een beetje dood gevallen geloof ik!
Heeft iedereen er nog wel zin in of zwakt alles al af omdat die server nog niet klaar is?
(No offense Mietje, ik weet dat het een heel karwei is)

Kom op jongens, een beetje doorzetten.

[Orphix]

Ik heb er nog wel zin in hoor! Alleen wacht ik eerst tot
a) de server + specificaties af zijn en
b) ik vakantie heb

[wacco]

zie voor mijn redenen Orphix's post
En ik heb er _zeker_ zin in!

[Verwijderd]

als het zo rustig is kan misschien iemand een overzicht maken met alle afspraken e.d. in 1 post ofzo?

[Apollo_Futurae]

lnfinitive heeft in zijn sig:
putStr (map (\x -> chr (round (21/2 * x^3 - 92 * x^2 + 503/2 * x - 105))) [1..4])

ah, een naamgenoot

[cobratbq]

Verwijderd schreef op 04 December 2002 @ 14:02:
als het zo rustig is kan misschien iemand een overzicht maken met alle afspraken e.d. in 1 post ofzo?

Ik dacht dat in een paar posts hierboven een goeie samenvatting stond, of misschien was dat vorige pagina. iig redelijk recent.
Tnx 4 the good mood

edit:
Laat maar, is langer geleden dan ik dacht ... Sorry
Ik had zeker meer pagina's in m'n cache dan ik dacht

[ Voor 16% gewijzigd door cobratbq op 05-12-2002 21:21 ]

[DaCoTa]

Hoe gaat het, mietje? Niet om je te haasten, maar het is erg stil hier en ik ben best wel benieuwd naar hoe het gaat worden eigenlijk.

edit:

[ Voor 8% gewijzigd door DaCoTa op 06-12-2002 16:03 ]

[Verwijderd]

Ik verwacht dat na het weekend het server prototype klaar is (onder voorbehoud). Ik heb nog geen identificatieprotocol aan het lopen, dus op dat prototype kun je dingen die in v1.0 niet mogelijk zullen zijn, zoals deelnemen met een ongeregistreerde client of met meerdere clients vanaf een ip deelnemen. Tevens is er nog geen observer-mode geimplementeerd (die ga ik trouwens limiten tot localhost connecties).

edit:
Het protocol ligt al voor een groot deel vast. Als ik straks thuis ben zal ik het posten.

[ Voor 12% gewijzigd door Verwijderd op 06-12-2002 15:22 ]

[MisterData]

Verwijderd schreef op 06 December 2002 @ 15:20:
Ik verwacht dat na het weekend het server prototype klaar is (onder voorbehoud). Ik heb nog geen identificatieprotocol aan het lopen, dus op dat prototype kun je dingen die in v1.0 niet mogelijk zullen zijn, zoals deelnemen met een ongeregistreerde client of met meerdere clients vanaf een ip deelnemen. Tevens is er nog geen observer-mode geimplementeerd (die ga ik trouwens limiten tot localhost connecties).

edit:
Het protocol ligt al voor een groot deel vast. Als ik straks thuis ben zal ik het posten.

Dat is mooi, dan kan ik eindelijk m'n framework afmaken Ik heb er niet zoveel meer aan gedaan sinds de vorige screenshot...

[Verwijderd]

Shit, iets vergeten... Ik paste dit rechtstreeks uit de header

code:

/* Protocol:
 * - Commando's bestaan uit een regel cleartext, eindigend op een newline.
 * - Elk commando bestaat uit verschillende velden, gescheiden door whitespace.
 * - Het eerste veld is een karakter lang en beschrijft het commando-type.
 */

/* Client protocol:
 * Rijden:      G <richting> <energie>
 * Schieten:        V <richting> <schild-energie> <buffer-energie>
 * Schild:      S <energie>
 * Radarscan:       R <energie>
 * Einde beurt:     .
 */

/* Server protocol:
 * Client is winnaar:   W
 * Client is dood:  D ["dader-naam"]
 * Client heeft gedood: R "slachtoffer-naam"
 * Status:      S <schild-energie> <buffer-energie>
 * Radarscan:       O <type> <richting> <afstand> <object-richting> <object-snelheid>
 * Einde beurt:     .
 */

[MisterData]

Verwijderd schreef op 06 December 2002 @ 22:08:
Shit, iets vergeten... Ik paste dit rechtstreeks uit de header

code:

/* Protocol:
 * - Commando's bestaan uit een regel cleartext, eindigend op een newline.
 * - Elk commando bestaat uit verschillende velden, gescheiden door whitespace.
 * - Het eerste veld is een karakter lang en beschrijft het commando-type.
 */

/* Client protocol:
 * Rijden:      G <richting> <energie>
 * Schieten:        V <richting> <schild-energie> <buffer-energie>
 * Schild:      S <energie>
 * Radarscan:       R <energie>
 * Einde beurt:     .
 */

/* Server protocol:
 * Client is winnaar:   W
 * Client is dood:  D ["dader-naam"]
 * Client heeft gedood: R "slachtoffer-naam"
 * Status:      S <schild-energie> <buffer-energie>
 * Radarscan:       O <type> <richting> <afstand> <object-richting> <object-snelheid>
 * Einde beurt:     .
 */

Dit is niet bepaald volledig helaas Hoe moet ik aangeven wat de naam van de bot is en hoe kan ik zien welke en hoeveel bots er online zijn? Het zijn dan misschien wat minder belangrijke functies, maar het lijkt me dat dat er toch in moet. Is het gewoon nog niet af of moet je het nog posten?

[Soultaker]

MisterData schreef op 06 December 2002 @ 22:51:
Dit is niet bepaald volledig helaas Hoe moet ik aangeven wat de naam van de bot is en hoe kan ik zien welke en hoeveel bots er online zijn? Het zijn dan misschien wat minder belangrijke functies, maar het lijkt me dat dat er toch in moet.

Wie zegt dat dat erin moet? De namen van de bots worden bij het configureren van de arena opgegeven (desnoods aan de hand van de bestandsnamen). Als ik het protocol zo zie, speelt elke client per executie precies één spelletje, dus het is nogal zinloos om bij te houden wie aanwezig is.

Het is de vraag of het wenselijk is dat elke client weet welke en hoeveel tegenstanders er nog zijn. In principe moet 'ie daar maar voor scannen. Je kunt er vanuit gaan dat er altijd tenminste één tegenstander aanwezig is, anders breekt de server het spel wel af.

[Orphix]

Soultaker schreef op 06 december 2002 @ 23:16:
Het is de vraag of het wenselijk is dat elke client weet welke en hoeveel tegenstanders er nog zijn. In principe moet 'ie daar maar voor scannen. Je kunt er vanuit gaan dat er altijd tenminste één tegenstander aanwezig is, anders breekt de server het spel wel af.

Aan de andere kant kan je je strategie ook weer af laten hangen van het aantal spelers. Bijvoorbeeld bij veel spelers een wat rustigere tactischere houding aannemen terwijl je bot bij nog maar 1 tegenspeler misschien een soort 'alles of niets' houding aan wilt nemen.

[Verwijderd]

Het plan is als volgt: iedere speler registreert voor de "finaleronde" een client onder een bepaalde naam. Na de registratie krijg je een password en daarmee kun je inloggen op de server. Tijdens die finale mag er maar één client met een bepaalde naam spelen, en er mag ook maar één client vanaf een bepaald ip spelen.

Daarnaast lijkt het me leuk als je weet door welke client je afgemaakt wordt cq. welke clients jij afmaakt, daarom zet ik die spelersnaam erbij in kill-berichten van de server naar de client. Als je het niet interessant vindt voor je client, lees je er toch overheen Alle commando's zijn strict van de server naar een client, er worden dus geen kill-berichten naar alle clients gebroadcast, alleen naar de dader en het slachtoffer.

Zoals het er nu uitziet weet je dus niet hoeveel clients er in de arena zijn, je weet alleen hoeveel jij er gedood hebt. De grootte van de arena is ook niet bekend, en die is afhankelijk van het aantal deelnemende clients. Clients worden niet random in de arena geplaatst maar op gelijke onderlinge afstand. Zoals al gemeld is de arena in zich gesloten, dus geen enkele client heeft voordeel op die manier.

Verder is <richting> een double van -Pi t\m +Pi radialen (absolute waardes, 0 radialen is richting oost Pi of -Pi radialen is richtig west, Pi/2 is noord, -Pi/2 is zuid), <afstand> een afstand in meters, <snelheid> een snelheid in m/s en <energie> een fictieve energiewaarde, <type> is 0 of 1 voor respectievelijk een projectiel of een tank.

Berichten van de server naar de client hebben deze volgorde: 0... * "R...", 1 * "S...", 0... * "O...", 1 * ".". Maw. de kills in de vorige beurt, de status en de objecten op de radar. Als de client gedood is of winnaar is, ziet de volgorde er zo uit: 0... * "R...", (1 * "D..." of 1 * "W"), 1 * ".".

Berichten van de client naar de server hoeven geen bepaalde volgorde te hebben, elk commando mag meermaals per beurt gestuurd worden, maar alleen het laatste commando wordt uitgevoerd (je kunt dus bv. zo vaak schieten als je wilt maar alleen het laatste schot wordt uitgevoerd). De server voert de bevelen in de volgende volgorde uit (dit is belangrijk voor de eindrichting en eindsnelheid van een afgeschoten projectiel): stuur de tank, schiet, voeg energie toe aan het schild, doe een scan. De resultaten van een scan worden dus pas bij de volgende beurt bekend, maar zijn wel up to date.

Nog wat losse eindjes: 1) Een tank rijdt met de laatst gegeven richting en snelheid door zolang als je hem niet stopt. 2) Het spel draait nu 1 fps, tankjes zijn max. 20 m/s snel, projectielen tussen 180 en 220 m/s.

[ Voor 8% gewijzigd door Verwijderd op 07-12-2002 06:25 ]

[Orphix]

Ok, hier kunnen we vast verder op bouwen
Nog even een vraagje, zodra ik een "S..." commando van de server krijg mag ik ervan uitgaan dat dat het teken is dat we in een nieuwe frame komen?
En wat gebeurt er wanneer bv 2 raketten in dezelfde frame exploderen en allebei verantwoordelijk zijn voor het 'dood laten gaan' van een tank? Wie krijgt dan de eer van de kill?

[Verwijderd]

Is er al een deadline voor het inleveren van code/binaries? Ik heb nl 16-20 dec vrij, dan heb ik pas echt tijd me in de engine te verdiepen (ben nu alleen beetje met het communicatie framework bezig, sockets e.d.)

[jelmervos]

Orphix schreef op 07 december 2002 @ 13:49:
[...]

En wat gebeurt er wanneer bv 2 raketten in dezelfde frame exploderen en allebei verantwoordelijk zijn voor het 'dood laten gaan' van een tank? Wie krijgt dan de eer van de kill?

De tank die het eerst schoot? De tank die het verst weg staat?

[Verwijderd]

Orphix schreef op 07 December 2002 @ 13:49:
Ok, hier kunnen we vast verder op bouwen
Nog even een vraagje, zodra ik een "S..." commando van de server krijg mag ik ervan uitgaan dat dat het teken is dat we in een nieuwe frame komen?

Zodra als je een bericht van de server krijgt is het (in principe) jouw beurt, je kunt beginnen met commando's versturen zodra als de server zijn afsluitende "." heeft verstuurd. (In principe, want na een "D..." of "W" bericht ben je natuurlijk niet meer aan de beurt).

En wat gebeurt er wanneer bv 2 raketten in dezelfde frame exploderen en allebei verantwoordelijk zijn voor het 'dood laten gaan' van een tank? Wie krijgt dan de eer van de kill?

Binnen een frame doet de server een continue-simulatie. De precisie is dus niet 1 seconde maar veel hoger (anders heb je een afwijking van gemiddeld 100 meter in je schoten). In het onwaarschijnlijke geval dat twee projectielen op exact de zelfde tijd raken zal de server één van die twee projectielen de "kill" toekennen, niet alletwee. (Maar het is dus onwaarschijnlijk dat dit gebeurt, de server simuleert met een precisie van meer dan 1 microseconde.)

[ Voor 4% gewijzigd door Verwijderd op 07-12-2002 15:02 ]

[wacco]

Kan je de radarscan (O) wat verder uitleggen? Hijs nu een beetje vaag... wat krijg ik nu als resultaat?
Alleen maar objecten? Geen ondergrond?

Verder vraagt dit volgens mij om een nieuw draadje

[Verwijderd]

Toch een voorbeeldje:

1e beurt:
server stuurt:
"S 200 200" (status: 200 energie in het schild en 200 energie in de buffer)
"."

client stuurt:
"G 3.1415 90.3" (ga naar het westen, stuur 90.3 energie naar de motor)
"V 0 13.4 50" (richt op het oosten, schiet met 13.4 schild en 50 explosie-energie)
"S 20" (20 energie naar het schild")
"R 11.2" (radarscan met 11.2 energie)
"."

2e beurt:
server stuurt:
"R hanky panky v2" (client heeft "hanky panky v2" gedood)
"R killbot" (client heeft "killbot" gedood)
"S 210 110" (status: 210 energie in het schild en 110 energie in de buffer)
"O 0 1.67 100 -1.67 190" (er komt een projectiel vanuit het noorden op de client af)
"O 1 1.67 105 0 10" (er is een tank in het noorden op 105 meter afstand)
"."

[MisterData]

Dat verduidelijkt het al een beetje ja Is het geen idee om de naam van de owner apart te houden van de naam van de bot? Dan kunnen we nog eea met de scores enzo regelen en kan iedereen meerdere bots maken. Ik heb in mijn GPCScript al onderscheid gemaakt tussen ownernaam en botnaam, dus misschien is dat wel makkelijk

[Verwijderd]

Ik registreer alleen de clientnaam, geen eigenaars. Evt. scores worden dus per client bijgehouden. Scores zijn overigens niet geimplenteerd, het ging om een "last man standing" contest, er is dus maar één ronde.

wacco>> Verschillende ondergrond is er ook (nog) niet, er zijn nu alleen objecten. Dat maakt het naar mijn mening al moeilijk genoeg, vooral omdat schoten die langer dan 1 beurt in de lucht zijn (verder dan 200 meter dus) nogal complex zijn. Kom je echter binnen die 200 meter straal van een andere tank, dan kan die tank jou in de volgende beurt afgemaakt hebben zonder dat jij de kans hebt te reageren...

edit:
in dit geval maakt de turnbased opzet het spel dus moeilijker...

Verder heeft de richting en snelheid van je tank invloed op de richting en snelheid van je schoten, voor het geval dat nog niet duidelijk is. Dat maakt het nog wat moeilijker (maar wel realistischer).

[ Voor 23% gewijzigd door Verwijderd op 07-12-2002 15:57 ]

[wacco]

Raketten gaan 200 m/s he... hoe groot is het veld dan?
(ik weet wel dat dat niet duidelijk is, maar ongeveer in 'omtrek')
I don't like the idea of getting shot without even knowing...

-edit-
Misterdata: dat weet je dus niet! Je hebt pas gewonnen als de server je dat verteld. Dat houd het spannend, je moet _altijd_ op je hoede blijven, er kan best nóg een bot rondcrossen behalve degene die je achterna jaagt.

[ Voor 41% gewijzigd door wacco op 07-12-2002 17:33 ]

[wacco]

MisterData: ik ben er niet van gewenst als m'n complete bericht gequote wordt, en aangezien je het ongeveer met elke post doet die in dit draadje geplaatst wordt is dit draadje ongeveer 2x zo lang...
en dan zjin je toevoegingen van één regel nog harstikke loos ook.
Verder zit je wéér 2 posts achter elkaar te mikken, en zijn je vragen compleet zinloos. Is namelijk allemaal al voorbij gekomen.

Namelijk:
d'r zijn geen x en y coordinaten, jij bent dus gewoon het midden, en alles wat je scan terugspuugt zijn afstanden tot jou, met een richting waar je naar moet kijken. Je moet hier dus niet met een veldarray gaan werken, maar met vectoren.
Dat het veld 'oneindig' is, dus 'rond', is alleen maar een zorg voor de server.

Verder heb je geen HP, maar een shield en een buffer. Is je shield leeg, gaat je buffer eraan. Is je buffer leeg, ben je dood. simpel.

-edit-
zie hier trouwens ook de puntjes waarom ik nog niet met m'n bot ben begonnen, het is nu pas duidelijk dat alles met vectoren gaat, dat zet je niet zomaar ff in een header om!

[ Voor 12% gewijzigd door wacco op 07-12-2002 19:40 ]

[Soultaker]

wacco schreef op 07 December 2002 @ 19:39:
Namelijk:
d'r zijn geen x en y coordinaten, jij bent dus gewoon het midden, en alles wat je scan terugspuugt zijn afstanden tot jou, met een richting waar je naar moet kijken. Je moet hier dus niet met een veldarray gaan werken, maar met vectoren.

Je kunt natuurlijk net zo goed relatieve carthesische coordinaten als relatieve poolcoordinaten doorgeven. Hoe je verder intern verder werkt, mag je zelf weten. Als je daar een veldarray voor wilt gebruiken, zou ik niet weten waarom dat niet zou mogen, al verlies je dan een stukje precisie.

[Verwijderd]

"R hanky panky v2"

Spaties in de namen wordt een beetje vervelend als parameters ook met spaties zijn gescheiden.

Er moet dan weer extra code worden geschreven om dit soort uitzonderingn af te handelen.

Kunnen we niet een ander scheidingsteken ascii waarde 1 ofzo, die kom je waarschijnlijk toch niet tegen in je parameters.

[Verwijderd]

Verwijderd schreef op 08 december 2002 @ 00:16:
Spaties in de namen wordt een beetje vervelend als parameters ook met spaties zijn gescheiden.

Er moet dan weer extra code worden geschreven om dit soort uitzonderingn af te handelen.

Je moet iig. t/m een '\n' karakter van de socket lezen om zeker te weten dat je een compleet bericht ontvangen hebt. Verder onderscheid je berichten op het eerste karakter, dus in de code die dat doet kun je eenvoudig inbouwen dat hij de volgende whitespace overspringt en dan alles tot aan het einde van de regel als naam ziet. (Ik gebruikte niet voor niets dat voorbeeld.)

Ik paste ook maar de defs.h header, daarin staan alle spelconstanten zoals ze nu zijn. Dit zijn dus geen definitieve waardes, ik post dit als indicatie, meer niet.

C++:

#ifndef GG_DEFS_H
#define GG_DEFS_H

extern "C++" {

const double    WERELD_FPS=                 1.0;
const double    WERELD_SCHILDAFNAME=        10.0 / WERELD_FPS;
const double    WERELD_MAXSNELHEID=         200.0 / WERELD_FPS;                             // 200 m/s
const double    WERELD_MINFORMAAT=          5.0 * WERELD_MAXSNELHEID * WERELD_FPS;          // 1 km^2
const double    WERELD_EXPLOSIEFACTOR=      1.0 / (10.0 * 10.0);                            // 50% op 10m
const int       WERELD_ALS_DADER=           -1;

const int       PROJECTIEL_TYPE=            0;
const double    PROJECTIEL_RADIUS=          0.05;                                           // 10 cm diameter
const double    PROJECTIEL_SNELHEID=        WERELD_MAXSNELHEID;
const double    PROJECTIEL_MAXSCHILD=       WERELD_MINFORMAAT / (PROJECTIEL_SNELHEID * WERELD_FPS)
                                            * (WERELD_FPS * WERELD_SCHILDAFNAME);
const double    PROJECTIEL_ENERGIETOENAME=  0.0;
const double    PROJECTIEL_MAXENERGIE=      PROJECTIEL_MAXSCHILD;

const int       TANK_TYPE=                  1;
const double    TANK_RADIUS=                3.0;                                            // 6 m diameter
const double    TANK_SNELHEID=              20.0 / WERELD_FPS;
const double    TANK_MAXSCHILD=             2.0 * (PROJECTIEL_MAXSCHILD + PROJECTIEL_MAXENERGIE)
                                            + WERELD_SCHILDAFNAME;
const double    TANK_ENERGIETOENAME=        PROJECTIEL_MAXENERGIE / WERELD_FPS + WERELD_SCHILDAFNAME;
const double    TANK_MAXENERGIE=            PROJECTIEL_MAXSCHILD + PROJECTIEL_MAXENERGIE
                                            + WERELD_SCHILDAFNAME;

const double    TANK_MAXAANDRIJVING=        TANK_ENERGIETOENAME;
const double    TANK_RADARBEREIK=           WERELD_MINFORMAAT / 2.0;
const double    TANK_MAXRADAR=              TANK_ENERGIETOENAME;
const double    TANK_STARTENERGIE=          TANK_ENERGIETOENAME;
const double    TANK_STARTSCHILD=           2.0 * WERELD_SCHILDAFNAME;

// XXX
const double    WERELD_SNELHEIDSCONVERSIE=  TANK_SNELHEID / std::sqrt(TANK_MAXAANDRIJVING);
const double    WERELD_RADARCONVERSIE2=     (TANK_RADARBEREIK * TANK_RADARBEREIK) / TANK_MAXRADAR;
const double    WERELD_RADARCONVERSIE=      std::sqrt(WERELD_RADARCONVERSIE2);

/* Openbare formules:
 * explosie_schade= explosie_energie / (afstand_tot_explosie^2 * WERELD_EXPLOSIEFACTOR + 1)
 * bots_schade= Minimum(schild_a, schild_b)
 * snelheid= WERELD_SNELHEIDSCONVERSIE * Wortel(energie)
 * radarradius= WERELD_RADARCONVERSIE * Wortel(energie)
 */

} /* extern "C++" */

#endif /* GG_DEFS_H */

[Soultaker]

offtopic:
He bah, Nederlandse coding styles zijn echt ontzettend ranzig. Daar kom je nog wel achter.

[Verwijderd]

offtopic:
Ik code normaal altijd in het engels, maar speciaal voor GoT heb ik het deze keer in het nederlands gehouden. Dat voorkomt dubbelzinnigheden, hoop ik. (Veel nederlanders hebben problemen met bv. speed en velocity.)

[Gerco]

offtopic:
Dan moeten die nederlanders maar engels leren, als je goed genoeg kan proggen om hier een bot voor te maken, kun je ook engels leren.

[ Voor 56% gewijzigd door Gerco op 08-12-2002 12:37 ]

[Mithrandir]

omg, wat een allemachtig lang topic is dit...

Ik heb het grootste deel gelezen, maar vraag me nu af hoe het is met de server en hoe ver de 'javascript-codeCompiler-ofzo' is.

Ik wil trouwens even zeggen dat ik het een gigantisch leuk idee vindt, en dat ik zeker mee ga doen als de 'bot-ontwikkelomgeving' klaar is. Ik vind de variabelen op deze manier prima. Meer hoef je niet te weten.

[Soultaker]

Zoals Mithrandir al opmerkt, wordt de thread niet echt overzichtelijk. Voelt iemand zich misschien geroepen een zo kort mogelijke samenvatting te maken en die op een webpage ergens te zetten? Het is misschien praktisch om alle feitelijke informatie op één plek te hebben staan (omschrijving, werking, protocol, constante waarden, regels). Ik moet namelijk toegeven dat ik zelf door de bomen ook het bos niet meer zie.

[.oisyn]

Ik stelde al eerder voor (op IRC geloof ik) om gewoon een nieuw topic te openen met alleen de feiten en de voortgang... de discussies kunnen dan in deze plaats blijven vinden. Dan houden we iig een overzichtelijk topic, en ik kan dan in dat topic wel een oogje in het zeil houden en offtopic reacties trashen...

.edit:

MisterData schreef op 08 december 2002 @ 21:19:
Kun je mijn onnodige reacties hierboven en deze reactie dan even trashen?

mja, maar erg veel nut heeft dat natuurlijk niet, het blijft onoverzichtelijk

[ Voor 32% gewijzigd door .oisyn op 08-12-2002 21:22 ]

[cobratbq]

Goede samenvatting.
Constanten zien er goed uit.
en idd
coden in het Engels is veel interessanter!

[DaCoTa]

Leven we allemaal nog of is de discussie tegenwoordig ergens anders? En is iedereen hard weggerend en heeft mij alleen laten staan? <snif>

Even serieus: hoe staat alles ervoor? De geposte dingen van mietje zien er imposant uit en, met de tijd inmiddels verstreken, is er al zicht op de eerste testversie?

[cobratbq]

ik ben nog niet weggelopen hoor !

[MisterData]

Het topic is inderdaad wat weggezakt ja Ik ben er ook niet echt actief meer mee bezig geweest helaas. Is er al enig uitsluitsel over wanneer we ongeveer gaan beginnen met de 'contest' (want dat was het idee?)

Misschien is het leuk om een T.net abbo'tje weg te geven als prijs

[Verwijderd]

ik ben er ook niet meer echt mee bezig geweest want ik zit midden in de examens

tot dinsdag heb ik men gewone examens
en na de kerstvakantie van CCNA

mjah, de komende weken zal ik nog wel wat tijd vinden

[Verwijderd]

wegens slaaptekort heb ik de afgelopen twee weken niet echt veel gedaan... Ben nog steeds bezig met m'n socket-framework. Maar goed, mietje is ook nog niet klaar zie ik
Gelukkig heb ik volgende week vrij =)

[wacco]

* wacco is al een anderhalve week strontziek en daardoor stond z'n kop niet echt naar programmeren...
maar als het er van komt ben ik natuurlijk nog steeds van de partij

[cobratbq]

Nog 1 daggie school en dan ben ik vrij... (2 weeks )
Hopelijk komt de hele boel dan weer op gang.
Naast een eigen programmatje hou ik nog steeds de boel in de gaten hier.
Ik zie het nog wel wanneer er weer beweging in de zaak komt.

[DaCoTa]

Toten-hosen?

[Verwijderd]

[Schop]


Hoe staat 't ervoor?

[cobratbq]

ik ben ook nog wakker!

[wacco]

Hoe staat 't ervoor?

me still ziek

[wacco]

/me SCHOP *

[Mithrandir]

wacco schreef op 24 January 2003 @ 15:56:
/me SCHOP *

Ben je niet meer ziek? (verkapt schopje)

[.oisyn]

Dit gaat nergens meer over. We kunnen 'm wel blijven schoppen, maar dat schiet niet echt op (en het is al helemaal geen slowchat topic).

Ik doe er een slot op. Als iemand nou echt iets zinnigs of iets nieuws te vertellen heeft kan diegene mij mailen op [e-mail], en dan gooi ik m weer open