[Request] Edit .wld and Portal

08/20/2014 03:10 castor4878#31
Unity 3D is a tool on which I'd like to spent time, unfortunately I spent quite all my time on warm water - you know when you have to figure out what is already known.

regarding portal:
- you must insert a portal def in wld to have the client triggering the server (requesting the server for a teleport) when the toon enters the area; client transmits index of portal (and likely toon coords).
the svmap must have a portal at the +/- same coords for that index. teleport is done with the target map ID & coords of the svmap.

to have a portal building drawn, you must have that .smod portal inserted at the right place
to have the visual effect (the red rift) you have to insert an effect (usually #1) at the right coords (+/- the center of the portal building)
to have a name displayed, yo have to create a name area and insert caption in <mapID>.txt file with right index (if you insert a 13rd coords, insert a "12 foo" statement).
08/20/2014 15:20 Truth1010#32
Thanks for the extra info there Castor, seems i still can't get a new portal defined in the wld. I can change all the portal data, and have it read properly through a python script to show that the co-ordinates of the portal itself, and it's destination have all changed, yet when i get in game. The "changed" portal is still in it's original place and none functional. There is nothing else other than the wld and svmap that give any data on portals?
I'm lost and confused with all this and seem to just be going in circles changing existing portals through the wld file and getting it reverted back to original as soon as it's all imported to the client and tested.
08/20/2014 16:10 sominus#33
If you make a flat terrain. You'll see back in shaiya how the ground TGAs are patched in a strange pattern. So, there should be a place where it says how every texture will be applied.

A height of ~91 in Unity, translates to 'sea level' in shaiya.

The basics in Unity (for making a shaiya terrain) are:

-New Project (select a folder where files will be saved)
-Select packages (not really needed, I choose Character Controller and Skyboxes, so I can walk the map for testing)
-Create the project
-Once in the IDE got to main menu, GameObject > Create Other > Terrain
-Click the Terrain in the left Panel, and in the right Panel, go to Settings (the gear Icon), and setup the terrain resolution details. (I use the same as in shaiya, 1024 size, 512/3, etc)
-Paint (sculpt) the terrain with the pencil tools there.
-One finished, go to the Settings icon again, and at the bottom there's the Export Raw button.
-Depth Bit16, byte order windows (don't know what this is lol).

The exported file, contains the height data that you must paste in a shaiya WLD file.
e.g. for a 1024 map, data has a 80802H lenght.

So, open the exported raw file in HyD, press CTRL + A, and copy it.

Then open a 1024 WLD (also in HyD), press CTRL + E, start position = 8, lenght = 80802, OK
That will select the height block, just paste the data you copied from the raw file (size should match).

And that's all. Import the WLD back to the client and test.


***Backup your map first, keep in mind that buildings, trees, stones, will be floating in the air after terrain editing (AKA: ruined map)

Edit: Changing the 'global(?)' terrain altitude (unity setting), changes the Unity2Shaiya heights conversions. It's like an altitude denominator or something. I used 512, the default is 600.
08/21/2014 00:37 castor4878#34
Quote:
Originally Posted by Truth1010 View Post
There is nothing else other than the wld and svmap that give any data on portals?
the definition in (svr) svmap is mandatory and defines what is actually done, according a few tests the definition in (client) wld is required to "initiate the request"; only these defs are required - any .smod, anim or waves are just for decoration, the teleport shall work without them.
of course, the portals shall be defined (ordered) in same order in both svmap and wld.

Quote:
Originally Posted by Truth1010 View Post
I'm lost and confused with all this and seem to just be going in circles changing existing portals through the wld file and getting it reverted back to original as soon as it's all imported to the client and tested.
is the modified portal the sole thing that doesn't work?
an error in your edition process is still possible, fortunately most of errors cause immediate crash; still less destructive errors are possible, in such case may be the portal is invalid (and only it if the error is limited to the inserted record) or ""some"" items (all portals, may be the named areas or the NPC, or ...) did you verify the basis of the edited map or only the portal you are working on ?
you can also send me your wld for double-checking if you want.

Here are the min & max heights for all WLD worlds, and the list of uniques "textures (or other) identifiers:

Code:
0	9237	23910	0,1,2,3,4,5,6,255
1	8227	23933	0,1,2,3,4,5,6,7
2	8834	26536	0,1,2,3,4,5,6,7
18	9183	18336	0,1,2,3,4,5,6,255
19	5786	24295	0,1,2,3,4,7
20	5796	28257	0,1,2,3,4,5,255
25	9822	17438	0,1,2,3,4,5,6,7,255
28	7930	21563	0,1,2,3,4,5,7
29	9652	32010	0,1,2,3,4,5,6
30	9424	23229	1,2,3,4,5,6,255
35	9687	26502	0,2,3,255
36	11162	25398	0,3,255
43	-32764	32764	0,1,2,3,4,6
44	9775	23118	0,2,3,4,5,6,7
45	9888	24529	0,1,2,3,255
46	10088	26029	0,1,2,3,255
47	5823	22566	0,1,2,4,255
50	9285	23122	0,1,2,3,255
51	12077	13514	0,1,255
52	12077	13514	0,1,255
64	7430	22926	0,2,3,4,5,255
68	9244	26379	0,1,2,3,4,5,6,7
69	7118	28004	0,1,2,3,4,5,6,7,255
70	9101	19302	0,1,2,3,4,5,6,7,255
75	4753	21712	0,1,2,3,4,5,6,7,255
76	7514	29803	0,1,2,3,4,5,6,7,255
102	9473	17438	0,1,2,3,4,6,255
103	9788	25189	1,2,3,4,5,255
104	9219	26080	0,1,2,3,4,5,255
105	9641	17438	0,1,2,3,4,6,255
108	9641	17438	0,1,2,3,4,6,255
select_a	8995	14034	0,1,2,255
select_b	8995	14034	0,1,2,3,255
the values are quite homogeneous, we can assume that 10000 is the sea level.
the sea is drawn with files listed in the .wtr file; for (actual) sea, the files sea_nn.dds are probably used; for the ground (the grass meadows) may be the same logic apply with file caustNN which are +/- green; still indexes are in (0..3 or 7) while the .wtr lists 31 caustNN files.
08/21/2014 14:08 Truth1010#35
I've sent you a message Castor, hopefully you can see what I'm doing wrong :)
08/21/2014 15:39 sominus#36
Those '0,1,2,3,4,5,6,255' values.
You mean the values in each 513 bytes line, of the second half in the terrain block? (the texture block).

So, 0,2,3... refers to the ground texture index.
Apparently, it forms a grid with squares 4x the size of the height squares.
This is a test writting a '01' on the first byte of the first block (the rest is just 00, until the 'FF' at the end) I've put a wireframe version over it for better viewing.

08/21/2014 18:22 castor4878#37
Quote:
I've sent you a message Castor
I will respond there since it may be interesting for all, and usefull comments can also come from others.

First good point, your map appears valid; no data is (badly) altered.
The second portal definition is changed as well as the X coords of the 1st portal changed from 88.212 to 92.212
For the 2nd portal:
original loc: 49.446; 10.549; 10.862 - 51.446; 12.549; 12.862 (exit to Keo)
new locat°: 84.212; 8.376; 114.413 - 88.212; 10.376; 116.14

with this definition, and IF the svmap contains a list of 3 portals and IF the second portal is defined at the position (+/-) x: 86.212, y: 9.376, z: 115.2, then the teleportation must work.

the svmap coords of portal must be "close / near / in" the wld rectangle coords; I usually set it to the center of that rect. you may have to take care to the azimut (altitude), if the wld range is (unnecessary) too important, the middle can be too high and the server can not success to find your toons in the portal area.

you indicate:
Quote:
When i edit the portal definitions in the WLD the changes appear to be made, but once imported into game, it seems to revert back to the unchanged WLD format, and doesn't allow the original portal to work anymore.
not sure to understand "revert back" as you meant it ...
if the portal doesn't work, either at its old and at the new location, the sole explanation is a difference between the client and the server definition, and that could be because coords are different or because the server doesn't find your toon on the portal sphere (only the center is defined and we ignore the radius, but again if Y is too low or too high, it won't work) ... or because the server wasn't restarted (svmap are loaded once).

or because another "feature" (weakness / bug / ...) of the server, your first and second portals are quite close, even if you moved a bit the first one; may be you are unlucky; if the client always choose to request an entrance to one portal (identified by its coords but mainly as #1) and the server decides you are hover the other (so thinking you can enter in #2) it will refuse the move.
you will avoid such possibility with clearly distinct areas. also adding the effect to the portal location helps to try it (at least for clear gameplay experience, since "center" of portal doesn't mean the same than "center" of effect).

I so change your map, to restore the 2nd portal and to add a 4th portal at the left of the stairs.
its coords are (11,3; 8.5; 114.85) - (13.9;10.9; 117.45); a new effect (56th) with eft:0 is added at (12.6; 10.7; 117.15); you must insert a 4th portal in the 53.svmap file at location (12.6; 9.2; 116.15)

of course I also encourage you to also edit your own changes to find out the issue.

edit: i didn't test the map in game, so the azimut of effect on added portal is may be wrong - my 4.5 ps_game.exe is broken & my 4.5 client ... tired; I broke them trying to have a 9-lvl per skill system, to be able to validate the skill editor of shStudio, since that date I never made a live test & resigned to release the tool ...
08/21/2014 18:33 sominus#38
The logical portal (svmap) is a trigger area? (as seen on many game engines). I mean, is it a flat horizontal square/circle (with no height) that the player model must enter?
If so, is not mandatory that we put it at ground level?

I was thinking on a portal in middle air, so the player has to jump from a cliff to enter (like an 'aion fly ring')
08/21/2014 19:43 nubness#39
Yes, the portal is a trigger area. To check that, attach the packet editor to the game.exe and see what packet is sent when you enter a portal. It'll specify the ID of the portal in that map.
08/21/2014 20:46 castor4878#40
all actions take place in a 3D environment, so yes the Y coord is also taken into account.
the bad point is, as you said, that you hardly control the azimut, you can easily move your character from left to right or front to back, but it's hard to jump at any height or to dig under the drawn portal.
08/21/2014 21:24 Truth1010#41
Well, i have to say you are a very clever sh*t Castor :)

Your edit works perfectly, and thanks to the WLD you sent i can read the data a little clearer. Quick question, in the WLD you uploaded, you changed a lot of bytes to read CD. Is there any specific reason for that? or does it just simple NULL the junk that would usually be filled in there?

All i have to work out now is where i was actually going wrong, taking a quick look at an original 53.wld and your version, i notice right away that the co-ord bytes for the GRB portal are actually different, which has me confused a little, as it shows in the right place in game.. but i will look into it a little more and hopefully understand how to do these portals perfectly soon enough :)

Thanks again for the help and info Castor :)
08/22/2014 00:35 sominus#42
Oficial files comes with some garbage. Instead of
Code:
85_01.tga................
You may find
Code:
85_01.tga.B®äPDTÅXB
That confused me a lot, until Castor posted that clean 1.wld time ago and it was easier to read.

My suggestion is, use a small map (like select_a.wld). Try to start removing items from it, grass, trees, etc.
That way you will end up with a small map, almost empty, that way is easy to see the structure. And then you start adding things again.
Of course you can rename select_a.wld to something like 86.wld and make it playable.

I've used python 'cause Im not a coder. But of course, using C++ (and C structs) would make things a lot easier.
08/22/2014 00:37 castor4878#43
Quote:
Quick question, in the WLD you uploaded, you changed a lot of bytes to read CD. Is there any specific reason for that?
hmm, yes I didn't count the number of groups of 4 bytes to store the 'DEAD BEEF' pattern.
more serioulsy, when I read the files, I fuly reinterpret the data and store them into tailored structures, the original garbage is never kept, for these "Str256" I use the filler 'CD' w/o special reason.

Edit: the original garbage also was a big puzzle for me, I spend tens of hours trying to find a structure into the data ... until I understand it was useless garbage.
08/22/2014 02:13 Truth1010#44
Ah, well that's good to know. I wasnt sure if the CD stood for anything, or if it was simply used as a filler.. Strange that the files are filled with so much garbage, i guess they must be some encrypted notes sent through development or something along those lines. And I use Python aswell, it's not perfect, but will get simple jobs done.. even if i'm not very good with it.. I really need to learn some C++ and take some tutorials on that, it's hugely useful.

Just another quick note. You say you fully interpret the data and then store it into tailored structures, removing all the garbage. If you do that, basically making up a "new" file, WLD for example. Does the game still know what "address" the data it needs is. Say if i moved the portal count byte from 1000 to 1100 in address, will the game still read it in the correct place for that WLD, or will it start collecting errors? :)
08/22/2014 04:23 sominus#45
As an example of bytes reading: (will put it on Spoiler since is offtopic)

Sorry for the poor explanation but english is not my primary language.