MINES version 3.0 Now With NAPALM!!!
Author |
Message |
domtech
Joined: Tue Apr 28, 2009 4:48 pm Posts: 29
|
MINES version 3.0 Now With NAPALM!!!
MINES The best way to protect your brain Have you ever needed to send your gaurd to do something but you havn't wanted to leave your bunker undefended? well here is the solution: (NOTE: it is normaly faster) Just place our custom Mines all around your bunker to protect your Brain Here Are the different types of Mines that we currentaly offer: Mine: A Mine that will explode when an enemy comes too close. Boulder Mine: A Mine that releases a huge pile of boulders when an enemy comes too close. Zombie Mine: A Mine that releases an explosion of toxic zombie slime when an enemy comes too close. NEW!Napalm Mine: A Mine that releases an explosion of Napalm when an enemy comes too close. Our Mines also include 7 custom built bunker modules for you to place your Mines in. Credits:Areku - For inspiring me to add the Zombie Mine and for providing me with the Lua file. Me - Sprites, ini files, and stuff. New in this version:• Added the Napalm Mine • Tweaked the the Mine explosions. • Changed the Boulder Mine to one big boulder. (dosent work right yet) To do:• Add a way to reset the Mines. • Make the Mine explosions look better. • Add more bunker modules. • Add more Mines. • Tweak how the mines detect enemies to improve efficiency. Here's the download:READ THE NOTES FILEAttachment:
File comment: Version 3.0
Mines3.0.rar [509.55 KiB]
Downloaded 984 times
Old Downloads:2.0:Attachment:
File comment: READ THE NOTES FILE
Mine.rte.rar [451.03 KiB]
Downloaded 454 times
Please comment and offer sugestions
Last edited by domtech on Fri Aug 14, 2009 7:59 pm, edited 4 times in total.
|
Wed Aug 12, 2009 3:20 am |
|
|
ToPhAt
Joined: Sun Jul 26, 2009 5:27 am Posts: 7
|
Re: MINES version 2.0 is here!!!
sounds good, dl right now yay first post!!!
|
Wed Aug 12, 2009 3:25 am |
|
|
duo9ace
Joined: Sat Aug 23, 2008 2:51 pm Posts: 209
|
Re: MINES version 2.0 is here!!!
Oh wow this is really nice.
I'm not very good with modding so I'll just say that maybe the delay time for the mines could be shortened?
|
Wed Aug 12, 2009 3:28 am |
|
|
domtech
Joined: Tue Apr 28, 2009 4:48 pm Posts: 29
|
Re: MINES version 2.0 is here!!!
its normaly faster though without Lua this is about as fast as its going to get
|
Wed Aug 12, 2009 3:36 am |
|
|
Sparx
Joined: Mon May 18, 2009 2:54 am Posts: 34
|
Re: MINES version 2.0 is here!!!
Boulder Mine is sorta useless. The Regular Mine is pretty useful, though sorta laggy. The Zombie Mine... WAY DIFFERENT STORY. I put a Coalition Soldier in between two mines, and detonated them. Well, lets just say it was 5x slower than holding PrintScreen for GIFs. And as a result it clogged up the next 3 segments of hall with Zombie guts.
|
Wed Aug 12, 2009 5:31 am |
|
|
Aveneski
Joined: Tue Jul 21, 2009 11:25 am Posts: 10 Location: Seattle, WA
|
Re: MINES version 2.0 is here!!!
Pretty good.
Boulder mine is... honestly, If you made this mine pretty much a Metal box that drops on a person, It'd work a lot better, like a hanging trap. Zombie mine, interesting, but I think A fire mine would be better, but not as FPS-rape-ish as the C4, and more effective. Like napalm. That'd be great.
|
Thu Aug 13, 2009 5:50 am |
|
|
Geti
Joined: Sun Jul 13, 2008 9:57 am Posts: 4886 Location: some compy
|
Re: MINES version 2.0 is here!!!
dude, just use lua castmorays.
|
Thu Aug 13, 2009 5:56 am |
|
|
Grif
REAL AMERICAN HERO
Joined: Sat Jan 27, 2007 10:25 pm Posts: 5655
|
Re: MINES version 2.0 is here!!!
Seriously geti? MORays? For friggin' MINES?
Hardly seems necessary.
|
Thu Aug 13, 2009 6:15 am |
|
|
Foa
Data Realms Elite
Joined: Wed Sep 05, 2007 4:14 am Posts: 3966 Location: Canadida
|
Re: MINES version 2.0 is here!!!
Grif wrote: Seriously geti? MORays? For friggin' MINES?
Hardly seems necessary. Why yes, we use lasers sights to identify threats with laser beams. I enjoy the Zombie mines, gassing is fun.
|
Thu Aug 13, 2009 6:25 am |
|
|
Kyred
Joined: Sun May 31, 2009 1:04 am Posts: 308
|
Re: MINES version 2.0 is here!!!
What Grif means is that raycasts eat up way to much processing power for something like this. Here, you could use a simple WithinBox(), which only takes one process per function call. An MORay can take anywhere between 50 to 5000+ processes per function call, depending on the length and accuracy setting of the ray.
Boxes are always more efficient for proximity checking than MORays, hands down.
|
Thu Aug 13, 2009 6:29 am |
|
|
Geti
Joined: Sun Jul 13, 2008 9:57 am Posts: 4886 Location: some compy
|
Re: MINES version 2.0 is here!!!
Kyred wrote: Boxes are always more efficient for proximity checking than MORays, hands down. rays are a lot faster than pos checks (casting a 100px ray every frame from 20 actors eyepos hurts my fps not at all.), even when using deltapos.magnitude, due to the table iteration of pos checks. the current box checking process also iterates through the actor table before it compares positions with the box for "within-ness". thats a lot more than one process. it probably would be better to use boxes though, considering the application. i simply meant to infer that lua would be a much better way of checking proximity, that would reduce lag and produce more reliable results.
|
Thu Aug 13, 2009 7:03 am |
|
|
Grif
REAL AMERICAN HERO
Joined: Sat Jan 27, 2007 10:25 pm Posts: 5655
|
Re: MINES version 2.0 is here!!!
Boxes on a 500,1000, even 50 ms timers to start a for loop tend to work much faster for me.
|
Thu Aug 13, 2009 7:16 am |
|
|
Geti
Joined: Sun Jul 13, 2008 9:57 am Posts: 4886 Location: some compy
|
Re: MINES version 2.0 is here!!!
fair enough, though you can always put timers on casting rays aswell. regardless of what method you choose (seriously, go box ) youre going to get a better result from lua rather than any .ini hacks.
|
Thu Aug 13, 2009 7:46 am |
|
|
Kyred
Joined: Sun May 31, 2009 1:04 am Posts: 308
|
Re: MINES version 2.0 is here!!!
Geti wrote: Kyred wrote: Boxes are always more efficient for proximity checking than MORays, hands down. rays are a lot faster than pos checks (casting a 100px ray every frame from 20 actors eyepos hurts my fps not at all.) The best way I can explain this is through code. I don't know entirely how a ray cast works, but I can sort of guess how they are coded based on what they do: Keep in mind, this code looks nothing like the raycast function. I'm just doing a mock up of it. Code: function SceneMan:CastMORay(StartPos,DirectionVec,IgnoreID,IgnoreMatID,Acc) local CurrentPos = StartPos; while CurrentPos.Magnitude <= DirectionVec.Magnitude do (1 check) If: some obstacle or pixel is found at this position, Then: (1 check) If: the ID of the material matchs IgnoreMatID or matchs the ID of air material, Then: (2 checks) CurrentPos = CurrentPos + Vector(DirectionVec.X,DirectionVec.Y):SetMagnitude(Acc); (1 process) else If: the pixel at the CurrentPos is that of a MovableObject, Then: (1 check) If: the MovableObject's ID does not match IgnoreID, Then: (1 check) return MovableObject's ID; end end end else CurrentPos = CurrentPos + Vector(DirectionVec.X,DirectionVec.Y):SetMagnitude(Acc); (1 process) end end Looking at this, for every pixel along the ray cast (assuming highest accuracy), you could be running anywhere between 2 - 6 processes/checks. Multiply that by 100 for a 100px ray, and you got a total somewhere between 200 to 600 processes/checks. Again, this is just a rough estimate. A box compares positions. If the actor is within the box, return true. That's one check. Multiply that by 20 for 20 actors, and you get a total of 20 checks.
|
Thu Aug 13, 2009 8:53 pm |
|
|
Geti
Joined: Sun Jul 13, 2008 9:57 am Posts: 4886 Location: some compy
|
Re: MINES version 2.0 is here!!!
well, if everything worked like it did in lua, boxes would look something like this Code: function Box:WithinBox(pos) if pos.X >= Box.topleft.X and pos.Y >= Box.topleft.Y and pos.X <= Box.bottomright.X and pos.Y <= Box.bottomright.Y then return true; else return false; end end thats 4 checks and then a return, not one. and noone uses highest accuracy rays, we dont ever work with 1px MOs (we have mopixels for those) so why would we? but of course, the C++ code works differently anyway, so why are we arguing? yes, boxes are better for this, ive agreed. when i said pos checks i meant Code: (self.Pos - thing.Pos).Magnitude or even the way involving math.sqrt. both of those are slower than rays, in my experience. especially the second one <_< now, lets move on.
|
Thu Aug 13, 2009 9:39 pm |
|
|
|
Who is online |
Users browsing this forum: No registered users |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|