.com.unity Forums

.com.unity Forums (http://forum.shrapnelgames.com/index.php)
-   Scenarios and Mods (http://forum.shrapnelgames.com/forumdisplay.php?f=130)
-   -   Mod: Variations in Friendliness (http://forum.shrapnelgames.com/showthread.php?t=44470)

ExplorerBob December 10th, 2009 07:31 AM

Variations in Friendliness
 
I began a mod a while ago to try to take things more to the basics of the game, working on balance, modifying the sides' tech a bit to make them more fit enemies/rivals to each other, changing the player's ship a bit.

I had an idea a while ago to have the attitudes of the races vary a bit, randomly. In one game, the Muktians, for example, might get along with you fine (friendly, better than norm), but in another they might try to kill you on first contact, for some unknown xenophobic reason. This makes the game a little more random and interesting; you never quite know what you're getting into when you make first contact.

Well, okay, I admit the main reason why I did it is because I wanted an excuse to blow up Muktian and Zorg ships; I like to always play the good guy, and right now it's impossible to come up with a scenario where you're justified in fighting them, which means you only get to take on three or four ship sets with yours. I'd like to have a more complete spectrum of enemies.

Anyway...

I tried to create an opening quest that would make the race friendly, hostile, or nil, but it didn't have any effect. I tried making varying versions of the same race, with different diplomatic stances, but it either didn't work at all, or I got several versions of the same race in at once, which just makes for confusing gameplay.

Do any of you know how you might implement this sort of effect into a mod? I'd prefer to avoid making it a main quest; I'd like to be able to have both random races and the Kawangi, or Ravians, or Primordius.

sgqwonkian December 14th, 2009 09:51 PM

Re: Variations in Friendliness
 
It would be tricky to have this swap from session to session, seeing as how there's the ambassador quests for it to conflict with. I suspect you don't want to try to trigger it at the start of the game, because their default settings may load after your quest. If multiple alliance-changing quests trigger, it's possible the game might only register the first or last one. I know sometimes it has trouble with that sort of thing.

Instead, you might try setting it up as a event triggered on a planet. (Those usually work more reliably.) Sort of a pandora's box thing, where some event happens that changes the alliances throughout the sector. Make several versions of the quest, all the with the same KEYS so only one can trigger per game.

ExplorerBob January 8th, 2010 02:07 AM

Re: Variations in Friendliness
 
I've tried a number of things, and this just isn't working out.

Quote:

Originally Posted by lovezorg
FLAG always
KEYS zorg

STAR 0
FLAG existing
PLNT hope
END STAR

PAGE 0
ACTN endquest
FRND zorg
END PAGE

This code is similar to the other five code files, which make the player's relations with the Zorg/Muktians friendly, hostile, and do nothing (keeping it neutral).

I used an explore condition earlier, to be attributed to a random star, but the problem is that this just meant that a star, somewhere in the galaxy, would hypothetically change your relations; you might not bump into it until after you've already met one of the alien races, and it'd be pretty obvious upon reaching it that your relations just changed, since the event was mutually exclusive with other events on the star.

If this can't be resolved, then I guess I'll be forced to give up on the idea of varying existing races' relations, and fall on a backup idea of mine; make a bunch of races with very similar ships, but different personalities, graphics, etc. to existing ones, and have those serve as evil Muk/Zorg/etc. The only problem with that idea is that it requires graphics and sounds that I don't have, so.

sgqwonkian January 9th, 2010 11:38 AM

Re: Variations in Friendliness
 
I have an idea.

In Drives R Us, I used a Condition structure on Hope:
STAR 0
FLAG existing
PLNT hope
ITEM wp_2bbeamlasr
END STAR

CONDITION 0
TYPE homeworld
STR0 terran
END CONDITION

PAGE 0
REQ0 0
ACTN endquest
ITMS 2 tech
END PAGE
If I'm remembering my thought process from two years ago, I originally tried a simpler structure, more like what you wrote.

I found that without the CONDITION block and the REQ0 line, it wasn't triggering. Also, without some item being always placed at Hope, the random items wouldn't appear. It really puzzled me as to why the homeworld trigger would have to work that way, but IIRC, it did.

You might try putting in something similar, and seeing if it works then.

Another option is to fall back on having it trigger when some other random star is explored, but add an ITEM command to the STAR block so there's an object on the planet when you get there. If you gave each of the five quests a different totally normal object from the main game, the player wouldn't immediately know that anything else had been triggered.

If I think of anything else relevant, I'll let you know.

ExplorerBob January 10th, 2010 11:12 PM

Re: Variations in Friendliness
 
Tell me what you think of this setup.

Quote:

Originally Posted by lovezorg
FLAG always
KEYS zorg

STAR 0
FLAG existing
PLNT hope
ITEM wp_projrail
END STAR

CONDITION 0
TYPE homeworld
STR0 terran
END CONDITION

PAGE 0
REQ0 0
ACTN endquest
FRND zorg
END PAGE

The railgun is added, but the Zorg are not affected, judging by the number of times I've encountered neutral Zorg.

Any idea what's going wrong?

sgqwonkian January 11th, 2010 12:20 PM

Re: Variations in Friendliness
 
What's your regular routine when you start the game? Do you immediately grab the nearest planet to fly off to, or do you stop to look at the map? I've noticed just a tiny bit of wonkiness with the homeworld trigger. The random two items in my Drives'R'Us mod sometimes show up after a really short delay. It's less than two seconds, but it might help to wait just a heartbeat before leaving Glory.

That's not likely to be the problem, but it's easy to check and rule out. The rest of my ideas involve tweaking with the files to find a solution:

Quote:

FLAG always
KEYS zorg
Do you have other quests with KEYS Zorg? If so, it's only going to generate one of them. You probably already knew that, or else you wouldn't have included that KEYS line. But, it's worth double-checking your files to make sure you don't have any other quests that might be triggering and preventing it due to the KEYS. Just to be safe.

Did you make similar quests for the other races? If so, check them to see if you accidentally left one of those quests with KEYS zorg as a copy-and-paste error. If there was a Muktian Quest that accidentally had Zorg KEYS, it could be causing the trouble without you knowing it.

Also, regardless of whether or not you have any other quests with that KEYS, you should make sure you don't have any other quests that modify the zorg behavior. If you do, deactivate all of them, and launch the game again. It may be that some other quest is triggering before or after this one, and is muddling the results. I know, it's annoying, but it's the only way to be sure.

Are the other alliance-changing quests set to "FLAG always"? IIRC, when multiple quests have the same KEYS, and are set to FLAG always, the game doesn't randomize them, it just takes the first one on the "game.ini" list. I think the only way to get random quests is via the "event" and "mainquest" FLAGs. You only get a certain number of events per game (2 to 4 by map size, if you don't go into "distribution.ini" and change it), so you'll need to be aware that having these alliance-changing quests may reduce the number of events.



If those tests and alterations don't fix the problem, you might try changing "endquest" to "break", and at the start of each game leave Glory and then immediately return before setting out a second time. I don't think it'll come to that, though, as I suspect the problem involves the KEYS, or some similar quest duplication / overlap problem.

ExplorerBob January 11th, 2010 12:46 PM

Re: Variations in Friendliness
 
Quote:

Originally Posted by sgqwonkian (Post 725795)
Are the other alliance-changing quests set to "FLAG always"? IIRC, when multiple quests have the same KEYS, and are set to FLAG always, the game doesn't randomize them, it just takes the first one on the "game.ini" list. I think the only way to get random quests is via the "event" and "mainquest" FLAGs. You only get a certain number of events per game (2 to 4 by map size, if you don't go into "distribution.ini" and change it), so you'll need to be aware that having these alliance-changing quests may reduce the number of events.

Experimentation has revealed that this appears to be the problem; upon changing the layout in game.ini, I was able to make the Zorg automatically love the player, and the Muktians hate him.

The only alliance-changing quests are these, and the same ones that exist in standard Weird Worlds. The problem, anyway, appears to be the game.ini layout. I'll work on making these events, and boosting the distribution.ini file to account for their existence.

Thanks for the tip! I'll let you know how it works out.

sgqwonkian January 11th, 2010 12:50 PM

Re: Variations in Friendliness
 
Awesome. Glad that fixed it. If you get things working to a level you're comfortable with, please post the mod. Evil zorg sound like fun.

ExplorerBob January 11th, 2010 05:02 PM

Re: Variations in Friendliness
 
The actual randomization process is working better now, but a curious side effect of using ENMY or FRND is that it seems to disrupt the standard communication response; instead of using the friendly or hostile first contact text, it doesn't give you anything. Just suddenly being dropped into combat with Zorg ships with no explanation or communication is undesirable, to say the least. I think I can come up with a way to resolve this, artificially, but I would prefer for it to use the standard race comm-stuff if possible. Have you had any problems with this before?

sgqwonkian January 11th, 2010 07:20 PM

Re: Variations in Friendliness
 
Quote:

Originally Posted by ExplorerBob (Post 725833)
a curious side effect of using ENMY or FRND is that it seems to disrupt the standard communication response; instead of using the friendly or hostile first contact text, it doesn't give you anything. Just suddenly being dropped into combat with Zorg ships with no explanation or communication is undesirable, to say the least. I think I can come up with a way to resolve this, artificially, but I would prefer for it to use the standard race comm-stuff if possible. Have you had any problems with this before?

Hmm. Sorry, but I don't think I can be very helpful on that one. I don't think I've ever made a quest that sets an ENMY on a race you haven't met yet.

You might try expanding the quest out a little bit, or making another "FLAG always" quest that uses the CONDITIONs of encounter and notfriendly to make some extra text block pop up.

It's weird though that the game isn't automatically putting up any sort of text. Did you change any other files? Perhaps you deleted or inserted something in the races/zorg.ini file? Accidentally moved something around inside the file, while you were making duplicates of the races and trying other tricks to make the zorg turn evil? That's the only thing I can think of. I'd check your zorg.ini and compare it against the default files of the main game.

ExplorerBob January 11th, 2010 08:10 PM

Re: Variations in Friendliness
 
Quote:

Originally Posted by sgqwonkian (Post 725851)
You might try expanding the quest out a little bit, or making another "FLAG always" quest that uses the CONDITIONs of encounter and notfriendly to make some extra text block pop up.

It's weird though that the game isn't automatically putting up any sort of text. Did you change any other files? Perhaps you deleted or inserted something in the races/zorg.ini file? Accidentally moved something around inside the file, while you were making duplicates of the races and trying other tricks to make the zorg turn evil? That's the only thing I can think of. I'd check your zorg.ini and compare it against the default files of the main game.

Nah, I didn't alter the files, beyond the flags.

I'll look into creating extra quest details, to fill in for the comm deficit.

S.R. Krol January 11th, 2010 11:22 PM

Re: Variations in Friendliness
 
Hey guys, just a quick note to say it's been awesome to see the mod forum getting all peppy again in the past month. I'll probably throw something in this month's newsletter about it, and definitely want to point people to the Teeming With Life mod.

sgqwonkian January 12th, 2010 12:08 AM

Re: Variations in Friendliness
 
Quote:

Originally Posted by S.R. Krol (Post 725887)
Hey guys, just a quick note to say it's been awesome to see the mod forum getting all peppy again in the past month. I'll probably throw something in this month's newsletter about it, and definitely want to point people to the Teeming With Life mod.

Thanks!

It feels good to be modding again.

ExplorerBob January 12th, 2010 10:08 AM

Re: Variations in Friendliness
 
Experimentation seems to have proven that using ENMY doesn't give you hostile first encounter messages. To test this, I acquired the Mantle of Babulon before encountering the Garthans, and upon meeting them, got the usual mantle response message. Afterwards, when I removed it, I just entered combat, with no prior warning.

The problem with using notfriendly is that it includes both neutrality and hostility, which is very inconvenient; it's somewhat annoying how neutrality is so disregarded in current WW.

Anyway, it seems the way to do this is to have the hatezorg/muk quests set triggers that allow for the notfriendly message to take its toll. Can you transfer uvar settings from one quest to another?

sgqwonkian January 12th, 2010 02:36 PM

Re: Variations in Friendliness
 
Quote:

Originally Posted by ExplorerBob (Post 725920)
Can you transfer uvar settings from one quest to another?

It's been more than a year since I've messed with UVAR, and the mod I was making that used it got eaten when my laptop died. IIRC, the uvars exist outside of the quests. Any uvar may be accessed by multiple quests. I think.

In fact, I seem to recall that if you play the game, and an UVAR is set to some value, and then play again without exiting to the desktop, it'll retain the uvar value. You may be able to use that, so that multiple games in a row end up with an ever-more-complicated political situation. If you don't want that, you might have to include a few lines in the quests/gameover.ini file to reset all your variables at the end of each game.

P.S.: Man, you've really got to put this mod up on the site when you've got it running. The more I think about all the cool things you can do with swapping allegiances around, the more excited I get. You could trigger alliance changes at the homeworlds of other races. Like, if you visit the muktians, it turns the zorg against you. If you conquer the urluquai, the garthans become friendly. It could get complicated, but awesome.

ExplorerBob January 14th, 2010 07:48 PM

Re: Variations in Friendliness
 
Sorry to disappoint you, and spend more of your time, but things haven't been going well at variability central.

Testing variable relations hasn't been convenient, since the Muktians never show up on the map when the moly cone (and thus their variable relations quest) are on, but from the last times I remember bumping into them, they were stubbornly neutral.

Here's the code I'm using right now:

Quote:

Originally Posted by lovemuk
FLAG event
KEYS muktian

STAR 0
FLAG existing
PLNT hope
ITEM wp_projmoly
SVAR wormthink wormlove
END STAR

CONDITION 0
TYPE preenc
STR0 muktian
END CONDITION

CONDITION 1
TYPE uvar
STR0 wormthink
STR1 wormlove
END CONDITION

PAGE 0
REQ0 0
REQ1 1
ACTN popup endquest break
MUSC music/vidcast.ogg
GFXP races/muktian.jpg 0
FRND muktian
TITL Muktian Vidcast
TEXT <color=990> Greetings, outdwellers. We welcome you to Muktian space. While you enjoy sanctuary, rest assured that an array of security forces stand at the ready to deal with any problems that might arise. <color=999>
END PAGE

PAGE 1
REQ0 0
REQ1 1
ACTN popup endquest
MUSC music/vidcast.ogg
GFXP races/muktian.jpg 0
FRND muktian
TITL Muktian Vidcast
TEXT <color=990>Hail, allies from beyond. This is Muktian space and you are welcome here. Feel safe in the knowledge that our system is protected by all of the formidable power our military can muster.<color=999>
END PAGE

PAGE 2
REQ0 0
REQ1 1
ACTN popup endquest
MUSC music/vidcast.ogg
GFXP races/muktian.jpg 0
FRND muktian
TITL Muktian Vidcast
TEXT <color=990>Welcome to Muktian space, far venturers. The wonders of our deep grottoes await you. You may consider this system a Haven, even as a brace of security drones have been dispatched to assure your protection.<color=999>
END PAGE

I took to inserting these texts when it became evident that artificially altering a race's relations with you prevented you from seeing their normal comm text. I inserted three of them in a half-hearted attempt at randomness that I expect will fail.

The Muktian race file hasn't been tampered in any way that would affect their appearance.

Let me know what you think of this problem, and the likelihood of this quest working.

sgqwonkian January 15th, 2010 02:36 AM

Re: Variations in Friendliness
 
Debugging suggestions:

Change "SVAR wormthink wormlove" to "UVAR wormthink wormlove" in the STAR block. UVAR initializes a variable, SVAR sets it if you're changing the variable's value after it's been initialized. You always have to UVAR before you can SVAR. Also, the modmaker's guide only lists UVAR for STAR blocks, and lists SVAR for PAGE blocks. I suspect they only work in the proper block types.

That change alone will probably solve your problems.

However, I'd also delete the entire PAGE 1 and PAGE 2 blocks. I don't think they'll generate randomly. I'm pretty sure it'll always read PAGE 0 first. Since PAGE 0 has both "endquest" and "break", it'll never check the pages after that once PAGE 0 has run. If PAGE 0 doesn't run (because you haven't UVAR'd the variable), then PAGE 1 and PAGE 2 still won't trigger.

Lastly, in PAGE 0, you might consider changing the order of the lines to ACTN, GFXP, TITL, TEXT, MUSC, FRND. (So, move MUSC to the bottom of the page, then move FRND right below it.) IIRC, the pages are sometimes very sensitive to component order, and won't load things if they occur at the wrong place in the page. Sometimes you can be lazy / sloppy and get lucky, but othertimes the game gets strict, and it's hard to predict. Some things can be out-of-order, but others can't. In general, you're best off if you try to follow the order they appear at in the Modmaker's Guide.

I'm fairly confident those changes should fix it, with the UVAR change being the most important part.

ExplorerBob January 15th, 2010 12:22 PM

Re: Variations in Friendliness
 
Unfortunately, the Muktians are as consistently neutral as ever...when they and the event show up at the same time, which is almost never. When the moly cone appears, I can almost count on there not being any Muktians -- I'll get literally almost every race but them, regularly, when the Muk variable diplomacy event comes up.

This is quite confusing, and frustrating; the code should be sound, but in spite of that it doesn't seem to work.

This is the Muktian love-code. Maybe try to test it, independently, and see if you can get anything out of it?

Quote:

Originally Posted by muklove
FLAG event
KEYS muktian

STAR 0
FLAG existing
PLNT hope
ITEM wp_projmoly
UVAR wormthink wormlove
END STAR

CONDITION 0
TYPE preenc
STR0 muktian
END CONDITION

CONDITION 1
TYPE uvar
STR0 wormthink
STR1 wormlove
END CONDITION

PAGE 0
REQ0 0
REQ1 1
ACTN popup endquest break
GFXP races/muktian.jpg 0
TITL Muktian Vidcast
TEXT <color=990> Greetings, outdwellers. We welcome you to Muktian space. While you enjoy sanctuary, rest assured that an array of security forces stand at the ready to deal with any problems that might arise. <color=999>
MUSC music/vidcast.ogg
FRND muktian
END PAGE


sgqwonkian January 15th, 2010 02:56 PM

Re: Variations in Friendliness
 
Turns out the problem is "preenc". Try setting it to "encounter" and it'll work just fine.

Relevant snippets from another thread that clued me in to this possibility:

Quote:

Phlagm:
Has anyone had success with using preenc in a condition, or do you know where it may have been used? I can get firstenc and encounter to launch the quest I'm trying to launch, but preenc does nothing.
Quote:

Fingers:
The pre-encounter condition is used in mantle_gar and mantle_url to set that race to be your enemy if you arrive without the mantle and have made friends with them earlier.

The preenc is triggered just before the radar screen would pop up. The radar would not pop up if they were friendly, that's why this feature was added. It may not be possible to use preenc to pop up a quest window as it's only intended to make (invisible) preparations before the actual encounter.
I tested your quest repeatedly, but with "FLAG always" and "CONDITION TYPE encounter" and it worked every time.

ExplorerBob January 18th, 2010 12:38 PM

Re: Variations in Friendliness
 
Working on some quite complicated code at the moment. When all is said and done, variations in friendliness should fully affect how mercs/ally ships behave, and are treated by the home race.

ExplorerBob January 22nd, 2010 03:18 PM

Re: Variations in Friendliness
 
1 Attachment(s)
As is par, I have experienced some complications.

The current code for handling ally relations is less than reliable. Please take a look at it, when you have the time; I'll post up all the files necessary to handle variable relations at the moment.

One notable difficulty with the current code is that, if I recall right, it refuses to acknowledge homeworld special relations, and will instead give you the neutral party line, even though it works fine if you visit a non-homeworld star also controlled by the Muktians.

The file should work, but if you experience any trouble, please let me know.

sgqwonkian January 23rd, 2010 12:45 PM

Re: Variations in Friendliness
 
Having looked briefly at your code and not found any obvious typos or conflicts*, I suspect the problem lies in when "TYPE homeworld" triggers.

I think it triggers only upon arriving at a homeworld and either avoiding or surviving a fight. After all, it's the same code used in the main game's home_muk to tell you "You have won a decisive victory!" and that only happens after the battle is over.

So, if you want them to be friendly or enemy at the homeworld, you need to make sure it's set before you ever get to the homeworld.

Currently, on the first two pages of lovemuk, you have a REQ3 that draws on either CONDITION 4 or 5. One of those is "nothome", so it'll trigger before the fight whenever you're not at Bandur. The other is "homeworld", so it'll only trigger at Bandur, but after the fight is over.

I think the solution is to get rid of REQ3 on the first page of lovemuk, and get rid of the second page entirely. Then, in theory, the first page will trigger whenever you meet them, regardless of where it is.

Also worth noting that in lovemuk, it's possible to match the triggers to both the first page and the third page at the same time. However, due to the "ACTN endquest break" in the first page, it'll never load the third page. If you remove the "ACTN" (and just the break, not the popup or endquest) from the first page, it'll display the third page after the first one. I think.

I'm hoping that solves your problems. I haven't tested it yet, but the logic seems sound.

__________________________________________________ ___________

*: Okay, so there is one possible conflict/error/typo, but I haven't tested it yet, and it's definitely not related to what's causing the muktians to not be friendly at their homeworld. You have REMS happen twice in page 1 of hatemuk. It targets different ships each time, but I've found that with some codes (it was either ITEM or ITMS, don't remember which off the top of my head) there's trouble when you use the same code twice in one page.

Don't know if that will be the case with REMS, but I mention it just in case. Should you ever find that the ship doesn't go away, it's probably because of the code happening twice on the same page - only one activation happens. The solution, should that problem manifest, would be to move the second instance of REMS to PAGE 2.

ExplorerBob January 25th, 2010 07:31 AM

Re: Variations in Friendliness
 
Testing on the Muktians has proven promising and it seems this particular part of this project is finally nearing completion.

One problem has popped up, though, when trying to extend variable relations to the Zorg; I've noticed that sometimes, the game has systems with no objects in-system, which is an annoying tip as to the state of the relations. While the current code does place plasma blasters and cone cannons on Hope, based on relation state, this is only for testing, so that I can restart the game until I get an altered-relations game. I don't want the rest of the galaxy to be affected by the state of variable relations.

It's also annoying how the event takes up a standard event slot, meaning that there can be either significantly fewer or too many standard star events, depending on how the variable relations generation goes.

All in all, this project has been promising, but perhaps inferior to the original idea of making new races, similar to existing ones, with only the different attitude. I do wish WW supported variable relations by default; it would make things a lot easier if there was a genuine hard-coded way to have it randomly choose a race's alignment at the beginning of each game.

While my original plan was to have the Muktians and Zorg fully affected by variable relations, it might be better, for the sake of the game's event limitations, to leave it to the Muktians. They are "fickle and cautious", anyway, so this explains their erratic behavior in-game. It takes somewhat more suspension of disbelief to accept the Zorg randomly deciding to attack people who just came to their space.

sgqwonkian January 25th, 2010 10:19 AM

Re: Variations in Friendliness
 
Quote:

Originally Posted by ExplorerBob (Post 728072)
One problem has popped up, though, when trying to extend variable relations to the Zorg; I've noticed that sometimes, the game has systems with no objects in-system, which is an annoying tip as to the state of the relations. While the current code does place plasma blasters and cone cannons on Hope, based on relation state, this is only for testing, so that I can restart the game until I get an altered-relations game. I don't want the rest of the galaxy to be affected by the state of variable relations.

Try inserting this bit of code into any quest that seems to generate an empty planet (or, if you can't tell which quest is doing it, insert this to every new quest that doesn't have a STAR block, or whose only STAR block references Hope / Glory).

Quote:

STAR 0
STRC yellow
END STAR

CONDITION 0
TYPE explore
STR0 0
END CONDITION

PAGE 0
REQ0 0
ITMS 1 tech
END PAGE
That should put a random item at the stars that are turning up empty. It should mask the problem nicely - the players will never be able to tell that anything unusual loaded at all.

ExplorerBob January 28th, 2010 06:40 PM

Re: Variations in Friendliness
 
1 Attachment(s)
It turns out that the lack of items on planets is because the itemless star is where the ship should be -- only it fails to generate.

If/when you have the time, please take a look at this code and see what you think of it. "Wormapathy" is generated by haven.ini; wormhate and wormlove are generated by the lovemuk and hatemuk files. It's been a while since I released the other files, but I think they should still be compatible?

The idea is to have three types of merc, one for each diplomatic state. hatemuk should trigger a Muktian mercenary; the others trigger allies that are functionally equivalent.

Composition of the zip file should be similar to last time; few tweaks to the love/hate files to get them to work better, and the currently-malfunctioning mercs.

sgqwonkian February 2nd, 2010 12:16 PM

Re: Variations in Friendliness
 
Have you ever tried to mod a quest that uses the THIF or SABT commands? I did, a while back, and I found there's all sorts of problems. Neither of those two codes will work with anything but the "explore" CONDITION. Put any other trigger on the quest, and it'll never take an item from you. There's some other weirdness specific to those codes as well, like THIF needing to be in the first PAGE, and it parses haveitem differently then it should. Point being, all the codes pertaining to Esmerelda are really wonky, and only reliably work in the specific scenarios used in the maingame. Stray far from the example, and it'll break.

So, after much tinkering and testing, I've come to the conclusion that MERC has similar restrictions. The problem isn't your code, it's the the very coding of the game itself. :doh: As near as I can tell, the MERC command doesn't work with CONDITION TYPE uvar. (It may just be that CONDITION uvar evaluates after the point where the game needs to already have launched the special MERC hiring window and protocol.)

I draw this conclusion most based on these two observations:
  1. If I change all your MERC entries to ALLY, it generates the ship in every scenario and combination.
  2. If I change all your ALLY entries to MERC, it never generates a ship.

I'll go add that to the big debugging list at the wiki.

So, your possible choices for the mod under discussion seem to be:
  • Revert to the default quest without modding it, since it works.
  • Remove the CONDITION TYPE uvar, and set them all to MERC.
  • Set that one MERC to ALLY instead, but keep the uvar CONDITION and use alternate text to hint that he's an outlaw.
  • Move the MERC code to the first PAGE, and test to see if that works. I doubt it will, but given how weird the THIF and SABT codes are, I can rule it out till it's been tested.
  • Surprise me with something clever, new and fun that's not on this list.

Sorry it took so long for me to figure out the problem. It wasn't till this morning that I thought far enough outside the box to realize the issue might not be your coding. The past couple days, I'd been looking for a typo that didn't exist.


One more thing. I found this other possible bug (depending on how you view it, you might see it as a feature) in the mod. Wormhate overrides the Mantle of Babulon. I had the mantle and met the Muktians. They gave me the "cruel Slorn" speech, like we were gonna fight. Then they gave me the "return of the ancient ones! We exude ooze in jubilation" greeting in a second window. Then they attacked me. You might want to go tweak mantle_muk to make it less surreal.

sgqwonkian February 4th, 2010 10:54 AM

Re: Variations in Friendliness
 
Quote:

Move the MERC code to the first PAGE, and test to see if that works. I doubt it will, but given how weird the THIF and SABT codes are, I can rule it out till it's been tested.
That was, of course, supposed to say "I can't rule it out till it's been tested."

ExplorerBob February 4th, 2010 09:52 PM

Re: Variations in Friendliness
 
I wonder if having any variations in the ally pages at all prohibits generation. I've been trying #3, changing the merc to an ally and having slightly variant text, but it never generates.

I'm getting inclined to give up on the merc side of variable relations and just get VR working again (since I managed to break it while I was working on the merc side).

sgqwonkian February 5th, 2010 03:09 AM

Re: Variations in Friendliness
 
Quote:

Originally Posted by ExplorerBob (Post 729958)
I wonder if having any variations in the ally pages at all prohibits generation. I've been trying #3, changing the merc to an ally and having slightly variant text, but it never generates.


Really? I'm pretty sure it worked just fine when I tested it. I'm fairly certain that I got the ally version to generate, with the mercs text, at a time when the wormhate variable was in play. They even took him away later. Weird.

You're putting the ally line in the right spot? After TEXT, not before it where MERC goes? Just double-checking, 'cause off the top of my head I can't think of anything else that would wind up with in me getting one result, and you getting the other. So bizarre.

I guess I'll try to play around with it again sometime in the next few days, and see if I can reproduce what I remember happening. Maybe I'm remembering wrong?

ExplorerBob February 7th, 2010 10:35 AM

Re: Variations in Friendliness
 
Muktians, for some reason, always give me the ally message now.

Quote:

FLAG event
KEYS muktian

STAR 0
FLAG existing
PLNT hope
ITEM wp_projmoly
UVAR wormthink wormhate
END STAR

CONDITION 0
TYPE encounter
STR0 muktian
END CONDITION

CONDITION 1
TYPE uvar
STR0 wormthink
STR1 wormhate
END CONDITION

CONDITION 2
TYPE noitem
STR0 ps_mukamb
END CONDITION

CONDITION 3
TYPE noitem
STR0 mantle
END CONDITION

CONDITION 4
TYPE haveshiprace
STR0 muktian
END CONDITION

CONDITION 5
TYPE nothome
STR0 muktian
END CONDITION

PAGE 0
REQ0 0
REQ1 1
REQ2 2
REQ3 3
REQ4 4
REQ5 5
ACTN popup endquest break
MUSC music/vidcast.ogg
GFXP races/muktian.jpg 0
FRND muktian
TITL Muktian Vidcast
TEXT <color=990>It is good that you come accompanied by one of our own! Since cooperation is your intent, we urge you to visit Bandur, our home world colony located in the <uvar=homestar> system, to meet with our potentates.<color=999>
END PAGE

PAGE 0
REQ0 0
REQ1 1
REQ2 2
REQ3 3
REQ4 4
ACTN popup endquest break
MUSC music/vidcast.ogg
GFXP races/muktian.jpg 0
FRND muktian
TITL Muktian Vidcast
TEXT <color=990>It is good that you come accompanied by one of our own! Since cooperation is your obvious intent, we grant you safe passage through our star systems that you may know our ventures are profitable.<color=999>
END PAGE

PAGE 0
REQ0 0
REQ1 1
REQ2 2
REQ3 3
ACTN popup endquest
GFXP races/muktian.jpg 0
ENMY muktian
TITL Muktian Vidcast
TEXT <color=990>Trespassers! As the cruel Slorn attacks the weak and the sick, we swarm now to attack you with horrific weapons and the hunger of victory in our digestive tracts. From deep caves of steel and stone, we come!<color=999>
MUSC music/vidcast.ogg
END PAGE
This makes no sense to me. Both of the ally messages require having a friendly ship, and I don't.

sgqwonkian February 7th, 2010 12:14 PM

Re: Variations in Friendliness
 
Found the problem.

According to the Modmaker's Guide:
Quote:

REQ0 <n>, REQ1 <n>, REQ2 <n>, REQ3 <n>
Required conditions. All of these must be TRUE for the event to occur. Up to four conditions can be defined for each PAGE block, and several PAGE blocks may use the same conditions (although the GOTO command is preferred over fully identical condition sets).
(emphasis mine)

REQ0 to REQ3 are all triggering. REQ4 and REQ5 have no meaning, and will never be taken into account, as the game doesn't even have a REQ4 command.

The game goes to PAGE 1, and evaluates it. REQ0 to REQ3 hold true, so the game launches the page. The game doesn't care that REQ4 and REQ5 aren't true, as it never looks at them. Then, since PAGE 1 loaded and ran, endquest and break keep it from ever considering the other PAGEs.

ExplorerBob February 7th, 2010 07:52 PM

Re: Variations in Friendliness
 
As you can see by the ever-increasing length of this topic, I've gone through major trouble ever since I embarked on this project. I can't be sure anymore as to whether my code is necessarily high-quality; testing things are impractical, at best. Therefore, I'm going to put the Muktian variable relation work on hold indefinitely; testing the mod isn't really fun anymore, and I want to change that. Hopefully I can come back to this part of the project with a new lease on things, and get it working to how it was before I started on the mercenaries (which messed everything up); right now, though, it's on hold and will be until I indicate otherwise.

sgqwonkian February 7th, 2010 10:43 PM

Re: Variations in Friendliness
 
Quote:

it's on hold and will be until I indicate otherwise.
That's a bummer, but I understand.

I got really angry with my current modding project earlier today, but stumbled across the solution just as I was about to give up. So, I hear you.

ExplorerBob July 30th, 2010 04:12 AM

Re: Variations in Friendliness
 
This project is back on. I'm attempting to recreate my original success based on the information provided earlier in the topic.

sgqwonkian July 31st, 2010 12:56 PM

Re: Variations in Friendliness
 
I hope you get it working. It should shake up the game nicely, and be a lot of fun.

ExplorerBob August 6th, 2010 05:33 AM

Re: Variations in Friendliness
 
Things seem to be going okay so far, but I haven't been able to test how mercenaries affect variable relations, because they never show up when the Muktian race is in the game, and vice versa.

In other words, the same old set of problems.

Intriguingly, the Tan Ru Demolisher merc is also broken, and only shows up fifty percent of the time now (the other times, the event comes up, but you receive no new ship). Does it work that way in 001 of my official release?

- Bob

ExplorerBob August 6th, 2010 06:38 AM

Re: Variations in Friendliness
 
1 Attachment(s)
Variable relations seem to finally be in place.

The only problem I can see are with technical factors -- such as getting them to appear in a consistent fashion, and getting them to show up without harming anything else.

I want to hone in both these things -- make it so the variable relations for sure don't affect the appearance of other events (or are in turn affected by the map's size), but the last time I went off on a project to expand this, I ended up breaking what we already had and we didn't get anything.

Thus, here's all the code relevant to making Variable Relations work.

The testing items are still in, so you get the Timeless Bauble (for loving Muktians), and a moly cone (for hateful ones) at Haven, at the beginning of the game.

Tell me what results you get -- if there's any events that show up less because of the relations, I need to know.

Installation is simple; add the lovemuk and hatemuk stuff to the quests section of the game.ini file. You may choose to modify your existing Odd Adventures installation if you wish, but these particular files should work in any mod that has Muktians.


All times are GMT -4. The time now is 03:52 PM.

Powered by vBulletin® Version 3.8.1
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright ©1999 - 2025, Shrapnel Games, Inc. - All Rights Reserved.