 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I add hipscor.qc and wrath.qc to a same progs.scr.
While doing that there are defs in both qc files that won't fit with eachother. org duplicate definition ignored Here you have a def of two shotgun types that can't go along with eachother so you have to hussle wich one does fit. You can click on the green definition to show you where both definition misargue. In this case you'll need to define new arguments for the TE_Explosion, ammu_shells1 rockets cells. It's rather kinky stuff because as soon as you find the string another one starts calling. I spend months to seek the head type the gremlin uses for the weapon change trick. Couldn't find it as it is integrated throughout whole the code. you downlaoded the hipnotic zip,
you unzip the qc.zip, you'll find the package with the progs.scr if you read it with an editor it ends up with the hipnotics.qc entities. That is if you have the hipnotics.zip My progs.scr looks like this, but is not finished yet
defs.qc hipdefs.qc frikbot/bot.qc frikbot/bot_way.qc frikbot/bot_fight.qc frikbot/bot_ai.qc frikbot/bot_misc.qc frikbot/bot_phys.qc frikbot/bot_move.qc frikbot/bot_ed.qc subs.qc fight.qc ai.qc combat.qc items.qc hipitems.qc weapons.qc world.qc client.qc player.qc monsters.qc doors.qc buttons.qc triggers.qc plats.qc misc.qc hipmisc.qc ogre.qc demon.qc shambler.qc knight.qc soldier.qc wizard.qc dog.qc zombie.qc boss.qc hipgrem.qc hipscrge.qc tarbaby.qc // registered hknight.qc // registered fish.qc // registered shalrath.qc // registered enforcer.qc // registered oldone.qc // registered2 Where I put the hipmodels.qc? Be aware that the progs.scr is only the script that the compiler reads before starting compiling.
What I see is that you made a sommon of the qc files before knowing if they even will compare. If you ask me where to put the hipmodels.qc you're already going with the hipgrem,hipscrge,hipsmisc,hipitems. As you're not common with the qc files I would suggest first to compile the SoA progs.dat to see if the outcome goes well. From there you can add new qc files to see what will happen. How do I do that?
What trigger type the button has to be, and what type the wall/door brush has to be. Door acts like platform/elevator but it lowers only ones and stays there (wait -1). I haven't figured it out yet. Hopefully someone is more experience with this subject? The best option is to use a func_button, because it lets you use the button textures which change when the button is shot. func_button is quite simple to set up, you just need to set "target" with the same value as the "targetname" on the destination entity.
You got it right using a func_door for the moving wall. If you want it to move back up when you shoot the button again, Try applying the TOGGLE spawnflag to the func_door, and see if that helps. If you want it to close automatically after some time then set "wait" to a positive value. And for the button to be shootable it needs to have "health" set to some amount. Setting it to 1 is usually good unless you want the player to have to use a lot of ammo to "kill" it.
Tragedy!
I sealed my map to test vis times and so on, and suddenly my light tool started to crash! I'm using ericw's tyrutils v0.15.5, I tested with the original tyrutils and there was no crash. Here's some evidence, if it helps anyone: http://puu.sh/pXDTr/40c285c6ce.zip http://pastebin.com/L7Vtx2m7 The zip file includes two versions of my The pastebin is an example of my console output when running qbsp.exe and then light.exe. When it reaches the "2." point, light.exe crashes, as shown in that log. Does anyone have any advice on how to fix this? I've tried sealing the map in various different ways around there, which has lead me to believe it is not that specific spot that causes the crash, but rather some issue with the sealed bsp as a whole. ... we have found a lost soul.. So repent sinner, repent !! And read the Holy Quake Mapping Bible...
http://web.comhem.se/bjp/tooltips.txt Hoped it helped :) For what it's worth, it worked for me. I'm not using the latest and greatest compiling programs on this computer though.
The 10 warnings from BSP are way more than I'd want to see. TxQBSP 1.13 ( XT build 260513 ) -- Modified by Bengt Jardrup -- Further mods by Baker, mh, rebb -- Original Detail/Hint code by Alexander Malmberg <alexander@malmberg.org> Inputfile: bad.map Outputfile: bad.bsp ------ LoadMapFile ------ 17422 faces 2633 brushes (0 detail) 325 entities 102 miptex 2261 texinfo WARNING: No valid wadfiles in worldmodel Building hulls sequentially... Processing hull 0... <snipped> ------ MergeAll ------ 5576 mergefaces ------ FinishBSPFile ------ WriteBSPFile: bad.bsp 6930 planes 138600 17617 vertexes 211404 8593 nodes 206232 2261 texinfo 90440 15092 faces 301840 11659 clipnodes 93272 4631 leafs 129668 19642 marksurfaces 39284 68937 surfedges 275748 35710 edges 142840 0 textures 0 lightdata 0 visdata 0 entdata 36592 Skipped 0 surfaces 10 warnings Elapsed time : 0:23.87 Peak memory used : 21.0 MB _____________________________________________ ---- light / TyrUtils ericw-v0.15.1 ---- running with 2 threads BSP is version 29 Colored light entities detected: 325 entities read, 144 are lights. 0....1....2....3....4....5....6....7....8....9.... Lighting Completed. lightdatasize: 470313 7 switchable light styles Writing BSP version 29 19.0 seconds elapsed Pritchard emailed me the bsp, it was indeed a crash bug in light.exe (tyrutils-ericw 0.15.5), will fix in the next update.
I do wonder about those warnings. I ended up switching to the tyrutils qbsp rather than txqbsp, which a) makes the map compile a lot faster and b) gets rid of all of those errors.
Are they being suppressed, or is the tyrutils set just better at handling my shoddy brushwork? Also, thanks again to ericw! He was really quick in replying to my emails. :) Anyone got any good resources for designing good monster fights? It can be hard to come up with something unique each time.
|
|
|
|
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2025 John Fitzgibbons. All posts are copyright their respective authors. |