![]() |
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. |
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. |
Re: Variations in Friendliness
I've tried a number of things, and this just isn't working out.
Quote:
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. |
Re: Variations in Friendliness
I have an idea.
In Drives R Us, I used a Condition structure on Hope: STAR 0If 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. |
Re: Variations in Friendliness
Tell me what you think of this setup.
Quote:
Any idea what's going wrong? |
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:
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. |
Re: Variations in Friendliness
Quote:
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. |
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.
|
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?
|
Re: Variations in Friendliness
Quote:
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. |
Re: Variations in Friendliness
Quote:
I'll look into creating extra quest details, to fill in for the comm deficit. |
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.
|
Re: Variations in Friendliness
Quote:
It feels good to be modding again. |
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? |
Re: Variations in Friendliness
Quote:
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. |
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:
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. |
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. |
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:
|
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:
Quote:
|
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.
|
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. |
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. |
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. |
Re: Variations in Friendliness
Quote:
Quote:
|
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. |
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:
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:
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. |
Re: Variations in Friendliness
Quote:
|
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). |
Re: Variations in Friendliness
Quote:
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? |
Re: Variations in Friendliness
Muktians, for some reason, always give me the ally message now.
Quote:
|
Re: Variations in Friendliness
Found the problem.
According to the Modmaker's Guide: Quote:
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. |
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.
|
Re: Variations in Friendliness
Quote:
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. |
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.
|
Re: Variations in Friendliness
I hope you get it working. It should shake up the game nicely, and be a lot of fun.
|
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 |
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.