Mysterious Command Post of Doom 2 [SOLVED]

(Yatta_Yatta-O_o) #1

Mysterious Command Post of Doom, 2 : The Return !

Now that seriously puzzle me … maybe you read my other post about the strange game behaviour when building the CP (solved issue) ?
Well, it strikes again !

Heres the issue, I have a tank using the globalaccum 8 bit 2 as an information of being able to go forward or not (barriers or whatever).

Now heres the Axis command post script :


const_cpx_canyon
{
	spawn
	{
		wait 200
		constructible_class 2
		constructible_constructxpbonus 10
		constructible_destructxpbonus 10
		constructible_duration 7000
		constructible_chargebarreq 1
	}
	trigger setup
	{
		setstate const_cpa_canyon_built invisible
		setstate const_cpx_canyon_built invisible
		setstate const_cpa_canyon_model invisible
		setstate const_cpx_canyon_model invisible
		setstate const_cp_canyon_antena invisible
		setstate const_cp_canyon_closed_model default
		setstate const_cp_canyon_t default
	}	
	buildstart final
	{
//		setstate const_cpx_canyon_built underconstruction
		setstate const_cpx_canyon_model underconstruction
		setstate const_cp_canyon_antena underconstruction
		setstate const_cp_canyon_closed_model invisible
	}
	built final
	{
		setstate const_cp_canyon_t invisible
		setstate const_cpx_canyon_built default
		setstate const_cpx_canyon_model default
		setstate const_cp_canyon_antena default
		wait 100

//		wm_announce	"<> ^3Axis Command Post constructed. Charge speed increased!"

		// *----------------------------------- vo ------------------------------------------*
		wm_teamvoiceannounce 0 "axis_hq_compost_constructed"

		wm_teamvoiceannounce 1 "allies_hq_compost_constructed_axis"

		wm_removeteamvoiceannounce 0 "axis_hq_compost_construct"
		// *----------------------------------- vo ------------------------------------------*
		wait 100
		setchargetimefactor 0 soldier 0.7
		setchargetimefactor 0 lieutenant 0.7
		setchargetimefactor 0 medic 0.5
		setchargetimefactor 0 engineer 0.6
		setchargetimefactor 0 covertops 0.6
		wait 200
		}

	death
	{
		trigger self setup
		setchargetimefactor 0 soldier 1
		setchargetimefactor 0 lieutenant 1
		setchargetimefactor 0 medic 0.8
		setchargetimefactor 0 engineer 0.9
		setchargetimefactor 0 covertops 0.8
//		alertentity const_cpx_canyon_obj
		wm_announce	"<> ^3Allies team has destroyed the Axis Command Post!"

		// *----------------------------------- vo ------------------------------------------*
		wm_addteamvoiceannounce 0 "axis_hq_compost_construct"

		wm_teamvoiceannounce 0 "axis_hq_compost_damaged"
		// *----------------------------------- vo ------------------------------------------*
	}
	decayed final
	{
		trigger self setup
	}
}

Well do you see anything refering to a globalaccum 8 bit 2 change ? or any accum stuff at all ? Neither are there accum scripts isnt it ?
Well, once the command post is fully built, the globalccum 8 bit 2 is set. I dont know how.

I’ve checked all stuff (script & entities) related to the constructible, none is calling any other script or targeting another entity that would.
This script was copied from my allied command post script (wich uses the same trigger_objective_info to be built), only altering it to fit the axis command post. When the allied command post is built, everything’s fine.

I’ve checked my whole script for anything messing with the globalaccum 8, and found nothing.
My scripts does extensive use of globaccum 8 bits, other bits than #2 seems fine.

When the command post is destroyed, the value is back to normal.
I’ve made a hack in my script manually setting globalaccum 8 bitreset 2 once the CP is built, but in a certain situation this can lead the tank to go accross a built barrier. Works, but this fix is temporary, until I find the cause.

Its probably that I’ve missed something during my checks, but Ive checked quite a lot already … so, any suggestions ?

(sodsm live) #2

unless you post all of the script that references “globalaccum 8” then i could only guess at what the problem is. did you accidently use set instead of bitset somewhere?

(Lanz) #3

Globalaccum 8 is invalid since there’s only 8 available global accums from 0-7. You should probably have an error in the console saying something like “G_Scripting: accum buffer is outside range”.

(sodsm live) #4

8 is fine, so is 9. you have from 0-9. the error should say “…0-10” even thought it’s only 0-9. unless you are on an old mod.

(Yatta_Yatta-O_o) #5

Works now … I really dont understand. Maybe I did some kind of file version error at some point ? Im quite los on what happened now, but I suspect it’ll happen again sometime =(

(Lanz) #6

Ok, I’ve checked the source code and there’s an overflow bug in the global accum code that gives the random result you experience Yatta_Yatta-O_o.

Here’s the problem, there are two defines in the code:


#define	MAX_SCRIPT_ACCUM_BUFFERS 8
#define	G_MAX_SCRIPT_ACCUM_BUFFERS 10

Then the array is defined for global accums:


int globalAccumBuffer[MAX_SCRIPT_ACCUM_BUFFERS];

BUT, in the code G_ScriptAction_GlobalAccum that handles… global accums… doh! it actually test the global accum array against G_MAX_SCRIPT_ACCUM_BUFFERS and allows an overflow resulting in writing in undefinded memory that can lead to all sorts of problems.


	bufferIndex = atoi(token);
	if (bufferIndex >= G_MAX_SCRIPT_ACCUM_BUFFERS) {
		G_Error( "G_Scripting: accum buffer is outside range (0 - %i)
", G_MAX_SCRIPT_ACCUM_BUFFERS );
	}

So once again global accums goes from 0-7, anything else results in undefined behavior as you have seen in your script.

(Yatta_Yatta-O_o) #7

Omg Lanz, thanks for the source investigation ! Altough this means im in trouble now @@
I have to move all globalaccum 8 bits to other accums with free bits left … sounds like a risky operation, better be very attentive not to make any mistakes << That also means it will get tricky to add other objectives or special stuff in my map regarding the now restricted accum capacities.
Or time to make use of normal accums instead of only globals =P

(Lanz) #8

Np, I hope you find a way to free up a few accum bits in your script.