csMaster

Zdaje mi się że przy EF_NODRAW ent nie jest wysyłany do gracza w addtofullpack więc to by miało sens, bo silnik po stronie gracza nie jest informowany że w danym miejscu znajduje się jakiś byt, ale też trzeba to sprawdzić żeby potwierdzić

Na to wygląda.

//Part of gamedll's code is moved here to decrease amount of calls to AddToFullPack()
//We don't even try to transmit entities without model as well as invisible entities
if (ent->v.modelindex && !(ent->v.effects & EF_NODRAW)) {
	qboolean add = gEntityInterface.pfnAddToFullPack(&curPack->entities[curPack->num_entities], e, &g_psv.edicts[e], host_client->edict, flags, FALSE, pSet);
	if (add)
		++curPack->num_entities;
}

Ale nie wiem jaki ma to wpływ na blokowanie się dwóch entity. Widziałem że w kodzie odpowiadającym za interakcję między entity jest zmienna, która wygląda jakby dotyczyła "widoczności" jednego entity przez drugi. Ale dokładnie nie sprawdzałem co robi. Na pewno EF_NODRAW ma większy wpływ na byty niż kRenderTransAlpha, bo tylko w tym pierwszym przypadku występowały glitche.
 

Dobra jednak już znalazłem rozwiązanie.

1. Fakemeta ma jakiś problem z tymi solid i movetype. Czasami się glitchują kolizje z entity, a czasami tych kolizji w ogóle nie ma. Engine jest bardziej pewny i stabilny.

2. Zmiana modelu entity powoduje wyzerowanie EV_FL_mins i EV_FL_maxs oraz EV_FL_size. Wymiary muszą być ustawiane po przypisaniu modelu, a nie odwrotnie. Dotyczy to tylko tych dwóch wartości, położenia nie.

3. Ustawienie SOLID_BSP wymaga żeby model był brush'em, w przeciwnym razie wywala serwer. Wtedy kolizje z entity są uzależnione od modelu i nie da się zmieniać rozmiarów (można zmieniać absmin i absmax i entity będzie gdzie indziej, ale kolizje będą tylko tam, gdzie model ma hitboxy).

4. SOLID_BBOX ewentualnie SOLID_SLIDEBOX jest do tego odpowiednie.

5. Dodanie EF_NODRAW do EV_INT_effects też wydaje się powodować ścinki przy interakcjach z entity. Jeśli ma być niewidoczny to lepiej go ukryć przez EV_INT_rendermode i EV_FL_renderamt.

Wyzerowanie EV_FL_renderamt powoduje, że byt jest niewidoczny nawet na Software.

Wow, naprawdę nikt na amxx ani am przez tyle lat nie wpadł na to i nie chciał się podzielić wiedzą?

A masz na myśli że rozwiązałeś problem z tym glitchowaniem się jak stoisz na entity?

No ja nie wiem, cały czas zmieniam różne rzeczy i dalej jest tak samo.

Na mapie na której to sprawdzam, obok mojego entity jest drugi, będący elementem mapy. Ma SOLID_BSP i MOVETYPE_PUSH, nie ma origin, ale ma mins, maxs, absmin, absmax i size. Jak na nim stoję to wszystko jest normalnie. Dosłownie wszystkie parametry EV_[INT/FL/VEC]_* przeniosłem na swój entity. Nawet model dałem *12 żeby było tak samo jak na tamtym i rezultat jest taki że eel zaznacza mi tego entity że jest w tym miejscu, ale można przez niego przechodzić jakby go nie było. Próbowałem też tamten entity będący częścią mapy zmieniać, ustawiłem mu SOLID_BBOX, MOVETYPE_FLY, zmieniałem jakieś inne parametry takie jak EV_FL_renderamt, i ten cały czas jest solidny, można po nim chodzić i nic się nie glitchuje mimo tych zmian. Są dwa identycznie ent'y obok siebie i jeden z nich działa a drugi nie...

public plugin_init() {
	set_task(5.0, "entity_edit");
}

public entity_edit() {
	new ent = engfunc(EngFunc_CreateNamedEntity, engfunc(EngFunc_AllocString, "func_door"));
	
	for (new i = pev_string_start + 1; i < pev_string_end; i++) {
		new szData[64];
		pev(41, i, szData, charsmax(szData));
		set_pev(ent, i, szData);
	}
	
	for (new i = pev_edict_start + 1; i < pev_edict_end; i++) {
		set_pev(ent, i, pev(41, i));
	}
	
	for (new i = pev_float_start + 1; i < pev_float_end; i++) {
		set_pev(ent, i, pev(41, i));
	}
	
	for (new i = pev_int_start + 1; i < pev_int_end; i++) {
		set_pev(ent, i, pev(41, i));
	}
	
	for (new i = pev_byte_start + 1; i < pev_byte_end; i++) {
		set_pev(ent, i, pev(41, i));
	}
	
	for (new i = pev_vecarray_start + 1; i < pev_vecarray_end; i++) {
		new Float:fData[3];
		pev(41, i, fData);
		
		if (i == pev_absmin || i == pev_absmax || i == pev_mins || i == pev_maxs) {
			fData[0] += 40.0;
		}
		
		set_pev(ent, i, fData);
	}
}

I tak samo z engine:

public entity_edit() {
	new ent = create_entity("func_door");
	
	for (new i = 0; i <= EV_INT_deadflag; i++) {
		entity_set_int(ent, i, entity_get_int(41, i));
	}
	
	for (new i = 0; i <= EV_FL_fuser4; i++) {
		entity_set_float(ent, i, entity_get_float(41, i));
	}
	
	for (new i = 0; i <= EV_VEC_vuser4; i++) {
		new Float:fData[3];
		entity_get_vector(41, i, fData);
		
		if (i == EV_VEC_mins || i == EV_VEC_maxs || i == EV_VEC_absmin || i == EV_VEC_absmax) {
			fData[0] += 50.0;
		}
		
		entity_set_vector(ent, i, fData);
	}
	
	for (new i = 0; i <= EV_ENT_euser4; i++) {
		entity_set_edict(ent, i, entity_get_edict(41, i));
	}
	
	for (new i = 0; i <= EV_SZ_weaponmodel; i++) {
		new szData[64];
		entity_get_string(41, i, szData, charsmax(szData));
		entity_set_string(ent, i, szData);
	}
	
	for (new i = 0; i <= EV_BYTE_blending2; i++) {
		entity_set_byte(ent, i, entity_get_byte(41, i));
	}
}

Jak dla mnie to powinieneś jeszcze raz zainstalować (re)hlds / metamod.

 

Jeśli dobrze rozumiem, to myślę że problem zostałby rozwiązany przez ustawienie wartości

fs_lazy_precache 1

graczom przy client_connect() i usuwanie modelu nie byłoby konieczne.

Wystarczy poprawić ścieżkę na ftp i w pliku konfiguracyjnym a model sam się pobierze i będzie śmigać

 

Nie wiem jak w tym przypadku, ale jak miałem kiedyś zp to niektóre modele miały dołączone niestandardowe dźwięki, które niektórym ludziom się nie pobierały (mimo że były na ftp) i ładowanie stawało w miejscu. Problem udawało się rozwiązać albo przez ustawienie tej komendy graczom, albo przez dekompilację modelu i usunięcie z niego dźwięku który sprawiał problem.