ah, so you didn't shoot the dog with a bb gun, you shot its cage.
poor lil mouse. 
ah, so you didn't shoot the dog with a bb gun, you shot its cage.
poor lil mouse. 
Errr no, I'm gonna try and explain this silly analogy...
Lets look at the maps, which are the animals in my analogy. As both of these are different maps, they are different animals. The older map is the dog, while the newer one is the mouse. The type and size of animals has no real bearing here, its impossible to take this analogy TOO far without seeing the maps themselves.
Then there are the compile tools which you USE on the maps. For some daft reason I chose to represent this by weapons. Again, the weapons represting the tools has no bearing.
Finally, there are the editors. These are also used on the maps but have no relation to the compile process. In the analogy these are the cages - the cages have no relation to the shooting or the guns, just as the editors have no relation to the compile tools.
As such, there is no direct link between the animals cages and their fate from the shooting - you could quite easily have stuffed the dog into the mouse cage and given the mouse the luxury of the dog cage and their outcome from the shooting would be identical. This proves (yeah, right!) that the editors had no bearing on your compile times.
Oh god, I'll do anything to distract me from mapping won't I!
[addsig]| ? posted by ReNo |
|
- you could quite easily have stuffed the dog into the mouse cage ......... |
so it was a small dog?
[edit] maybe a large mouse cage? [/edit]

LOL, this post is just plain crazy ![]()
Seriously though G.ball, I won't believe you until I have conclusive evidence. For that, I'd need you to run the following experiment. I'll now accept that you are taking editor and tools as one package, rather than as two seperate variables.
CASE 1:
Worldcraft 2.1
Whatever tools it comes with
A map
A freshly restarted computer with no programs running
CASE 2:
Valve Hammer Editor 3.4 / 3.5
Whatever tools it comes with
The SAME map
A freshly restarted computer with no programs running
Compile with case 1, time it. Restart your computer and compile with case 2, timing it. I doubt case 1 and 2 would yield much difference, and if case 2 is longer than case 1 by any significant amount (giving some margin of error for incalculable errors like differing page faults while accessing memory etc...) then chances are its because case 2 is doing a better job of compiling ![]()
And submit your compile log for all to see ![]()
Maybe whats happening is... youre compiling through HAMMER! I'm not surprised it would take longer to compile through 3.4/3.5, that part of the code probably hasnt been touched since wc2.1, since most mappers never use it. It still *works*, but has become less effective over time as other parts of the program are upgraded and this part is neglected.
In short... DONT COMPILE W/ TEH HAMMRE!!111!!11!!1!!!1!1!
[addsig]
crazyd, let me appologise on behalf of all the *twitch*sane*twitch* people here. editing threads don't normally go this way. at least not before they get resolved.
i asked what mod you were making this for, because some mods need to have a certain entity in the map before they will appear on your maps list. for tfc you would need a tf_detect entity in your map.
if it is another mod, then there may be a specific entity that you need. there should be someone here that's able to tell you what it would be.
a sure way of getting your map to load is with the changelevel command in the console. all you need to do is start up your mod with one of the maps that you can see. once your in the game, enter changelevel mapname in the console. where mapname is the name of your map, of course.
this should load up your level, even without its 'detect' entity.
^that's all assuming that you did compile a playable .bsp, and it's in the correct mods maps folder.
Good point, and one I hadn't thought of. As hammer has been upgraded, its memory requirements have probably shot up considerably also. Thus, if you compile using older versions, you have more memory available for your compile tools than you would compiling with a new, more demanding editor. Cut out this possibility by, as wilson said...
...NOT COMPILEINGG WIFF TEH HAMREEE!!!1!!1
[addsig]
| ? posted by ReNo |
|
Good point, and one I hadn't thought of. As hammer has been upgraded, its memory requirements have probably shot up considerably also. Thus, if you compile using older versions, you have more memory available for your compile tools than you would compiling with a new, more demanding editor. Cut out this possibility by, as wilson said... ...NOT COMPILEINGG WIFF TEH HAMREEE!!!1!!1 |
Well why didn't ya just say so ?
With that in mind, yes, I can understand how VHe would take longer. =D Also, sorry for de-railing the question.

both versions all but die when the compilng starts though, giving up any ram they may be using. you can see/hear the ram getting filled up after compiling, as data gets lifted from the HD, and hammer stutters to life again.
i think it's a throwback to when WC was 1st made, when 16megs was a lot of ram to have on a comp, that it was designed to give up the relatively large chunk of system memory that it would be using.
and seeing as how WC, or hammer, or hlcc, or whatever, dont actually compile anything anyway, i dont think there would be much difference at all.
the compiler 'tools' could have an effect however. different, newer versions, have elements added to them, which have been turned on by default, such as clipping off sky brushes. small things like this have been deemed necessary, whether it's to stop you falling out of the map, or to make it look nicer. so any small addition to the time .rad or .vis takes to do there jobs, and i do believe it would be small, is time well spent.


