Lauren

To just tell a specific unit something use: scripts.lua function TellOtherSuperSpecificAlly(self) ObjectBroadcastEventToAllies(self, "SuperEncodedMessage", 99999) end scriptevents.xml<ScriptedEvent Name="SuperEncodedMessage" /> ... <EventList Name="SuperSpecificUnitFunctions"> <EventHandler EventName="SuperEncodedMessage" ScriptFunctionName="MyHandler" /> </EventListSo as you can see you can name your event whatever you like, a radius of 99999 should usually be enough to affect a whole map, and only handle it by your specific unit. I'm not even sure if the passing of self is a must, could be that you can also do something like this: scripts.lua function TellOtherSuperSpecificAlly(self) ObjectBroadcastEventToAllies("123456", "SuperEncodedMessage", 99999) end scriptevents.xml<ScriptedEvent Name="SuperEncodedMessage" /> ... <EventList Name="SuperSpecificUnitFunctions"> <EventHandler EventName="SuperEncodedMessage" ScriptFunctionName="MyHandler" /> </EventList scripts.luafunction MyHandler(self, data) if data == "123456" then ... end end

Yeah sure you can do that, but the standard shaders use RGB. Theoretically it would be enough to save only 2 axis as the third can be calculated from them, but then you'd need a much longer time doing the calculations.

You've already changed the text, so I am not able to quote it. The things you pointed out on the lower corners of the quad is a very special case that only occurs in the size you've chosen, this happens very rarely but it's because it uses 4x4 blocks and there's just no way to cover these 3 colors. You have lots of artifacts, even on the diffuse in your uncompressed picture, which are the result of aliasing. If you'd aligned the vertices of the uv in a way that these would have been axis aligned they would all be sharp as a razor. I see you already started to change some stuff like changing 5:6:5 in the text and pictures, hope you don't just use the old ones and paint them over. Also I hope you're saving the jpg with full quality, otherwise it kills the whole purpose. For a nice reference for axis aligned lines: You don't need to be as extreme as they are, but it can certainly help in a few cases.

DXT is still basically the file format if you're working with DirectX. With multiple objects layered on top of each other etc it's basically impossible to see that the base textures only have 16 bit colors. Esp with all post effects and calculations that change the final pixel color. You are correct, DXT1 is either on or off. So yes it's the goto for diffuse, assuming it's not a half transparent/translucent unit, otherwise as needed DXT3 or 5. Depending if you have clear cut transparencies or not. Spec maps usually don't use alpha (obv alpha could still be used there, but I don't think it is in any standard shader). You also have to consider all the things spm stuff does is basically the setting of how intense the result is, it's still mixed with the other stuff, so 5 bit are usually enough. Using green for reflections is actually a wise choice as they can be the most distracting and thus you have just a little more control over them. Normal maps do not use alpha at all, the color of the normal is the direction of the vector that pixel will have. It's RGB used as XYZ, subtracted by 0.5 (so you go from 0 to 1.0 to -0.5 to 0.5), and normalized via multiplied by 2 (so it's the normalized vector from -1.0 to 1.0). As you can see you usually don't even need anything but DXT1, and as this saves to 1/8th of the original this is a lot of small texture sizes. Still if you look at a lot of games you see they have thousands of textures (where a lot of them have to be loaded into the graphic cards memory) which still take up a lot of space, also you need to consider if the players graphics card can hold all textures you need on the map it only needs to load them once instead of swapping them out and in again and again which takes time (also your graphics ram is usually the fastest memory in your pc, excluding cpu cache, so you want to have everything in there at once). A dxtn file can be loaded and used in your memory as it's still a direct draw surface (hence the dds file extension), other non dds files might need to be expanded to an uncompressed format even when not used to prep them for being used, depending on usage, tga for example doesn't need to be expanded if just read. Even if your usual low end graphics card has 2GB of memory now keep in mind the textures you send in there aren't the only things stored there. All the surfaces you draw on need their space too, and multiple times because of swap chains, and these are often floating point images, so 4*32 bits per pixel which means for 1024x1024 alone 134217728 bits (aka 16MB) but you usually now render in even larger 1920x1080 or 2048x2048 (about 32 and 64MB respectively) sizes. And your game probably isn't the only thing in there.

Reading the tutorial in the first part he states a few times something like This gives the reader the idea that you would expect DXT3/5 to compress colors better than DXT1 while he fails to understand that they all use the same compression, he even fails to understand, or at least express, that the compression used in DXTn isn't just reducing the size to 5:6:5. What he also doesn't understand is a reason why it's 5:6:5 and not 6:5:5 nor 5:5:6 nor 5:5:5 (what he used in his examples) the human eye can distinguish shades of green the best of all colors, thus a bit more is given (5:5:5 would waste 1 bit anyway). This is a huge difference and his 5 bit picture is not representative of the actual result of 5:6:5. The resulting image also varies a lot depending on which method is used to fill the last 2 or 3 bits. It doesn't help that you cannot view his pictures in full size because his account is set to private but keep in mind: in the previews one already cannot really see much difference, now remember the object is even smaller in the game itself. He does not know what DXTn actually does, thus in his conclusion he still thinks DXT5 compresses color slightly better while it's the same exact compression. He also states that there isn't a point to using DXT3 over DXT5 while there certainly is, as stated in my explanation above. All in all he fails to understand what he is talking about, even from an artists perspective as 5:6:5 cannot be compared to 5:5:5 (yes self taught artists often miss the thing about how the human eye works, but learning about perception is one of the most important things). The point of a compression format is to have big textures, which can be read in real time, with relative small file sizes. He mentions the tga format and says it's superior, but he doesn't know how that works either. Targa is nice, it's lossless, but the problem with targa is it's a runlength encoded compression, thus if you've got lots of pixels of the same color in one horizontal line it works incredibly well, but as soon as you start to have a more natural image the size explodes. In the worst case, where each pixel has a different color than the one in front of it it's even slightly bigger than uncompressed. As graphics evolve to be more and more realistic the textures are becoming more and more natural and less favorable for tga's rle. My final judgement: Nicely written lecture, but with no basis it's sadly just a waste of time, especially as it gives you the wrong ideas how stuff works. Sorry. The article is from 2013, I hope he learned a bit more in the meantime and if not and reads this post takes it as constructive criticism and not an attack or anything! I know you can force the format, but I just cannot recommend using uncompressed but instead just increase the texture size (size of a 16x16 uncompressed block is 512 bits, with dxt it's 128, so you can have a 32x32 that takes up the same space which means you can get more details and less artifacts for the same size). I can only recommend using uncompressed formats for the UI, nothing else. One note: regardless of compression diagonal lines are always a problem, because of rasterization and resulting aliasing, esp if you zoom in more. As an artist one should try to have all edges aligned to be either horizontal or vertical if possile, this will reduce issues 100%, if completely horizontal/vertical, even if fully zoomed in. Most games do not support the dxt normal map thingy as it's mostly just a pain in the butt for negligible results.

I don't know this tutorial but from what you're writing it sounds a bit crappy. The compiler will convert your textures into DXTn anyway, and if nothing set it will probably default to DXT5, so you should just export them in the DXTn format directly. DXT color compression is always the same. DXT1 has 1 bit alpha per pixel. DXT3 has 4 bit alpha per pixel. (for sharp edges in the alpha) DXT5 has 8 bit interpolated alpha per pixel. (for smooth gradients in the alpha) DXT1 is 64 bit (8 byte) per 4x4 pixels, and the smallest. DXT3 and 5 are 128 bit (16 byte) per 4x4 pixels.

Probably a detach special power, and a state toggle for autoheal/no autoheal

One thing that you didn't try/show but what I am quite interested in: can you still move the apc/engineer that is currently healing something away or is it in a locked state?

Have you tried LeechRangeWeapon?

You don't cast the special power on an object, so it either wont go off at all or it goes off at the Corrupter itself. Dunno if it works but try ObjectDoSpecialPower(self, "SpecialPower_CorrupterGetIntoRangeHealBlast", requester) or something. Also from the way you've set it up it looks like the unit who wants to get healed is the one firing the SP.

Wander AI works, at least if its a somewhat small range. The system in BFME was to have a sort of burrow which spawns creeps that wander around it. I have one of these with a Tiberium Fiend in TW which works flawlessly.

the apt format is the same for kw and tt so it will work on them too, maybe have to make sure first, so far I just tested it against the tw and ra3 files as the swf were released for them at some point (and tac files which I used to validate action script). For both projects: my time is quite limited because of my job, personal stuff, and me just wanting to relax and play a game/watch a tv series. At least I'm not depressed anymore.

1. Iirc that was one of the last things Apoc released, dunno if even publicly.

Btw lately I spend a bit more time on AptEd, so it might be that you see something like that in about 6 months

I see, yes what Raven said. You can simulate the behavior by linking the end vertices of your hydraulics to the right bones (recoil and pitch, the "lookat" thing basically does that anyway it's just the inverse calculation). Don't forget you can set up 2 bones per vertex and give them weights.

Dunno what you mean by LookAt constraint.

Well one could finish an editor in a few weeks, but rl stuff is preventing me from having the energy to do so, and probably no one but me will. jonwils rudimentary apt2xml and xml2apt could work but it has a few flaws and bugs. Also you would have to script the action script stuff on a byte level.

BFME is quite the same, trust me. It had a lot of Generals behaviors removed etc, some were reimplemented for BFME2 to support mods (like the TankDraw) but they still have bugs (like the TankDraws barrel facing into the wrong direction and that was mostly unfixed in TW). BFME doesn't really have more options, but different ones. Though I'd say even with a few modules not working TW has the most options (actually TT but no one did a tool support that yet).

At the moment: not at all It can read most of the files but there is no display/edit/save functionality. I actually messed up - the binary files shouldn't even be uploaded. I linked it more for you to maybe take a look at the source and see the data structures as it's not just simple coordinates..

They are a lot more than that. Esp the ActionScript part is a bit harder. The most complete version of AptEd (though I was starting a new one to refactor it but hadn't had the energy to continue): https://github.com/Qibbi/AptEd.

It made sense in BFME, but it didn't carry over quite as good for TW imo.

1. Loadscreen images are set in the aptui, but there's no real editor for it. 2. Rather use a status like USER_X. 3. It is used in the score screens, with a aptui editor one could add it to the skirmish menu too.

Yeah, sadly. It can work manually if you place both squads REALLY close to the container, but there is nothing you can do to fix the actual problem. You can get rid of squads though as single units work like a charm.

Oh right, I didn't touch AI stuff for KW, was quite exhausted from the hundreds of behavior files Still my comment holds true for his case

You are viewing only the entries in the static_common_2.manifest, the files you are looking for are in an older version. If you want to extract stuff I suggest loading a skudef, not a big. This will load all assets in their most recent versions. And no, no hashes involved. The manifest file is a list of all assets in that stream. The entry also defines the length in bytes of the asset, as the binary length is 0 here it means that the asset is not in the corresponding bin file, thus it's loaded from an earlier version (load skudef loads all manifest and version files and connects them).