lol, nah you did not offend me in the least. I found the posting humorous which is why I posted it the way I did. I was just simply jokingly adding, "hey not everyone is asleep", for the fun of it.
I took it in the way you just described from the beginning. Did not mean for it to sound like anything else other than a friendly post. sorry for the confusion!
And oops you are correct it was fine, I misread what the buttons said. I did not notice that it detected Titanium as both Battlepack and Titanium with two seperate buttons.
I looked and glanced at it and assumed that the next one down was another drive letter. I had 2 iso's and 95 GBL in my drive which is what caused the confusion.
Sorry about the trouble.
James 3:5-10: My Reminder
And the tongue is a fire, a world of iniquity: so is the tongue among our members, that it defileth the whole body. Out of the same mouth proceedeth blessing and cursing. My brethren, these things ought not so to be.
Skyfaller wrote:
Developing an AI ... well, first I'd like to get the mechs walking in the original levels. In order to make modding the levels easier, I plan to export level descriptions as XML files that reference geometry in the PRJ (.WTB files). Once the mechs are walking and shooting, network and/or AI will have to be developed. While it seems easy to program a simple AI (come to a certain fighting distance with the opponent, then shoot until the mech runs hot or there is no more ammo), creating an AI that is interesting to fight is much more of a challenge.
The other worry I have is networking. I'll have to brush up my network programming skills. Also, I plan that destroyed buildings should sink into a pile of rubble rather than flying around wildly as before.
Your assessment I believe to be correct.
You must get the basic movement code functional before you go any farther.. developing an ai without that is possible, but it would seem to me to be a frustrating way to go about it since you would not be able to see it in action visually.
The XML files for each level make sense as you already are exporting most things in that form anyway. It is better than writing a new scripting language for it that is for certain. Why double the work when you can use something premade and easily parseable?
As for the networking side, I am hopeless on this side so I cannot make any suggestions.
James 3:5-10: My Reminder
And the tongue is a fire, a world of iniquity: so is the tongue among our members, that it defileth the whole body. Out of the same mouth proceedeth blessing and cursing. My brethren, these things ought not so to be.
I discussed networking with Myg a while ago. He proposed to use TCP/IP, which blocks function calls until a message was confirmed to be received, effectively doubling the time required to send the message. UDP does not do this, it returns immediately. I do not care about lost packages, instead I might want to send a new package with updated information. The alternative is to use a different thread for communication, but I wanted to avoid multithreading for MechVM.
Skyfaller wrote:
Developing an AI ... well, first I'd like to get the mechs walking in the original levels. In order to make modding the levels easier, I plan to export level descriptions as XML files that reference geometry in the PRJ (.WTB files). Once the mechs are walking and shooting, network and/or AI will have to be developed. While it seems easy to program a simple AI (come to a certain fighting distance with the opponent, then shoot until the mech runs hot or there is no more ammo), creating an AI that is interesting to fight is much more of a challenge.
The other worry I have is networking. I'll have to brush up my network programming skills. Also, I plan that destroyed buildings should sink into a pile of rubble rather than flying around wildly as before.
Opinions...?
I wasn't suggesting developing AI at this stage, just that if you were planning to replicate the original sim AI, I had decoded the format they use to store the AI tables in the project file and you might find it useful. In hindsight it's probably more useful for modding (ie: tweak the existing AI). I agree with your development plan (it's the same order I plan to follow when I finally start coding my sim ).
Yes, thank you, the AI files you posted will certainly be helpful in recreating the game as closely as possibly.
Please notify me if you find out more. Col. Kell was also interested in the AI tables, he may have questions.
This would have been important enough to discuss in a new thread.
AI tables
[ Notes ]
From the MERCAI.HTM file:
* <state (optional)> <msg> <obj-ref> <msg-param> <trans-action> <new-state> <new-state-arg>
* state/new-state = [ Target, Attack, Follow, Patrol, Godirect, Flee, Idle, Rest, Shutdown, Dead ]
* msg = [ M_PROX, M_DIST, M_REACH, M_DESTROY, M_TGTABLE, M_TRUE, M_FALSE ]
* obj-ref = [ agp_enemy, agp_friendly, agp_user, agp_myleader, agp_me, agp_home, agp_rbanchor, @, *, <explicit-ref> ]
* explicit-ref = Explicit reference to world object (gamepiece, gamething or navpoint) - not sure how these are assigned,
probably internally by the sim (not loaded from file)???
* msg-param = [ &n, &s, &t, &r, &l, <positive-number> ]
* trans-action = [ T_NULL, T_PUSH, T_POP, T_CLEAR_STACK, T_NOTIFY ]
* new-state-arg = [ @, %, *, agp_enemy, agp_friendly, agp_user, agp_myleader, agp_me, agp_home, agp_rbanchor ]
[ Format ]
0 - 1 : Number of state records in table
This is then followed by that number of state record headers:
0 - 1 : State
2 - 3 : Number of transition records for this state
After this come the transition records. The number of records is equal to the sum of all the "transition record count" fields
in the preceeding state record headers, and their order matches that of the state record headers (ie: the first "transition
record count" records belong to the first state record, the next "transition record count" belong to the second, etc):
0 - 1 : Message
2 - 3 : Object reference
4 - 5 : Message parameter
6 : Transition action
7 - 8 : New state
9 - 10 : New state argument
11 : (always zero)
State & new state values are:
0x0000 - idle
0x0002 - target
0x0003 - attack
0x0004 - flee
0x0005 - follow
0x0006 - recon (FIXME: Not documented in MERCAI.HTM?! Although it does mention additional unimplemented states...)
0x0007 - patrol
0x0008 - godirect
0x000a - rest
0x000b - shutdown
0xffff - nothing (FIXME: Not documented in MERCAI.HTM?! Although it does mention additional unimplemented states...)
0x???? - dead
Object reference values are:
0x0000 - NULL (FIXME: ???)
0x002a - '*' (NB: Value is actual ASCII code)
0x0040 - '@' (NB: Value is actual ASCII code)
0x2100 - agp_home
0x2101 - agp_rbanchor
0x2201 - agp_myleader
0x4201 - agp_enemy
0x???? - agp_friendly
0x???? - agp_user
0x???? - agp_me
0x???? - <explicit-ref>
Message parameter values are:
0x0000 - &n (FIXME: Only used with M_REACH & M_DIST I think - otherwise I believe this is just zero)
0xfffc - &r
0xfffe - &t
0xffff - &s
0x???? - &l
OR any positive integer value.
Well, AI wasn't exactly my top priority, I haven't been doing anything lately in the modding field, I've been too caught up with school and learning programming. Would be nice to know what the tables all mean tho.
I was just simply jokingly adding, "hey not everyone is asleep", for the fun of it.
