Nali Weapons 3 - Preview 2 (includes Nuclear Explosion)

[Myth]

The thing is that I wouldn't go all the way and make that animated texture for every texture and every color possible.
20 textures 5 colors 20 frames 128x128 size, all that gets multiplied and in this example the result is 32 megabytes.
I'd rather have one well colored, well animated generic grid texture that is applied to all meshes for a re-spawn effect. But it's your call.

Isn't this effect possible by using scripted textures? I always thought scripted textures are 32-bit and can't have masks, I remember you saying that they are 8-bit in which case they can be masked.

native(473) final function DrawTile( float X, float Y, float XL, float YL, float U, float V, float UL, float VL, Texture Tex, bool bMasked );
Whit 3x calls to this function you can animate an almost identic texture transition.

Anyways good luck finishing this mod. I can't wait to play whit these new stuff.

[Feralidragon]

You know what? You're right

I didn't really remember scripted textures anymore. Although it would only reduce the core filesize, the rest of the weapons will keep their sizes (they really have nothing that could be solved by less textures, since they are all different and all needed as they are, nothing to do around it :\).

Thanks for the tip Myth

EDIT: Checked something sad, but not related with this solution, but potentially regarding new mods: it seems that UT2004 as a DrawPortal capability in Scripted Textures, while UT doesn't, meaning that if UT had that function, CCTV systems and a Portal gun would be possible to recreate. :\

EDIT2: It doesn't work :\ The scripted textures are an identity, meaning when I render the scripted texture in one actor, the same thing gets rendered in all the actors with that scripted texture, they aren't seperate. The solution was good, but it's impossible since each respawn have its own timing, therefore I'm afraid the core will still have about 12Mb in the end, being 5Mb the respawn FX (320 textures)... :\ I tried, I really did...

[Myth]

Here is how i thought it could be done. My only problem was that i don't know if scripted textures are mask-able or not.

There is a static object that holds 16 128x128 scripted textures and some other arrays containing meta data about these textures, more precisely 16 names of the base skin texture, 16 floats that have a value between 0-1 the state of the animation (0=started; 0.5halfway done;1finished), 16 bools whether the scripted texture is used or not.

In the tick function if (boolactive[n]) {floatstate[n]+=deltatime; if (floatstate[n])>=1 {boolactive=false}}

I've never used scripted textures yet so i don't know when they have to be redrawn, but only active ones need to be redrawn and the parameters in the drawtile function are interpolated by the floatstate variable.

When a respawn effect is spawned:
It checks all the active textures to see if the desired texture is animating by checking name[n], if floatstate[n]<=0.1 then texture=scriptedtex[n]
this way if 2 of the same type are re-spawning in the same time they use the same texture. If this check fails an unactive texture is used and starts the animation.

This is how i'd do it. You can have a number of unique respawn effects at once. If scripted textures can be created and destroyed dynamically then you can have unlimited respawn effects at once, but I seriousely doubt that you need more than about 20.
This is essentially the same way how unreal engine manages sound effects into sound slots and channels and everything.

Now about that drawportal, I remember once playing whit a weapon. The weapon featured a guided missile which was similar to the redeemer's alt fire. But instead of going full-screen, a small screen appeared on the hud so that you could see what you see and don't get assassinated and guide the missile. I didn't see anything like that in any other mod. And i don't know where i can dig up that mod, but it's probably on my hard drive in one of the few thousand *.u packages intalled into my ut.

[Feralidragon]

@ Scripted Textures: That's also a very good idea, however, what I save in filesize I will waste in processing, relative to how it is now.
For instance, as you said, there will be a static object controlling/holding the meta-data, which means that each inventory will have to look for it at the beggining, even thought is just right in the beggining, a map can have over 500 pickups to look for that object, and each one looking for it using the actor list is really painfull for a server. I could cut that processing as well to a really low value, if made that "static object" a pawn, and just by using the pawn list I could locate it really quickly without much processing, however, some gametypes don't like pawns they don't know about, which again could be solved by giving them a team of 255 on most situations (since its a playerreplication.team issue with the gametype itself).

But then, I would have 16 scripted texture x 5 colors (since unlike canvas, I can't give it a custom color), having 80 scripted textures, meaning that in the worse of all cases, the game would have to render (drawtile) 80 times per tick each tile, but since the texture isn't just a grid, but a grid and a bar, it would be 160 times a tick (in the worse case).

Add that to the fact that the server will constantly sending some of those variables to the client (since the rendering is made there), and you have a relative high processing job for a effect that shouldn't take much at all, and that's not relevant for game, processing that can be saved for nukes for example

Btw, scripted textures can be masked, translucent, whatever you like In a mesh or sprite, just set their style to one of them, in a BSP surface, just set that surface to masked or translucent, since scripted textures are still textures.

So, I prefer to have a bigger filesize and spend about 5Mb on texture storage by the system, which won't affect an online game, than having a bigger load of processing going on. However, I won't let the system be as it is, since it's taking up too much processing either ways, and since all the respawn effects have 2 seconds, I will make the grids nativelly animated (I won't code anything native, what I mean is that I will animate them in Ued in the texture browser), since I know they're affected by gamespeed, and work independently (since the actual texture is always the one you place there, and not the following animated ones, and I can always modify its animrate even on real time, I think). That way, instead of being the uscript code animating them, leading to an excessive processing load, it will be the native part doing that, and the processing will be reduced to minimum.

Btw, I compressed the core into a uz with its current 12Mb, to see what size the clients have to download using redirect, and guess what: the clients will only have to download 3,15Mb, almost 1/4 of the actual core size, so I guess it will make everyone happy?

@ DrawPortal weapon: Regarding the DrawPortal weapon, I know what weapon you're talking about: it's the TomaHawk (I think it is its name) from Unreal4Ever. But DrawPortal has some rendering problems: doesn't render the sprites or coronas for example.
But while in UT DrawPortal can only be made on canvas, in UT2004 it can be made on Scripted Textures as well (and afaik, UT2004 doesn't have those rendering problems anymore).

[Myth]

Stop signs and problems at every corner whit scripted texes? Well it just got tiring...
Besides I'm not very experienced whit uscript...

@PortalGun, It's a same that it can't be properly done whit see-through.

[Feralidragon]

Stop signs and problems at every corner whit scripted texes? Well it just got tiring...
Besides I'm not very experienced whit uscript...

However you gave really good ideas there, and the 1st really looked as a doable one (that's why I attempted right away )...
I wish sometimes that this engine could have the material systems the newer engines have...

[Meindratheal]

I was gonna mention that
I think lulthefirst put it best, if you don't move when you first connect, before the game starts, and modifiers on spawnpoints are enabled, you will pick up the modifier, and when it respawns you will pick it up again ad infinitum. If you move away and move back, you won't pick up the modifier.

IIRC this also creates an AccessedNone, and I also think it actually gives you a different modifier to the one actually there (might be wrong on that one though, my memory isn't that hot )

Keep up the good work

[Feralidragon]

Thanks for the report guys
Actually, I knew that the modifiers were pickable before the start off the match, didn't know it caused further bugs...

Either ways, that should be fixed in the new ones, since currently in NW3 they can only picked when: you're holding a Nali weapon, and in case you have "The One" modifer they only let you pick up 3 of them and nothing more for that weapon.
As before the match starts no one has a single weapon, it's therefore now totally impossible to pick them up while spectating.

There was also a little problem regarding "The One" modifer where sometimes one of the modifers was replaced by a new one instead of just adding it, and that's solved as well.
Also I added bot support, meaning that bots will only pick up a modifer if they have a Nali Weapon without a modifer at all, meaning they will pick just 1 under normal conditions, or 3 modifers if their weapon have "The One" modifer, being able to hold 3. Other than that, they will simply ignore them.


Either ways, although I am avoiding many bugs with the new core and weapons architecture instead of fixing them, any bug you still find on NW2, please keep reporting so the same doesn't happen in NW3.

Thanks so far for your input

[Feralidragon]

The UltimaProtos is going to be one of the last weapons to be (re)made, so I still didn't get to it yet. However, the UltimaProtos firing has some problems indeed, specially since it uses timed functions, kinda badly done, which weapons do not like. The new one will have it's firing fully animated and situations like that will be avoided by it.

For instance, the Graviton used that kind of functions to make it fire a bit after you hit fire, which led to problems like hanging up when the firing is too fast. As now it's fully done and animated instead of timed, you will still have that fire delay, but it never ever hangs, nor produces that kind of problems anymore.

[Meindratheal]

That would be cool, kinda like an overpowered Spartan Laser (from Halo)

I'm seriously looking forward to this, I'll be putting it onto my server as soon as possible

[Feralidragon]

Thanks for the idea, but I already thought out how the new one will be like, and I'm afraid that it will be "either you fire or not", but there won't be more crashes since the whole thing will be handled by animation and not timed events.

[Meindratheal]

I'm not entirely sure, but I think this is a NaliWeapons problem (although IIRC it's only happened when playing MonsterHunt).
Sometimes, it will seem as if you can't change weapons from the W.R.E., but you can still fire. But, when you try to change weapons, sometimes it will have different modifiers. If you keep switching, eventually you will get to your other weapons.
I found out the reason when I died. MH scatters all of your weapons, and there were probably around 100 W.R.E.'s laying on the floor. No idea what the reason is, but it only does this with that weapon.

[Feralidragon]

Thanks for the report, but I already know that bug. It happenned on Killerbee's MH server, right?

You just needed to get "burned" (flametracker) by another player, and the server would make you respawn countless times, and each time you respawned, the nali mutator gives you a new WRE. Basically, a lot of WREs, seperated ones.

But it seems this is solved now on that server, and I know the cause and is fully fixed already in NW3.

Again, thanks for the report, and keep posting whatever problems you still find on the previous pack

[Meindratheal]

Actually it was on my own server
I assume it's to do with Nexgen, since that's what 'prevents you from dying' (in it's own words).

Out of interest, will you still be able to fly using the graviton?

[Feralidragon]

Actually it was on my own server
I assume it's to do with Nexgen, since that's what 'prevents you from dying' (in it's own words).

It's exactly that. It seems it reacted to the "burned" type of damage (perhaps due to avoid death on lava zones), that's why once you got on fire, you would get respawned over and over, and the respawning was so fast, that the current NW2X mutator kept giving WREs to the player ROFL
But now in the upcoming pack, either you activate that or not, that shouldn't happen on MH matches, and even if you respawned, you would get only 1 WRE this time (the new mutator is very different, and even supports other weapons from other packs to avoid mutator conflicts and add other possibilities of gameplay).

Out of interest, will you still be able to fly using the graviton?

Like the NW2X, by default you won't, but you can always turn that on and fly with it (that option is in the graviton part of the ini).