.Map :: MoHAA Mapping

roger that.
grb

Anyway, before this topic got hi-jacked to talk about classes, the original problem of FS_file empty is caused by a bad tik file, probably the ammo-box.

yes i was just about to say... and search wouda done the trickl others (and me) must have answered this question around 20 times by now...

m4rine and balr14,
After I removed the ammo boxes for "mg" the problem seems to have
gone away. Thanks all for your help. Guess this topic is closed at this
point. Strange though, that if one makes a copy of the map to another
file_map_name, then recompiles from scratch, the new map that
contains all the original stuff (including the ammo boxes for mg type
ammo) does not produce the error.....that is the map loads and runs
ok in the game. So that tells me there was nothing wrong with the
tik file in question. If it works for the second map copied from the
original, then why doesn't the original map work. I had also deleted
a duplicate set of brushes I found referenced earlier in this thread as
a chaulked cylinder with a particular name, etc.. So who knows what
really was causing the problem. I bet if I create a new map and use the
ammobox for the mg ammo, that the map will work just fine. Since it
worked fine in the original map I discussed for quite a few days of
map editing in Radiant and then running the map.
This is partly why I went off on various tangents reacting as I did based
on observations I was making. At any rate, thanks again for help on this issue.

George

That is because copying the map to a new name generates a new min file when you load the game, which causes the correct entities to be pre-cached, over-riding the error. The error occurs because you added an entity with a bad tik file to a map you had already tested, in which case the min file is not recreated and the entity in question is not pre-cached. You could have accomplished the same thing by deleting the min file of the original map.

Sorry to keep this thread alive, but it does contain some valuable info.

hey if any of us can learn new things, we should not cut off any topic.

I believe I understand what you explained above. But, would you
agree to the following statement?

A "bad" tik file most likey means it has lines of code, whatever, that
simply is not compatible with the game engine.

So regardless of what map I used that particular tik file in ...........
shouldn't that compiled map always cause the FS_ReadFile with empty
name ....error to always happen?

Perhaps the explaintion would be to verbose, in which case do not
feel obligated to respond. You should not have to write a hundred
page disertation on how the engine views and uses entities etc..

But if I understand you correctly, I should if I see this particular
system error message re-occure, simply delete the "X.min" file
and rerun the game, which means the engine must create a new
"X.min" file and most probably the error condition would no longer
exists? Am I far off the point?

regards,
George

I believe you have it down pretty well. The one thing I would add is recreating the min file doesn't always work. It depends on the nature of the error. Sometimes the error will persist, or a bad min file is created.

Understand. Thanks for the information.
George