i think i can solve that. A random question, let's see ... if i turn a brush entity like a trigger into a point entity to avoid a limit, does it still keep the bbox? Does the player need to go to the point to trigger it?

By the way, the previous meessage was me. Forgot to put the nick. 

I was thinking about it from an anti-spam perspective. I'll concede that if blocking anon posting is not an option, then I'm all out of ideas of how spam and shitposting can be reduced. 

Entity Enemy Help. [EDIT]
Posted by kibbles on 2018/05/29 01:08:43
I've been searching for information on how to make monsters attack other types. Is there a way to do this within worldcraft? I can't find the entity index online


#1 posted by kibbles on 2018/05/29 01:10:46 spam
I tested smartedit adding enemy 6 to key and values to a monster enemy and placed all the monsters near it, he didn't attack
He Protec But He Also Attac
#2 posted by anonymous user on 2018/05/29 01:19:28 spam
Post in Mapping Help if you don't want a smac.
Need Help With Mapping?
#3 posted by anonymous user on 2018/05/29 01:23:35 spam
Get in line like everybody and ask in mapping help thread.

#4 posted by mankrip on 2018/05/29 03:04:44 spam
IIRC, in vanilla Quake the .enemy reference is cleared by the QC code during entity initialization. You need custom QC code. 

I had a thought just now...if you make a trigger hurt, and set the .owner field to the edict number of another monster, then drop a monster into the hurt trigger, and cleanup by killtargetting the hurt trigger soon after...runs off to double check T_Damage code. 

I had a thought just now...if you make a trigger hurt, and set the .owner field to the edict number of another monster, then drop a monster into the hurt trigger, and cleanup by killtargetting the hurt trigger soon after...runs off to double check T_Damage code. 

I know it is a bit of a creep, but I've been rumbing into the QTest file and I wondered if it would be possible to get access to the progs.dat.
As there is no progs.src the file bounces off as soon as I try decompiling it.

For what it is worth, I would like to play some SP maps in it, but there is no way to reach the bsp files as they all are in a different shape.

I know it's a silly question, but I just have that old fashion feeling how it would look like to add all given monsters in a usefull way.

Now it is just a stand-alone for DM with a rather broken way to use the entities. 

I use Quoth2 for my new map. How can I make a pendulum using info_rotate? 

qtest's .dat format is slightly different. from what I recall, the opcodes are mostly the same, it gains line number info, but it also lacks information about which variables are locals and which are not. if you were to adapt a qc decompiler, it would just end up treating all locals as globals. I don't think there'd be much else of an issue in tweaking a decompiler though.
however the bsp format is different too.

iirc, TimeServ made some tweaks to FTE years ago in order to run qtest's .dat paired with bsp29 maps. Whether that still works (and whether the map's entities have changed too) is a different matter. It doesn't support qtest's bsps (issues with surface triangulation), and I have no idea about the hud. Its also not software rendering. 

The qtest progs.dat is 312kb. I don't think there is a monster.qc included, as a small comparisment showed.

I took the first test1.bsp, which is "the place of the two deaths". In the original Id dm I placed some monsters, and then took both bsp files. With Texpath I could add the monsters to the test1.bsp file, but it immediately gave the "higher than 311kb buffer" warning.

So I think there is only info about weapons/ammu/health and deathmach players.

I tried decompaling with proqcc.exe -dec progs.dat but it ends up with "Error opening defs.qc".
No idea how to use FTE for decompiling.

@digs - Maybe not what you want, but here's the
doe pendulum qc. Maybe that helps, but it's not rotating. 

not sure what you're trying to do, but theres a modified qtest1

http://quakeone.com/forum/quake-talk/single-player/3837-qtest-mod

http://shub-hub.com/files/mods_singleplayer/qtest1.zip 

Thanks, but I do not want to use any additional scripts. I thought that this is possible in the limits of the chosen mod. It's a pity if this is impossible 

Do you want to add Qtest features into a mod? What does it have that you want?

Let me know where to download it and I can add it into Keep for you. Which reminds me. I never did add in some of your stuff. Would you mind if I did? No reason to leave a mod behind. 

It's certainly possible to create a pendulum using the rotating entities in Quoth, where are you getting stuck? 

I looked through the description of all the rotations, but did not find how I can do it. I do not even know where to start. I thought that you could force the door to open and close, but it only seems to open or just close. She can not return to the position in which she was 

You might want to look at using the func_rotate_train class as a controller, instead of the func_rotate_door. It's more complex but has the flexibility to do what you want. I'll see if I can put together an example map. 

@spy- thanks for the link, I'm registerd at quake.one but this has slipped off my attention.

@Qmaster- It was just my curiosity while playing Qtest1. I wondered why there were these monsters while they were not used. As I made a remake for the serpent, and a shield Ogre from the prequel screens, I thought it would be nice to make some Sp maps for it with the original monsters.

For what I seen in the q1test of Mega lol, he added the original quake monstes into the dm maps. My concern was to keep the authenticity of the original qtest, eventually added with a shield ogre. 

http://www.quaketastic.com/files/single_player/maps/pendulum.zip

Start by running pendtest.bsp in Quoth, observe the pendulum slicing. Notice how you can collide with the flat of the blade without taking damage, but it slices into you when you stand in the path of the rotation.

There's a lot going on to make this one object work, so follow this guide while looking through the map files in an editor to get an idea of how it works.

   External Models
The new idea (and the one that requires Quoth rather than plan Hipnotic) is to create the rotating entity as an external model, and then reference that model from the main map. This avoids the need to use an info_rotate entity (which historically made the rotating entity hard to texture and light correctly).

Take a look at the pendulum.map file first. You can see this just contains the brushes to make the physical, visible pendulum. Two things are important to note here
1) The brushes in this map are assigned to worldspawn, not part of an entity
2) The metal pivot at the top of the pendulum has been aligned exactly with the point '0 0 0' in the map. This point will be the centre of rotation for the object

Although I've been lazy in this test map and skipped lighting, another benefit of this file is that you can add lights to it. This lets you create lighting that looks reasonable at every angle the pendulum swings to.

The last thing to find out is how the external model is included after it's compiled. Open up pendtest.map in the editor. Normally, the brushes for a rotating object would be made into a "rotate_object" entity. In the case of an external model, we add a point entity to the main map with classname "rotate_object_point"; if you look at the example in pendtest, the key "model" "maps/pendulum.bsp" shows the format to specify the external model.

The Controller
Each rotating object in hipnotic requires a collaboration between a visible "rotate_object" entity, and a second entity which controls that visible entity. In this case, we are using a using a "func_rotate_train" to control. The targetname field on the visible entity links to the target field on the controller. The other keys we set on the controler are the noise it makes, the obituary text, and the damage it inflicts - 10hp is probably a bit low for such a huge chopper, but it is a test map.

The Paths
A rotating train needs a series of path entities which describe the sequence of rotations. For the back and forth rotation we want, only two "path_rotate" entities are needed. It's important to note that lots of different behaviours are possible at each step on the path, depending on the spawnflags used. In the example map the following are set: Angles & Stop rotate & Speed sets movetime

The first flag is the key to how our rotation works - we are stating that the waypoint specifies an angle for the object to face at the end of the movement (as opposed to setting a rate of rotation). "Speed sets movetime" is a bit of a convenience, it lets us say that the rotation must take 1 second directly, rather than having to calculate a speed of travel that makes the rotation look sensible. Stop rotate is cosmetic, it just adds a very short pause between each swing.

There's some subtlty to the angles chosen here: '410 0 0' and '-50 0 0'. The important thing to know is that after each step of the path completes, the angles of the object get normalised to the range 0-360. For example: after travelling to '-50 0 0', the angle is transformed to into '310 0 0', meaning that the object rotates forward to get to '410 0 0'. If we specified '50 0 0' instead of '410 0 0' the object would rotate the long way round, which is NOT what we want.

Finally, note that the path_rotate entities target each other to form a loop, while the "path" key of the func_rotate_train links it to the start of the path.

The Movewalls
The movewalls are needed to give the blade collision. All of them are given the same targetname as the original rotate_object, so they are moved by the controller in the same way. For demonstration purposes I've applied the "visible" spawnflag and an alpha value of 0.5 so that you can see what they're doing in the demonstration map. This spawnflag is very helpful for debugging, but in a final release can be turned off again.

There's also an argument to be had over the "damage on touch" spawnflag. On the one hand, I like the fact that you can touch the flat of the pendulum without taking damage, but on the other hand, you only get pushed if you get hit by the edge of the blade but aren't trapped by the walls on the other side. Perhaps just setting this flag on the end movewalls would be a good compromise.