Fgd File Question
#34 posted by Ankh on 2006/08/15 00:55:37
Would it be possible to change the fgd file in a way that entities would be assigned to specified visgroups upon creation? For example every new light entity would be assigned to the "lights" visgroup when created. The same with monsters and other point entities. Maybe this could be done with triggers also.
Not 100% Sure
#35 posted by than on 2006/08/15 10:30:39
but I reckon not :/
You should just use shit+drag clone as much as you can bear, the visgroups are kept unless you group (ctrl+g) something that has a visgroup assigned, or make it into an entity.
I pretty much never create new lights after I've got one or two in the level - just clone drag them around and tweak values as neccessary. If you have certain types of lights in your level that are a reccuring feature then cloning is perfect anyway :)
Sometimes I do group lights so that I can tweak the values of many without having to select them all individually. Unfortunately, I think you need to ungroup them to do this, then regroup when you are done, which loses the visgroup data. Maybe g works?
Er, And By G
#36 posted by than on 2006/08/15 10:33:20
I meant "ignore groups". Perhaps ignore groups keeps the whole group selected at first and lets you alter the brightness of all the lights in the group without having to ungroup first and regroup later.
Whoa
#37 posted by bambuz on 2006/08/15 12:56:40
tell me more tips when you use wc...
I didn't know about shift-drag, i always hit ctrl-c ctrl-v like mad!
Sorry
#38 posted by bambuz on 2006/08/15 13:00:47
in wc, the proper term is indeed shit-drag as you said
Ankh
#39 posted by ijed on 2006/08/16 09:34:04
I'm modifying the qouth fgd at the moment and I've checked about ~three different styles of .fgd format and I'd guess setting the visgroup inside the entity definitions is impossible. Its your basic system (hauntingly familiar of raw .html (cascades)) and not too difficult to get the old breadbox round; but there seems to be no way of modifying how objects are created - though you can change how they are viewed in the editor.
#40 posted by Ankh on 2006/08/16 11:45:56
thanks for the answers. Looks like I will have to stick with drag cloning (which I'm already using but not in that extent).
Thanks A Lot Baker! :D
#41 posted by born4trance on 2006/09/02 08:06:42
i'll be damned. Your QuakeAdapter does the trick.. You must know i've been using Worldcraft as my first Quake Map/level editor, and i've been searching the net for better working alternatives.. I've been using QME 3.x, Qoole, Thread and Quark, but i liked Worldcraft most because of its simplicity. Now today, i found this page, and i'm damn happy i found it!
So, once again you did it. I'll definetely keep an eye on you... atleast, i'll try :o)
As a little suprise i'll share the two DM maps i've ever made, using Worldcraft 1.6a .. all enjoy :-) http://members.chello.nl/j.leijten1/q1a&q1b_born4trance.zip
For now, thanks a lot and see you around! =)
/b4t
Thanks
#42 posted by Baker on 2006/09/02 16:58:31
I got very frustrated with WC 1.6's lack of rotation w/o messing up the textures and the later versions of Worldcraft were a pain with the need for constant texture conversions.
Feedback
#43 posted by ijed on 2006/09/04 10:47:17
ok, I finally tried it out and nearly everything runs perfectly, apart from the aforementioned texture limitation problem ("over 1024 textures in a WAD, you are insane!") which means its not easy to use many different wads (ie. splitting them into two, three or even four pieces), including nehahra and my own project wad (though that'll definately be shrinking alot). the other problem is that the compilers call the log by default everytime a portion of vis is completed - which slows it down a huge amount (i'd guess x3-x4 though this behavior can be disabled)- in the readme you say its bengt's tools but to be honest I didn't check which versions.
Since I'm in the middle of something I don't want to go through the process of reconversion (since loading a .map in 3.3 makes it incompatible with 1.6 (most likely an easy fix editing within the .txt of the mapfile)). However this is a huge leap forward when you consider 1.6 has been around and used for almost as long as quake itself - great work.
As to all the other tools and adaption systems; they worked perfectly, possibly the only gripe that could crop up is having base directory as c:/program files/worldcraft but since its such a small utility to move I can't see anyone complaining.
All in all, a very useful set of tools that will eliminate the headaches from alot of mappers lives, I salute you.
Ijed
#44 posted by Baker on 2006/09/05 02:55:41
All in all, a very useful set of tools that will eliminate the headaches from alot of mappers lives, I salute you.
Thank you. I appreciate the feedback I have been getting on this.
#45 posted by Napalm on 2006/10/20 03:40:43
Absolute Newbie question. Whenever I run the map all the textures are missing. What am I doing wrong?
Other than that it seems to work great.
Thanks alot for this.
Sounds Like...
#46 posted by Blitz on 2006/10/20 07:32:47
Your map doesn't have its worldspawn properties pointing at the .wad you're using to make your level. What editor are you using?
#47 posted by Trinca on 2006/10/20 08:05:01
Napalm setup Quake directory in program!!?!?!
I Found Out What The Problem Was.
#48 posted by Napalm on 2006/10/20 08:57:13
I am using Baker's Worldcraft3.3 Quake fix and it turns out you need to have your Quake Directory somewhere in c:\ (i.e. c:\Quake for example) otherwise it can't write the GFX from the wad into the BSP.
You Can Also
#49 posted by bambuz on 2006/10/23 08:38:57
have the wad in the same dir as your compiler and the map file... or something like that. don't remember if the wad had to have the same name as the map too or if it was specified to qbsp.
Vb6 Runtime Link For Win32
#50 posted by dingo on 2010/06/06 12:41:56
Is This A WC Bug?
#51 posted by Cocerello on 2014/03/28 21:40:08
- I have a map done in WC1.2 back in the day.I have another done in WC3.3 with Qadapter.
- The first map has a button that opens a door. The second has a button that targets a light to turn off.
- The first ap was compiled with the tools that come with WC1.2. The second map was compiled with txqbsp and MH colured lighting tools.
- In the first map, the door dissapears. In the second, the light dissapears, or the light is off at the beginning and turns on when triggered. This can change every time i compile the map even if i haven't touched a single thing.
- Even if i delete all the entities involved into this and redo them from scratch (new entity--inputing the data manually) the problem is still there. haven't tried to change the variables (Ex: targetname ''door1'' for ''poor2'').
- I have seen similar things happening with other entities but less annoying.
Cocerello...
#52 posted by distrans on 2014/03/30 03:46:31
...are you using killtarget instead of target?
No, No
#53 posted by Cocerello on 2014/03/31 20:56:22
And that doesn't explain why it goes and comes back on random when i compile it again.
Cocerello
#54 posted by Preach on 2014/03/31 21:56:17
You might have to bite the bullet and upload the map file, there's not enough to go on from the symptoms...
OK
#55 posted by Cocerello on 2014/04/02 21:04:37
I'll try to get the error to show up again, and upload both a .map and .bsp.
*Distrans, forget what i said in #53. But i want to ask you something: I don't see how using killtarget there instead of target can lead to that kind of error, as the issue is about things that happen when the map loads, not when you trigger those entities. Could you explain, please?
#56 posted by necros on 2014/04/02 21:36:26
depends if the killtarget is on the door. doors fire their targets (and killtargets) when they open.
Hi Cocerella...
#57 posted by distrans on 2014/04/03 06:58:54
...what necros said plus I assumed (probably wrongly) that In the first map, the door dissapears. In the second, the light disappears happened after the button was pressed. My mistake...
Case Solved
#58 posted by Cocerello on 2014/08/13 16:56:51
While trying to reproduce those issues again to send you guys the files, i noticed which were their causes.
In the case of the WC1.1.2 map it was that there was a hidden triger_once triggering to the door hidden in a secret (the MH one) afar from the door, so that explains why sometimes the door wasn't open and sometimes was. It was hidden near some busy brushes so it took me 17 years to find it.
In the case of the recent map, it was just a case of cross-connected entities, which plagued too my second map for sm175. Since them i stopped placing simmetrical rooms in 0,0,0
|