Hi, me again hacking around,

I want to let users mark their entities for being e.g. completely solid, with soft alpha and binary alpha to treat those models in my ssao solution differently. And I don't want to use the regular entity flags because I would constrain the user.

Question: Are the unassigned entity eflags safe? E.g. you have assigned (1<<0), (1<<1) and then 5 unassigned bits, then (1<<7), (1<<8) are assigned and then again 7 free bits and so on (see atypes.h!). Are you using them internally or don't you?

If you don't, I would like to use them on my own instead of FLAG1...8 or similar.

We're using all unassigned flags internally for secret stuff, except for the 8 general flags.

When you need more flags, the best way is using a skill variable.

I don't want to use a skill because then there would be one skill which can't be used by the user. I tested it, nothing went wrong here with using (1<<2), (1<<3) and (1<<4)

Your logic isn't correct Christian.. 2 Points:

1) Even if you can use the flags: In this case it would be possible for all users ==> The unused emasks flags could be used by the end-user and therefore would lead to conflicts with your code.

2) Even if it would be possible now: Your code wouldn't be "foreward compatible" (your code wouldn't work in a future 3D-Gamestudio Version).

Solutions:
1) Some kind of init function (I'm sure you have one?). E.g. heelx_use_skill(33); instead of useing of predefined skill..
2) ATTENTION, SLOW OVERHEAD (ofc not very efficient etc.): Create a Linked List / Dictionary (any possible ADT which applys to your situation) which manages any additional information you need..
I would not recommend this method if you have to manage a lot of entities (slow searching) or you don't want to use any skill (skill contains pointer to handling structure).

ahh why am i writing.. i'm sure you know it for yourself

Hi TechMuc,

thanks for your input. I decided finally that the user has to sacrifice one skill:



Which can be changed easily (just replace skill100 with the skill you like). And I use the follwing public flags:



and one private flag (used by system):



I think this is for the moment the best solution.

Using a skill parameter beside that is another possible solution. I will think about it, thanks for sharing your thoughts The problem I see is twofolded: First, I think that most people aren't adressing skills as an array and rely mostly on the "old" fashioned way. So there might be confusion if they have to pass the skill number based on a 0-index (zero; for array adressing) instead of a 1-index basis (define like usage like in c-script). I could say "pass the numnber for skills 1...100", but that would be inconsistent and very confusing.

So, defining a skill might be the most compatible solution for everyone.

Since there aren't really much events in Gamestudio (like when ptr_remove is called on an entity or so), I can't use a passive solution that keeps a parallel datastructure.

[EDIT] Superku told me about the on_ent_remove event.. didn't knew that!

Ahm - isn't skill99 the highest skill available?
The definition in the entity struct is

var skill[99],

so I guess there's only skill 0 to 99.
However, as you said, the skill number can easily be changed.

You know that you can "overwrite" ptr_remove with a macro that does your cleanup stuff and then calls the real ptr_remove function?

No, it's skill[0] to skill[99], but skill1 to skill100
So, skill[0] is skill1 and skill[99] is skill100.

It's defined in compat.h.

That is on the first sight a real cool idea. But on the other hand not so wise in the end. If I would do that, my solution would'nt be loosely coupled to the users's project, because I would

• hijack his "engine"-functions
• have problems if he would like to do the same (same problem as with using the eflags)
• I would have serious issues with a level_load (ptr_remove is maybe called, but in the engine and not from Lite-C)

So, I don't think this is a good solution in comparison with the skill-method. I really want to have a loosely-coupled standalone solution that isn't aggressive in terms of usage ergonomics and engine-hacking

[EDIT]

Superku told me about the on_ent_remove event, didn't knew that. If I have to store more data for each entity, maybe this will be a solution... gnaaarr

on_ent_remove event!?

Never heard of that, but this makes a lot of sense. This is such a sweeet feature.