This topic contains 50 replies, has 0 voices, and was last updated by  Deathstryker 12 years, 11 months ago.

  • Author
    Posts
  • #11416

    imported_gcamp
    Participant

    @gcamp wrote:

    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.

    Update: I have added two more optional attributes, just in case.
    noluminance – stops the explosion from appearing to be made of fire (default is : will look like fire)
    nowindaffected – stops the explosion from being blown in the wind (default is : will be affected)

    Let me know if you can think of any more…

    #11417

    Bobirov
    Participant

    @gcamp wrote:

    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.

    I have added two more optional attributes, just in case.
    noluminance – stops the explosion from appearing to be made of fire (default is : will look like fire)
    nowindaffected – stops the explosion from being blown in the wind (default is : will be affected

    I have briefly checked them out and they all seem to work well. I’ve got the gas grenade back to looking like gas again. Thanks for all the new attributes :).

    One thing I have noticed though after I slowed down an explosion with min/maxlife is that explosions are not animated? Its like it just uses one frame from the textureset and expands it in size and fades it throughout the life of the explosion. Maybe they weren’t animated before and I just never noticed it until now? Shouldn’t it cycle through all the frames in the textureset throughout the life of the explosion or is that only for napalm? Forgive me, I’m just curious about things.. πŸ˜‰

    Also, I never mentioned it before, but the final round of fixes to WeaponRedirect caused absolute vertical redirects to require being set to 90 degrees to be parallel to the horizontal. Its not a big deal but to me it just seems like an absolute redirect to 0 degrees should cause this. 90 degrees should be straight up, just like when aiming in the game. It originally was like this, so I am guessing that it was perhaps an uninentional change? However, if it runs the risk of breaking something to change it I say just leave it like it is. Its easy enough to figure out the angle required for the desired effect and I’m probably just nit picky… πŸ˜›

    #11418

    imported_gcamp
    Participant

    @bobirov wrote:

    One thing I have noticed though after I slowed down an explosion with min/maxlife is that explosions are not animated? Its like it just uses one frame from the textureset and expands it in size and fades it throughout the life of the explosion. Maybe they weren’t animated before and I just never noticed it until now? Shouldn’t it cycle through all the frames in the textureset throughout the life of the explosion or is that only for napalm? Forgive me, I’m just curious about things.. πŸ˜‰

    Yes it did used to cycle through the bitmaps, and now it does just use one for each particle (randomly selected).

    The thought behind this was that it happens so fast that you cannot really see the difference anyway. But this approach saves the number of textures needed for the explosion as before I had to use two per particle to blend out of one frame into the next, and now I only need one.

    However I could make it do either, if you think it was better.

    Also, I never mentioned it before, but the final round of fixes to WeaponRedirect caused absolute vertical redirects to require being set to 90 degrees to be parallel to the horizontal. Its not a big deal but to me it just seems like an absolute redirect to 0 degrees should cause this. 90 degrees should be straight up, just like when aiming in the game. It originally was like this, so I am guessing that it was perhaps an uninentional change? However, if it runs the risk of breaking something to change it I say just leave it like it is. Its easy enough to figure out the angle required for the desired effect and I’m probably just nit picky…

    Yes this was intentional. Never really thought about the consistency with the tank elevation. But it fits in with the world coordinates. If it is set to zero rotation and zero elevation it points straight up to the sky (which seems right). If I changed this to be the same as the tank zero zero would point to the right, parallel to the ground.

    #11419

    Bobirov
    Participant

    @gcamp wrote:

    Yes it did used to cycle through the bitmaps, and now it does just use one for each particle (randomly selected).

    The thought behind this was that it happens so fast that you cannot really see the difference anyway. But this approach saves the number of textures needed for the explosion as before I had to use two per particle to blend out of one frame into the next, and now I only need one.

    However I could make it do either, if you think it was better.

    Maybe another optional attribute to animate the explosion? You’re right about the default explosion speeds being too fast to really notice any animation. But, when an explosion is slowed down, I really think it would look better if there was a way to play the entire animated explosion throughout the explosions lifespan. Again, its mainly for when you are trying to achieve a cloudlike look. By slowly animating the explosion it would help to make it look more fluid. After all, what is the point of having all those snazzy explosion animations in the textureset if you can’t really use them anywhere eh? I dunno, maybe I’m just a bit grumpy because I made a gas explosion animation and now its not animated anymore. πŸ˜‰

    @gcamp wrote:

    Yes this was intentional. Never really thought about the consistency with the tank elevation. But it fits in with the world coordinates. If it is set to zero rotation and zero elevation it points straight up to the sky (which seems right). If I changed this to be the same as the tank zero zero would point to the right, parallel to the ground.

    Like I said, its not really a big deal. It works just fine and is easy enough to use. I just figured I’d mention it because I didn’t know if it was an intentional change or not. Since it was, and the primitive does work just fine, I say just leave it like it is and don’t worry about it.

    #11420

    Bobirov
    Participant

    Instead of having the sound for the Laser Beam effect hard-coded, could it be seperated into an attribute for the WeaponAnimation primitive? Something like or something would be just lovely. The reason I ask is that I was thinking about using the laser beam effect on a weapon but I want to use a different sound than the one that is used but I don’t see a way to do it.

    #11421

    imported_gcamp
    Participant

    @bobirov wrote:

    Instead of having the sound for the Laser Beam effect hard-coded, could it be seperated into an attribute for the WeaponAnimation primitive? Something like or something would be just lovely. The reason I ask is that I was thinking about using the laser beam effect on a weapon but I want to use a different sound than the one that is used but I don’t see a way to do it.

    Ok, done.

    You may also want to check out the cavern environment to see what you think, comments welcome. There is a sample config commented out in the landscapes.xml file.

    p.s. I like the look of Apoc Mod v2 v nice πŸ™‚

    #11422

    Bobirov
    Participant

    @gcamp wrote:

    Ok, done.

    Me wub joo πŸ™‚

    @gcamp wrote:

    You may also want to check out the cavern environment to see what you think, comments welcome. There is a sample config commented out in the landscapes.xml file.

    Ya I saw that on the TODO and DONE list earlier so I just had to do a new build and check it out. I haven’t played with it at all other than to check it out with the test landscape you have commented out. I think its a cool idea and it is something different. I think its a cool setup because it provides for more difficult shots. It also would really work well with or without the water surrounding. Are you planning on leaving it indestructable like it is currently or possibly making it optional for it to be destructable (to a maximum height)? I personally don’t see why a nuke wouldn’t take out the roof just as it does the floor but thats just me :). It might also be cool if dirt stuck to the roof when it collided with it too. Just a few thoughts.

    Speaking of not using the water surroundings tho, is it possible with the current set up to not draw the water (e.g. ) but still draw the bouys or something equivalent on the boundaries of the landscape? I have been toying with the idea of doing that already (moon and desert landscapes) but I think this new cavern style landscape would work well without water as well. I just think it would help to change things up a bit to have a few landscapes that don’t have water on em (ala old Scorched Earth). Its just that when you turn off the border, it turns of the bouys so you don’t know what kind of walls are on the map unless you shoot it. You also can’t use them to line up shot distances and so forth as well. There might be something like or or something I just haven’t tried anything like that. I’m just wondering.

    @gcamp wrote:

    p.s. I like the look of Apoc Mod v2 v nice πŸ™‚

    Ya I think it is getting a more unique and polished feel to it. I’m more and more happy with it each day. One thing that is bothering me though, its up to about 2 MB when RAR’d on the best settings now. I’m starting to get nervous about transferring out that much data out potentially hundreds of times a day from my home. I’m not supposed to run a file server with my current set up and I’m not real sure how that would work out, I might just be being paranoid though as everyone tells me. I might have to disable or at least drastically limit use of the auto-download system for fear of my ISP taking notice heh. In doing so, I’ll still more than likely be relying mostly on people still downloading the mod from a site. It is with this in mind that I am wondering if I could get an Apoc 2 download link on the official Scorched 3D pages, or maybe even (I doubt it :P) Apoc 2 included with version 38 of Scorched. In addition to my woes, I think it could help kick off the new mod system, but what do I know?.. πŸ˜›

    #11423

    imported_gcamp
    Participant

    Are you planning on leaving it indestructable like it is currently or possibly making it optional for it to be destructable (to a maximum height)? I personally don’t see why a nuke wouldn’t take out the roof just as it does the floor but thats just me :).

    I agree. But if I make it destructable then I would have to send it as part of the level when people connect. Which may be a problem for modem users. If I don’t make it destructable then it can be generated via a random seen and it gets around this issue. But perhaps in 39 it will be switchable πŸ˜‰

    but still draw the bouys or something equivalent on the boundaries of the landscape?

    Yeah I noticed this too. I will put them into the non-water version too.

    It is with this in mind that I am wondering if I could get an Apoc 2 download link on the official Scorched 3D pages,

    Yes that would be great, if ok with you.

    or maybe even (I doubt it :P) Apoc 2 included with version 38 of Scorched. In addition to my woes, I think it could help kick off the new mod system, but what do I know?.. πŸ˜›

    That would be really cool :). Need to think a way to give the needed credit etc. And perhaps a couple of set single player games as well.

    #11424

    Bobirov
    Participant

    @gcamp wrote:

    I agree. But if I make it destructable then I would have to send it as part of the level when people connect. Which may be a problem for modem users. If I don’t make it destructable then it can be generated via a random seen and it gets around this issue. But perhaps in 39 it will be switchable πŸ˜‰

    Hmm I am assuming by how this is worded that in multiplayer each client would then have a different “roof” shape? If this is the case I think that would be odd seeing as how projectiles can collide with the roof. That would mean that each player would have a different set of obsticles on the roof to shoot around which isn’t exactly fair, or am I just mistaken in how that works? Of course if the roof is generated from a file that wouldn’t matter anyways… πŸ˜›

    @gcamp wrote:

    Yeah I noticed this too. I will put them into the non-water version too.

    Awesome thanks! πŸ™‚ This means I will definately be able to turn it off on the desert and moon type maps in the mod to complete the effect.

    @gcamp wrote:

    Yes that would be great, if ok with you.

    It would be okay by me for sure if you want to put a link to the Apoc files page (http://apochq.handwired.net/Files.htm) in the Files section or mirror the download or whatever. Of course the next scenario is even more preferable as everyone with version 38 would have the mod :).

    @gcamp wrote:

    That would be really cool :). Need to think a way to give the needed credit etc. And perhaps a couple of set single player games as well.

    Hmm, single player games eh? I was planning on making some custom AI types that stick to specific weapon groups and use the modded weapons (eg. a Pyro fire AI guy, a Bio/Chem AI guy, etc) and I could customize a default set of single player difficulty settings for the mod (at least the custom game type). Is this what you were talking about or were you referring to making a way to actually make a single player scenario? πŸ™‚

    Yes, I definately need to make up a list of all contributions that were made to the mod (knowingly or otherwise.. :P). I was actually thinking about this the other day. I would definately love it though if Apoc was included with the game. People would have no choice but to have a glimpse at the madness then.. 😈

    #11425

    imported_gcamp
    Participant

    @bobirov wrote:

    Hmm I am assuming by how this is worded that in multiplayer each client would then have a different “roof” shape?

    No this is not the case. They should all be the same, although truthfully I’ve not checked yet. As you pointed out anything that affects the gameplay should be the same across all clients.

    The landscape (and roof) are generated using a random sequence of numbers. But using the same psuedo random number generator and seed on each client will result in the same sequence of numbers, and so the same landscape πŸ™‚ This means I don’t need to send the landscape only the seed to each client.

    But when the landscape is deformed (by explosions) I need to send the diff to any clients that connect after the start of the round. Which takes bandwidth, this is what I want to avoid sending for the roof.

    @gcamp wrote:

    Yeah I noticed this too. I will put them into the non-water version too.

    Awesome thanks! πŸ™‚ This means I will definately be able to turn it off on the desert and moon type maps in the mod to complete the effect.

    Ok, done.

    Hmm, single player games eh? I was planning on making some custom AI types that stick to specific weapon groups and use the modded weapons (eg. a Pyro fire AI guy, a Bio/Chem AI guy, etc) and I could customize a default set of single player difficulty settings for the mod (at least the custom game type). Is this what you were talking about or were you referring to making a way to actually make a single player scenario? πŸ™‚

    Yes that is what I was talking about.

    I was actually thinking about this the other day. I would definately love it though if Apoc was included with the game. People would have no choice but to have a glimpse at the madness then.. 😈

    Yeah, that would be cool. If it was included then it would not really be a seperate mod and we wouldn’t need to use the mod stuff as it would always be there! oh well πŸ™‚

    #11426

    Soggy Bottom
    Participant

    A couple of ideas I had kicking around in my head for new weapons… If a laser weapon is created, how about requiring batteries to fire it, and use up a specific number of batteries determined by the strength of the laser beam used. As a counter-measure to the laser weapon, how about a shield which absorbs the laser energy, and converts it into batteries. In other words, if you had this absorbtion shield on, and a laser weapon was fired at you, the energy would get converted into batteries for your own use. Or as an alternative counter-measure to the laser, how about a reflector which would bounce the light beam elsewhere like a mirror, possibly back onto the tank firing the laser or onto another opponent.

    Another idea I had was to develope magnetic field weapons. What I was thinking about was something like the anti-ship sea mines which are magnetized and then drawn towards the metal of a passing ship or submarine. What about magnetizing a roller weapon, so that if it rolled into a specific radius of distance from a tank it would change direction and be drawn to its metal hull. You could even have this weapon be able to roll uphill if it were close enough to a tank. A counter-measure to magnetized weapons would be a type of shield that is actually a magnet repeller. The shield would use reverse polality to push the magnet-roller away, rather than toward it.

    Another thing I was thinking about was that although parachutes are available as a counter-measure to Digger weapons, there is no counter-measure to any of the Napalm, fire-type weapons. How about being able to purchase fire extinguishers, or fire foam, which would lets say reduce napalm damage by 50%.

    One last idea I have in this posting has to do with wind speed. The strength of the wind in any given round of play is almost always a deterent, making shots more difficult. What if there was a weapon that could take advantage of wind by deploying a parachute once it reached maximum altitude. I was thinking of converting a weapon, lets say for example an MIRV. Once it reached its maximum altitude, each warhead would deploy a parachute and it would then drift 3 times the distance it normally would have drifted as determined by the wind strength and speed. This would then allow the weapon to reach a great distance without needing a lot of power to fire the weapon as in the case of a damaged tank with no batteries to restore power.

    #11427

    Bobirov
    Participant

    In my never ending torrent of ideas surrounding this game, I have come up with a few more ideas for some basic changes to the weapon primitives that I think would be useful. No new primitives here or anything, just some minor changes and additional attributes for a few of the existing ones that I think would be appropriate.

    Some Basic Ideas:
    The first and probably most basic of these additional attributes is one for the WeaponRoller primitive that controls the amount of time that the roller rolls before it detonates. This is probably just a matter of exposing a variable in the xml, I hope, and shouldn’t be too tough to add. It just seems like this should be there, and I’ve often wondered why its not, even if I have never really needed it.

    Another attribute I would like to see is for the WeaponProjectile primitive and that would cause the projectile not to spin (or possibly control of the spin speed?). If the projectile’s spin is disengaged, the projectile’s top will remain facing upwards throughout the projectile’s flight. The ability to do this would help during situations when the projectile is made to look like an airplane/helicopter/insect/etc. Seems like it would be a simple addition that opens up the possibility for a lot of neat content.

    Also, for quite some time I have thought it would be nice if you had more control over the decal that is applied to the ground when a deforming WeaponExplosion is used. Currently the only place this is defined is in the landscapestex.xml definition. And while this is great at keeping things simple, I think it would help to further distinguish some weapons from others if there was more control over what decal is used. I think that an optional attribute for the WeaponExplosion (and WeaponNapalm?) primitive that would override the tag in the landscape definition would accomplish this. By leaving the attribute optional you could still rely on the landscape definition for the majority of standard explosions, but you could still have control of the decalling if you so desired. By having this, it could be made so that fireballs and so forth always leave burnt up or lava looking textures, ice bombs would always leave blobs of ice and snow, and on and on. Again here a fairly simple addition that opens up lots of fun possibilties.

    WeaponReference Ideas:
    Just recently, I have started exploring the use of the new WeaponReference primitive (great idea btw) and I have already made a few weapons that would be extremely lengthy without it. However, I have noticed a few issues with the primitive that might need to be addressed. The first thing I noticed is that the weapon that is being referenced MUST BE above the weapon that is using the reference in the xml code. If this is not the case, you will get an error. I’m sure this is just because the file is read sequentially. I don’t know if this needs to or can be addressed but I thought I would mention it at least.

    Also, right away I noticed that the only type of accessory you can reference is seems to be the type, “WeaponProjectile”. If you try to reference any weapon that starts with a different primitive (WeaponMulti, WeaponDelay, etc), you will get an error stating that it is of the wrong type. While I can see that being able to reference fuel, parachutes, shields and so forth could cause problems, I don’t see why you shouldn’t be able to reference any accessory that begins in one of the weapon primitives. This, would make this new primitive even more usable and open up a range of possibilities.

    Perhaps the most important thing that occured to me is that when you reference a weapon it will use the same armslevel as the original weapon. This creates cases where you make a large weapon that rewards like a smaller weapon and you have no control over it. It seems to me there is a need for an attribute that, when engaged, would override the entire referenced weapon’s armslevels and use the armslevel defined in the WeaponReference primitive itself. This would allow WeaponReference to be kept fair when used to create larger, more complex weapons from a series of smaller ones.

    ….

    Well thats it, not too bad I hope. I don’t think any of it is too terribly extravagant, and much of it opens up lots of possibilites with a minimal amount of changes. But then again I’m not the one sitting there trying to write all the code to do it.. πŸ˜‰ Anyhow, questions/comments are welcomed of course. And, as always, thanks for the terrific game and keep up the great work.

    #11428

    Knochi
    Participant

    Can i turn off the rotation around the longitude axis for the rocket Models in Ver 38 ????

    I would like to make a V2 and a Tomahawk Weapon model… they have wings and fly more like a plane than a rocket.

    Thx
    Knochi

    #11429

    Bobirov
    Participant

    @knochi wrote:

    Can i turn off the rotation around the longitude axis for the rocket Models in Ver 38 ????

    I would like to make a V2 and a Tomahawk Weapon model… they have wings and fly more like a plane than a rocket.

    Thx
    Knochi

    Not at the moment but if that idea for a attribute makes it in, you would be able to. Lets hope it does :).

    #11430

    Cambo
    Participant

    Long, long ago… in a version far, far, away….

    When I first hacked in custom missile support there were custom rotation vectors as part of the weapon model def…

    Gavin pulled it out when he cleaned up the code… πŸ™

    Cam

Viewing 15 posts - 31 through 45 (of 52 total)

You must be logged in to reply to this topic.