Portal System v2.5

[Moderator]

17th October
Bribe: An intricate system which has been tested and refined to work properly. Thanks for contributing these resources of yours!

 

[Arad MNK]

We had another Portal system. However must see if this is similar or not.

 

[Spellbound]

Well I did do a search for Portal and I did find one that was pretty cool. Mine tries to recreate a Nydus Canal from sc1.

 

[Chaosy]

Hm.. seems like too much code considering how simple this is.

You COULD pick all portal unit types and check for every unit close to it. Teleport to connected portal.. and that's that. That's five actions (+ leak removal) or something.

If I were to make it perfectly efficient I would create a trigger for each portal with the event unit comes within range..
Kind of hard to describe with words but something like this, concept wise:

function Teleport takes nothing returns nothing
	call SetUnitX(...)
	call SetUnitY(...)
endfunction

function CreatePortal takes nothing returns nothing
    trigger t = CreateTrigger()
    call TriggerRegisterUnitInRangeSimple( gg_trg_Untitled_Trigger_002, 100, CreateUnit(...))
	call TriggerAddAction(t, function Teleport)
endfunction

 

[Spellbound]

Well I've only recently came across event-creation, and honestly i have no idea how it works, so I'm using a system Wietlol made for me. I guess if I understood how to make it work, I'd be able to streamline the code better, but alas I don't know how to code in JASS.

 

[Chaosy]

You can do it in GUI too.

You just need to create the trigger in jass.

 

[Spellbound]

Yeah but Wietlol made a whole trigger for me for call TriggerRegisterUnitInRangeSimple( gg_trg_Untitled_Trigger_002, 100, CreateUnit(...)) to work. How would I even replace DynamicEvents when I don't know how to code it :\

Or are you talking about something different? I'd rather not use timers if I can avoid them.

 

[Chaosy]

Well, I did the following. This is only handles teleportation for now, I will work more on it when I am bored. Point being that the code is much shorter.

library portals initializer myInit

	globals
		private hashtable h = InitHashtable()
	endglobals
	
	function Teleport takes nothing returns nothing
		local unit u = LoadUnitHandle(h, GetHandleId(GetTriggeringTrigger()), 1)
		local real x = LoadReal(h, GetHandleId(u), 2)
		local real y = LoadReal(h, GetHandleId(u), 3)
		call SetUnitPositionLoc(GetTriggerUnit(), PolarProjectionBJ(Location(x, y), 260, GetRandomDirectionDeg()))
	endfunction
	function ConnectPortals takes unit u, unit u2 returns nothing
		call SaveReal(h, GetHandleId(u), 2, GetUnitX(u2))
		call SaveReal(h, GetHandleId(u), 3, GetUnitY(u2))
		call SaveReal(h, GetHandleId(u2), 2, GetUnitX(u))
		call SaveReal(h, GetHandleId(u2), 3, GetUnitY(u))
		
	endfunction
	
	function SetPortal takes unit u returns nothing
		local trigger t = CreateTrigger()
		call TriggerRegisterUnitInRangeSimple(t, 150, u)
		call TriggerAddAction(t, function Teleport)
		call SaveTriggerHandle(h, GetHandleId(u), 1, t)
		call SaveUnitHandle(h, GetHandleId(t), 1, u)
	endfunction

	private function myInit takes nothing returns nothing
		call SetPortal(gg_unit_hhou_0000)
		call SetPortal(gg_unit_halt_0002)
		call ConnectPortals(gg_unit_hhou_0000, gg_unit_halt_0002)
	endfunction
endlibrary

 

[Retera]

Of course, the danger to wanting the shortest code possible is that before too long somebody might come along with a library that lets you write even shorter code. For example, suppose you had a library SlickCommon that provided a more object oriented approach to many of the functions in common.j. You could express even the vJASS you just posted with even less code:

library portals initializer myInit requires SlickCommon
	struct PortalTransportTrigger extends Trigger
		private real destinationX
		private real destinationY
		public static method create takes unit portal, real destinationX, real destinationY returns PortalTransportTrigger
			local PortalTransportTrigger this = .allocate()
			set this.destinationX = destinationX
			set this.destinationY = destinationY
			call this.registerUnitInRange(150, portal, null)
			return this
		endmethod
		public method doActions takes nothing returns nothing
			local real ang = GetRandomReal(0,bj_PI*2)
			call SetUnitPosition(GetTriggerUnit(), destinationX + Cos(ang)*260, destinationY + Sin(ang)*260)
		endmethod
	endstruct
	
	private function myInit takes nothing returns nothing
		call PortalTransportTrigger.create(gg_unit_hhou_0000,GetUnitX(gg_unit_halt_0002),GetUnitY(gg_unit_halt_0002))
		call PortalTransportTrigger.create(gg_unit_halt_0002,GetUnitX(gg_unit_hhou_0000),GetUnitY(gg_unit_hhou_0000))
	endfunction
endlibrary

 

[Chaosy]

@Retera
I am usually not a performance greedy guy, but when you can make a system more efficient while being a bit shorter.. then I feel like improvement is needed.

 

[Retera]

Sorta makes sense, just gotta be careful. Speaking of performance, your sample code leaks a location handle every time a unit steps through a portal because the inline call to PolarProjectionBJ creates a new location handle that is never destroyed. Might want to warn people who use it to fix that.

 

[Chaosy]

I know of the leaks, I am simply lazy. Fixing leaks are last touch things can I create things.

 

[Spellbound]

Honestly I'd love to be able to turn this into a vJASS thing where you just go something like call ConnectPortals (GetTriggerUnit(), GetTargetUnitorwhatever(), range, effectin, effectout, effectactive) but I have NO idea how to even go about doing that. I mean, I'm still not sure how creating events work.

 

[IcemanBo]

Alone the installation looks quite specific, hardcoded and restrictive, if you ask me.
Systems should be as configurable as possible to be compatible for more different requests.

Like this event system now. When you use/need other systems, link to them so we can check them out.

 

[Spellbound]

Alone the installation looks quite specific, hardcoded and restrictive, if you ask me.
Systems should be as configurable as possible to be compatible for more different requests.

Can't really argue there, though I'm not sure what I could do to make it more configurable. If anyone has any ideas, I'll see about implementing them if I can.

Like this event system now. When you use/need other systems, link to them so we can check them out.

I... I did... in the documentation :|

 

[BPower]

I once submitted a portal system, which honestly needs an update .
I'm going to check your code soon

 

[Spellbound]

I'm actually thinking of using a timer everytime a unit right-clicks a portal so that people won't have to use DynamicEvents and edit the variables for the accompanying trigger, but would that be a worthwhile update? It would make the installation less annoying, but... periodic timers.

EDIT: Updated to version 2.0!

 

[Spellbound]

Changes made.

 

[Wietlol]

Lol, this is not something that you should use that Unit In Range event for actually
I made that to show you how to do that for units that are created throughout the game that require something better than pick every unit in range and give you the event response to give the unit that the target came in range of.

In this case, using smart would work the best imo.

 

[Spellbound]

It's not using DynamicEvents anymore. I should point out that the thing about this system is that it gives you buildable portals that you can connect, reconnect and disconnect as you see fit.

I haven't actually looked at the code of DynamicEvents either though I don't know how to read JASS (at least I didn't know then). I might take a look at it now, but I doubt I'm that more enlightened since then

Anyway, it works the way it should now (hopefully). Waiting for that mod mark of approval

PS: What do you mean by using smart? D'you mean right-clicking the portal when the unit is in range?

 

[Spellbound]

UPDATE v2.2
• Portal_index changed to Portal_ConfigIndex and is used only in configuration. Portal_INDEX_CASTER/TARGET/TRAVELLER were added to use as index in the rest of the system.
• Added a failsafe to prevent movable portals (like the owls) to use portals while connected as this seemed to bug out their own connections. Disconnect them to allow them to use portals.
• Checks to see whether portals are connected in the configuration now, rather than in the connection trigger. This is to avoid switching out values from portals that are already connected. I'm afraid there's no way around this.
• GUI AutoFly no longer needed. Add storm crow form to your dummy units to remove the need for autofly on dummies. (This is for reducing the amount of requirements for the system. I recommend having autofly in your maps regardless as if may come in handy in other places).

Also made some small changes here and there to fix some bugs.

 

[Bribe]

Spellbound, I've tried using the missile-based teleportation method but it always deselects the unit once it's teleported. I think it has to do with hiding the unit. Is there any other way to do it? Perhaps you could add a button to the teleporter to select the most recently teleported units.

 

[Spellbound]

I could make the missiles invulnerable instead of unselectable and attach the value of the units to them. If they are still selected when destroyed, select the units as they are unhidden.

 

[Spellbound]

UPDATE v2.3
• Portal missiles no longer use locust and instead of made invulnerable unless they are made targetable.
• Portals now retain unit selection.
• Updated screenshot

 

[BETABABY]

I could make the missiles invulnerable instead of unselectable and attach the value of the units to them. If they are still selected when destroyed, select the units as they are unhidden.

Well, I'm no expert but I think you still can retain the locust and making the unit hidden part. Just put an action in the trigger where it selects the teleported unit after it has done teleporting.

 

[Spellbound]

Then it would select even if you don't want them to be selected. The way it currently is, if you deselect the missile, it won't select the unit when it reappears. If you use locust it will reselect regardless. You have more control that way.

 

[Spellbound]

UPDATE v2.4
- Added a new variable to handle the Sever Connection ability since that had to be set manually if the id of the spell was not to same per map. Set it in Portal Connect at the top. That method also allows you to use whatever no-target spell you want to disconnect portals.
- Move Portal Periodic trigger up to facilitate installation as some functions were being disabled on import bcz world edit is dumb.
- Portal Connect is no longer optional. Not sure why it was in the first place...
- fixed an issue where non-flying missiles would get stuck on units.
- Updated README.

 

[Mirage1]

First thing: Nice system, very useful to me

I tested the map and I found a bug when a ground unit is teleported. When the unit reaches its destination it begins to walk in little circles when turning. It also (more rarely) cause the unit to literally walk in circles when trying to execute an order to attack.

Note: I've used the missile teleport from Arcane Vault and don't know if the others have any bugs.

 

[Spellbound]

Hmm, I've been unable to replicate the bug. Could you tell me what units you used/what portals were used, or anything else you can remember?

 

[Mirage1]

The unit I've used was the Spell Breaker and the Sorceress (don't know if Fly movement based units are affected). The unit that walked in circles when trying to attack was a custom demon hunter. The difference appears after using the portal. The unit walks one way before using the portal and another after using the portal (forming a subtle arc to turn around).Literally walking in circles is rare but it happened once or twice (try replicate with a melee unit maybe you see). I think when the turning bug is fixed the unit won't walk in circles anymore. I tried to fix myself but I could not figure out where the bug is.
The portal I've used was the Arcane Vault Missile one, not the instant one.

I hope I helped a bit =D

 

[Spellbound]

Okay, fixed. At first I couldn't tell what you meant by walking in little circles, but eventually I noticed the slight bobbing in a direction when the unit turned. The issue was being caused by SetPropWindow, which in retrospect was a pointless function to use here since flying units are going to drift away from one another regardless of whether the PropWindow is 0 or not. Damn flyers /shake fist

UPDATE v2.5
- Fixed a bug that caused units to do a very slight arc when turning after using a Portal.

 

[Mirage1]

Now it's working properly. Thanks for fixing
Sorry for any confusion in the bug description

 

[Spellbound]

You're welcome, and no problem at all

 

[The General]

It's a good spell but how do I configure it?

 

[Spellbound]

It's explained in the README under CUSTOMISATION. Look at the Connect Portal 1 trigger to see what can be customised.

Specifcally, look for this:
All variables within is described.

• -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- --------
• -------- CONFIGURE HERE --------
• -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- --------

 

[Eagle XI]

Great work.
Extremely useful for rpg type maps as it can be used for flight paths or an fast-travel system inplace of the usual instant teleportation.
Thanks to you i can finally link those highelven waygates.
(maybe i should update that map sometime)

 

[Spellbound]

You're welcome

 

[Spellbound]

NB: This system can be considered deprecated in favour of CustomWaygate v1.04. However, CustomWaygate does not have an in-built missile system, is coded in vJASS and has a few requirements. I'll keep this here for those who prefer something in GUI.

 

[tlstkwjr]

Hello. I applied this to my map but some units stop on their way. In your test map, all units are naturally teleported with a single command. do you know what the problem is? thanks.

 

[Spellbound]

Can you describe the issue in more detail? Posting your triggers would also help.

 

[tlstkwjr]

I found problem. If the portal unit is walkable, there is a same problem of mine.
I hope others who apply this system do not make the same mistakes as me.

 

[tlstkwjr]

Hello. I am trying to use this system, but there is a problem with making the neutral portal unit. In one direction, unit moves normally, but in the other direction, the unit does not return and is teleported to its original position.
How can I solve this problem and use neutral portal unit? It works perfectly when the portal is playerself-owned.
To tell you the exact situation, attach a map that is causing the same problem.

 

[Spellbound]

Well, at first glance, in PortalTarget, the conditions only pass if the portal unit belong to an ally. Wrap this line in a Or block and add a condition that checks for neutral ownership.

 

[Unregret]

I currently use Vexorian's Table, and also tried to apply this system. It takes many custom scripts using this.flush(key), wanna know how to keep these two Tables compatible without any conflict.

 

[Spellbound]

This system doesn't use Table though... did you mean CustomWaygate v1.04?

 

[Unregret]

This system doesn't use Table though... did you mean CustomWaygate v1.04?

I must be mistaken. Since this system is required less thing to work, is there any part of this system that only allow specific units for teleportation?

 

[Spellbound]

There shouldn't be any unit id/type restrictions, if that's what you mean. The only restrictions are that the portal unit and the traveller have to be allied and that the traveller cannot be a building. You can modify those conditions in Portal Target trigger.

 

[Mediumunwell]

I reproduced a bug that is occuring in my map in your test map. I wanted to make the portals change ownership to an allied computer player when any user player walks in range. When I input this into your map it causes you to no longer be able to teleport from the casting portal and the casting portal also leaks a spell effect that never gets destroyed. You can still teleport from the targeted portal of the link spell and then the targeted portal will destroy it's spell effect, but the caster one as I said will leak even when you use the unlink spell. I thought it would be an easy fix for you since you made it. I've spent, too long trying to find the issue to no avail. I probably need sleep.

Edit: I finally thought of a possible workaround after seeing again that it does at least work when the portals don't start as neutral passive. I'm going to try having them either just be created when the user walks in range. Or start as CPU, then switch to neutral passive and re-create FoW on that region.

Edit 2: The starting them as my computer ally, switching to neutral passive at 1 sec in (already have too much at init and at 0 sec I feel idk) and creating a FoW after a sec wait totally worked. I am very happy. Thank you for this system. I was going to use the vJass one but I have too many libraries and am not very sure if I could make whichever ones backwards compatible. I have no vJass knowledge.