This topic contains 50 replies, has 0 voices, and was last updated by  Deathstryker 13 years, 1 month ago.

  • Author
    Posts
  • #11401

    Anonymous
    Participant

    I just found this and DLed last night! My buddy and I played the original
    2D SE to death. What I’ve seen of this 3D version is very cool.

    I had a couple of ideas about weapons (same idea actually):

    Rocket Jump: A rocket which launches, dragging your tank along with it.
    After a short while, you are released (randomly?) to float back down to
    the surface (you did remember to pack a parachute, right? 😈 ).
    Would fulfill basically the same role as fuel does, with a longer range and
    more flexibility, but also with less control (to balance it).

    Lander: Launches as a seemingly normal projectile, but once descent
    starts it will emerge as a crab-like lander, lock onto any tank within its
    descent cone, home in on it, land on it, and then blast back off with the
    tank dangling underneath, after which it works basically the same as the
    Rocket Jumper. Good for dragging little cowards out of their deep holes.

    Oh and the old 2D version laser was very unbalancing-and not very fun,
    not being a ballistic weapon (and that is without considering that batteries
    are not drained as advertised), so don’t bring it back…

    John DiFool

    #11402

    Bobirov
    Participant

    The new WeaponTranslate primitive got me thinking about another idea for a new primitive. What about adding a new WeaponRedirect or WeaponHeading primitive that looks something like this?

    	
    Redirect


    bmissile.bmp
    1
    10
    1
    45.0
    5.0

    ...

    Here and would be the angle, in degrees, to adjust the horizontal and vertical heading of the next projectile in the series.

    For example, if user fired a shot in the example above at 135 degrees horizontally and 40 degrees vertically, the next projectile in the weapon would actually travel along 180 degrees horizontally and 45 degrees vertically. This could be very useful and quite cool if used in conjunction with the new WeaponTranslate and WeaponVelocity primitives. It would make possible things like zig zag leaping weapons or X-shaped explosion patterns or even a functional version of the elusive “shotgun” type weapon. I don’t think it sounds like it would be too hard to implement, but I don’t really know :).

    What do you think?

    #11403

    Bobirov
    Participant

    There seem to be a few undesired side effects when using none in a WeaponExplosion. While it does have the desired effect of not altering the terrain in any way, unfortunately and do not function at all when it is called. I have made a COOL earthquake weapon using a series of WeaponDelays and non-deforming, earth shaking explosions. The problem is that intially I couldn’t get it to play a sound at all but I worked around that with a tiny downward deforming explosion in the first collision. However, I can find no workaround to disable or alter the default explosion animation in a non-deforming explosion because the tag seems to break like sound.

    However, one thing that is actually a nice unexpected side effect of none is the fact that the landscape texture is not altered in any way. Perhaps that behaviour could be extended to any WeaponExplosion via tag or control over explosion landscape textures. If nothing else leave this part broken for non deforming explosions because it is better than it being left on :).

    Also, I noticed when messing with the earthquake weapon that does not function at all of the WeaponExplosion is non-damaging (0.0). Since I had to have the initial explosion start shaking the screen I had to make it do a slight amount of damage. This lead to another observation.

    I then finally noticed that non damaging explosions do not create flying debris, which makes sense, but there is no way to turn off debris on an explosion that does damage. We now have the ability to turn off many things (, none option for sounds/textures, etc) I figure that a for WeaponExplosion, if not complete control over debris amounts, would be in line with the other new options. Again here, if not a new option then leave debris broken for non-deforming explosions at it works well this way and seems appropriate.

    I probably should post the earthquake weapon as it is right now as I think its probably the most original weapon I’ve come up with since I first discovered apexcollision with a funky bomb spread ;). If these few things would be fixed it would be, without a doubt, the coolest weapon I’ve come up with yet in my opinion. With the same fixes, gas type weapons like I mentioned previously in the topic would be quite doable as well, without needing another new Weapon primitive of their own.

    Summary of requests/ideas:
    1)
    – Fix and for explosions using none

    2)
    – Leave landscape texturing broken for non-deforming explosions
    OR
    – Fix it & provide a or something similar
    OR
    – Provide complete control over what texture is applied in any explosion (including a ‘none’ texture)

    3)
    – Leave debris creation broken for non-deforming explosions
    OR
    – Fix it but provide a tag or something similar
    OR
    – Provide control over the amount of debris created during an explosion

    I’m probably getting a bit whacky with all my requests and ideas but that is when you’re supposed to e-punch me in the face and tell me to shuddup already… πŸ˜‰

    #11404

    dracon23
    Participant

    Bobirov wrote:

    I’m probably getting a bit whacky with all my requests and ideas but that is when you’re supposed to e-punch me in the face and tell me to shuddup already…

    well i wouldnot necessarily say that but this could lead to a “extras” option in the game that would be available after a small monetary submition to the scorch team programmers to make up for their spending so much of their time putting all these requests into effect….

    but then again i am in no position to even suggest such a thing πŸ˜‰ .

    in my own opinion i thing that the Gavin and company have done such a good job above and beyond any of my expectations that i would be more than willing to part with a portion of my own meager budget if such a situation arose.

    this is the best freeware game that i have ever played and the most friendly. (even though it has its quirks πŸ˜€ )

    dracon23

    #11405

    Bobirov
    Participant

    First, I want to thank you for implementing the previous suggestions for non-deforming explosions. They are now quite useful and unique. I now use them for all cosmetic explosions and I have successfully managed to make my long dreamt of Gas weapon using delayed, non-deforming explosions and a new explosion texture complete with a hissing sound of my own crafting. It wouldn’t be possible without many of the changes that have been made and I can’t thank you enough. I will try to repay the hard work by puting all the new features to good use and doing my best to show off a little of what is possible in the next release. I think whenever version 38 is complete and released it is going to leave little doubt as to the best 3D artillery game in existance. Worms 3D??? Scorched3D eats worms for breakfast, fried in a little napalm with a side of sand hog, just before it goes out to toss a nuke in your face and smile.

    On to business…

    @bobirov wrote:

    Here and would be the angle, in degrees, to adjust the horizontal and vertical heading of the next projectile in the series.

    The more I think about this idea, I think that the vertical redirection should be an absolute angle, not relative to the current weapon’s heading. The horizontal adjustment, should however still be relative to the weapon’s heading tho. If the vertical adjustment were absolute, it would be far easier to control and more useful.

    I really think a Redirect primitive would be a GREAT extension to several of the other primitives, particularly the newest ones. Currently the only time you can get any use out of WeaponTranslate is right at the beginning of an accessory like it is with the new Blast Weapons. If you try to use it in a collision you can’t really get it to behave like you want to. Of course it wasn’t designed for anything but the Blast weapons, I still think it could do much more with control over direction. I was thinking that if a controlled method for redirecting weapons was implemented you could really use the new Translate, Velocity and even the old AimedWeapon primitives in new, interesting ways. Particularly Translate and Velocity though, I really think they are lacking without a way to control direction. This is of course just one man’s opinion and he happens to have a unquenchable thirst for new methods of destruction.. πŸ™‚

    I understand however, that sometimes my ideas are not in line with your ultimate vision of the game or otherwise are not able to be implemented. I won’t press the issue on this idea or anything. I just mainly wanted to do another post to suggest that if this idea does ever make it in, that the vertical adjustment be an absolute setting instead of relative to the current path like the horizontal adjustment. That, and to try to make the case for it a little better, because it would be extremely useful.

    #11406

    imported_gcamp
    Participant

    Ok I’ve done the WeaponRedirect primative. Not tested it though, let me know how you get on πŸ™‚

    #11407

    Bobirov
    Participant

    Well after messing with it a little bit it seems to work like I had invisioned but there is a slight error. The horizontal redirect is off by 90 degrees to the left. So if you enter 0 and then set the nextaction to a projectile it fires 90 degrees to the left of where the weapon is aimed. Other than that it works just like I requested.

    However, after playing with the primitive for just a short time it occured to me that a relative vertical adjustment is needed for certain situations (the shotgun type for instance). I was thinking to accomplish this an optional tag could be like or something like that could be added. If you’re really feeling frisky the same functionality could be added for the horizontal adjustment as well but the vertical one is the crucial one in my opinion. Hopefully since there is already a relative mode (hredirect) and an absolute mode (vredirect) that providing a way to choose between either isn’t too much more work to implement. Any method of getting both redirection modes would be fine, as long as there is a seperation between horizontal and vertical. And by that I mean that you can have one be relative and the other absolute, not both set by one toggle.

    I hate to just keep asking for stuff though so unless I just have a stroke of absolute genius or I find something horribly wrong I think this is the last definition addition I am going to request until 38 comes out. Don’t get me wrong, I love all these new options I get to use. But I think there comes a point when I need to say enough is enough and I just need to let you do your thing.. πŸ˜‰

    #11408

    imported_gcamp
    Participant

    The horizontal redirect is off by 90 degrees to the left

    Fixed.

    However, after playing with the primitive for just a short time it occured to me that a relative vertical adjustment is needed for certain situations

    Ok ive added in two new tags. habs and vabs which are booleans that set if the two angles are relative or absolute. Sorry untested again.

    I hate to just keep asking for stuff though so unless I just have a stroke of absolute genius or I find something horribly wrong I think this is the last definition addition I am going to request until 38

    No worries I don’t mind. Keep asking I can always ignore you πŸ˜‰

    #11409

    Bobirov
    Participant

    Vertical redirect seems to work just like it should when in absolute mode. If the shot is travelling along 0 degrees and you do an absolute vertical redirect of -45 degrees it will indeed travel along -45 degrees (315 degrees).

    Negative adjustments seem to work like expected from what I have seen so far. This is good because I was a little worried that negative values wouldn’t be accepted.

    However, horizontal redirect is now off by 180 degrees instead of 90 degrees. If you enter false and 0, the shot goes in the exact opposite direction of where the shot was aimed. A relative horizontal adjustment of 0 degrees should cause the shot to travel along the original horizontal trajectory… πŸ˜‰

    Strange things seem to happen when using a relative vertical adjustment. Below is a weapon I have been using to do some testing with.

    	
    Redirect Test
    Shoots 3 projectiles at different vertical angles
    mirv.bmp
    1000
    1
    7

    Redirect Test
    7
    5

    Redirect Test
    7
    1.0
    down
    3
    exp00
    explosions/small.wav



    Redirect Test
    7
    false
    false
    180
    15

    Redirect Test
    7
    2.5
    fatman/fatman.txt

    Redirect Test
    7
    1.0
    down
    3
    exp00
    explosions/small.wav




    Redirect Test
    7
    false
    false
    180
    -15

    Redirect Test
    7
    2.5
    littleboy/littleboy.txt

    Redirect Test
    7
    1.0
    down
    3
    exp00
    explosions/small.wav



    A regular missile is fired along the original trajectory, another projectile (fatman model) is aimed 15 degrees higher than the original trajectory and yet another projectile (littleboy model) is aimed 15 degrees below the original trajectory. Now I’ll post a few screen shots of what is happening.


    Here is a picture of the above weapon fired at 45 degrees vertically. At a glance, everything appears to be working fine. The fatman seems to be travelling along a path that is 15 degrees higher than the original projectile path (large missile). The littleboy seems to be travelling along a trajectory that is 15 degrees below the original projectile path.


    Here is the same weapon fired at 60 degrees vertically. The fatman should be travelling at 75 degrees but it seems to be travelling at 45 degrees. The littleboy should be travelling at 45 degrees but it seems to be travelling at 15 degrees.


    Again the same weapon, this time fired at 30 degrees. The fatman should be travelling along 45 degrees here but instead it seems to be travelling at 75 degrees. And lastly, the littleboy, which should be travelling at 15 degrees instead appears to be travelling at 45 degrees.

    Another thing is that relative, vertical redirections that cause the angle to be lower than 0 degrees or higher than 90 degrees seem to wrap around within the range of 0 to 90 degrees. Its difficult to say that this is indeed happening tho with the problem that I displayed above. But, if it is happening, I think that this too would need to be adressed. A shot fired at 90 degrees with a relative vertical adjust of positive 15 degrees should technically fire at 105 degrees, not 15 degrees.

    May this information be useful in hammering out the bugs in this sweet little primitive in the making.

    #11410

    Bobirov
    Participant

    Just to show the usefulness of the primitive and to prove that you can indeed do what I was talking about with it, here is a quick cross-shaped explosion pattern I made. A single projectile hits and creates 9 explosions in a cross-shaped pattern.

    You could add some more explosion branches and a delay on each and make explosions that slowly ripple outwards and so forth with the same approach. Like I said earlier, the new translate primitive will get along quite well the ability to direct it. πŸ˜‰

    #11411

    Ebonite
    Participant

    oh, kewl! would these new primates, once shaved, trained, and working correctly, allow for a “drill” type weapon? what I would be interested in would be a weapon, or series thereof, that would sequentially impact in the same spot, say 3 to 5 times. the purpose of such a weapon would be to carve valleys through mountains (or Tons of Dirt) in order to reach a tank in an impossible spot (such as buried). Rather than launching 10 baby missiles to run a trench to another tank, have 3 – 5 baby riot bombs hit the same spot in succession so that the first hits makes a crater, and then the second hits within the first crater, and the third hits the second crater, ad nauseum. This would allow for faster “tunneling” than only one sot per round. Would make for an interesting effect on reflective sields, as well.

    #11412

    Bobirov
    Participant

    @[PDX]EboniteΒ² wrote:

    would these new primates, once shaved, trained, and working correctly, allow for a “drill” type weapon?

    Yes, I can think of several ways to do this and I like one of them so much I wrote it down. So, you might see something like this in Apoc 2 if I like it once I see it in action.

    #11413

    imported_gcamp
    Participant

    I think it works now, well your test weapon works anyway. I am still not 100% sure what will happen when verticle relative is used for missiles on the way down.

    #11414

    Bobirov
    Participant

    I noticed that explosions are now drawn a lot faster than they were before. I think it looks awesome for all conventional explosions but it kinda ruined my gas grenade I had going because the explosions draws way faster than the time of the weapon. I could fix it by adding in a lot more delayed explosions on shorter intervals (instead of 1 / second like it is now) but that would be harder to get the weapon strength right and not to mention make the xml very lengthy for the weapon. Its not just my gas grenade that utilize slowly drawn explosions, my meteor weapons which create clouds before the meteor appears, acid weapons and another weapon I had planned are better suited to having slowly drawn explosions as well.

    So, this got me wondering, is there some optional tag to control the speed at which explosions are drawn in the xml? If there is not, could we get one maybe? Something like # which would represent the number of frames to draw from the textureset per second or some other method of controlling the draw speed for explosions. I think this should definately be an optional tag if you decide to make it. If the tag is omitted, the current default speed should be used. It could also go into the textureset.xml file. But I think it would be better to have it in accessories.xml, because you could use the same textures but at different speeds.

    If you can already do this somehow, will you please show me how? And if you can’t, I really hope you agree with this one, otherwise my gas grenade or anything else that is cloudlike in nature just isn’t going to be the same :).

    #11415

    imported_gcamp
    Participant

    Yeah, I think the new weapon explosions are really nice now πŸ™‚

    I have added two new optional attributes to the explosion. These are minlife and maxlife which is the minimum and maximum amount of time an explosion particle will live for. Using this you should be able to have very long living particles. Internally that is how the new napalm works just a textured particle that lives for the life of the napalm flow.

Viewing 15 posts - 16 through 30 (of 52 total)

You must be logged in to reply to this topic.