.map in the correct directory, but no bsp.

fishy said:
but the thread strays a bit, so i may be reading that in the wrong context.

it does? never noticed that occurance around here before

seriously though, i didn't follow this thread, but.. even though i use steam, all i had to do was tell HLCC where i wanted the stuff to go.. in this case ".....half-life\valve\MAPS".. where all mappers should put them to play :smile:

Orpheus said:
seriously though, i didn't follow this thread, but......

true, true. you only accounted for 5% of the posts this time.

fishy said:

Orpheus said:
seriously though, i didn't follow this thread, but......

true, true. you only accounted for 5% of the posts this time.

remind me again why i like you,fishman :wink:

why don't you do something constructive, like learning your BBCodes :heee:

/runs

Orpheus said:

fishy said:

Orpheus said:
seriously though, i didn't follow this thread, but......

true, true. you only accounted for 5% of the posts this time.

remind me again why i like you,fishman :wink:

why don't you do something constructive, like learning your BBCodes :heee:

/runs

Only I am liked by Orph enough to be on his piss list. :biggrin:

Fishy, when I first wrote that 'tutorial' the only sure fire way I could get Hammer to compile the maps while making them for steam (I know this SHOULDN'T matter) was to place the rmf's in a specific location. Hammer (or something) tends to rename your map to your email address, and places the files within the SteamApps directory.

It failed almost every time I placed them somewhere else, no matter where the final map directory is.

That's the only reason why I suggested it.

1024 kilobytes in a megabyte. 1000 kilobytes of every megabye are useable. the extra 24 are used for parity. Computers do effecticly count in 10's, in that respect.

xconspirisist, are you sure about that? It just sounds wrong... What exactly is this "parity" you're talking about? And does this extend further up or down? (i.e 1 Kilobyte is just 1000 bytes, with 24 lost, or 1 GB is just 1000MB, with 24 lost. ) If it does, it doesn't make any sense at all :/

1 Kilobyte is just 1000 bytes, with 24 lost, or 1 GB is just 1000MB, with 24 lost. If it does, it doesn't make any sense at all :/

No, this is pretty much what happens. Because the size of space 'counting' goes up to 1024, but those prefixes only allow 1000, amongst other things.

All pieces of memory go to 1024 in physical size (as physical as electronic memory gets). So, yes, 1 Kb is 1024 Bytes. and 1 Mb is 1024 Kb. not just 1000.

Very strange, I never heard of that before. What are these prefixes for then?

These prefixes are old, man. They've been used for more then 200 years, well most of them anyway.
They just used them mostly because the people were probably familure with physics (you have no idea how much 'physics' knowledge was needed to create what is now known as a computer), however, I don't understand why they won't just count to 1024, and it wouldn't have been too hard to begin that way, oh well.

When talking specifically about hard drive space, Windows is the only one to do this, because other OSes allow you to define the cylinder number you want something to reside at and such (when making a partitian of course).

Also, imagine having to say "I have a 515396075520 bit drive." as to "I have a 60Gb drive." Or something as such.

Crono, you remind me of the sort of IRC newbie that bashes microsoft all day, and bulls**ts about stuff they dont know about, yet you have windows and office installed.

They are suffixes, not prefixes, in a sense. Partity is a form of validation. Those that want to know how it works, pull up a stool, I think this is going to be a long assed explination.

Computers store data using a thing called binary. They have been doing this even before orph was born. :smile: If you want to know how binary actually works, go find google. But just accept that computers use binary instead of the alphabet to store data.

This is the letter A, as a binary digit : 01000001
This is the letter B, as a binary digit : 01000010
This is the letter C, as a binary digit : 01000011

You get the idea. When you look at a binary digit, you can see that it is comprised of 8 numbers. Now, in the good old days, computers used things like card, and oil, stuff like that to remember data. Data bits were either set to 1, or 0. If the computer was using card, it would see if there was a punch in the card, if there was, that bit was 1, if not, 0.

Now, the whole confusion over parity.

You have a binary word; snarkpit. Translated, this is;

0101001101001110010000010101001001001011010100000100100101010100

I used a binary translator. :smile: http://nickciske.com/tools/binary.php

So, the word snarkpit is being read from a card, oil, valves, hard drive, whatever you're generation. On you're hard drive, what happens if there is a eeny weeny something crawling across you're hard drive, or your hard drive gets dirty, etc, etc. The idea is, the read may read a 1, instead of a 0. This f**ks things up.

Look at the first number from the binary translation of snarkpit. It is a 0. Imagine if it was a 1;

1101001101001110010000010101001001001011010100000100100101010100

This now translates to ?NARKPIT. Wild eh ?

Parity, is designed to prevent this error. back to the letter A; 01000001.

Count the number 1's in the binary digit. There are two 1's. Wonderous stuff. Because it has two, the binary digit of A, is said to have 'even parity'.

The letter C, has odd parity, because the letter c; 01000011, has an odd number of 1's.

When I said that binary digits are made from 8 numbers, I lied. The data is stored in these 8 numbers, but binary now-a-days, is made from 9 digits. The 8 digits that contain the data, and a thing called a parity bit on the end.

'A', has even parity; 010000011

The extra bit on the end, means that when all the 1's are counted, it should be even. If odd parity is expected, like in the letter C, a 0 would be put on the end.

Here is our ammended table...

This is the letter A, as a binary digit : 010000011
This is the letter B, as a binary digit : 010000101
This is the letter C, as a binary digit : 010000110

When the reader on a hard drive, goes to read the 9 numbers in a binary digit, it will check the parity bit, to see if the last 8 numbers, the data, was correct.

What happens if the parity bit is incorect ? well, shame. The chance of a parity bit being wrong, is 1/9. which is actualy quite unlikly. sometimes, things like hard drives and modems are able to correct binary digits from parity, but I am not sure how this works.

Now i've piffled on about parity quite a bit, so I may aswell piffle some more. When you get a lot of binary digits, they need to be grouped, its just a way to orginise things. This is a big long list of the 'groups', which you have almost definatly seen before in file sizes.

binary / byte
bits ( 8 bytes )
kilobyte ( 10 to the power of 1 )
megabyte ( 10 to the power of 3 )
gigabyte ( 10 to the power of 6 )
terabyte ( 10 to the power of 9 )
petabyte ( 10 to the power of 12 )
exabyte ( 10 to the power of 15 )
zettabyte ( 10 to the power of 18 )
yottabye ( 10 to the power of 21 )
nonabyte ( 10 to the power of 24 )
doggabyte ( 10 to the power of 27 )

And its as simple as the parity going up this scale. :mrgreen:

And what exactly happens because of this parity bit? Assuming a 32 bit word length, by your theory, every word is actually 33 bits in length with one parity bit appended somewhere. So in 1024kb of memory, only a 32/33 fraction is available to be used, (which is a recurring decimal) which is definitely not 1000kb.

xcon, this is convincing me less and less, mostly because
1)It sounds completely and wholly wrong, unless you've missed a hunge chunk of info in the middle
2)AFAIK, it is now the CRC technique used to detect errors. Parities are not easy to handle at all

Anyway, this isn't going anywhere, seeing as I am not likely to trust any info unless its from a very reliable source like a textbook or a whitepaper of some sort (no offence or anything)... Do you have any links or books where I can verify this?

google.com - parity. My info isnt right from a textbook, its from my head. Its not a topic I talk about everyday, so you're welcome to pick it apart.

This thread has gone completely off-topic, but I'm not interested in parities. I want to know if 24kb from every 1024kb is actually lost (and if it is, it might not be just because of parities). AFAIK, it isn't.

Anyway, this isn't going anywhere.... I suppose I'll just go look for it properly

Heres more off topic goodness :razz:

xconspirisist -

You're = You are - the apostrophe replaces the a

Your = As in "How is your cat?" - your implies "ownership"

So, for example, this sentence:

whatever you're generation. On you're hard drive, what happens if there
is a eeny weeny something crawling across you're hard drive,

Should read like this:

whatever your generation. On your hard drive, what happens if there
is a eeny weeny something crawling across your hard drive,

It's a common mistake, but its also one of my pet hates. It is also
infinitely more noticeable than other common language errors (eg
spelling "environment" without an n). Just so you know :smile:

Also on the subject of OS bashing, i think the point is more FAT32/NTFS
are really, really bad filing systems, compared to the others out
there. but, TINA strikes again... (tina - there is no alternative* :razz: ).
It's nearly impossibly to argue a case for a file system so badly
effect by fragmentation issues.. i cant quote passages at you or
anything, but i did research the subject in some depth when i was using
Debian/Mandrake/Win98 at the same time..

*disclaimer - for the regular or moderate computer user.

Hah, I didn't realise this had gone onto parity and stuff rubs hands together :razz:

The idea that the extra 24 bytes/bits/whatever go to parity is complete nonsense. Computers don't use parity or any other kind of error detection internally. Serial ports use parity, CD drives use some very complicated codes such as run length limiting codes (side note - when you write a 700 meg CD, you are actually putting more like double that in physical bits on the disk so that it is then possible to read them back properly even once the CD has been scratched), and ECC memory uses hamming codes (afaik) - ECC memory with a stated capacity of 512 megs actually has more capacity than this, with the extra dedicated to automatic error detection and correction - perhaps this is what you were thinking of xcon?
I'm not sure what coding hard disks use internally, I'm guessing they use something, but this does not have to be the case. Most devices should work with no errors ever, hence hardly anybody has ECC memory.

Crono, you remind me of the sort of IRC newbie that bashes microsoft all day, and bulls**ts about stuff they dont know about, yet you have windows and office installed.

That's nice, especially because I was talking about the operating system's interpretation of physical ram size and not device's data transfer.

Secondly, I do have a Window box. But I have several UNIX/Linux Boxes as well, so get over your self.

That 'extra' 24 Bits/Bytes are used, most likely, by system utilities. I was emphasizing on how it would be nice, if Windows in particular, showed that space within the OS's interface, instead of tucking it away, since it does not need all of that space.

Also, 'Giga, Mega, Kilo, Pico, etc' are prefixes. Suffixes come at the end of a word not the beginning.

Maybe I should start putting the base number at the end of all numbers I write so no one become incredibly cocky about their reply.

/me pointedly remains out of this one, but in this case... i feel crono was wronged.. course could be only my ignorance.

good luck

Not that you would ever do such a thing, eh Crono :wink: Hehe :smile:

But I definately see your point.. I will say you know a lot for your
age/experience level xcon, but Crono is studying this for higher ed.
and has probably been using computers a lot longer than yourself.. not
quite an IRC newbie :smile:

Speak wisely and with restraint and respect, and replies will be less scathing and filled with irritation :smile:

I'm not sure why you are talking about the 'extra 24', they don't even exist? I don't understand where this whole concept has come from... If you go to the properties for a file, the size on disk is larger than the actual size of a file because there is a minimum writeable 'block' of data possible with a given filesystem. I can't remember the exact stats, but say 'scaryFS' has a minimum block size of 32K, and you go to save a 33K file, the size on disk will be 64K. The extra 31K is just wasted space that doesn't get used by anything. It is perfectly possible to reduce the minimum block size, but this in turn increases the filesystem overhead.

The formated size of a hard disk will be smaller than the advertised size due to some of the space being used up by the chosen filesystem - it is possible in theory (I suppose) to have a filesystem with zero overhead, and if you were to use such a system, you would have access to the actual maximum space.

Finally, some programs obtain file sizes in bytes and then divide by 1000 or 1000000 to get K or megs, obviously giving a different result. Although the prefix 'Kilo' normally means 1000, the correct way with computers is to use Kilo to mean 1024, because the way a computer is designed makes this more conveinient.

Right, Jeff. That's what I was saying. I'm talking about at a hardware level, the sizes are 1024 chunks. However, from the view of the user, physical size is based on increments of base 10. It's not even important really; it would just be nice if the file systems supported it, that's all :smile:

So:

some programs obtain file sizes in bytes and then divide by 1000 or 1000000 to get K or megs, obviously giving a different result. Although the prefix 'Kilo' normally means 1000, the correct way with computers is to use Kilo to mean 1024, because the way a computer is designed makes this more conveinient.

Thanks for elaborating on my point, even if you didn't know you were :smile:

Thanks, guys :smile:

Sometimes if I look like I don't know what I'm talking about in regards to hardware, it's because most of my studies have been in regards to low level hardware performance and such. Most architecture classes I've had focus on the processor architectures, bus, ram, chipset, and so on. But, I assure you, I'm not 'newbie' :smile:

I didn't know what was going on, I was just trying to look clever :smile:

EXPOSED!