bug in no quarter ?

(Qualmi) #1

there is a bug when you play neuschwaben_final2 and noquarter. well thats what i at least believe. i also could be wrong, but im pretty sure that no quarter and this map dont work well together.

at kernwaffe server, where i played this map the first time, i saw this bug the first time and i got interested. objectives are: destruction of both reichsflugscheiben + delivery of the secret documents. in mapscript this is managed by one globalaccum. the mapper meant it like this:

descrution of reichsflugscheiben = globalaccum 1 inc 1
delivery of docs = globalaccum 1 inc 1

when the globalaccum reached 3 then the end of the map gets executed.

in nq however this is what happens:

descrution of reichsflugscheiben = globalaccum 1 inc 2 //instead of inc 1
delivery of docs = globalaccum 1 inc 1

the reichsflugscheibe is a func_explosive, with both scriptnames and targetnames different each. so i cant explain this to me as it seems the mapper has done everything correct.

also as i said on other mods this map works well, only in nq there is this prob. so i thought maybe i inform you about that bug as it seems (we tested nq1.1.1 and nq 1.2.5) that this bug is pretty weird and might cause problems.

greetings

qualmi

(stealth6) #2

maybe they are running a mapscript on kernwaffe that changes the script?

(Qualmi) #3

yea. i also thought so.

here are my testing results. im also noob at this, so blame me if my mappingskills dont reach that far to understand all of this.

i tested:

mod local etmain. result: no bug
mod inet etpro. result: no bug
mod nq (1.1.1) local. result: bug
mod nq(1.2.5) inet. result: bug

so i conclude it must be no quarter, but im not sure. so im asking you guys. is there sth i dont understand ? im also asking to prevent this bug for my next map(s). so im also interested in solving this.

so whenever i destroy reichscheibe 1 or reichscheibe 2 in nq mod, it seems that the corresponding scriptblock gets executed twice, instead of only once. i cant explain that :frowning:

(crapshoot) #4

it’s the etpro map script support implementation of NQ (and i would bet etpub) that causes this. even though the map script itself doesn’t have any etpro map scripting… same thing happened with Stalingrad if i remember correctly and it’s why etpub releases an updated script for it. reason i remember it is that when fritzbot implemented etpro map scripting based on etpubs code, the problem was detected and fixed. i sent a patch to tjw at that time, but i guess it was never fixed.

anyway, for your case, just search for tjw on this page to see how they ‘fixed’ it in map script:

http://trac2.assembla.com/etpub/browser/trunk/docs/Example/mapscripts/stalingrad.script

(Qualmi) #5

hm…but the thing is: the trigger_flagonly_multiple-scriptblock only gets executed once. so are there any “leaking entities” or sth ? do you know maybe which entities are affected ? for now it seems that func_explosives are affected.

and yea of course. you can fix this if you know exactly what is happening. you can do nqfixes (via etpromapscripting) or you can try to supply a bugfixed mapscript “apriori”. a mapscript which works on ALL mods. you could do it like this:


//scriptblock which would get executed twice in nq
affected_entity
{

   spawn
   {
      accum 1 set 0
   }

   death
   {

      accum 1 abort_if_equal 1
      accum 1 set 1

      //CODE
   }
}

did not tested it yet, but should work. this way the block will only get executed once. as far as i know et is not multithreaded, so one “code” wins, either the one for the etpromapscripting as you say or the normal code.

and yea i saw how tjw tried to fix this. in neuschwaben we simply applied the logic. there was a branch branching the accum at the value of 3. now since one reichsscheibe-block gets executed twice we simply branched at the value of 5.

(crapshoot) #6

it’s been a while so i don’t remember exactly, but i believe it was some logic problem in SP_func_explosive related to an EF_FAKEBMODEL check. i’ll take a look this weekend and try to get a fix committed to the mods.

edit: fix committed to etpub and nq. no map should require map script edits for this problem any more.

(Qualmi) #7

will that fix be working backwards ?

and one thing i dont understand. why is oasis working ? there are also 2 func_explosives for the guns, but on my local nq seems the fix was already done. did you supply a fix with nq release or why is oasis working and other maps not ??

(system) #8

Wasn’t there something that this mod took out some stuff for mappers ?
I do not recall what it was but i am 100% sure they took out some commands or something, maybe it affected this error ? :S

ups, sorry found it.

http://forums.shitstorm.org/viewtopic.php?f=65&t=10010

but i doubt as a non-mapper it has anything to do with this…

sry, my bad :slight_smile:

(crapshoot) #9

[QUOTE=Qualmi;201770]will that fix be working backwards ?

and one thing i dont understand. why is oasis working ? there are also 2 func_explosives for the guns, but on my local nq seems the fix was already done. did you supply a fix with nq release or why is oasis working and other maps not ??[/QUOTE]

yes, it is backwards compatible with existing map scripts (if that’s what you mean). the reason for the difference between maps is that the entities are set up differently.

(Qualmi) #10

both errors are sth different i think. one is because nq doesnt support a keyword in the mapscript, the other is the one i described above. one scriptblock gets executed twice instead of only once, like in etpro or native et.

i meant it like you do a mod. there is a path to a texture, a skin etc… and you replace that file with another file using the same path. is that also possible with code :wink: admins would simply take the patch, put it in their nq folder and the corresponding code would be fixed. would be awsome :slight_smile:

the reason i ask this is caus there are many servers who simply play the older nq mods, for whatever reason.

the reason for the difference between maps is that the entities are set up differently.

you feel like explaining that :smiley: im really interested. i didnt see anything special in oasis.

(IRATA) #11

TU Qualmi for reporting and crapshoot for the fix!

To clarify: Both bugs we are talking about are fixed for the next release but we won’t do patches for older NQ versions.
We strongly recommend to use latest versions anyway doesn’t matter if we talk about 2.60b or latest version of NQ.
1.2.5 f.g. fixes the callvote exploit issue which is a damn good reason to upgrade. Sorry we have lost the interest to act like prayers and tell the admins what to do/use for whatever reasons …

(system) #12

Well the callvote exploit can be easy fixed, turn off votes wich sucks anyway :stuck_out_tongue:

sorry, i hate votes to the gutter…i mean a vote “does dutchman suck” is fine with me but any vote that influences the game just sucks, including vote shuffle cause the team with more players wont press F1 anyways :S

thats why i am thinking all the time for a good ATB system for our mod but its so damn hard to make it fair but i got a little solution…just need to convince our progger :smiley:

(sorry for offtopic :slight_smile: )

(Blowfish) #13

[quote=dutchman;201784]Well the callvote exploit can be easy fixed, turn off votes wich sucks anyway :P[/quote]You cant :tongue:. And if latest NQ will fix callvote bug, I really have to think of changing our jay to nq… or accept bug.:cool: Good to hear you guys fixed it.

(crapshoot) #14

this is the code in the current versions that causes it:

void func_explosive_use( gentity_t *self, gentity_t *other, gentity_t *activator ) {
	G_Script_ScriptEvent( self, "death", "" ); // JPW NERVE used to trigger script stuff for MP

	if(self->parent)
		G_Script_ScriptEvent(self->parent, "death", "");
	func_explosive_explode(self, self, other, self->damage, 0);
}

calling that second death event is what was causing the problem because the parent has the same scriptname in maps like Stalingrad