Jump to content

Home

bsah

Members
  • Posts

    16
  • Joined

  • Last visited

Personal Information

  • Favorite LucasArts Game
    jk3
  • Resolution
    1024x768

bsah's Achievements

Newbie

Newbie (1/14)

10

Reputation

  1. Hmm, there should be some kind of a master server that would collect the AI files (or, maybe let's call them "souls") from anyone wanting to submit them, and give them away to anyone that would request them. Let's say there's a master server M, and clients A, B and C which are the AI behind the bots, connecting to game server G. \A played for a while with a few "real" players and found that it was good enough to not get killed all the time, so it sent a copy of its soul to M. Now that B and C are also connecting to G, they can request a new, random soul from M. M sent them A's soul. Now that all three (A,B,C) are playing, the evolution of their souls would go in different ways. Each of them would submit their result to M after a while. Now, M would need to check if the clients aren't sending "soul spam" somehow... Maybe each time a client receives a soul, when it gives back an evolved one, it would also return some info about the rating of the one it received before? That way, M would see which souls seem to be the best, and give away only the best ones. And master servers could exchange souls as well. Decentralized evolution As of the format of the file, converting between a tree and a lisp-like thing with parentheses should be very easy, and also Lisp thing would be very human readable. The protocol for exchanging the files... It should be easy to come up with one: you request a soul, you get a soul and an unique identifier, so you can later vote whether it was good or not. Or, you connect, send an identifier you got previously, your rating, and the results of your evolution. Of course, in this scheme, A, B, C, G and maybe even M could be one program as well. I just feel like... It's another great idea that will get buried as soon as I get another one. = very soon.
  2. I just added g_crash.o to the list of .o's in the Makefile and... damn, it works now Great thanks btw, someone who's in charge of Linux stuff should update the CVS now.
  3. I keep everything somewhere on /mnt (lost the track of directory hierarchy under /mnt years ago), and GameData/ is symlinked to ~/jk3/: $ ls ~/jk3/ [cut!] base linuxjampded mymod (aka ojp basic) mybettermod (aka ojp enhanced) [cut!] $ ls -l mymod/ mybettermod/ mybettermod/: total 1069 -rw-r--r-- 1 harry users 733184 2008-03-18 18:34 cgamex86.dll -rw-r--r-- 1 harry users 10361 2008-03-18 18:38 jampconfig.cfg lrwxrwxrwx 1 harry users 19 2008-03-18 18:14 jampgamei386.so -> src/jampgamei386.so lrwxrwxrwx 1 harry users 54 2008-03-18 18:15 src -> /home/harry/Hack/mybettermod-src/Enhanced/source/game/ -rw-r--r-- 1 harry users 348160 2008-03-18 18:34 uix86.dll mymod/: total 0 lrwxrwxrwx 1 harry users 19 2008-03-18 16:13 jampgamei386.so -> src/jampgamei386.so lrwxrwxrwx 1 harry users 38 2008-03-18 15:52 src -> /home/harry/Hack/mymod-src/source/game Both Basic and Enhanced build cleanly, but jampded doesn't like Basic jampgamei386.so: Loading dll file jampgame. Sys_LoadDll(/mnt/junk/jk3/GameData/mymod/jampgamei386.so)... Sys_LoadDll(/mnt/junk/jk3/GameData/mymod/jampgamei386.so) failed: "/mnt/junk/jk3/GameData/mymod/jampgamei386.so: undefined symbol: DisableStackTrace" Sys_LoadDll(./linuxjampded/mymod/jampgamei386.so) failed: "./linuxjampded/mymod/jampgamei386.so: cannot open shared object file: Not a directory" Resolving masterjk3.ravensoft.com masterjk3.ravensoft.com resolved to 63.146.124.53:29060 Sending heartbeat to masterjk3.ravensoft.com Sending heartbeat to masterjk3.ravensoft.com Sys_Error: Sys_LoadDll(jampgame) failed dlopen() completely! But I'm just repeating myself now. $ file $( chase mymod/jampgamei386.so ) /home/harry/Hack/mymod-src/source/game/jampgamei386.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped $ file $( chase mybettermod/jampgamei386.so ) /home/harry/Hack/mybettermod-src/Enhanced/source/game/jampgamei386.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped I have no clue what's wrong with this... I doubt that the fault is on the side of the filesystem or directory layout... Although when I rm'd the symlink to the .so the server crashed in a somewhat similar way. Hm, the command for getting an older revision seems to be "svn co -r [number] url". I'll try that later. BTW has anyone else had problems with building & running Basic on Linux? Some people actually /do/ build in on Linux from time to time, right?
  4. I have no clue how file I/O exactly looks like on Windows (I started programming for real just at the time I decided to finally get rid of it), but I suppose that it shouldn't be too hard to make some #ifdefs and provide wrappers around Unix syscalls/WinAPI calls? Hmm... Maybe I'd be interested in that, but you know... I'm very lazy, I often start projects, hack them a little and never go back to them, I just never finish anyth
  5. Maybe when I'll have the Linux version of Basic working, I'll really start diggin' into the code and see if I can do something interesting there... I just can't decide which language would be the best for coding up such a genetic library, I've tried doing some experiments in Python recently but I ended up rewriting everything in Java, because Python lacks stronger typing and doesn't care if a function accidentally won't return any value =/ at least until runtime. And then rewriting the Java version in Python again, because Java just... Sucks. (I'm reading "Practical Common Lisp" (http://gigamonkeys.com/book/) ATM and I have a strange feeling that the final version will be in Lisp.)
  6. Read my first post - this isn't an issue, when I removed that cast everything compiled OK but the jampded thing is refusing to load the .so and just crashes. Enhanced builds and works perfectly, but I'd like to play around with basic, and possibly make my own mod on top of it. BTW I made a diff between basic and enhanced source tree, and as I've looked in places like g_main.c or g_local.h, nothing suspicious found have I. As the windows build seems to work, the breakage might be very subtle =/ Hm. Maybe an older revision would work, but I'm a total SVN newb and I dunno how to check it out halp?
  7. @razorace, How about using lisp-like tree structures, and mixing & mutating & crossing branches of code instead of DNA-like strings? It seems far simplier and more effective to me, but hadn't really digged too much into this. BTW, servers could exchange AI files the same way nethack users used to exchange "bones". And I don't mind running a server full of bots (half "classic", half "learning") in the background for 24/7, so "thousands of generations" might not be that long again (given the rate at which bots kill each other).
  8. HM. How about using evolutionary algorithms in bots' and npcs' AI?
  9. Of course, the name is suggesting that.
  10. Hm The same little error with casting lvalue (does the ms' cc just look the other way? o,O)... And btw what's the point of casting a float to a float?... ...and the Enhanced build works OK <hurray!> so someone must've broken Basic.
  11. HM. Just put all bots in team blue or red and players on free? Should work... Zombie npcs... AFAIK doable, just make npcs with very high perception etc, and with melee as the only weapon... Hm. But last time I checked (it was long ago though) NPCs with melee selected will only stand in place and beat the air with fists. Hmm... Change the AI so they would walk slowly (or not slowly) towards the player? Or maybe do other moves from time to time.
  12. So, well. $ cd ~/Hack $ svn co http://opensvn.csie.org/ojp/ ojp/ [ > 200 mb downloaded... ] $ cp -r ojp/Basic/ mymod-src/ $ cd $_/source/game/ $ make [ *build* *build* *fail* ] uh oh... aotctc_holocron.c: In function ‘AOTCTC_Holocron_Loadpositions’: aotctc_holocron.c:170: error: lvalue required as left operand of assignment Hm. $ head -170 aotctc_holocron.c |tail -1 (float)stats[statnum] = (float)atof(t); wtf? oh well s/\(float\)stats/stats/ $ make Yeah! Got the jampgamei386.so. $ cd ~/jk3 $ mkdir mymod $ cd $_ $ ln -s ~/Hack/mymod-src/source/game src $ ln -s src/jampgamei386.so ./ $ cd .. $ ./linuxjampded +set dedicated 2 +set net_port 21000 +set fs_game mymod +map mp/ffa3 JAmp: v1.0.1.1 linux-i386 Nov 10 2003 [blah blah blah] Loading dll file jampgame. Sys_LoadDll(/mnt/junk/jk3/GameData/mymod/jampgamei386.so)... Sys_LoadDll(/mnt/junk/jk3/GameData/mymod/jampgamei386.so) failed: "/mnt/junk/jk3/GameData/mymod/jampgamei386.so: cannot open shared object file: No such file or directory" Sys_LoadDll(./linuxjampded/mymod/jampgamei386.so) failed: "./linuxjampded/mymod/jampgamei386.so: cannot open shared object file: Not a directory" Resolving masterjk3.ravensoft.com masterjk3.ravensoft.com resolved to 63.146.124.53:29060 Sending heartbeat to masterjk3.ravensoft.com Sending heartbeat to masterjk3.ravensoft.com Sys_Error: Sys_LoadDll(jampgame) failed dlopen() completely! $ echo $? 1 Uh oh. Halp? Stock basejka .so works O.K. SVN revision number is 599. I'm using Debian sid, apt-get updated & upgraded as of today. I get the same results with GCC 4.2.3 and 3.4.6. Also: $ file `chase {base,mymod}/jampgamei386.so` /mnt/junk/jk3/GameData/Base/jampgamei386.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped /home/harry/Hack/mymod-src/source/game/jampgamei386.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped Stripping it doesn't help $ ldd `chase {base,mymod}/jampgamei386.so` /mnt/junk/jk3/GameData/Base/jampgamei386.so: linux-gate.so.1 => (0xffffe000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7593000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb756d000) libcxa.so.1 => /usr/lib/libcxa.so.1 (0xb7564000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7409000) /lib/ld-linux.so.2 (0x80000000) /home/harry/Hack/mymod-src/source/game/jampgamei386.so: linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7443000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb72e8000) /lib/ld-linux.so.2 (0x80000000) That yields something interesting. I've got libcxa1 in place, but GCC is refusing to link against it: $ gcc -shared -o jampgamei386.so [a-sh*tload-of-.o's] -lm -ldl -lcxa /usr/bin/ld: cannot find -lcxa collect2: ld returned 1 exit status WTF?
×
×
  • Create New...