War2.ru Slogan
News: Back by popular demand, the SMF Arcade!!!
PLAY NOW!!!!!!!!!!!!!!!!!!!!!!!!


Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
Welcome to the forums! We're glad to have you here! :) You can register your account here, then feel free to introduce yourself in the Server.War2.ru board & let us know who you are on the server.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Lambchops

Pages: 1 ... 105 106 [107] 108
1591) Mods & Development / Re: Color palettes in channel, tilesets, screenshots, etc.
« on: September 22, 2016, 02:05:38 AM »
      The return of  The Gigantic Gob    ( queue Scooby-Doo scary music now )



WARNING: Great big nerdy post ahead... continue at you own peril...


Why is there a gigantic gob of....

So, I've been having a look at the extra colors that are added to the channel palette for the banner ads with regards to using them for channel icons.

Some of the stuff I have been talking about with regards to this I have just been assuming based on the results I see being rendered in glorious 8-bit color on my monitor. Understanding how graphics hardware works, there can be no doubt about what is happening (things weren't too complicated in '96), however not having access to the server I could never actually try any of it out. After a recent conversation with Mousey (thanks for your help with that =) I now realise that some of the steps that I was assuming were happening server-side are actually being performed automatically by the client, I suspect in battle.snp or maybe storm.dll. Most notably the color matching.

if you want to take a picture from a bitmap with one palette and display it using another palette, you have to do color matching......Get a SS from the channel. This is an 8-bit palette base pcx file. Convert it into a .BMP file, but make sure it stays 8-bit
...etc

This is stilll a good idea because you will be able to see exactly what your icon will end up looking like, and you won't wate your time designing with colors that just aren't there when it eventually hits the screen, however it turns out that when the icons leave the server they aren't 8-bit palette images at all, they are sent as full 24-bit tga files. So the color-matching must be happening client-side.

The same process takes place, but unfortunatey it's being done automatically somewhere in one of the code modules loaded by the exe. This is nice programming from our friends at Blizz - saving extra steps for themselves later on when developing new stuff as bnet progressed, but sadly for us, it takes away the extra control we might have had by doing it manually and then just sending the finished product to the client.

Mousey tested this out, and despite the fact that the channel screen gets a whole gob of new colors from the banner ads, it seemed the icon color matching refused to use those entries. This puzzled me for a bit, as it would seem to be masive overkill to write in checks that deliberately rejected a certain range of palette entries from the color matching 'just in case' someone at blizz got a bit confused designing icons sometime. So why do it?

Well, maybe one of the programmers was just really anal-retentive and did it anyway...OR... as it dawned on me a bit later (duh) theres a much more likely reason why this is happening: --> As the icons are being served as 24-bit images, then it seems they're mixed down to the 8-bit palette when the client is constructing the channel screen from its various components, then it makes sense that a similar thing is probably happening with the banner ads, only the banners get a much more personalised color conversion, which allows them to import up to 64 new entries into the palette.... and again this would be done automatically by the client.

So... what it seems to me would be happening is: when you log in and the client constructs the channel screen, it starts off with the 'standard' palette that is hard-coded into the exe (or for the channel more likely one of the lib modules) which includes the infamous Gigantic Gob of 64 blank entries. Next the icons are imported and color matched to the existing palette, then finally the banner is imported and the extra palette entries are added. The icons are never matched to the extra palette entries, because at the time the icons are imported, those new entries still havn't been added.

So where does this leave us for extra icon colors? Well unfortunately it seems it would have to be some sort of war2combat client mod, no way around that. Maybe if we're lucky we could get away with just a simple war2patcher mod or perhaps something a bit more substantial would be required. On the face of it, you could easily just overwrite The Gob with a bunch of new entries at its source, then they would already exist when the icons are color-matched and hey-presto... more colors. That's all well and good until the banner loads, at which point it overwrites those entries with it's own and the colors go bleh.

So we can cheat and use the palette from the banner, so the correct entries from the banner are already there so when it overwrites them it does so with exactly the same values and everything works. Cool... well thats if you never want to change the banner, because as soon as you do, the palette changes and we're back to bleh again :/...

Lambchops scratches his head.... thinks hard (ouch)... then scrambles for the mouse and pulls up a SS with a colorful banner ...


Cool. So i just did a quick crop of just the banner part of a SS, then pasted it back onto a reduced size 8-bit bitmap saved that, then loaded it with Irfanview and it says: "63 unique colors." Nice, so it looks like the banners only use their extra 64 colors (I probably cropped one off at an edge somewhere) and they don't do any color-matching to the standard palette entries. This means that if the people waving the banners are happy settling on having only one palette, we can write that in to the client they can still change the banners without messing up the icons.... Maybe.

Yeah there's always a maybe. The other problem that might occur is that by rights, according to the official specs ... certainly for .bmp format.. and possibly for others as well... palette entries are supposed to be ordered according to their frequency of use... i.e. if your picture contains a heap of a certain shade of green, then that color should be placed at the start of the palette, followed by the color that has the next highest amount of pixels using it, right down to the color that is only used for a handfull of dots at the end. The theory being that this reduces cpu usage as the rendering routine doesn't have to search as far through the palette to locate the colors its more frequently using.

In practice it's such a tiny amount of data anyway that it really doesn't matter in the slightest, and many libraries don't bother doing it............If you still don't know what im referring to, 'it' is the process of, when saving or constructing a new palettised image, going through each unique color that occurs in the image one by one and counting up the number of pixels that use each of those colors, then resorting the palette entries according to this associated frequency data .......So if Captian Anal was programming that bit, there's a chance that even if a new banner contains all the same colors as the old one, they might possibly end up in a completely different order..... and we're back to bleh again. But I dont think this is a big chance, its far quicker and easier to just copy the imported palette straight over The Gob. Anyway it's something that's relatively easy to test.

But REALLY what we want to do is have the client just load the banner ad first, then load the icons after it, and everything would be fine. At first thought that didnt seem too hard - these processes would undoubtably be written as seperate subroutines, then we could just put a debug watch on the memory addresses where The Gob lives and track down the instructions that write to that location, then its relatively simple to trace it back to the call that enters that sub. The icon matching might be a little bit trickier to find, but once we have those, just exchanging their call targets so that they are executed they other way round is easy-peasy.

Seemed like a nice idea for about 1 minute before the obvious smacked me in the face (story of my life). Problem is that this stuff is part of a conversation between the client and the server, and its very unlikely that the client receives all of the info from the server and piles it up in a great big heap and then starts processing it... that would be very inefficiant and make it a resource hog... most likely each section of data is received from the server and processed on-the-fly ...first it gets icons.bni which is then processed into whatever format the client ends up using it in at which point the client is finished with it, then the next bit - maybe the banner, or the list of players in the channel, or whatever - is received and it overwrites the received copy of icons.bni which is still sitting in the input buffer. So if we wanted to change the order that these are processed in we would have to either:

a) Change the order that the server sends the info to the client  or  b) allocate another buffer and make a backup copy of icons.bni then replace it in the input buffer later on before we call the color matching subroutine.

Method a) would, at worst, require modding not only the client but also the server (yuck.. bugs... headaches... crashes... stuff that), although depending on the actual structure of the client- server conversation, it could be as simple as just getting the client to request the various bits in a different order, and the server might happily comply without a care in the world. If we we're really lucky the network requests from the client might be housed in the same subroutine as their relative graphics importing code and we're back to the simple switcheroo again. But thats a lot of maybes, and a lot of tracing, debugging and swearing at screens full of disassembly to even start testing the theory.

Method b) is technically a bigger mod as it would be actually adding new code to the client, but allocating a buffer and copying a bit of data back and forth is pretty basic stuff and would probably be quite painless to insert, however to get there you still have to do a whole pile of debugging to find the right places to put it.

.... and then there's the cheating method. Just an idea, but one way to avoid the whole client- server transaction and image import routine head-fuck is just to sneak a little bit of code in right at the end that simply saves the 64 entries that make up The Gob to a disk file then have the war2patcher or something write those in when the module is first loaded. The only drawback would be that when the banner is changed, the first time you log in the icon colors would be bleh, but it would only be a matter of exiting out and restarting , and everything would be perfect until the next banner change.

To continue thinking about this I need a bit of info on how the banners are produced. What format are they in when they server sends them to the client? The .bni writer doesnt seem to have anything to handle banners so its some other related format? Are they 24-bit when they leaves the server or already paletised?.... anybody?

1592) Mods & Development / Re: i'm back!
« on: September 19, 2016, 03:23:47 PM »
was not expecting to find that in this spot....fucks that number mean tupac lol gave me 2 extra units before farm kicked on.
https://www.experts-exchange.com/questions/23061795/Binary-32767-32768.html

-1?

it is negative one lol,each townjall erases and also +1 so 2 extra units :P look at the cpu!!!


Maybe I can help with this. Here's some info. Theres actually a very simple method here
for working out signed integers, and, because I'm me (sorry) also a whole pile of related
info that you may or may not find useful.. or may already know.. do with it what you will.

-------------------------------------------------------------------------------------------

It really helps if you're trying to get your head around signed binaries to just ditch decimal.

Decimal if great when you're counting with 10 fingers, but pretty much blows for anything
binary based (i.e everything to do with compters).

Use Hexidecimal. The shit actually makes sense in hex.


BYTE:
Decimal: 0-255,        256 possible states.
Hex:       00-FF         100  possible states

WORD (or SHORT):
Decimal: 0-65535,      65536 possible states
Hex:       0000-FFFF,   10000 possible states

DWORD (doubleword):
Decimal: 0-4294967295,          4294967296 possible states
Hex:       00000000-FFFFFFFF,    100000000 possible states


......etc
Clearly one of them is much easier to remember than the other.


If your value is being interpreted as a signed number then yes,... blah blah blah
... bit 15 is being used as a sign bit (for words, or bit 31 for dwords.. etc)  but then is it
"(n/2)-1 thru minus (n/2)"? or was it umm err plus one ... and the... um....

OMFG. No. Computers work with very simple concepts, we just make it difficult
because we have the wrong number of fingers for the job.

In HEX:

for a 16-bit ('SHORT' or 'WORD')     signed integer, the value "-1" is  FFFF
for a 32-bit (DWORD, doubleword)  signed integer, the value "-1" is  FFFFFFFF
for a 64-bit (QWORD, quadword  )  signed integer, the value "-1" is  FFFFFFFFFFFFFFFF
.......
(and yes if anybody actually used 8-bit signed binary ints it woud be FF)

they count backwards from there...
so for a 16-bit number:
       
              -1     =     FFFF
              -2     =     FFFE
              -3     =     FFFD
              -4     =     FFFC
              -5     =     FFFB
              -6     =     FFFA
              -7     =     FFF9
              -8     =     FFF8
              -9     =     FFF7             .... etc


Here's the good bit:
YOU REALLY DON'T HAVE TO UNDERSTAND HEX TO USE IT FOR THIS.
Just do this:

Pull up the windows "calc" calculator or anything else that will convert hex to decimal.
... for calc you need to select 'scientific' mode from the 'view' menu ... at least in the XP
version I have - probably still the same in others.


Work out how many bits ur using... most likely for WC2 it will be 16 bits, 
perhaps 32 for some things.

Ok divide that by 4... easy
this is how many zeros you want.... as in the table above.
 i.e.   WORD - 10000   DWORD - 100000000

16 bits - 4 zeros
32 bits - 8 zeros
64 bits - 16 zeros  ..... etc

Lets try a random example... say  -7629, just for lols

so .... if you want to know how to represent the number -7629 in a 16 bit signed integer
DO THIS:

     1 - first select HEX MODE
     2 - THEN enter a 1 and 4 zeros "10000"
     3 - then select DECIMAL mode
     4 - then enter your number and press '='
        ....... so in this case press [-] [7] [6] [2] [9] [=]
theres your answer:  "57907"

----------DONE---------

Note: that's the [subtract] button, not the [+/-] sign
button, you are just subtracting the absolute value.


If you want you can convert it back to hex, then its: "E233"

In the actual CPU or RAM or on a bus or a disk drive then its
"1110001000110011"

These are all the same number, the only one that's real is the last one.
The other two are just ways funny hairless apes like to think about numbers
because it suits their funny brains.


NERDS CORNER:
If, like me, you're a bit on the nerdy side, you may have wondered:
"if 57907 is 1110001000110011 and that actually equals -7629..
then how can we represent the actual number 57907 as a
16-bit integer???"

Well, 57907 is processed as 1110001000110011, yes, it's exactly
the same number. How can this be? Well everything in a binary
machine is ones and zeros.... "1110001000110011" could also
represent the position of 8 black pixels in part of a monochrome
bitmap, virtually any other type of information that can be processed
by a computer. It's up to the program to know where it wants to get
the ones and zeros from, and what type of data it is that it is getting
(then it has to decide what to do with it)... and thats the whole gig.

If its looking for a 16-bit WORD and it gets 1110001000110011 then it
says "Oh thats 57907". If its looking for a SIGNED 16-bit integer
and it gets the same 1110001000110011 it says, "Oh thats -7629" - or
if its a bitmap it says "thats black - black - black - white - white - white -
black - white - .... etc"

Carefull of this bit - maximum nerdage:
The actual CPU etc. doesnt say "oh thats..." anything at all, it just has the
ones and zeros. Its 1110001000110011 period. The system works that
way, because in a 16 bit CPU, adding 57907to a number gives you eaxtly the
same result as subtracting 7629. The answer is the same sequence of ones
and zeros. The CPU doesn't know or care if it is adding on 57907 or adding
on '-7629', the result is the same. In the end the program knows if it wanted
a signed integer, an unsigned integer, black and white spots, a floating point
number or a string of neucleic amino acids, and it knows what it wants to do
with that info... because thats what a program is. The CPU couldn't care less.
Neither could RAM or a disk drive or whatever...    which is the stuff you are
manipulating to make your patch. Obviously to manipulate the data, you need
to know what the program expects to find, and what it wants to do with that
data - only then can you know what to change in order to get the result you
want.


BTW: You may have realised by now that the internal graphics format you are
tweaking is an old Blizzard propriatory format called GRP. I think I gave a general
description in one of my posts about PCX palettes or there abouts.

 :)



Oh, and one more thing....

I expect you should already know, but if you are directly manipulating data in a file
or volume with a hex editor, the you need to be aware that our funny human brains
are used to seeing numbers with the least signifigant value at the right..
i.e  539

5 = 500
3 =  30
9 =    9

Most data storage (and certainly all the stuff in wc2) is the other way around. To
further confuse the issue, hex editors have evolved to display data 8 bits at a time
which = 1 byte = 2 hex digits.... 00 thru FF.

A 16-bit number as we now know, has 4 hex digits - or 2 bytes. Most of the internal
values in the wc2 game engine are either 16-bit or 8-bit. However the exe is a 32-bit
PE file (M$ Portable Executable) so all of the values related to the exe as an object or
memory addressing etc. are all 32-bit values, which of course have 8 hex digits or 4
bytes.

The hex number 5D79 (dec 23929) is a number arranged exactly like a decimal number
except hex uses 16 digits (0123456789ABCDEF) instead of 10 digits (0123456789),
however the layout is the same - least signifigant on the right, each column to the left
having a value that is the equivalent exponent of the number base being used.

Our trusty hex editor - still presents everything as it was back when the world was made
of 8-bit numbers (flared trousers anyone?) The Byte. So every 8 bits was presented as
a hex number. Little digit on the right, big digit on the left.

But..... as we are directly manipulating the data as it exists, when we come to larger numbers
(16-bit...32-bit..etc.) we find that they are actually stored the other way around i.e. the with
the smallest part on the left through to the largest on the right, however, each pair of 2 hex
digits is still being 'conveniantly' presented to us as a 'correct' hex number... which is actually
backwards... SO

If we want to directly read or write data larger than 8-bits (1 byte) with a hex editor, we have
to rearrange it - but only in groups of 2 digits. On disk, our hex number 5D79 is actually stored
as 2 bytes like this 79:5D ... the order of each byte is reversed.

YES! Fellow nerdlings!... thats not true either we all know that its really just stored as a bunch
of ones and zeros... but thats the way a hex editor displays output and accepts input, so that's
what you will be using and seeing,... but really, its just another one of those kooky ways the
hairless apes decided to do things, because we just love to make life easy for ourselves.

The same principal applies to a 32-bit value.... take a random 7EE9D123. On disk or in memory,
we represent this as 23:D1:E9:7E ..... in practical terms split it into groups of 2 digits then
reverse the order.

        7EE9D123

---> split into bytes

        7E - E9 - D1 - 23

---> reverse the bytes

        23 - D1 - E9 - 7E

           ^^^ And there we have it


Same for our 16-Bit value

        5D79

--> split

        5D - 79

--> reverse

        79 - 5D

**BUT**
==>Remember to make sure you have the right number of digits to start with!


i.e.  I want to write then number 2016 as a 32-Bit (DWORD) value on disk:

2016 decimal = 7E0 hexidecimal

but its 32-bit, so we want 8 digits = 000007E0   (just like 00002016 = 2016 )
 now we have 8 hex digits we're good to go:

         000007E0

         00 - 00 - 07 - E0

         E0 - 07 - 00 - 00
      ^^^^^^^^^^^^^
This is how a hex editor would display the number 2016 stored
on disk as a DWORD


....and if it isn't stating the blindingly obvious when you see something like:

0x6F34

the '0x' at the start just means "this is a hexidecimal number", because of
course '1234' is a perfectly valid hex number as well as a decimal number.
0x1234 = decimal 4660....... indeed 101110011 is a vaild hex number and
a valid decimal number and a valid binary nunber. Time to STFU before I start
talking about octal....











1593) Server.War2.ru / Re: Just get hacked by dellam.
« on: September 19, 2016, 01:07:19 PM »
Re: Just get hacked by dellam.
« Reply #33 on: Today at 03:21:10 AM »

cant believe a grown man has been doing this same shit for years now.  dellam youre so beyond being a merely a loser at this point that im guessing you have some actual, literal mental problems.

Sentinel
Wtf r u talking about .../...Why r u saying that for?

Can't speak for Sent, but I'll try to help out. I've given it some thought and I believe he's saying it because your a hacking loser with mental problems. Perhaps not though. Maybe he's just talking shit because you're such an annoying dick, and the rest of it was just a lucky guess....


1594) Server.War2.ru / Re: Dellam breaks the tard barrier!!
« on: September 19, 2016, 12:41:39 PM »
Dellam got that "shit on your chest and look for corn" line from ownage pranks.

Yeah but it was the hand-holding that really creeped me out.... eww

1595) Server.War2.ru / Re: Dellam breaks the tard barrier!!
« on: September 19, 2016, 12:32:12 PM »
Yep that was me , I caught itmustbelove hacking in ch0ppy's game . Several of us saw it and he tried to turn it around .

Antihack doesn't lie



OK Here's just a few of the things wrong with this:

1) You're a dick.
2) You're a complete dick.
3) OMG what a dick.
4) You are NEVER in ch0ppy's games because when you join, he bans you instanly. Partly for being a known hacker, but mostly for being a total dick.
5) Your head.
6) I still use my original wc2bne CD not war2combat so obviously, you're a dick. ( and I will post SS any time NP - like this one http://ss.war2.ru/ss/8992.pcx )
7) You're an ugly, creepy dick.
8 )How the hell do you know I ate corn yesterday? Are you some kind of weirdo stalker too?
9) Did I mention you're a dick?
10) Who is "several of us"?... you, winchester and your the rest of your imaginary friends?
11) FFS stop using our oxygen.


I normally don't bite on such obvious trolling, all the regular players are used to his crap, but he actually had some hapless noob believing him for about 10 minutes today.... until they both joined ch0ppy's game, and the dick got instantly banned xD

The real question is: why did he join? Seriously WTH? he knew he was going to get banned, and that everyone would just say "He's a dick", then the noob would know he's a dick, so why do it? Best guess: he's so pathetic that he actually likes being know as a total loser dick. It makes him feel special.

It's OK Dellam, you are special. You are so very special. You're a complete dick. Nobody can take that away from you. You don't have to keep proving it. Everybody who has ever met you knows that.

... now about the oxygen: you've had your share. Please cease and desist. Dick.


PS if anybody hasn't worked it out ItMustBeLove is my old AKA I use sometimes....

1596) Server.War2.ru / Dellam breaks the tard barrier!!
« on: September 19, 2016, 09:14:39 AM »
Im not easily offended ...but

WTH?









>Now ......
>I wasn't hacking
>I had the anti hack running
>I was hosting standard gow

>So, lightbringer- why was I banned?


Good question. Would you like to phone a friend? Oh ....  that's right. Sorry mate.

But seriously dude, I thought they just banned u for being a dick. They need a reason u say?
 .... Interesting theory.

I love your little recommendation. I can just see everyone scrambling to do what you tell them to xD
but I'm sure LB is very glad u posted this, at the least he would have got a big hi-5 from the other
admins. Next time I see him I'll thank him for doing his job and keeping an eye on things. Good man.

You should write to Uthar Longdonger, that dude's pretty badass. Kick's butt for justice an' all that.
I'm sure he'll stick up for you. Or maybe the tooth fairy, or is there a patron saint of rangas?




1598) Server.War2.ru / Re: I found these whilst being a loser as per usual
« on: July 31, 2016, 03:49:03 AM »
Verily. Whilst browsing yon gaming server on the week of last, happenstance colluded to thrust before my countinance the old familiar vista, of a scrubbeth hacketh try-hard... And tho my mouse hand close to blister and the hour of sleep well past I did don the garb of small and blue and joineth by his hearth.

Wonder oh I wonder do, just why the order fixeth, and chopping on ef was such astounding mental trixeth. Twas orcish that I parlay'd but when start the trial scrub did, a whimsy overcame to exchange my homonid,... for another creed that seemeth viewed a  trifle more refined, not so common or distasteful but with brilliant armor shined.

But imagine if thou caneth how astoundeth my surprise, when the scrubbeth hacketh try-hard held exactly the same mind! Wouldst I could recalleth such uncanny co-event, for at the final moment both our colours went, from tusk and claw and axe and evil necromancy's spell, to the valiant, couth and civil, just delightful, Oh let's shall! I choseth mine a sapian, all know the scrub's a homo, who would have though these two of cheese and chalk would play in slow-mo?

But, dear LORD, I could not grasp, thy cunning machinations, for the pace of snail and garden had been terribly hastened. What a stoke of luck, for hadeth not my absent whimsy guided, I would surely have worn tidings from fell scrubbeth so derided, scribing of its sadly misplaced ego's ever fettid drool, using just one hand, the other firmly clasped around it's tool. But yet again he read my mind. How so this mental runt? Just a single word was mustered, it managed nought but...

Shit I can't even remember I was lol so hard. Why don't you talk like a human being you goit? ...and seriously, does anybody really fall for that rigged map crap? I used to have one of those t-shirts. If I find it moving house I'll burn it just to avoid any association.

>>>>>FUN SEARCH guess who that only other person on this forum is who says "whilst"?      bahahahahaha xD

1599) Flame Wars & Offtopic / Re: Meet deelam
« on: June 07, 2016, 03:22:49 PM »
Lamby lives in Australia, you meeting dellam lamb?

He specified Melbourne sydney or Perth. I live in QLD. Nearest is Sydney, about 850 km (528 miles).

Tempting as it is, a 24 hr round trip just to get charged with assault isn't really on my to-do list ;)

warbandit or quick might be able to make it....

nice work...i was in 24 bit bmp maybe why i couldnt get the .pal...u into making grps? u seem very keen in the paint stuff.

Happy to help if I can, but I must confess I'm not much of an artist. My interest is far more nerdy than that lol, I understand the internals of graphics containers as a by-product of programming, it helps to know if you want to display pics. I just did a quick prog to pull the palette info out of a pcx and make a bmp.

For the nerds:
grp is an interesting one, its an in-house blizz format. I think its main purpose was to have the graphics prepared for those 1995 486s to blast all those super-flash new graphics onto the screen :) its pretty cool, from a programming angle: each line of pixels is pre packed with a variable offset and length, so the processor only has to go to the exact spot it says to and then squirt out the exact pixels that are there.... very efficiant. Isn't that what normally happens? yes and no, often when you used to have a 'sprite' situation like this where you have to draw a little picture (say a grunt) over a background (grass or whatever) you might have a pic of a grunt which is actually rectangular, with a color (often color 0) designating transparancy. Then the processor has to decided whether or not to draw each pixel in the whole rectangle. grp has just the pixels it needs, and all the possible info that can be calculated before time. Its cool......... Of course these days that sore of stuff is done in nanoseconds by multicore GPUs, but it was neat work back then. Before modern graphics cards CPUs could spend 60-90% of their time just pushing pixels around.

Why is there a gigantic gob of the same shade of green in the channel palette lamby? It seems like such a waste. Is this something that could be changed?

Hehe. Very easily apparantly. I was just going to write my theory about how it might be space for custom colors for the banner ads, but I just looked....

Yep sure is. No surprise to at least one person around here lol. Presumably the bnet client part was made to download the palette entries with the banner ads when you log on... or maybe theres a few built in palettes to choose from idk.

I took that palette from an old SS that's just got the big blue and gold "WELCOME TO BATTLE.NET" baner, however with the current 'summer festival' there's a bunch of new entries there. Cool :)

So, we should ask whoever puts the ads on the server how it works ... blid i spose

and I got to say, having a summer festival now is pretty silly cos June is in winter...  ;)


1602) Server.War2.ru / Re: OGREMAGE:
« on: May 22, 2016, 08:00:50 AM »
.... is it just me, or did the guy with the Neil Patrick Harris quote pinned to his avatar just call somebody else a fag? xD





1603) Server.War2.ru / Re: icones news me creating
« on: May 20, 2016, 01:44:01 AM »
Anybody doing icon stuff might find this useful. The complete set of button graphics, including some that never made it into the game...

http://forum.war2.ru/index.php/topic,1006.msg37872.html#msg37872

1604) Server.War2.ru / Re: icones news me creating
« on: May 20, 2016, 01:41:22 AM »
Dellam is a hardcore hacker, he knows DOS commands.

This is a good point, should say "hack user" its dis-respectful to hackers.

Same reason I don't call him a cockroach. I hate roaches, but not that much...

Oh here's the original button tile graphics. If anybody needs them. Pretty sure I pulled them from a memory resident mpq, but it was a while ago.

There's a few extras that never made it into the game. Check out the horses and wargs. I thought maybe there was and idea in the original design to produce horses then put a footie on them to make a knight or somesuch, but their position in the order of tiles suggests these were upgrades, like ranger/beserker upgrades only for knights and warg-riders? ?

Not sure what to make of the little spell icons that come straight after the orc shield upgrades, perhaps they were and original design for the little on screen unit spell markers, like the little blood droplet for lusties.



Pages: 1 ... 105 106 [107] 108