Does 1 equal 660 or whatever?

[glowplug]

The video

 

 

The code

scn TrigTest01Script

int iCounter

Begin OnTrigger
	let iCounter += 1
	Message "Triggered %.0f times.", iCounter
	PrintC "Triggered %.0f times.", iCounter
End

 

[DrakeTheDragon]

Hmm, did you step down from the trigger and wait for the remaining 600+ messages to pop up?

 

I'm not 100% sure, but I do recall Oblivion having a message buffer, a queue if you like, and going by what I see in your video it was still running its queue down, just not remotely as fast as new entries came up while still standing on the trigger.

[qwertyasdfgh]

Yeah, I don't see anything wrong. OnTrigger block continues to run every frame for as long as player is standing in trigger area, which is reflected in console log. The messages can't be updated that fast, so it's lagging behind.

[glowplug]

Hi DrakeTheDragon, thank you for your reply.

 

The trigger box is the size of the width of the room, once entered then idle animation will persist. I can repeat this with GameMode anyway. If it were simply a caching delay (queue) on message then I would expect it to jump, not increment asynchronously.

 

What brought this up is that I'm developing a course on CSS/OBSE and stumbled back over it. Back when I was working on Silatari, if I remember correctly, I was trying to get the evil overlord to die several times but his OnDeath was showing different values for the same quest variable as the quest's GameMode. Quest GameMode seems to have a lag independent of it's Priority.

 

Having encountered much the same with a number of managed languages I'm guessing it is a multitask instantiation issue but that's not a very good explanation...really.

The objective is to have one exercise hit the wall due to lag caused by event and/or quest then the next few demonstrate clean and simple solutions. Put the GameMode on a light on the wall instead of a Quest, for example. One will teleport the player to a random cell but solve things by popping an item in/out of inventory using NoSpam - no problem with somebody dropping a quest item if they have absolutely no idea it was ever there.

 

It would, however, be nice to link out to a precise technical explanation but I don't know what that is.

[glowplug]

Yeah, I don't see anything wrong. OnTrigger block continues to run every frame for as long as player is standing in trigger area, which is reflected in console log. The messages can't be updated that fast, so it's lagging behind.

Nothing wrong?

Please, no offense intended but if this were C, Message and PrintC would be pointing to the exact same 16 bits of RAM. Any lag on Message would make it jump in synchronization with PrintC - 1, 132, 345 or whatever.

 

As I replied to DrakeTheDragon, this seems to be some sort of managed code issue.

 

With around 3 decades on a multitude of languages I have the experience to preempt and deal with this in a reasonable fashion. What I would like to do is fast track that in the course.

[qwertyasdfgh]

 

Please, no offense intended but if this were C

 

Well, it's not, so what's your point? When I said "nothing wrong" I meant that the script you posted produced exactly the expected result in the video.

Message command is also called every frame from your script, except that the actual messages are put in queue by the game. In theory, if you wait long enough, you'll eventually see all 800+ of them.

[glowplug]

I hear what you are saying qwertyasdfgh, nothing appears to be wrong. Where it would seem that things will catch up, they won't. Of course it's not C, the values are coming from different blocks of RAM - time will only increase the variation.

My point is that this becomes a problem when an event and/or quest have different values at critical times. Take my custom Black Soul Gem in Indornia that I was told can't be done. Take the asynchronous talking submarine in Harodich - it performs a several minute voyage within millisecond variations with/without the time correction such as OblivionReloaded does.

I'm underway with developing a CSS/OBSE course and that, my friend, is what I will teach.

[glowplug]

I apologize qwertyasdfgh, you are right, it doesn't matter. Having done some more work I realised I was breaking one of the fundamentals of the teaching techniques - short and simple hands on exercises that are easy to follow. I've scrapped the layout for that particular tutorial and will work out something else.

The other point is the need to release a beta at some stage and listen carefully to what anyone says about it. Just as I should have listened to you and thanked you for your input.

Thank you as well DrakeTheDragon. As you say, the message is buffered. The course can mention that but it should go nowhere near how or why.

If there's one thing I can learn here is to stop being pedantic, especially for the wrong reasons.

[QQuix]

If memory serves, sending the same message twice clears the buffer.

 

Good for this scenario, Bad if there is some important message in the buffer.