Bobwithkeycard wrote:quite fascinating. Based on the one map editor for Damage Inc I always assumed it was just an object as well, but it seems this either just concerned the placement on the map or it was a workaround since damage Inc's map editor was just an alteration of a M2 map editor's source code.
There were lua scripters who tried to integrate swinging doors into aleph one by exchanging static scenery objects with rotating 3D objects. Of course there was always the problem of collision detection in these efforts.
I'm curous as what you'll be able to tell about sliding doors.
Johnman wrote:Damage was one of my favourite games when I was a child. I haven't played since, but I remember the squad management being the ultimate form of AI in computer games... I won't play it again since I don't want to spoil those good memories.
Also it contained a wolf howl sample that I have heard *everywhere* since. It's featured at the beginning of Kavinsky & Lovefoxxx's "Nightcall" from the Drive OST. I suppose it's one of those samples.
Bobwithkeycard wrote:hey asylum, in case you are interested: a while back (actually it's been four years now) I put together a mml file just so see to what extent A1 was able to load up Damage Inc. files. I got a couple of levels working, albeit with all the non A1-feautures missing. I lost interest in it once I learned that Damage Inc was using 128 or 512 texture slots in the shapes file instead of Marathon Infinity's 32 and the futility of the effort dawned on me.
Since there was no way of exporting damage Inc's physics for me, I just put in the standard physics for pistol, shotgung, ma-75B and gave the monsters the Trooper's behaviour without able to fire grenades.
It might be of some limited use as a start. Here's a screenshot:
Link to picture
Drop me a line if you want the files
Asylum wrote:Might actually be a better idea than making Aleph One load Damages shapes file.
Asylum wrote: I'm trying to familiarize myself with Aleph One's codebase. I added some new features to it. It used to be all monster attributes like enemies, allies, gravity, speed, intelligence were shared across monster types. You couldn't have, say, two troopers with different speeds. The modifications I made changed that so that the original monster definition was just used to instantiate a separate definition for each monster on the map. I've tested it and it works.
Bobwithkeycard wrote:Asylum wrote:Might actually be a better idea than making Aleph One load Damages shapes file.
Acutally my aim was not to change the original Damage Inc shapes file and have A1 load it up with a help of a custom mml file so A1 would know where to find the basic stuff like collections for wall textures, player torso 'n legs, enemies and everything without A1 quitting to the desktop.
Maybe I've misunderstood your reply, so I apologize for writing things twice (I blame my English): the whole problem is that the damage Inc file uses alot more collections than A1's 32. So since any A1 custom physics and mml file can only point to collections below or equal 32 a Total Conversion of Damage Inc to A1 only gets you so far as perhaps Damage Inc's level 4 until items, enemies and other stuff will appear that is found in damage Inc shapes file only beyond collection 32.
Shape Fusion, the 3rd party shapes editor is still able to load it up, though. From the end user's perspective it seems that they didn't change the M2-shapes format very much apart from maximizing the size of allowed connections (A1: 32, Damage Inc maybe 512, Prime Target 1024).
I only offered the files to you because it's sort of grunt work to tell A1 in a mml file where to find correct door 'n switch sounds, wall texture collections and all sorts of other stuff. Doesn't sound like much, but it's still quite a list of things at the end of the day. Hours not very well spentAsylum wrote: I'm trying to familiarize myself with Aleph One's codebase. I added some new features to it. It used to be all monster attributes like enemies, allies, gravity, speed, intelligence were shared across monster types. You couldn't have, say, two troopers with different speeds. The modifications I made changed that so that the original monster definition was just used to instantiate a separate definition for each monster on the map. I've tested it and it works.
sounds interesting, completely individual monsters. Now we could have trooper races, may the most intelligent win
Users browsing this forum: No registered users