[easy to use] Skippable Transmission v1.1

[Moderator]

03:01, 5th Jun 2016
Tank-Commander: V1.1 - An interesting submission, I apologise that it's taken so long to get around to reviewing it, please see my post for critique

 

[Daffa]

It's vJass and GUI, which means users need JNGP.

 

[Emm-A-]

thanks for pointing that out. I changed the description and added this information.

The thing is, this somehow aims to help beginners to intermediate map-makers (as I assume, every experienced map maker uses something like this?), so I tried not to scare people away from it by declaring this as vJass ..

Do you think, this is even useful? Should I improve it?
I am happy about any suggestions

 

[Rheiko]

The thing is, this somehow aims to help beginners to intermediate map-makers (as I assume, every experienced map maker uses something like this?), so I tried not to scare people away from it by declaring this as vJass ..

I can see your point but by not doing that, the user will experience problem instead as vJASS requires JNGP and doesn't work with Vanilla World Editor.

Can't give you any feedback for the code, though. I'm not a vJASS user.

 

[Emm-A-]

I could add a non-JNGP version, where you have to copy the function to your map header, and call the Initialization from the GUI init trigger - but I dont know if this will be accepted on the hive? Using vJass for this system is not required but it is simply more convenient to use a library.



EDIT: I uploaded an instruction on how to easily important this system into normal GUI trigger editor in 3 steps.

 

[Chaosy]

Not going to say this is bad, but you'd need to build the entire cinematic around the system which is not exactly what I'd wanted if I'd use this system.

 

[Emm-A-]

Not going to say this is bad, but you'd need to build the entire cinematic around the system which is not exactly what I'd wanted if I'd use this system.

Thanks for sharing your feedback, Chaosy, but can you maybe explain a bit more? All it does basicly, is exchaning the normal transmission call with a skippable one. I dont really understand, where you have to build something around the system?
Do you mean by that, that it is impractical to use the custom script?

 

[Chaosy]

By reading the title I thought someone (you) had come up with a system I could simply add to my map and it would somehow make my transmissions skip-able.

However you'd have to change the entire cinematic (almost). It's not simply" copy and pasting the custom script".
When working with GUI cinematics you usually don't have a variable ready for the text, the player, the unit etc. Thus you'd have to copy over all these things over to the script, it's a fair amount of boring work.

Still, one improvement I'd suggest is the syntax. I strongly suggest to work with structs to use syntax like:
transmission.next.next.next
transmission.prev.prev
That way the user would be able to jump between transmissions freely.

This would still require the user to put effort to make the system work with his cinematic if already started it, but if you create something from scratch I think this would be a better approach.

I got quite motivated by writing this..

edit: something like this:

//! zinc
	library CinematicScene requires TimerUtils
	{	
		type transCallback extends function(integer);
		
		function daCallback(integer this, transCallback c)
		{
			c.evaluate(this);
		}
		
		public struct Scene
		{
			thistype next;
			thistype prev;
			
			force p = bj_FORCE_PLAYER[0];
			unit u;
			string name, msg;
			real time = 3;

			transCallback callback;
	
			static timer countdown;
	
			static thistype last;
			
			static boolean first = true;
			
			static thistype current;
			
			static method onNext()
			{
				thistype this = GetTimerData(countdown);
				DestroyTimer(countdown);
				this.next.Start();
			}
			
			method Start()
			{
				current = this;
				this.name = GetUnitName(u);
				TransmissionFromUnitWithNameBJ(p, u, name, null, msg, bj_TIMETYPE_SET, time, false);
				if(callback != null)
				{
					daCallback(this, callback);
				}
				countdown = NewTimerEx(this);
				TimerStart(countdown, time, false, function thistype.onNext);
			}
			
			static method create() -> thistype
			{
				thistype this = thistype.allocate();
				p = bj_FORCE_PLAYER[0];
				if(first == false)
				{
					last.next = this;
					last.next.prev = last;
				}
				else
				{
					first = false;
				}
				last = this;
				return this;
			}
			
			static method onInit()
			{
				countdown = NewTimer();
			}
		}		
	}
//! endzinc

//! zinc
	library MEGADEMO requires CinematicScene
	{
	
		function RestartCine(Scene s)
		{
			s.next = s.prev.prev; //aka going back two scenes
                       //I could set s.callback to null here to save some performance since this only needs to happen once.
		}
		
		Scene sOne, sTwo, sThree;
		
		function onInit()
		{
			unit test = CreateUnit(Player(0), 'hfoo', 0, 0, 0);
			
			sOne = Scene.create();
			sTwo = Scene.create();
			sThree = Scene.create();
			
			sOne.msg = "Da dum tss 1";
			sOne.u   = test;
			
			sTwo.msg = "Da dum tss 2";
			sTwo.u   = test;
			
			sThree.msg = "Da dum tss 3";
			sThree.u   = test;
			sThree.callback = RestartCine;
			
			sOne.Start();
			
		}
	}
//! endzinc

This little script will cycle through three transmissions. But I could manipulate them in any way I wanted I could skip the middle one entirely etc, play them backwards.

 

[Emm-A-]

Ah, now I see, what you mean - and thanks for this intense feedback.

I still think, that using this system is not that much work, but I get your point.

I do not feel comfortable in oop yet to release code in that style. Maybe you want to finish your proposed system? You are right, it has much more potential than my system, but on the other hand, its more expertly code would make it less attractive for gui users, I guess.

edit:

By reading the title I thought someone (you) had come up with a system I could simply add to my map and it would somehow make my transmissions skip-able.

I wrote easy to use not easy to implement

 

[Rheiko]

I wrote easy to use not easy to implement

I was hoping easy for both.

 

[Chaosy]

You are right, it has much more potential than my system, but on the other hand, its more expertly code would make it less attractive for gui users, I guess.

I suspect that this is true. Using my method in GUI is not the best of choices I guess. But in a way I think it's easier to use if you understand the syntax.

edit: updated my system I can now use this to skip transmissions:

• Demo 2
  • Events
    • Player - Player 1 (Red) skips a cinematic sequence
  • Conditions
  • Actions
    • Custom script: call DestroyTimer(Scene.countdown)
    • Custom script: call Scene.current.next.Start()

 

[Emm-A-]

You only have to make it MPI now, Chaosy.

Chaosy
I think it's easier to use if you understand the syntax.

I actually experienced quite often, that oop systems scare away gui users, even if they only had to use custom scripts, because there is no way, most people get what you coded.
But yeah, your system is neat.

I just thought of a way, we can recognize, if a player is in a cinematic. Maybe ForceUIKey or ForceSelection or something like this works. I am going to try ...

Rheiko
I was hoping easy for both.

Sry On the other hand, it is not that bad. I actually tried it. It pays out for longer cinematics though, because you have to set most variables only once.

I mean, if you compare it to all these classic tutorials and threads on how to make cinematics skippable, my system is actually both, easy to implement and use.

Edit: Also, I provided a version, which you can actually use with normal Vanilla GUI (without JNGP) in a very flexible manner and in GUI style. It is easy to follow through. This is a clear advantage over the vJass variants for GUI users

 

[Chaosy]

Cinematics are very very rarely used in a MPI scenario. All players are mostly shown the same cinematic.

 

[Emm-A-]

then I would suggest to use bj_FORCE_ALL_PLAYERS instead of bj_FORCE_PLAYER[0].

MPI is something, I was actually aiming for. Think of an ORPG for example. Every player may be involved in some conversation, which may be skipped independently from each other.

 

[Chaosy]

bj_FORCE_PLAYER[0] is the default value it can be changed by sceneVaraible.p = some other force

I get what you mean, I think I know how I can implement it fairly easy.

 

[Bribe]

Does this support waiting to skip the cinematic until all players have successfully escaped out of it?

What you can do is make the system queue up codes or function name strings and run them via TriggerExecute/Evaluate or ExecuteFunc (depending on your preference). Something like "CinematicAddScene". This way, the cinematic skipping can be handled internally by this system, and you'd use a "CinematicCleanup" behavior to remove any extra features not needed by the system.

 

[Emm-A-]

Hi Bribe,

thank you for your comment.

Does this support waiting to skip the cinematic until all players have successfully escaped out of it?

No, but I thought of implementing this. Right now, it is completely independent.
I did not add this, because I was not sure about a good solution. Now that you mention it, I am thinking of adding a check up for each single transmission, that waits for all other player. Is this kind of synch, what you suggested?

What you can do is make the system queue up codes or function name strings and run them via TriggerExecute/Evaluate or ExecuteFunc (depending on your preference). Something like "CinematicAddScene". This way, the cinematic skipping can be handled internally by this system, and you'd use a "CinematicCleanup" behavior to remove any extra features not needed by the system.

To get rid of the TriggerSleepAction?

 

[Bribe]

One could still use the sleep action with TriggerExecute or ExecuteFunc.

 

[Tank-Commander]

Going over the criticisms made I'm going to summarise the key points of issue for the system at the moment:
- While being described as easy to use

• Custom script: call CIN_PLAYER_CINEMATIC( udg_CINE_PLAYER, udg_CINE_SCENE_FADEOUT_KEEP_UI, 0.25, 0.25, udg_CINE_UNIT, udg_CINE_TITLE, udg_CINE_TEXT, udg_CINE_TIME, udg_CINE_SOUND[2], udg_CINE_SKIPPABLE)

isn't a particularly friendly looking line, while arguably less efficient it'd probably be better to have all those things applied to globals and then use a simple function call (e.g. CIN_PLAYER_CINEMATIC()) after all of those things have been set up
- I strongly endorse Bribe's suggestions for both his suggested feature and handling method, it would improve the system's applicability and ease of use (particularly because it's plausible that people would want to add optional skipping as an afterthought rather than beforehand)
- Alternatively I'd suggest a structure similar to Chaosy's method, though I know you've stated your not entirely comfortable with OOP to that degree. though I'd place this second as I wouldn't want you to go through with the extra effort only for it to be superseded by Chaosy's before you finished
- I would strongly recommend against the use of TSA given its inconsistencies
- You have an inefficient IF structure in your code (most notably at the interfaceMod section where you filter using GetLocalPlayer in a nested IF statement when it could be on the other side of the nesting and be more efficient

other minor comments:
- You have some needless nulling of handles which don't need to be nulled in your script (player variables & triggers don't necessarily need to be nulled, only if that trigger is to be destroyed is it needed), you also only need to null a handle when it's set to something (the timer in the main function)
- Your code is very compressed, I'd suggest spacing it out more to be more readable
- Please also list the GUI version in the trigger listings as I need to also go over that one if it is to be submitted with it
- Your filename should match your version number

 

[Emm-A-]

hey Tank-Commander, thank you for this review and your time!! and again thanks to everybody else commenting!

As I am currently working a lot on a map of mine, I dont really have the time to include all your suggestions atm., and I was a bit undecided of what to do as well. I will not forget this and will upgrade it later, but you may graveyard it 'till then, if you need to.