HL1 entities list?

[stefanhendriks]

I wonder how the entities are stored in HL. Why? Because i need to be sure for a traceline function i am writing.

In HL1, i see for looping through clients, to know player index + entity, we use INDEXENT(index).

I see in the RACC code, the EXACT SAME THING, happens. So that means, we copy players too in the index. Though i am not interested in those!

My traceline function, is taking either an iPlayer index, OR an iEntity index. Since MY entities list starts with 0, i want to keep it this way. So you mean, ENTITY 10 in MY list, it must translate this index into the proper index of HL1 and then find the correct pEdict for it...

So far i have this:

 
	// when iEntityFires is set, so this entity should be ignored 
	if (iEntityFires)
	{
		// FIXME: Is this true or not?
		// The entity in half-life is indexed , 0 = worldspawn, 1 to > max players is the player
		// so , in order to know the correct entity compared to our list, we should somehow
		// compensate.
		//
		// so, in ITM_, the real entity list starts at 0
		// in Half-Life it starts at 1
		// , in ITM we have a SEPERATED clients list
		// , in HL its integrated in the entity list
		//
		//
		// so, to be sure ITM Index 0 equals HL1 entity 1 (cause 0 is worldspawn) we have to do
		//
		// entity_index = iITMEntityIndex+MaxPlayersInServer
//		pEntIgnore = INDEXENT (entity_index); // attempt to bind this entity's structure
	}

as you can see, only comments. My question is, is the theory correct?

And yes, i know, i could just copy the entire freaking list, what is 32 entities anyway at max? But even then...

[sfx1999]

Try looking through Quake code.

[Pierre-Marie Baty]

The way you intend to do things would work, however I don't think it's a smart way to do things. To me players should also be represented as entities. Players should be represented as players to hold what the player knows about himself, and also as entity to hold what others know about him.

If you look in my code you'll see the player_t structure encapsulates a pointer to a corresponding entity_t structure.

[stefanhendriks]

my player is an entity itself too, but in my list. I could probably code it that way, like HL1 does. I need to rethink about my class hierarchial stuff then; either just add pointers... or keep it seperated

the reason to keep it seperated is, well, there is no need for encapsulated stuff. The bot just needs all info, and i retrieve all info. Nuff said? If any other bot would run (a different plugin, ie POD_MM) then it would not care about how i treat my data, as it just asks HL for data. So i don't see a reason. The only change is just the 'list' of data. Ie, in your case PMB, you would still look through your entities list, and i just look into the players list.

[Pierre-Marie Baty]

No, you haven't understood.
I *do* have two separate lists. The entity list and the player list. But the player list also features pointers to their respective entities.
This way, the entity structure holds data that is common to players and entities (render model, angles, speed, etc.), while the player structure holds data that is typical to players only.

[stefanhendriks]

Ah, oh well, thats not a bad idea at all

Its stupid though, in my case, i have a player class, derived from the entity class heh... so in a way, it has the same props as an entity, but it just aint in the same list. I could probably make a pointer to the list, but i still don't see a reason , since i can have the same props anyway.

Too tired to think clearly now and to make more sense...