How to script a historic event message to open?

[Taiji]

I need to find a way to open a historic event message when it appears, my first one opens but subsequent ones do not.

Does anyone have an idea how to do this?

I failed to find a way to do it by selecting ui elements. I can't seem to find the event message element to be able to simulate a click on it, for example.

Any help is appreciated

[irishron]

In my experiences of trying to get them to fire, I have found (1)if more than one entry for a turn, only the first one fires, (2) if an event has more than one date like Mongols appearing, any others inside those dates does not show, and (3) the eathquakes of Anatolia and Alexandria only show if you are there to witness it for vanilla.

I have not tried adding any.

[Taiji]

Thanks for responding, IrishRon,

Currently in DLV we have a load that fire at the start of the campaign, when exiting one the next one pops up fine. Also we have some attached to the finance button, quite a few, that open the next as you close the last.

But I've scripted a menu using yes/no historic events which allows cycling through 5 options. And it's with this that the problem appears. The first option opens perfectly but when it fires the next option that new option just slides silently down the side of the screen without popping up.

It's workable as it is but it just feels wrong to me. My vision for it was of this menu using instant popups, and even then it still looked almost too clunky in my mind's eye. But now I've seen the effect of the 6 state recruitment rate system that it controls... I really have to have it!! So I will put up with it, but if I can find a solution then I'll be very happy indeed

[irishron]

I have not looked at it.

I have about every region on the map to have the plague and so far it is working.

What I am about to say has to do with Win 95/98 than XP but I believe what you are descibing sounds a little like it.

I have the old ABPA Baseball game for DOS and Windows and the code never got to XP.

One of the players wanted to automate the season schedule for rainouts, doubleheaders, starting lineups, trades and injuries to keep those as accurate as posssible. The only way the company wiould let him do it is with "hooks" to the hardcode instead of letting him adapt the hardcode. It may wotk for the first 50 days of the season, loses the "hook ', and merrily carries on without ever seeing his program again. I feel like we are dealing with a similar issue.

If this makes sense to you, my thinking is the game's code because of memory allocation constraints can only handle x amount of options at one time before it throws up its hands and quits on us.

I do like what you, G5, and others have done scripting to make this game work "right" and I am still trying to learn. If I can pass along my observations and experiences, hopefully they help.

[Taiji]

Not sure I follow completely, but yes, this does look like a conflict of some sort. Initially I thought that it might begin to work if I split the launching of the next event outside the '_accepted' monitor where it previously resided. But that didn't work, and had the weird effect of requiring a click on the initial trigger button to get to the next menu level in my script... Very odd, I must have something to learn there...

Sorry if that lot is confusing, I'm confused...

About script conflicts of the sort you mention, I think I'm at 10000+ if statements in my CS. From what I remember right now, there hasn't been a stability issue that I haven't been able to fix by creating trackers that allow if statements. The basic idea is that anything we need exported from an event gets a tracker - a monitor which monitors the event and records the export on a counter. That way we can if statement anything. So no more problems with conflicts because everything gets fired sequentially

Perhaps I am being lazy but to me that means that the exact nature of conflicts within scripts doesn't matter - They just don't happen if we 'if' it (That sounded like an advert )

[irishron]

I can follow it a little because of the old fi-then statements in BASIC but that is a long time ago.

Now I am having to learn all over again even if I can follow the logic some. The only changes in my CS so far are the ones I did to the Mongels and Timurids and BBB's family tree pricess triggers.

One nice things firing seguentially is if one does not fire, you know where to look. Good luck on your quest.

[Taiji]

Yep, no different. It's just stringing 'if-then' processes together to avoid them happening simultaneously.

Then it's odd stuff, that's actually intuitive if you think about it. Like you don't want to run a command with an if statement either side of it, put it at the end. If statements come in strings and they come before any commands. They may still work in some situations with a command coming before 'if' but, with enough potential conflicts going on, it may fail. I say it's intuitive because we already know not to put commands before conditions, and if statements are conditional.

I doubt there's much more to them than that. And the thing whereby exports are not carried through if statements, but that's what an export-tracker-counter monitor is for, so that's covered.

Scripting isn't difficult. And the error messages the system generates are usually very helpful, plus we have the docudemons, and loads of samples in the community. And GED's script replicator, which allows me to make a load of mistakes extremely quickly (not the fault of the tool)

And check this out, this is really nice and useful:

Command line: C:\>for /L %i in (16000,1000,32000) do @echo %i >>16-32.txt

That will create a 16-32.txt file in c:\ with a list of numbers from 16000 to 32000, in increments of 1000. I found it useful in conjunction with GED's script replicator, making duplicate entries for historic events that pop up with costs, making the scripts that create and compute those costs. Very useful little trick

edit:

I am still stumped on this problem, if anyone has an idea of the cause of the problem, or a solution, then please let me know

[The Bruce]

And GED's script replicator, which allows me to make a load of mistakes extremely quickly

I never thought such an esoteric thread on scripting could actually make me laugh out loud!

[irishron]

True.

The command line I had forgooten about. Thank you for reminding me.

[Gigantus]

Check this little note in descr_event_images:

;; importance - messages marked as high importance will open immediately they appear on screen, unless more messages
;; of high importance are displayed, in which case they will open as soon as the others are closed down

[Taiji]

Check this little note in descr_event_images:

;; importance - messages marked as high importance will open immediately they appear on screen, unless more messages
;; of high importance are displayed, in which case they will open as soon as the others are closed down

That file only seems to respond to hardcoded event strings. Sadly it's of no use, unless I've missed something. There's lot's of nice things I could do if this file worked with individually named historic events. BTW I've already explained that historic events in general are functioning in terms of popping up, and this file would also be useful if that wasn't the case. But the problem is with my menu.

Thanks for the suggestion though

[redxavier]

Which command are you using? Try simply 'historic_event pop1 true' rather than the 'add_events' method.

[Augustus Lucifer]

This is just a stab in the dark, seeing as I've been out of practice for quite some time and stumbled drunkenly into this thread. I remember hearing somewhere that when an event is tied to the clicking of an accept/decline, the problem is that it will try to fill the same space before it clears, fail to do so, and then minimize to the side. Not sure why this is different than events independent of one another that don't fire off accept/decline, but it seems to be.

The solution, as I recall and as seems to be suggested by one of my scripts, is to add a wait line before each historic event firing. This basically tells the game to wait on the script long enough for the screen to catch up to the event trigger. One second seems to be sufficient, like so(bold preceding the event is the important part, the rest just shows context):

;Prompt player for Military(Accept) or choice of Economic/Cultural(Decline)
monitor_event FactionTurnStart FactionIsLocal
		and I_CompareCounter policy_timer == 0
		and I_CompareCounter military_exhaustion == 0
	
	campaign_wait 1
  	historic_event policy1 true
end_monitor

;If Accepted, set to Military policy
monitor_event EventCounter EventCounterType policy1_accepted
		and I_EventCounter policy1_accepted == 1
	set_counter policy_timer 20
	set_counter military_policy 1
	set_counter economic_policy 0
	set_counter cultural_policy 0
	set_counter recovery_policy 0
	set_counter current_policy 1
	set_counter policy_change 1
	set_event_counter policy_event_counters 1
	;Below lines governs military exhaustion
	inc_counter military_exhaustion_compiler 1
	set_counter last_policy_delay 3
	
	set_event_counter policy1_accepted 0
	campaign_wait 1
	historic_event military_policy
	
end_monitor

;If Declined, prompt for Economic(Accept) or Cultural(Decline)
monitor_event EventCounter EventCounterType policy1_declined
		and I_EventCounter policy1_declined == 1

	campaign_wait 1
  	historic_event policy2 true
	set_event_counter policy1_declined 0
end_monitor

As a general rule it's not a bad idea to space conflicting and buggy commands with wait times to see if it fixes the problem, since wait times of a second aren't really noticed by a player but is plenty of time for a computer to perform necessary cleanup operations.

[Gigantus]

That sounds like a cool move - I will implement that in my 1648 script.

[Taiji]

That works fine AL, thankyou very much

BTW campaign_wait 0.5 is a little snappier (and 0.1 didn't work)

Very happy to have this thing working the way I wanted, again my thanks