Have 3 normal army deploys and then use a conditional quest var to decide it?

YES! Thankya!

I never used the conditional stuff before, but thats obviously the easiest of solutions.

And if you want to make it like you suggested (only need 1 army deploy effect and no conditionals), it would look like this:

First use QV Set X,Y,Z (LB) to set all spawn locations for every player, and make sure to include a number in ascending order in all the QV names.

Use the QV randomize effect to choose a random value between the lowest number you used in the spawn location QV and the highest.

Use the Army Deploy in QV area effect to deploy the army at the random QV location by including the random value in the base QV name of the spawn location quest vars.

Example:

QV Set X,Y,Z (LB) -> P1SpawnLocation1X, P1SpawnLocation1Z
QV Set X,Y,Z (LB) -> P1SpawnLocation2X, P1SpawnLocation2Z
Quest var Randomize -> QV_random, between 1 and 2
Army Deploy in QV area -> set meters x to: P1SpawnLocation"+1*trQuestVarGet("QV_random")+"X and set meters z to: P1SpawnLocation"+1*trQuestVarGet("QV_random")+"Z

EDIT: the effects:

<Effect name="QV Set X,Y,Z (LB)">
      <Param name="SrcObject" dispName="Unit" varType="unit">default</Param>
      <Param name="QVx" dispName="QV X" VarType="string">X_pos</Param>
      <Param name="QVy" dispName="QV Y" VarType="string">Y_pos</Param>
      <Param name="QVz" dispName="QV Z" VarType="string">Z_pos</Param>
<Command>trUnitSelectClear();</Command>
<Command loop="" loopParm="SrcObject">trUnitSelect("%SrcObject%");</Command>
<Command>trQuestVarSet("%QVx%", xsVectorGetX(kbGetBlockPosition("%SrcObject%")));</Command>
<Command>trQuestVarSet("%QVy%", xsVectorGetY(kbGetBlockPosition("%SrcObject%")));</Command>
<Command>trQuestVarSet("%QVz%", xsVectorGetZ(kbGetBlockPosition("%SrcObject%")));</Command>
   </Effect>

   <Effect name="Army Deploy in QV area">
      <Param name="SrcArmy" dispName="$$22348$$Army" VarType="group">default</Param>
      <Param name="ProtoName" dispName="$$22434$$ProtoName" varType="protounit">Villager</Param>
      <Param name="L1" dispName="metres x" varType="string">QV1</Param>
      <Param name="L2" dispName="metres z" varType="string">QV2</Param>
      <Param name="Count"  dispName="$$22435$$Count" varType="long">0</Param>
      <Param name="Heading"  dispName="$$22432$$Heading" varType="long">0</Param>
      <Param name="Clear" dispName="$$22464$$Clear Existing Units:" varType="bool">true</Param>
      <Command>trArmyDispatch("%SrcArmy%", "%ProtoName%", %Count%, trQuestVarGet("%L1%"),0,trQuestVarGet("%L2%"), %Heading%, %Clear%);</Command>
   </Effect>

---

What are the key ingredients to make a popular RPG? To find out, read the results of the RPG survey.
Want to create an advanced patrol/pathfinding system? Have a look at the powerful Pathfinding triggers.
Games I'm playing: The Witness [80%] Chivalry: Medieval Warfare [20%]

[This message has been edited by Lewonas (edited 09-10-2017 @ 06:02 AM).]

Thx, will be tested since 1 effect in the Deploy-Trigger is less than 3 effects, thus easier to deal with. (If I'm going crazy with like 5 spawn spots per player hero and another 5 per player army)

I wont need the randomization, since I want the players to be able to set and reset their new spawn location through approaching with a hero or something. But thats easily done with a small trigger per player/location which fires all the other locations for this player for resetting. (duh)

Ascending Numbers in the QV-Names will still be useful HeroP1Loc1 and ArmyP1Loc1 and so on.

I like having a cinematic block as the spawn position .. though I'm kinda curious why you took in X-, Y- and Z-values, but killed the Y with a zero in the spawn. If thats the vertical axis there's no need to save it at all I guess x.x

[This message has been edited by Izalith (edited 09-10-2017 @ 03:00 PM).]

Yes Y is for vertical but it gets set to the height of the land regardless of the value you enter. So you don't need to save it but the effect Lewonas posted is just a general effect from a trigger pack (someone may want to use Y).

Just for the record, since I have suddenly no time for testing:


HLocX_ and HLocZ_
HLocX0 and HLocZ0 hold data for Position 0,
HLocX1 and HLocZ1 hold data for Position 1, .. and so on.

HLocP_
HLocP1 saves on which position the Hero of P1 should spawn.
HLocP2 saves on which position the Hero of P2 should spawn.
E.g.: Valid positions are 0, 1, 2, 3 .. and so on, referring to the HLocX/HLocZ-Numbering.

Save Location
Pretty much as presented by Lewonas without the Y.

Spawn at Location
An Army Deploy Trigger with:
Parameter: PlayerNumber varType="string" to add 1, 2, 3 ..as the players number.

On trArmyDispatch X and Z are read out in that fashion:

trQuestVarGet("HLocX" + 1*trQuestVarGet("HLocP"+"%PlayerNum%")),0,trQuestVarGet("HLocZ" + 1*trQuestVarGet("HLocP"+"%PlayerNum%"))

Thus we get the HLocP-Value to add as Location Specifier for the HLocX and HLocZ-Questions.


e.g.: PlayerNum=2, HLocP2=3, Player 2 wants to spawn at Location 3.

get(HLocX + get(HLocP2)), where HLocP2 holds 3, thus:
get(HLocX3)


... I'll try in a couple of days if it works as intended X_X

[This message has been edited by Izalith (edited 09-11-2017 @ 07:09 AM).]

That should do it.

Help!

Azarath.scx failed to load ;_; .. and I have no Backup.

I can upload you my Typetest-Stuff and the SCX but I have no Idea on how any of that is going to be able to fix the map... ;_;


Last Thing included was the SaveLocation and the HeroDeploy Effects, on trying to test it out everything crashed ... ..if not on fullscreen aom crashes with a windows "not responding"-error.

[This message has been edited by Izalith (edited 09-11-2017 @ 10:31 AM).]

You may be able to recover it if you've the advanced editor. It saves backups of the last scenario you've edited as ~last and last scenario you've playtested as ~testing.

If that doesn't help, upload your scenario and maybe I or someone else can find the problem.

[This message has been edited by Lewonas (edited 09-13-2017 @ 05:35 AM).]

You can edit the hex values of scenarios. While this means very little for me (and probably you) people like nottud (and invent00r, Mythic_Freak, lostro, elrich etc) can actually separate the trigger code from the rest of the scenario. AoMED does this with SCN files.

I remember a post by invent00r explaining it but I can't seem to find it. But here's one from Elrich.

Of course once you've decompiled the SCX you'd then have remove the trigger code that crashes the scenario and then re-compile it using the reverse method.

That's the theory - but I've never been able to do it But it's probably from lack of trying

Yes, that's exactly what I wanted to try. I don't know what to look for exactly to find the corrupted part, but who knows it may be very apparant if I compare it to other scx files. I know AoM Expert has done something similar a few times already, so if all else fails he will likely be able to find the issue.

Woaw, and here I thought it was totally lost o.o ..

In the ~last and ~testing savings the scenario wasn't there for some reason. I found an somewhat older version with no triggers in there yet and just a little less map designing.

In total the scenario wasn't that far done, so it's a work of about ~2 days to get it back to the status I lost.

If anyone wants to try anyways (with less than a hour working on that, otherwise I'd feel really bad), there's the file & the trigger2-XML used so far (not sure if the last one is required):

azarath.xml
Azarath.scx

It's on the Titans version, not chinese or something.

[This message has been edited by Izalith (edited 09-14-2017 @ 09:36 AM).]

I've tried a few things, but to no avail. It seems to be impossible to find the problem without 1) a proper scx parser that doesn't exist yet, and 2) many hours of research. There are a few programs such as AoMED that have their own parsers, but their source code offer no help mostly because of a severe lack of documentation, confusing naming convensions and programming languages I'm unfamiliar with.

So for me it's not really worth the effort to figure it all out by myself. Maybe AoM Expert or somebody else can help you. Luckily you've only lost 2 days of work, so all things considered, it isn't all that bad.

I would've liked to be of more help though.

Thx for trying! I'll make proper Backup-Files more often now for some time ~,~

Is there anyone on that Parsing Project? That does sound interesting, but .. well, dunno how far it gets/got without help from officals or something x.x


OT: Since I cant answer on the RPG survey & a bit late, the second bullet point on long/short scenarios gets a total of 110% o.ó

[This message has been edited by Izalith (edited 09-14-2017 @ 02:54 PM).]

No, the few people that ever looked into decoding the scx file have stopped working on it a very long time ago. I'm not sure if nottud ever did something similar with scx files. Ykkrosh has done the most work on this, but only for scn files though. And like Matty said, lostrozzacavalli, invent00r and Mythic_freak have done a few things with scx parsing. But all of them have moved on from AoM.

Regarding the survey, multiple answers could be given to each question, so the total value can exceed 100% such as in the first bullet point. But you're right about the second one. I accidentally made a typo there (37% should have been 27%, this is actually one of the few questions where everyone only gave 1 answer). It's incredible I never noticed that. I fixed it now, thanks.

EDIT: The biggest thing I don't understand is how to make 95% of the unreadable data inside the scx file readable. For instance, the highlighted area says something about Unit with scenario name 1268 in your scenario, but I've no idea how to interpret/modify this data:



I know invent00r must have converted this partly to readable text because of his AoM SCN Unit mod tool which can be used to change the dimensions of all the units on the map, but he unfortunetaly hasn't published the source code for that.

So if all the data could be converted to a readable format, then the corrupted part could probably be found very easily.

[This message has been edited by Lewonas (edited 09-14-2017 @ 08:05 PM).]

Eww. I've had a go at the RCX stuff a little, and have successfully edited triggers in SCX by manually decompressing, tweaking and putting it back together again. This stuff is beyond me, though: I could get quite a bit out of the RCX besides the easy XML, but couldn't touch the decompressed header, the tail (there's some stuff on the end of the compressed data block!), or the actual rec data itself. Player data seemed fairly straightforward. Working something like the above mess out would probably be a lot easier knowing the proto/location etc of the named unit - after all, there's probably just binary packed values for all of these in some predetermined order in that highlighted section.

But yeah, there's a lot of stuff in the SCX, and trying to pin down the problem that's causing the game to reject it is gonna prove very difficult to put it lightly.

I got to a similar location as you Lewonas, may I suggest looking at invent00r's Mother nature editor if you haven't already - he included the source for that

Also Mythic_Freak still updated the aomcodereference on github and his email address is still active - but his knowledge has more than likely slipped away since he doesn't actively continue tinkering with AoM files anymore.

Ok, so I figured out that the unreadable text is actually an ASCII hex representation of blocks of 4 bytes of data. This data can be converted to something readable by converting the hex values to the data's original pre-compressed data type such as the int32 data type. I tried this method before, but I hadn't realized that the hex values were actually in little-endian format. So now some of the data actually make sense after converting them by using this format.

With these new findings I was able to edit the scx to remove all the triggers from the scenario, and the scenario could be loaded again. So the corrupted part is somewhere in the trigger section as Izalith suspected. So I tried removing individual triggers, but this seems to be more complicated than I anticipated. I tried removing a trigger by removing it from the trigger list, removing its id value from the trigger group data and adjusting the total number of triggers and lines of trigger code, but this didn't seem to work (it also doesn't work on an empty map with just 2 triggers and then removing just 1 of them).

Loggy, maybe you can shed some light on this since you've already been able to edit the triggers?

EDIT: Whelp nevermind, I've figured it out.

[This message has been edited by Lewonas (edited 09-15-2017 @ 02:07 PM).]

I have no idea what little endian and such are, but I am impressed o__o .. is this format read- & modifyable for not that knowledgeable users? That does sound like you're onto solving that holy parsing grail riddles *________*

I look forward to the presentation your findings/parsers when you're done ^_^

[This message has been edited by Izalith (edited 09-15-2017 @ 01:51 PM).]

For tinkering with triggers, the rules are simple: you can replace characters in the XS, but not add/remove them. Thankfully the map I was editing had enough characters to do what I wanted (though I ended up with some lines with a LOT of /////// at the end). Anything that changes lengths makes the game reject the file - the same is true with RCX player names (you can replace characters, but not change lengths). Chances are that the mysterious header has offsets or section lengths in it somewhere, but I never took the time to investigate as I didn't really need to. The fact that I've successfully changed characters suggests there's no checksumming, at least in the bits I've messed with.

I don't know what the trigger editor makes of tinkered triggers once you open the scenario back up - I've to never tried anything as drastic as adding/removing things, only changing the XS that's in the save to tweak the generated trigtemp, whilst making sure I didn't do anything that caused compile errors.

I wonder if there's enough expertise around to actually decipher these formats already. It could open up possibilities like repairing recs broken by too many observers, or converting scenarios back from EE format to TT. Trouble is, that'd be SO much work, and it seems to be beyond my ability.

@Izalith: Endianness is the order binary is read. IE: whether binary "1100" is 12 or 3 in decimal depends on which side you put the 1 bit at. To get anywhere with these files you have to take a hex editor to them and try to figure out the patterns and structures in it, which maybe isn't the easiest task ever.

[This message has been edited by Loggy (edited 09-15-2017 @ 07:00 PM).]

Thanks for your insight Loggy. Right now I've been able to decipher almost everything in the trigger section of the file. I can remove/add/modify the trigger in any way I want. It's a very tedious task though, because changing one thing in one place means I've to change other things in other places as well. It's not an intuitive process at all, but at least I'm able to understand most of it now.

What I've seen so far is that the triggers have some very odd identification numbers. So I'm changing those as I go to make it clearer for myself. And there's one very odd thing going on with the SaveSpawnLocations trigger that appears in both the Ungrouped and HeroMechanics trigger groups. But it doesn't seem to be breaking anything, so I'll just leave it since I don't know how to fix it.

I'll continue working a little bit more on this tomorrow. Hopefully I can make enough progress to find the problem then.

Oh and Loggy, you make an interesting point about converting scenarios from EE to TT. I've an idea how to make that work as long as the designer hasn't added any EE-exclusive content or trigger commands in the scenario. That would be pretty neat. But that's another experiment for later.

[This message has been edited by Lewonas (edited 09-15-2017 @ 07:51 PM).]

wah, still on that map o__o .. it's totally fine if you leave it, but as long as it's interesting to you, well.. ^^' thx!

..there should be max. only two faulty effects used about once each, the Arc Azar SaveLocation and Arc Azar Hero Deploy, which was what I tried to test when it got killed. The Triggers would be called something like SaveLoc, probably in HeroMechanics but maybe Ungrouped, and something like P1Hero_Deploy (fired by P1Hero_Cou) in the HeroMechanics Group.

On the Error my Effect-Commands got pretty long as I notice now, if it's not a syntax error maybe that broke it. Like one line looks like this in the Deploy Effect:

<Command>if(trQuestVarGet("HeroChoicePlayer"+"%PlayerNum%")==1)trArmyDispatch("%SrcArmy%", "Hero Greek Atalanta", 1, trQuestVarGet("HLocX" + 1*trQuestVarGet("HLocP"+"%PlayerNum%")),0,trQuestVarGet("HLocZ" + 1*trQuestVarGet("HLocP"+"%PlayerNum%")), %Heading%, true);</Command>

If there is a character limit for condition/effect-XML-lines, I probably violated it, and if not with Atalanta, with Greek Hero Bellerophon for sure.. x_x

[This message has been edited by Izalith (edited 09-15-2017 @ 10:15 PM).]

It's fine, I think it's intriguing.

Oh wow, you're way way waaay over the character limit in that command line. But that should only cause a trigger lock, not a complete scenario lock. I doubt it's a syntax error either, because that would only cause trigger locks as well. And grave syntax errors in the xml code would prevent the whole xml file to be loaded into AoM, so you wouldn't be able to use your custom triggers.

I'll get on top of this... eventually.

Ok, so you were actually right.

Whenever I try to add the HDeploy triggers (which contains the effect you talked about), AoM crashes upon loading the map. And somehow these triggers have also affected some of the triggers that come after them. For instance, when I add the XP triggers and load the scenario, a pop-up message appears that the scenario failed to load (which is better than an instant crash, but still bad). So I cannot reliably/quickly recover the triggers created after the first HDeployP1 trigger (unless I spend even more time on this, but I don't want to ).

So what this comes down to is that I can recover your map including the first 18 triggers. You probably have already progressed further than that. But if not, I can email it to you.