NoFantasy

Support for the above issues added in [10381]. Sorry again for not being aware of this in the first place. Note that the system became a bit more generic and can be used for more than just totems. Hacks was removed for shapeshift/forms and are also using data from the new table. As for how to fill and maintain the new table, it's a job for database devs, but below are an example: INSERT INTO creature_model_race VALUES -- dr (4587, 1024, 19638, 0), -- water (4588, 1024, 19637, 0), -- earth (4589, 1024, 19636, 0), -- fire (4590, 1024, 19639, 0), -- air -- tr (4587, 128, 37773, 0), (4588, 128, 37768, 0), (4589, 128, 37771, 0), (4590, 128, 37769, 0), -- or (4587, 2, 37772, 0), (4588, 2, 37767, 0), (4589, 2, 37770, 0), (4590, 2, 37766, 0), -- dw (4587, 4, 37752, 0), (4588, 4, 37750, 0), (4589, 4, 37751, 0), (4590, 4, 37749, 0); The new table may very well have other uses, where we expect some creature model to change depending an race (or team for that matter, team is simply all races that belongs to a team).

Yes, it's clearly a client bug, which we can't do too much about other than to avoid using it.

Problem is Database, you should override the model selection from creature_template with: UPDATE creature SET modelid=17115 WHERE id=17591; Remove expected data will not do much good, that is one of the reasons we have the override-feature

The most logical solution would of course be to select model for race, based on the native model. The more generic it can be, the better of course. Currently, it seems that making own storage as creature_model_racial VALUES (modelid, race, modelid_racial) and drop the current modelid_other_team is a fair solution. I don't know if there are other cases where display model is selected by race other than totems, but if they do exist, a generic system like that should already be usable for it. Edit: ok, it need more research. creatures already exist for race, and it can seem more proper to select model from the creature entries instead of defining a modelid directly for the race.

Although the pastebin is expired, i briefly remembered the basic idea of this. Corrections are done in [10358] along with other issues. Consider it accepted

Why? Whyyy! Clearly something changed in 3.3, i was not aware of this at all during the make and before it was committed. Unsure how to adapt code for this change, but it's more clear now that we need even more explicit code for totems than what was added in this rewrite. I'm pretty sure something fancy will come up though

1. Wires from brain to keyboard failed, and I pushed without amend with author, sorry about that 2. Added comments and used a pointer-version. The concept still remains. 3. Accepted

Not going to hit anyone more than usual. My point was: when someone spend time in finding a bug/a limit/a missing feature, we all should expect that they already study the existing code and already know how similar parts of our ways work. I bonk Schmoo in the head every other day though, and i'm pretty sure he didn't get so hurt that he's not able to continue the good work he already do, although sometimes with a weird code. As a side note to that, he also point out my weird things when he find them (which i expect people to do, this is how things are improved)

Even so, you miss the whole idea about processing GO's per type. Instead you want to add some hack where you feel it's needed, which in my opinion will not benefit either yourself, me, the users or the learning process and understanding of the code. Rejected, alternative code will be made instead, that will not break with the current way of processing GO's per type. http://github.com/mangos/mangos/commit/1bf693154e511dbc5747a018af2ece0043b1ed48

No idea why you want this weird code, you are already able to have script for the actual used GO, and from there fully able to to achieve what you want.

Could it be ok to restore more than just this thread, when it comes to our hidden hideout forums? I can't remember anything special, but i do know some old threads was still valid in terms of research and validity. Possibly things we would have use for once we feel like starting to work on it...

[10295], after removing some whitespace

I've posted some real creatures model data at a DB project forum, in case someone want to do supplemental research.

It may be easier to see the reason behind modelid_alternative with this: SELECT entry, modelid1, modelid2, modelid3, modelid4, name FROM creature_template WHERE modelid1!=0 AND modelid2!=0 AND modelid3=0 AND modelid4=0; From this we can see that there are several patterns: * male vs. female models * invisible vs. infernal (and other models we can call place holder models) * models with same gender and/or same model w/different appearance - The first case is easy enough, we select random gender later in code. - The second case has been source of more than one headache, it makes creatures appear with the place holder model, instead of the invisible as we expect. Since the new code require modelid_alternative to use model1, we simply won't add any alternative for model2. - The third case i'm actually not 100% sure of, but there may be cases where we have a random selection between model1 and model2. If so, we simply define the alternative and will then have 50% chance to use it. Note how creature entry 328 has two models, one white(model1) and one brown(model2). Without alternative, we end up with the brown version, with alternative we end up with 50% to be white.

To the last question: Two different creatures: entry 24637: mod1=1557, mod2=12199, mod3=12200 entry 24853: mod1=1126, mod2=11686, mod3=22670 In the first case, we may add model 12200 as model_alternative for model 12199, and then we have a random selection between the three In the second case, we do not want to use mod1 and mod2, since it should always be mod3. For this example, the invisible model 11686 should not have an alternative, and as result we will use 22670 always. So yes, this is basically a way to make a pattern so that we can eliminate those we do not want, and in opposite case, make sure we get a randomness where it's needed/wanted. Edit: @ Kirix: it's nothing wrong with the current system per definition, it works if you know what data to put where. This is however the main reason to change the system, it's too hard to maintain and it's too dependent on customized and hand made data for every creature.

As many will know already, our model system has a design that does not allow us in a easy way to use cache data directly. The data need to be modified quite a lot and is not always easy to understand what to fill in where for the four fields in creature_template. I basically want to change this system so that we can use data from cache directly, for two reasons: * simplify the life of Database devs * getting more accurate model for creatures in-game We know that 80% of the creatures are easy, they have only one model. It's the remaining 20% that gives us heart attacks and sleepless nights. It is not easy to determine how we can do this, but i think i am very close to a fair solution. In words, it can be narrowed down to this: As this text imply, creature_model_info will get a new field, model_alternative. The purpose of this will be to fill with an alternative model for special cases. Unlike modelid_other_gender that stores the male/female, this may simply store an alternative (for example a critter that may have two models, but does not have a gender). This way we avoid mixing up the data with gender related models. In addition, we all know that models for totems has always been a topic for discussion, they depend on the players team. This will be solved with a new field like the modelid_alternative; modelid_other_team. Now, the question is really, what do we want? Adjusting the current code will break a lot, and will more than likely end up with a cataclysm, breaking things all over. The changes i want to do, is written using cache data only, with no modifications or current database values provided by DB projects. Is it ok for you guys to change Mangos so that we can use model data directly? The code written so far is http://paste2.org/p/932047 It may be some lol-code in there, however it's the concept that is more interesting, how we select the native model (not that the two new database fields are not actually added/used in the code yet, but access functions are made as place holders). Edit: below is the most interesting part, showing the code/function for actual model selection only. uint32 ObjectMgr::ChooseDisplayId(uint32 team, const CreatureInfo *cinfo, const CreatureData *data /*= NULL*/) { // Use creature model explicit, override template (creature.display id) //if (data && data->displayid) //return data->displayid; // DISABLED while working // use defaults from the template uint32 display_id = 0; // models may be categorized as (in this order): // if mod4 && mod3 && mod2 && mod1 use any, by 25%-chance (other gender is selected and replaced after this function) // if mod3 && mod2 && mod1 use mod3 unless mod2 has modelid_alt_model (then all by 33%-chance) // if mod2 use mod2 unless mod2 has modelid_alt_model (then both by 50%-chance) // if mod1 use mod1 // model selected here may be replaced with other_gender using own function if (cinfo->ModelId[3] && cinfo->ModelId[2] && cinfo->ModelId[1] && cinfo->ModelId[0]) { display_id = cinfo->ModelId[urand(0,3)]; } else if (cinfo->ModelId[2] && cinfo->ModelId[1] && cinfo->ModelId[0]) { uint32 modelid_tmp = GetCreatureModelAlternativeModel(cinfo->ModelId[1]); display_id = modelid_tmp ? cinfo->ModelId[urand(0,2)] : cinfo->ModelId[2]; } else if (cinfo->ModelId[1]) { uint32 modelid_tmp = GetCreatureModelAlternativeModel(cinfo->ModelId[1]); display_id = modelid_tmp ? modelid_tmp : cinfo->ModelId[1]; } else if (cinfo->ModelId[0]) { display_id = cinfo->ModelId[0]; } return display_id; }

Useless, in terms of that the spells used won't do/can't do any real harm if caster is Unit. I wold not have noticed though, if it wasn't for the comment +1, will commit when I get time tomorrow

I have to be honest, after the leader of Trinity, once again managed to toss some trash-talk at the UDB forums recently, i am reserved about Trinity. I am very aware though, that many may very well disagree in this ongoing "harassment" in public from their leader/founder, and that is one of the reasons we see more coming back to the mangos community, spending more time here with constructive talk and proper solutions. In other words, i have no objections per definition about SilverIce.

I tested some randomly chosen mob in a start area, and the little bugger attacked me right as he respawned (entry 1718 for the record). If i add some goodwill to it, it may have been a small delay of 0.5 seconds, but nothing i would really mention as a "feature". As conclusion, I agree with the several who point out that they doesn't do this always. It should be very simple for others to verify it. Further research and adjustments are needed before this can be accepted in my opinion.

@3: Yes, there are several quest related taxis that should fly with lower rate. Possibly the majority of them. Examples are bombing quests in hellfire.

Yes, me and Vladimir was playing ping-pong in the garden yesterday and we forgot to turn if off Our ping-pong program is now switched off and system restored to normal state.

http://github.com/mangos/mangos/commit/6be77850b8ca8ca86756cfb56e4eea613dcf2439 should fix the first issue at least.

Vladimir made me aware that a patch already existed here, a minute after i push http://github.com/mangos/mangos/commit/cf5b81d47382114dbcc53b39a41bdfc818079e00 It is pretty much the same code, so consider this patch accepted. Sorry, i should have been looking here first, before writing myself.

It is not possible to "activate" anything, when it's not yet created. For doors and similar, it's not significant at all, script can save instance data and at creation of the GO use this data to set the expected state of the GO when it's created. Hardly comparable with the case of the whole floor in the instance, you can in fact never reach that far in to the instance that the GO will ever be created with a small distance visibility

Of course, "fixing" it in the way Schmoozerd suggest is just a "lol-fix". I've no idea how it could even be anyway near a real solution. The real problem is, as i understand it, is that a node get guid assigned twice and then crash since it can not have two guids. In other words, it must be related to how it's added at spawning GO for event and then how it's added at spawn of the regular pool. Removing the node from the game_event_gameobject table and watch how the pools work ok after is an indicator that support the theory. As a side note, this crash can also be reproduced by walking in to an area where the GO is supposed to be spawned and .event start 28 (assuming having the database as initial post). At least i have always crash doing this.