9 odpowiedzi w tym temacie

[csMaster]

Pewnie już nie jedna osoba grająca w cs zauważyła problem dotyczący entity. Mianowicie, nie można po nich chodzić (ani się o nie ocierać), bo powoduje to dziwne "ścinki".

Problem ten nie występuje w przypadku bytów będących częścią mapy, ale w przypadku tych stworzonych przez pluginy - już tak. Dotyczy to zarówno SOLID_BBOX jak i SOLID_SLIDEBOX wraz z różnymi MOVETYPE_*.

 

Póki co, próbowałem już różnych metod, ale żadna nie spowodowała praktycznie żadnej zmiany:

Spoiler

- zmiana pev_solid i pev_movetype

- zmiana wartości cvaru cl_force_ent_intersection (ma to jakiś wpływ na SOLID_SLIDEBOX ale w tym przypadku nic nie zmienia)

- ciągłe aktualizowanie wartości pev_nextthink na jakiś małe wartości typu get_gametime() + 0.001

- ustawienie pev_modelindex

- zmiana info_target na func_wall i inne

 

Próbowałem ustawić jeszcze pev_solid na SOLID_BSP, ale to właśnie sprawia problemy. Przy zmianie pev_movetype na MOVETYPE_PUSH (a tego wymaga SOLID_BSP), entity po prostu znika. Albo jego pozycja się zmienia, albo przestaje być "solidny" i można przez niego przejść jakby go nie było. To samo dzieje się, gdy ustawie MOVETYPE_PUSH na SOLID_BBOX. Próbowałem jeszcze SOLID_BSP z MOVETYPE_PUSHSTEP, ale wtedy serwer crashuje się z błędem:

ERROR : SV_HullForBsp: Hit a solid_zone with no model (models/rpgrocket.mdl)

Model jest ustawiony byle jaki, ale jest - przez EngFunc_SetModel.

 

No i na tym błędzie się zatrzymałem. Na czym polega ten błąd? Jak go naprawić?

 

Ewentualnie, czy da się rozwiązać ten problem z chodzeniem po entity w jakiś inny sposób?

Zauważyłem, że stopień w jakim kolizje się glitchują jest zależny od fps gracza - są bardzo słabo widoczne przy 20 fps, prawie ich nie ma przy 40, ale potem problem staje się mocno widoczny tym bardziej, im więcej jest fps, tak gdzieś do 100-200. (dlatego próbowałem zmieniać pev_nextthink)

 

Mam na serwerze najnowsze wersje wszystkiego, w tym regamedll i reapi.

 

A może dałoby się naprawić ten bug w samym rehlds'ie? Mogę go edytować, o ile ta zmiana nie będzie wymagała ingerencji u graczy. Czy ktoś ma jakąś wiedzę na temat tego problemu?

 

[rzeznik9871]

Też kiedyś to rozkminiałem i nie doszedłem dlaczego tak się dzieje, ale doszedłem do rozwiazania które jest banalnie proste. Otóż wystarczy... stworzyć być przez engine a nie fakemete... serio, nie wiem co to zmienia ale tworząć byt przez create_entity() wszystko działa prawidłowo

[csMaster]

Zmieniłem na create_entity() i wszystkie set_pev na entity_set_*. Ciągle jest tak samo. Jeśli stoję na entity to wciąż się glitchuje. Tak jakbym spadał cały czas do dołu mimo że stoję na bycie, ale co jakieś 0.1s przywraca mnie na poprzednią pozycję trochę wyżej. Chyba że masz na myśli ten problem z ustawieniem SOLID_BSP - to zaraz jeszcze sprawdzę.

 

@Edit/ Dobra sprawdziłem. MOVETYPE_PUSHSTEP można ustawić, o ile model jest ustawiany po pev_movetype. Ale na SOLID_BSP i MOVETYPE_PUSHSTEP wciąż entity znika. Tak jest na engine i na fakemecie. Także problem z giltchowaniem się nadal jest i nie mam już za bardzo pomysłu jak to rozwiązać.

[rzeznik9871]

Hmm jestem przekonany że właśnie użycie create_entity wystarczyło, ale sprawdzę to jeszcze jak wróce do domu i dam znać.

Kojarzę też coś że ma znaczenie kolejność ustawiania modelu, originu i wielkości bytu i coś mi świta że użytałem entity_set_size zamiast "ręcznego" mins, maxs bo to też powodowało jakies problemy.

[csMaster]

Teraz zauważyłem, że chyba w ogóle zepsułem coś w kodzie i w ogóle ten entity nie działa. Czekaj, zobacze dokładniej. Może trochę za dużo pośpiechu bo już z 5h próbuję to rozwiązać.

 

@Edit/ Nie no jak dla mnie to ten SOLID_BSP w ogóle nie działa.

Natomiast jak tak patrzę, to nie wiem czy SOLID_BSP w ogóle można ustawiać mins i maxs.

vec3_t			mins, maxs;	          // only for non-bsp models

Ogólnie nie chodzi mi o to żeby na siłę używać tego SOLID_BSP. Może być nawet BBOX lub SLIDEBOX, ale żeby tych glitchy nie było, bo strasznie źle to wygląda.

 

Może jednak dałoby się to zmienić w rehlds'ie?

Ogólnie nigdy wcześniej nie analizowałem jakoś specjalnie tego kodu, więc nie jestem pewien w którym miejscu jest fragment, który odpowiada za kolizję w ent'ami. Wstępnie znalazłem tą funkcję:

Spoiler

// Bounce and fly movement. When onground, do nothing.
void SV_Physics_Bounce(edict_t *ent)
{
	SV_CheckWater(ent);

	// regular thinking
	if (!SV_RunThink(ent))
		return;

	if (ent->v.velocity[2] > 0.0f || !ent->v.groundentity || (ent->v.groundentity->v.flags & (FL_MONSTER | FL_CLIENT))) {
		ent->v.flags &= ~FL_ONGROUND;
	}

	// if on ground and not moving, return.
	if ((ent->v.flags & FL_ONGROUND) && VectorIsZero(ent->v.velocity))
	{
		VectorClear(ent->v.avelocity);

		if (VectorIsZero(ent->v.basevelocity))
			return; // at rest
	}

	SV_CheckVelocity(ent);

	// add gravity
	switch (ent->v.movetype)
	{
	case MOVETYPE_FLY:
	case MOVETYPE_FLYMISSILE:
	case MOVETYPE_BOUNCEMISSILE:
		break;
	default:
		SV_AddGravity(ent);
		break;
	}

	// move angles
	VectorMA(ent->v.angles, host_frametime, ent->v.avelocity, ent->v.angles);

	// move origin
	VectorAdd(ent->v.velocity, ent->v.basevelocity, ent->v.velocity);
	SV_CheckVelocity(ent);

	vec3_t move;
	VectorScale(ent->v.velocity, host_frametime, move);
	VectorSubtract(ent->v.velocity, ent->v.basevelocity, ent->v.velocity);

	trace_t trace = SV_PushEntity(ent, move);
	SV_CheckVelocity(ent);

	// If we started in a solid object, or we were in solid space the whole way, zero out our velocity.
	if (trace.allsolid)
	{
		// entity is trapped in another solid
		VectorClear(ent->v.avelocity);
		VectorClear(ent->v.velocity);
		return;
	}

	// If we covered the entire distance, we are done and can return
	if (trace.fraction == 1.0f)
	{
		// moved the entire distance
		SV_CheckWaterTransition(ent);
		return;
	}

	if (ent->free)
		return;

	float backoff;
	if (ent->v.movetype == MOVETYPE_BOUNCE)
		backoff = 2.0f - ent->v.friction;
	else if (ent->v.movetype == MOVETYPE_BOUNCEMISSILE)
		backoff = 2.0f;
	else
		backoff = 1.0f;

	SV_ClipVelocity(ent->v.velocity, trace.plane.normal, ent->v.velocity, backoff);

	// stop if on ground
	if (trace.plane.normal[2] > 0.7f)
	{
		VectorAdd(ent->v.velocity, ent->v.basevelocity, move);
		float vel = _DotProduct(move, move);

		if (move[2] < sv_gravity.value * host_frametime)
		{
			// we're rolling on the ground, add static friction
			ent->v.flags |= FL_ONGROUND;
			ent->v.velocity[2]= 0;
			ent->v.groundentity = trace.ent;
		}

		if (vel < 900.0f || (ent->v.movetype != MOVETYPE_BOUNCE && ent->v.movetype != MOVETYPE_BOUNCEMISSILE))
		{
			ent->v.flags |= FL_ONGROUND;
			ent->v.groundentity = trace.ent;

			VectorClear(ent->v.velocity);
			VectorClear(ent->v.avelocity);
		}
		else
		{
			float scale = (1.0f - trace.fraction) * host_frametime * 0.9f;

			VectorScale(ent->v.velocity, scale, move);
			VectorMA(move, scale, ent->v.basevelocity, move);

			trace = SV_PushEntity(ent, move);

#ifdef REHLDS_FIXES
			if (ent->free)
				return;
#endif
		}
	}

	// check for in water
	SV_CheckWaterTransition(ent);
}

[rzeznik9871]

Usiadłem do tego wczoraj na 20 minut i faktycznie to co ci pisałem nie działa ;/ ale jestem pewny na 99,99% że kiedys sie z tym uporałem, jak znajde chwilę czasu w weekend i sam tego nie rozwiążesz do tego czasu to jeszcze przysiądę do tematu.

[csMaster]

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...

 

Spoiler

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:

Spoiler

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));
	}
}

[csMaster]

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ą?

[rzeznik9871]

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.

Czytałem chyba na allied modders że w engine funkcje aktualizujące informacje w silniku są trzy

 

entity_set_origin

entity_set_model

entity_set_size

 

a w fakemecie tylko dwie

 

engfunc 

dllfunc

 

wiec wychodziłoby na to że aby poprawnie zaktualizować dane w bycie po stronie klienta trzeba ich użyć zamiast set_pev... co by mogło wyjasniać dlaczego fakemeta jest "bardziej niestabilna"

 

 

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.

Czyli tak jak pisałem ważna była kolejność ustawiania danych w bycie, ale nie byłem świadomy tego że po zmianie modelu _size się zmienia, gratki za znalezienie tej zależności

 

 

 

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).

Fajna ciekawostka, tego nie wiedziałem

 

 

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.

 

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ć

 

 

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

Dużo jest tajemnic amxx/cs których ludzie nie mówią innym po rozkminieniu, niestety niektórzy robią jakieś dziwne sekrety z ciekawostek i mechnik rządzących 25 letnia gra...

Użytkownik rzeznik9871 edytował ten post 17.07.2024 20:22

[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.