|
Title: UQM stars/races relocation mod? Post by: logarithm on October 31, 2015, 12:38:37 am Hi
I was wondering if there's any mod for classic SC UQM which would change locations of stars, locations of different races, maybe even change galaxy size... As it's a bit spoilerish, when u remember all key locations. If there's no such mod, then is it hard to make such? I might consider to dive into such effort, if it's not too complicated. Title: Re: UQM stars/races relocation mod? Post by: logarithm on October 31, 2015, 10:48:28 am Ok. Checked code and made a brief plot.
Seems like will need to do followings: (1) Randomize coordinates for stars and quasispace portals ** src/uqm/plandata.c ** src/uqm/hyper.h (2) Find where races territories are defined - corellate them with randomization in (1). ** src/uqm/gameev.c -- found some coordinates for some events => better extract them as constants ** src/uqm/ships/${RACE}/${RACE}.c -- territories of races are most probably defined in FLEET_STUFF sections (3) Apparently some coordinates and system names are hardcoded in conversations => extract them as constants and corellate with randomization in (1) (click to show/hide) Count of stars: sc2/src/uqm/starmap.h, line 30: #define NUM_SOLAR_SYSTEMS 502 Stars and star-clusters names: sc2/content/basegamestrings.txt (check sc2/src/uqm/gamestr.h for metadata) Their reference in dialogues would require additional search. Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 01, 2015, 01:05:56 am Set up DEV environment and got project built. Also experimented with stars relocation.
Found useful info in older thread: http://forum.uqm.stack.nl/index.php?topic=3972.0 This one is quite old, but still might contain some useful hints: http://forum.uqm.stack.nl/index.php?topic=1597.0 Gonna study these and probably other threads... Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 01, 2015, 11:37:13 am There are hardcoded assumptions made towards generated systems and planets (if those assumptions fail, game generation is faulty).
Currently there are these hardcoded assumptions towards generated galaxy: (A) About stars coordinates (B) About quasispace portal coordinates (C) About names of stars and clusters (D) About gameplay-important stars - their numbers of planets, moons (E) About gameplay-important stars - ??? anything else assumed? (F) About races coordinates (G) About races strength (H) About events when races move and/or attack other races (I) About distances between races (based on their relationships) (J) About distances between races and related artifacts/ships and other objects (K) ??? It's quite important to figure out what else is assumed Apparently, mod will target changing (A), (B), probably (C) and definitely (F). And will need to respect and be cautious with (D), (E), (H), (I), (J). Clarifications required for (E), (I), (J) and (K). I assume (G) and (H) are strictly hardcoded in events. And thus, if Pkunks whole fleet decide to travel through Kohr-Ah territory, they won't fight and weaken each other. However, I will need to check distances and speeds at which whole-fleets travel. Although it's (most probably) only of a cosmetical priority... Few possible approaches to deal with (D) and (E) vary in elegancy/dirtiness, simplicity/complexity. Have to choose from these: (1) Respect every assummed generated parameter/state. Put defensive constructs and workarounds near each assumption in code. (2) Generate whole galaxy using original seed and content. Then remove all nonimportant stars, relocate important stars, and regenerate all nonimportant stars randomly. (3) Extract random seed state for all important stars, and hardcode usage of such random seed state near assumptions. (4) Same as (3), but also use separate random generators for important and nonimportant stars. (5) Import data for important stars using dumps (http://forum.uqm.stack.nl/index.php?topic=3972.msg60225#msg60225). Option (1) is probably the most correct one - as I would better identify all risks. But this would also be most boring choice. Options (2), (3) and (4) look quite easy and safe for me. But they are vulgar. I like (5), but that looks also most complex for me, as it will require biggest changes in code, I think... I wonder if anyone tried to to make functions for importing stars from dumpfiles? Another tasks which I'll need to solve (i) for (A) is evenness of random distribution of star-clusters and stars within them (ii) for (F) and (I) is evenness of random distribution of races (iii) after merging sets of important stars with nonimportant ones (also after enforcing respects of (I) and (J)) will need to take additionl cares for evenness of distribution of stars (iv) ensure that stars and quasi-space portals don't overlap (v) test if melnormes are fine with new coordinates of Rainbow Worlds ---------------------------------------- I hope experienced comunity members share their thoughts and knowledge (and probabably pieces of code) on things said. Especially on assumptions (E), (K) and on solution (5). If anyone is willing to participate - welcome! :) It would be great if someone defined (I) and (J) in complete details. Title: Re: UQM stars/races relocation mod? Post by: kfdf on November 03, 2015, 04:36:04 am Some thoughts on the subject...
The game surely has some replayability potential in it, and not making everything fixed in place seems like the obvious way to realize it. But maybe you should start small, like, randomizing star colors and moving them just a tiny bit, so that their seed would change? This will keep all those hand crafted nice looking constellations while changing their planets. And coupled with some additional adjustments you can actually fix some important game imbalances. For instance, you could reduce chances of finding life in subzero temperatures, which in turn would make buying Melnorme technologies much harder, which would greatly delay the moment your flagship becomes virtually unstoppable death dealer capable of taking on Ur-Quan battlegroups single-handedly, which would introduce you into ship management where you actually lose ships in combat and have to buy them... And while I am at it, you could decrease the number of enemy ships that pop out in hyperspace and in normal space, but at the same time massively increase their speed. This will result in enemy ships catching up to you when you leave planet orbit and enter space, then deep space and then hyperspace. So you won't be able to explore planets in enemy space so light heartedly as you can do it today. I played the game some time ago and the only thing that I remembered at the beginning of the game was a bunch of mineral rich stars to the left of your starting position (or you can actually listen carefully to what Hayes says about star colors). And that was enough to break the early game in many ways. Why? These stars are in Ilwrath space, who are very dangerous enemies in combat, but aren't really a threat because they can be easily avoided. So instead of meticulously gathering minerals and building your fortune bit by bit, you just go there and grab some easy money. Making their speed in truespace and hyperspace independent of their combat speed would fix this problem. As to moving around races, this sounds like a massively daunting task, there are too many invariants set in the dialogs and in the game lore that must be kept for this to make sense. You have to pick the spot for the battleground where the the two races fight for Sa-Matra, you have to decide which way is the center of the galaxy, where the Ur-Quan and Kohr-Ah fleets came from, where the Alliance of Free Stars was, and that roughly defines where most of the races and special places should fit. With all this, I don't think you can really have much variety here, the end result will always end up looking something like the current fixed map, only mirrored and/or rotated. And I'm afraid to think of what it will to take the rest of the code to reliably work with the generated map. You have to guarantee that a crash or a softlock won't happen because the generated map violated some implicit assumption made by the rest of the code about the map. And even if you manage to do all this, there will be very little actual gain from the gameplay perspective, there are not too many races and they are quite easy to find, and when you find a few of them you can visually pinpoint where the rest of them are. But what IS hard to find and what greatly affects mid-to-late game are certain special objects. Right now it is really tempting to say when you are still relatively early into the game: "ok, this much fuel should be enough, off to Alpha Pavonis, and I'll drop by Beta Corvi while I am at it." And that's really game breaking, isn't it? The mid-to-late game is about looking for information on where you can find some stuff and if you can just go and grab it right away it ruins the game a bit. So you can go through these important objects, one by one, decide if it really make sense to move around this object, if yes figure out where the object can go (like VUX beast can go to any of the 8 stars in the constellation, the taalo shield must be somewhere around Orz space, the Crashed Dreadnought can appear anywhere on the map, it doesn't have to be somewhere near the Arilou space, those guys can go anywhere they want) then place it and adjust the relevant dialogs appropriately. Overall, I think that you can improve the game, especially it's replay value, by doing one small thing at a time, first picking some low hanging fruits then moving to something more complex. I haven't really looked at the codebase, but something tells me that it's easier to write a remake (and in a higher level language, like c# or java) from scratch than introduce big changes into the game. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on November 03, 2015, 05:01:41 am And while I am at it, you could decrease the number of enemy ships that pop out in hyperspace and in normal space, but at the same time massively increase their speed. This will result in enemy ships catching up to you when you leave planet orbit and enter space, then deep space and then hyperspace. [...snip...] Making their speed in truespace and hyperspace independent of their combat speed would fix this problem. Your flagship's truespace and combat speeds are related. To make this not true of your enemies would make it seem like they are cheating. I'm not quite sure about hyperspace speed; do enemy speeds vary at all in hyperspace? I'm pretty sure the flagship's speed does vary, though.As to moving around races, this sounds like a massively daunting task, there are too many invariants set in the dialogs and in the game lore that must be kept for this to make sense. You have to pick the spot for the battleground where the the two races fight for Sa-Matra, you have to decide which way is the center of the galaxy, where the Ur-Quan and Kohr-Ah fleets came from, where the Alliance of Free Stars was, and that roughly defines where most of the races and special places should fit. With all this, I don't think you can really have much variety here, the end result will always end up looking something like the current fixed map, only mirrored and/or rotated. And I'm afraid to think of what it will to take the rest of the code to reliably work with the generated map. You have to guarantee that a crash or a softlock won't happen because the generated map violated some implicit assumption made by the rest of the code about the map. And even if you manage to do all this, there will be very little actual gain from the gameplay perspective, there are not too many races and they are quite easy to find, and when you find a few of them you can visually pinpoint where the rest of them are. Basically I would say you shouldn't move any race's sphere of influence. You could however change the homeworld or other important locations to be some other planet within the sphere of influence, at least for the new races that didn't appear in SC1.the taalo shield must be somewhere around Orz space, It should be in the Vulpeculae constellation, probably, and it shouldn't be in the Androsynth system. Also, if I recall correctly, it's supposed to be a moon. That doesn't leave a lot of options.the Crashed Dreadnought can appear anywhere on the map, it doesn't have to be somewhere near the Arilou space, those guys can go anywhere they want) The crashed dreadnought can't go literally anywhere. It must be placed somewhere out of the way, which means it shouldn't be in any sphere of influence (including the Ilwrath's original SoI that appears on the paper starmap which was included with the game). This also means it shouldn't be in Sirius or the Centauri constellation, as those are too close to Earth.Moving important objects like that is probably a lot harder than you think. The dialog is currently hardcoded with numerous assumptions on the locations of important items, meaning that if they can move you would need some way of dynamically altering the dialogue to fit. It's not just a matter of changing numerical coordinates. Title: Re: UQM stars/races relocation mod? Post by: kfdf on November 03, 2015, 07:21:17 am Quote Your flagship's truespace and combat speeds are related. To make this not true of your enemies would make it seem like they are cheating. I'm not quite sure about hyperspace speed; do enemy speeds vary at all in hyperspace? I'm pretty sure the flagship's speed does vary, though. Of course enemy speeds vary in hyperspace. Slylandro probes are barely slower than the Flagship with all thrusters, no one else comes close to that. And "cheating" is the usual way to balance out AI's stupidity, who doesn't "lead" the target, who enters planet's near space instead of waiting for the player in deep space, who can't catch up with the player in hyperspace while he is exploring a star system because all entities in hyperspace freeze during that time. The "proper" way would be to fix all those issues, but just boosting their speed seems to be the most simple option.Quote It should be in the Vulpeculae constellation, probably, and it shouldn't be in the Androsynth system. Also, if I recall correctly, it's supposed to be a moon. That doesn't leave a lot of options. Is all of that is said in some dialogs? I don't remember the "out of the way" part. Regardless, deciding where each item can go should be decided on a case by case basis and even there are only a few possible spots, that's enough to keep honest people honest.The crashed dreadnought can't go literally anywhere. It must be placed somewhere out of the way, which means it shouldn't be in any sphere of influence (including the Ilwrath's original SoI that appears on the paper starmap which was included with the game). This also means it shouldn't be in Sirius or the Centauri constellation, as those are too close to Earth. Title: Re: UQM stars/races relocation mod? Post by: kfdf on November 03, 2015, 09:05:27 am Quote Moving important objects like that is probably a lot harder than you think. The dialog is currently hardcoded with numerous assumptions on the locations of important items, meaning that if they can move you would need some way of dynamically altering the dialogue to fit. It's not just a matter of changing numerical coordinates. I poked around the code a bit (good lord, I certainly can't into Git or plain C, all I can do is to monkey my way around with GoToDefinition and FindAllReferences) and for instance in NPCPhrase_cb function in commglue.c you get a pointer to chars constituting the phrase, index of the the phrase, and I'm sure that you can figure out which alien the phrase belongs to from CommData. The pointer is writable as done in DISABLE_PHRASE macro which simply writes terminating null at the start. All of that seems to be enough to at least overwrite the existing phrases. Doing it here is an ugly kludge and not being able to reallocate the phrase is a serious limitation, but it's a start, and I'm pretty sure this can be easily overcome with some dedication and time. Of course there is no real way to fix the voiceovers.PS Just noticed, judging by the forums Star Control 2 seems to be deader than dead, but several dozens people seem to download it every day, and that's three years after the latest release. They could be downloading a much better game... this game needs you, logarithm. ;) Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 03, 2015, 10:00:36 pm I'm not yet sure, but if this function below (from solarsys.c) is all it takes to determine star planetary content, then i'll just fake the seed for important stars. In any case I'll keep original contents inside important stars.
Code: DWORD GetRandomSeedForStar (const STAR_DESC *star) { return MAKE_DWORD (star->star_pt.x, star->star_pt.y); } I'll be working on this mod on weekends. So, not much progress on working days. ---------------------------------- Thanks for comments guys. :) But maybe you should start small, like, randomizing star colors and moving them just a tiny bit, so that their seed would change? Yeah, I actually plan to do small steps, and stick to KIS principle. One of mistakes Nicholai did was putting alot of different unrelated stuff under one mod - which is antipattern, and a common mistake for unexperienced developers. Although I like the ideas you mentioned about poor balance, I'll leave it to another mod, - but this mod will be totally about relocation. I hope I'll do it (the better-balance-mod) later, and for this reason I ask you to open disscussion about it's probable content in different topic. As to moving around races, this sounds like a massively daunting task, there are too many invariants set in the dialogs and in the game lore that must be kept for this to make sense. You have to pick the spot for the battleground where the the two races fight for Sa-Matra, you have to decide which way is the center of the galaxy, where the Ur-Quan and Kohr-Ah fleets came from, where the Alliance of Free Stars was, and that roughly defines where most of the races and special places should fit. With all this, I don't think you can really have much variety here, the end result will always end up looking something like the current fixed map, only mirrored and/or rotated. And I'm afraid to think of what it will to take the rest of the code to reliably work with the generated map. You have to guarantee that a crash or a softlock won't happen because the generated map violated some implicit assumption made by the rest of the code about the map. And even if you manage to do all this, there will be very little actual gain from the gameplay perspective, there are not too many races and they are quite easy to find, and when you find a few of them you can visually pinpoint where the rest of them are. Basically I would say you shouldn't move any race's sphere of influence. You could however change the homeworld or other important locations to be some other planet within the sphere of influence, at least for the new races that didn't appear in SC1. (click to show/hide) 35 special stars, which is <10% of all. If we imagine it as a graph (where nodes are stars, and links - distance assumptions), then it would be a set of weakly connected sub-graphs. I bet it won't contain more than 50 assumptions. And since I'll have to extract all coordinates and star names (read below about this) out of dialogues - this will help me also to define most (but not all) of those assumptions. What I need is to define the rest of assumptions, - and your sentences about "taalo shield" and "Crashed Dreadnought" and similar stuff could actually help me doing that. Once I have such graph defined, I'll simply have to apply some graph layouting algorithm with randomization. Next draw cluster areas. And finally fill clusters (and non-clustered space) with 465 non-important stars. Moving important objects like that is probably a lot harder than you think. The dialog is currently hardcoded with numerous assumptions on the locations of important items, meaning that if they can move you would need some way of dynamically altering the dialogue to fit. It's not just a matter of changing numerical coordinates. Good point. I was thinking about that too. I still haven't decided how to deal with that, but most probably I'll make use of script, which finds all usages of star/cluster names in all dialogues. Not hard to do so. And I think I'll find 10-20 usages. I will already have to extract coordinates out of dialogues, so extracting star-names after that won't be hard. Once I extract star-names, I have a really nasty idea to change (randomize) names of important stars too....You have to pick the spot for the battleground where the the two races fight for Sa-Matra, you have to decide which way is the center of the galaxy, where the Ur-Quan and Kohr-Ah fleets came from, where the Alliance of Free Stars was, and that roughly defines where most of the races and special places should fit. With all this, I don't think you can really have much variety here, the end result will always end up looking something like the current fixed map, only mirrored and/or rotated. Why not breaking huge Ur-Quan and Kohr-Ah fleets into 3 smaller circles?.. ;D This would give a better potential for randomization. Also, Sa-Matra don't have to be in the middle of galaxy I think (if that's the price for better randomization).And I'm afraid to think of what it will to take the rest of the code to reliably work with the generated map. You have to guarantee that a crash or a softlock won't happen because the generated map violated some implicit assumption made by the rest of the code about the map. Yeah, this is quite an important point. But so far I haven't identified any other assumptions apart from ones listed in the second post (considering, that I'll leave important stars contents original). I'll keep an eye on this, tho. If anyone spots any suspicious please Title: Re: UQM stars/races relocation mod? Post by: kfdf on November 04, 2015, 04:42:06 am Quote Actually, I plan to move them. I know this makes relocation quite complex algorithm, but that's the way I really wanted it from beginning. Ok, in this case planet randomization will be just a minor side effect of what you are trying to achieve. Hopefully, your project won't get buried under its own ambitions.Quote I want to start game in completely unexplored cosmos. But that's against the lore! ;D Remember there was Star Control 1! And there is Commander "Spoilers Galore" Hayes who can tell you much about it. So much, in fact, that this will nullify all your efforts of putting the player in unexplored space, who will be able to map most of the races even before he leaves the Solar system. So, I think you'll have to simply ditch the Lore, cut out or adjust a lot of info from dialogs that restrict the possible layout of the map. You can even forego the idea that there are two regions separated by the coreward front where the old alliance fought the hierarchy, you can make it look like the modern wars without clear and definite front lines, so that anyone can go almost anywhere. Quote Why not breaking huge Ur-Quan and Kohr-Ah fleets into 3 smaller circles?. That's actually would be quite surprising. But something tells me that there are very strong assumptions in the code that every race has only one sphere of influence, so you'll have to introduce two pairs of dummy races in the game, synchronize their dialogs etc. etc. Not saying that's impossible, but certainly not very high on the priority list. Actually, the same can be said about layout algorithms, dialog patching, lore consistency and such. If your core idea is to randomize everything as much as you can, just go for it then and push it as far as you can. Try to rewrite item placement algorithms for special worlds, so that you could randomize them too, get rid of the hardcoded stuff (there seems to be lots and lots of it, why only 465 stars? I want 565..), make the game accept whatever nonsensical map you can throw at it and not blow up your computer. This surely doesn't sound like a small first step, but it will be an important proof of concept.Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 04, 2015, 07:00:31 pm Hopefully, your project won't get buried under its own ambitions. Yeah, I hope so too. I thought about that from bare start of the endeavour. Actually I didn't even think I would get that far - all I did was just for fun an in really relaxed mode. Probably that's a proper way to do things for me without losing motivation. That's what I meant by small steps - no pressure. If I see that graph layouting becomes too hard for me, I'll just make a step back. 8) something tells me that there are very strong assumptions in the code that every race has only one sphere of influence I you have any clue or idea of how such assumptions might look like, or where (in which logics) to look for them - please share. :) I'll put the check for such assumptions in early analysis TODO list. Title: Re: UQM stars/races relocation mod? Post by: rootxploit on November 05, 2015, 04:07:54 am Quote Your flagship's truespace and combat speeds are related Though I agree with this from a world-building perspective it is not difficult to change this in the game. It is kept in the RACE_HYPER_SPEED macro in races.hQuote something tells me that there are very strong assumptions in the code that every race has only one sphere of influence Quote If you have any clue or idea of how such assumptions might look like, or where (in which logics) to look for them - please share. I'll put the check for such assumptions in early analysis TODO list. Each race is synonomous with a sphere of influence. The game will iterate through the race queue and load the RACE_DESC data structure for each race. In that data struct, for example, one is blackurq.c for the Kohr-ah it will definate a sphere of influence size. So to add another one you'd have to create a new race data struct inside a new file (e.g. blackurq2.c) change the sphere of influence and add it to the make file. I'd guess you'd also have to add it to the species_id data struct in races.h. If you do that and it segfaults you probably need to add entries to the rest of races.h. I'm still getting a handle on the different places where races and ships are used myself. It is usually done via a mix of indexing and linked-list iteration in queues. I've made a spreadsheet to help me understand the relationships between each datastructure and that has helped somewhat. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on November 05, 2015, 06:32:26 pm Is all of that is said in some dialogs? I don't remember the "out of the way" part. Regardless, deciding where each item can go should be decided on a case by case basis and even there are only a few possible spots, that's enough to keep honest people honest. The "out of the way" part is based on the assumption that a Dreadnought crashing within another race's sphere of influence is unlikely to go unnoticed. Since only the Arilou discovered it, it shouldn't be too close to other races where they would be likely to discover it first. This is never mentioned in dialogue as far as I recall.Actually, I plan to move them. I know this makes relocation quite complex algorithm, but that's the way I really wanted it from beginning. The algorithm which would respect clusters too. I want to start game in completely unexplored cosmos. And I think I'm a capable programmer for such task. The reason I suggested not moving the spheres of influence is because they're given on the paper starmap (for all the races). There are also assumptions in the story about relative positioning of the SoIs. For example, if the Ilwrath SoI is moved too far, it wouldn't make sense for them to have been assigned to watch Earth. The Zot-Foq-Pik need to be within the Ur-Quan SoI (at least partially), because in the story they have a unique insight into the conflict due to their proximity. The Utwig and Supox need to be near each other, because they're friends. The races from SC1 (except Arilou) all need to be arranged near each other, because they were drawn into the war in the first place because of their proximity. The VUX and Mycon need to be near each other due to the Syreen backstory - the Syreen world is a former Mycon planet, and they fled towards VUX space when the planet was captured. VUX and Yehat need to be near each other, because they have a history of hostilities (I think). Yehat and Shofixti need to be near each other, because the Yehat raised the Shofixti. Umgah and Spathi probably need to be near each other, since the Umgah seem to particularly enjoy pranking the Spathi, though this is a more flexible relationship than some of the others. Ilwrath need to be relatively close to Earth, as do the Spathi, because they were assigned to watch over it by the Ur-Quan. Pkunk needs to be somewhat close to Yehat, because the Pkunk are an offshoot. Pkunk also needs to overlap with the Ilwrath, because the Ilwrath are attacking them. The Druuge can't be moved much due to their interactions with the Utwig and the Arcturans (I think they had a race-name but can't remember it). If you can encode all these assumptions into your graph, then by all means, randomize the SoIs. Mirroring the galaxy on the coreward diagonal would probably be fine, though - ie, the Yehat, Vux, and Mycon go up near the left, with the Druuge right at the top left, and the Spathi, Umgah, and Thraddash arrayed along the bottom of the map. The Ilwrath, Pkunk, Utwig, and Supox wouldn't be affected much by this (though the Supox and Utwig would roughly swap positions).Good point. I was thinking about that too. I still haven't decided how to deal with that, but most probably I'll make use of script, which finds all usages of star/cluster names in all dialogues. Not hard to do so. And I think I'll find 10-20 usages. I will already have to extract coordinates out of dialogues, so extracting star-names after that won't be hard. Once I extract star-names, I have a really nasty idea to change (randomize) names of important stars too.... There may be some more indirect references too. I'm not sure. The only way to be absolutely sure is to read through all the dialogue carefully. But maybe it's not worth it for just catching a few extra references.Why not breaking huge Ur-Quan and Kohr-Ah fleets into 3 smaller circles?.. ;D This would give a better potential for randomization. Also, Sa-Matra don't have to be in the middle of galaxy I think (if that's the price for better randomization). I suppose it could make sense for the Ur-Quan and Kohr-Ah to be split. The Sa-Matra does need to be in Ur-Quan and Kohr-Ah space, though. I think it wouldn't make much sense if it wasn't vaguely near the centre of the map, but the centre of the map is a large area.Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 07, 2015, 09:28:54 pm rootxploit
Thanks for thoughts on race fleet separation. I was seeng this in a similar way. CelticMinstrel Great job on defining those distance assumptions. Althought assumptions for Druuges not clear. I don't remember many things from gameplay. And according to map, Yehat is quite far from Pkunk. Not sure if this is starting location or late location, - if i remember correctly, at some point their fleets got intersecting. According to code their (Yehat) fleet starting loc is 497.0, 4.0. (click to show/hide) In the end I want to have a specification for all those assumtions in a strict form, something like this: Code: ... I can then keep them in separate file and load into game in relocation procedure. I'll start with the minimal specification - for the proof of graph layouting algorithm, and in the end we can use a full specification.DIST ( {HOME_PKUNK, FLEET_CENTER_PKUNK }, NOT_APPLICABLE, MAX( 30.0) ); DIST ( {HOME_PKUNK, FLEET_EDGE_ILWRATH }, MIN( 20.0), MAX( 50.0) ); DIST ( {HOME_SOL FLEET_EDGE_PKUNK }, MIN( 50.0), MAX( 250.0) ); DIST ( {HOME_SOL, FLEET_EDGE_ILWRATH }, MIN( 10.0), MAX( 50.0) ); DIST ( {HOME_ILWRATH, FLEET_CENTER_ILWRATH}, NOT_APPLICABLE, MAX( 50.0) ); DIST ( {HOME_ILWRATH, FLEET_EDGE_PKUNK }, MIN( 10.0), NOT_APPLICABLE ); DIST ( {HOME_ORZ, ENERGY_TAALO }, MIN( 2.0), MAX( 30.0) ); ... If anyone willing to start defining this specification - welcome! :) If anyone willing to participate, then I'll start publishing stuff into my GIT repo... ------------------------ So far I've managed to run a module, which randomizes all stars locations (keeping contents of important stars). Currently without complex logic of forming clusters, respecting distance assumptions and other stuff. It also writes all star relocations to dedicated log file - gonna need it later for testing. Also managed to enable no-intro mode for faster debugging and learned to use debug key. Next stage will be extraction of all hardcoded coordinates (and fleet sizes, and distances) to managable module. Bad news, is that it's gonna be hard to test them all. So probably I'll leave some of them them untested (risk should be quite low though). If anyone wants to help testing - welcome. Meanwhile slowly approaching to the hardest challenge - graph layouting algorithm. Started reading some papers on that and tapping related communities. Title: Re: UQM stars/races relocation mod? Post by: kfdf on November 08, 2015, 08:01:42 pm Quote The "out of the way" part is based on the assumption that a Dreadnought crashing within another race's sphere of influence is unlikely to go unnoticed. That sounds like a far fetched assumption. There is an entire race that stays almost unnoticed inside two other races' spheres of influence. I actually remember being surprised, like, what the hell the ur-quans were doing out there so far from their battlefield? And btw, the original game didn't really push you into the fight with the ur-quan until the very end. They are the main antagonists of the game, but you rarely had any reasons to fight them. And the search for the crashed ur-quan dreadnought deep into their territory sound like the good opportunity to fix this. It would be even better if you didn't know the exact location of the crash site. Same thing with the Syreen ships. The intelligence ZFP give you on them could be a little more vague...Quote If anyone willing to start defining this specification - welcome! Here is a doodle to try some ideas. It reads fleets and constraints information from a file, arranges the fleets randomly on the map and runs a simulation (at 30 fps for illustration purposes) that pushes and pulls them according their constraints. Space key shakes up the map, any other key randomizes fleet locations. Sometimes the results make no sense, but sometimes they are quite playable. dotNET 4.0 required.https://drive.google.com/file/d/0B-x8G2X1znSaMThHYnZWbWI5UW8/view?usp=sharing (https://drive.google.com/file/d/0B-x8G2X1znSaMThHYnZWbWI5UW8/view?usp=sharing) Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 08, 2015, 10:43:55 pm Quote If anyone willing to start defining this specification - welcome! Here is a doodle to try some ideas. It reads fleets and constraints information from a file, arranges the fleets randomly on the map and runs a simulation (at 30 fps for illustration purposes) that pushes and pulls them according their constraints. Space key shakes up the map, any other key randomizes fleet locations. Sometimes the results make no sense, but sometimes they are quite playable. dotNET 4.0 required.https://drive.google.com/file/d/0B-x8G2X1znSaMThHYnZWbWI5UW8/view?usp=sharing (https://drive.google.com/file/d/0B-x8G2X1znSaMThHYnZWbWI5UW8/view?usp=sharing) Which algorithm/library did you use? Would you join mod development? ::) I was thinking about using the Spring Embedder algorithm, but kinda got lost among it's versions for now. The steps I was thinking about: (1) Randomize all impotant stars/fleets locations. (2) Let springs do the job. (3) After timeout check if all constraints are respected. If not, goto (1). Title: Re: UQM stars/races relocation mod? Post by: kfdf on November 09, 2015, 03:24:40 am Quote Great stuff! Grin Coding is my hobby, hobbies are supposed to be fun, and there is no fun for me in plain C, only misery and pain. Looking at the codebase only confirmed and reinforced my worst fears. Which algorithm/library did you use? Would you join mod development? And there is no algorithm per se, things are just arranged randomly, and then "forces" are applied to them until they fall into their proper places. I played with it a bit, mainly trying to introduce some structure into the map it by using dummy fleets that represent empty space (or as they say in Art, "negative space") by being arranged into chains, attached to edges or the center of the map, or even real fleets... I had mixed success, so I ended up using two dummies with fixed positions to force ur-quans away from the edges and one dummy around the Sol to push other fleets away from it without explicitly defining all those constraints. But I still believe that judicial use of dummies and constraints can make maps look more realistic. (click to show/hide) Quote (3) After timeout check if all constraints are respected. If not, goto (1). Yes, that's what the spacebar does. ;D And it would help to run some heuristics to detect cases where results are technically acceptable but aren't very playable or visually pleasing, like when all or most fleets are lumped together on one side of the map leaving large empty spaces elsewhere, or pushed against the edges of the map etc.Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 09, 2015, 07:11:33 am kfdf
Thanks for the code - will make use of that. It's good for at least first versions, later we can refine it (althought for me all maps it generated looked quite alright already). Quote there is no fun for me in plain C, only misery and pain Yeah, that language isn't a gift, especially when got practice with some really advanced languages, like Scala or Haskell. But at least C got macroses loool.---------------------------------- I'll also need to think of the way of making stars into constellations. Not sure how will be done yet. Probably (1) random-evenly generate only constellation stars first (2) random-evenly put attractors to map, and let them attract nearby stars, grouping them into constellation (3) scan map to get emptiest spaces, and fill them with non-constellation stars From 502 stars total I've counted 102 constellations stars, and 30 non-constellation stars. Title: Re: UQM stars/races relocation mod? Post by: kfdf on November 10, 2015, 12:29:09 pm Quote I'll also need to think of the way of making stars into constellations. Not sure how will be done yet. I wrote a star randomizer that grouped them in constellations as a part of a tool (admittedly, mostly redundant given the generated nature of the map) that can be found in this thread http://forum.uqm.stack.nl/index.php?topic=6078.0 (http://forum.uqm.stack.nl/index.php?topic=6078.0), and while simple, the end result needed some postprocessing and more importantly, is kind of hard to integrate with the fleets map. So here's a better, yet even more simple randomizer. It's very much like you described it, and there is even no need to run a simulation on it. Stars are randomly generated and then every star selects one attractor and is pulled towards it. Which attractor is selected is based on the distance to it and its strength, and pull strength is dependent on two factors, one comes from the attractor (to give every constellation some individuality), and another is defined by the star itself. Playing with strength and factors formulas can give some interesting looking results, the ones I used seem to give sufficiently adequate results. (click to show/hide) Quote From 502 stars total I've counted 102 constellations stars, and 30 non-constellation stars Is this really important, which stars are parts of constellations and which aren't, they are just names, right? So you can have Alpha Groombridge, Beta Groombridge etc... I mean, the game even has a couple of stars missing from constellations and nobody cares...Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 10, 2015, 09:38:19 pm On first iterations we can make this simple. Later, after whole mod is done, we can refine this.
I think better stick to those requirements (1) Each "constellation attractor" should attract no more than ~2-10 stars (fixed random for each attractor). (2) Attractor shouldn't make stars come too close to each other. (3) (doubtful) While attractor attracts - it may move too. This way we may get something more complex, than only spheric constellations. (4) Attractor better stop, if stars densities gets too high nearby. May somehow incorporate with (3). Maybe too complex for first iteration, though. The refinement for after-release may be making a file containing constellation patterns (for constellations like Horologii, Vulpeculae, Chamaeleonis, etc). And for some constellations instead of using dynamic attractors - just place stars in predefined patterns. Can even make more patterns, than generator would actually use - this would give even random set of constellations for each generation... I'm getting more and more confident, that I'll need to remix names of all stars (except for Sol). Remixing names will fit well into constellation generation procedure (for proper naming of constellations). I'm now somewhere 70% done extracting all hardcoded coordinates to a single manageable module. Next will be extraction of star-names. Btw, if you feel more on playing with interesting tasks, you may also tackle the problem of identifying big empty spaces. There are few interesting approaches for doing that (like using fields, or making use of sectoring, or other approaches). Knowing, where attractors acted might be handy.. ;) Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on November 12, 2015, 02:26:39 am Althought assumptions for Druuges not clear. I don't remember many things from gameplay. Basically, the Druuge have confirmed relationships with two races in the story - the Utwig, to whom they tried to sell the Ultron (but got ripped off), and the Burvixese of Arcturus. That means that Arcturus needs to be near the Druuge sphere of influence, and it should probably be near that edge of the map as well, since the Druuge saved themselves from the Kohr-Ah by sacrificing the Burvixese.And according to map, Yehat is quite far from Pkunk. Not sure if this is starting location or late location, - if i remember correctly, at some point their fleets got intersecting. According to code their (Yehat) fleet starting loc is 497.0, 4.0. That map has the Pkunk's original location. Eventually, they move to rejoin the Yehat. (click to show/hide) By the way, one SoI on there was different before the war - the Ilwrath sphere of influence used to be a lot smaller and centred near the Tauri constellation (where their homeworld is). This probably isn't very relevant to your randomization project though. Quote The "out of the way" part is based on the assumption that a Dreadnought crashing within another race's sphere of influence is unlikely to go unnoticed. That sounds like a far fetched assumption. There is an entire race that stays almost unnoticed inside two other races' spheres of influence. I actually remember being surprised, like, what the hell the ur-quans were doing out there so far from their battlefield? And btw, the original game didn't really push you into the fight with the ur-quan until the very end. They are the main antagonists of the game, but you rarely had any reasons to fight them. And the search for the crashed ur-quan dreadnought deep into their territory sound like the good opportunity to fix this. It would be even better if you didn't know the exact location of the crash site. Same thing with the Syreen ships. The intelligence ZFP give you on them could be a little more vague...There's a simple answer for why the crashed dreadnought is so far from the Ur-Quan's battlefield. The Ur-Quan are not from this part of the galaxy. They arrived from the top left of the map, conquered the Thraddash, and then moved on into the war with the Alliance of Free Stars. After bringing the Sa-Matra in to quickly end that war, they met in combat with the Kohr-Ah at the centre of the starmap. So, in fact, that crashed dreadnought is actually pretty close to the area that the Ur-Quan came through. I think it wouldn't make any sense for the crashed dreadnought to be in their current sphere of influence. I could maybe understand it being in the Thraddash, Umgah, or Spathi SoI, or maybe even in the Ilwrath or VUX SoI, but if it was in their current SoI I would really be wondering why they didn't find and destroy it already. Don't forget that their ships are designed to self-destruct when defeated, so as to keep their technology out of enemy hands. I wouldn't be surprised if they have the ability to detect emissions or something from ships whose self-destruct failed. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on November 12, 2015, 02:35:06 am I'm getting more and more confident, that I'll need to remix names of all stars (except for Sol). Remixing names will fit well into constellation generation procedure (for proper naming of constellations). There might be a few others that it's simpler to not rename. Arcturus and Vela in particular, but possibly also Betelgeuse, Procyon, and Groombridge....speaking of Groombridge, will your randomization retain the arrow formation of the rainbow worlds? ...oh, also, the placement of the Slylandro should probably be kept in the upper-left quadrant. This could be difficult, because there's several vague references indicating their location - I believe the Spathi, Thraddash, and Zoq-Fot-Pik all give information that points in the right general direction. Maybe the Umgah do as well? I kinda suspect not, though. (The Melnorme give the exact location, I believe, so that's easy.) Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 12, 2015, 09:13:14 pm CelticMinstrel
:) Thans for hints. I already took care of Slylandro. Yeah, there are some stars weaved into story. Apart from mentioned ones, also Antares and Horologii constellation (for Supox and Utwig). Apparently, I'll have to respect those assumptions while relocating stars, races, and giving names to stars and constellations. Quite a knot. But not too difficult. As for Rainbow worlds - probably not. Maybe in some future release after v1.0. But I'll keep that in mind. Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 15, 2015, 12:54:33 pm Finally finished extractind all coordinates.
Had to generalize some coordinates evaluation. F.e., when fleet decides to approach another fleet for attack. Also extracted few more distance assumptions. Tested most coordinates, except for event, when Ilwrath decides to approach Thadds. Also didn't make sure events flow normally (like fleets die in war). And didn't test most of communications - only tested Spathi on Pluto for proof of concept, and then cloned the solution to other communications. If anyone would wish to test, notify me. The risk is low, but it's still worth to test if global events (involving moving and fighting fleets) are not damaged. Dialogues duplicate in Code: sc2/content/base/comm/ andCode: sc2/content/addons/3dovoice/ Not completely sure, but I think latter ones are not used. I modified only first location.------------------------------------ Next - extraction of all star and cluster names. After that - randomization of fleets locations. Will make use of experiments made by kfdf. Have also some thoughts for other future mods, but can't allow them to spring yet. )) I'll just leave them here, so they don't bother me: ** One of ideas involve making alien fleets in Hyperspace more random. F.e. some Slylandros faster, some slower, some attacking with not full crew. Also not all fleets will attack. Some will pass by, and some will run away. Make racial fleets appear rarely randomly away from their Sphere of Influence. Make mixed fleets of mercineries, traders, pirates, cargo. Loot (not only credits), trade and bribery... ** Another mod idea is about better balance. Probably will make cost of thrusters and turning-jets depend on how much installed already. Like, 1st - 500 RU, 2nd - 750, 3rd - 1000, 4th - 1500, 5th - 2000... ** Make "Kohr-Ah Death" mod a bit more configurable. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on November 15, 2015, 10:26:06 pm For races whose homeworlds or home constellations are given by name, you can probably just assign names after generating all the stars and assigning homeworld locations, so that the name constraints are satisfied. For example, when naming stars, the constellations containing Supox and Utwig should be called Antares and Horologii because the homeworlds of those two races have already been assigned to a star in that constellation.
Dialogues duplicate in Both should be used. The first would be used when voices are disabled, the second when voices are enabled. Or, at least, I think that's the intention. If voices are installed, it might use the second one even if they're disabled.Code: sc2/content/base/comm/ andCode: sc2/content/addons/3dovoice/ Not completely sure, but I think latter ones are not used. I modified only first location.Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 15, 2015, 10:53:12 pm CelticMinstrel
Actually, with voices on - it used sc2/content/base/comm/ (at least for Spathi on Pluto). I guess I'll have to double-check that... As for naming - yeah, I'll have to choose proper order of stars relocation, renaming, constellations formation, fleets relocation. I'm not planning to keep original names for homeworlds and important stars. That's why I'm extracting star/contsell names. For Antares and Horologii it's even harder. These are not homeworlds, - these are territories in UrQuan SoI, where allied Utwigs and Supox may come to attack evil asses. I spent few hours for writing/testing algorithm of calculating coordinates of these regions for cases, when Utwigs and Supox reside elsewhere. So I'll have to pick nearby constellation and a lone star and place there, - specially for Supox and Utwigs... ::) Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on November 16, 2015, 02:40:01 pm Actually, with voices on - it used sc2/content/base/comm/ (at least for Spathi on Pluto). Hmm. It could be that the second location doesn't have the full dialogue? It might just have some files overriding the defaults. I'm not really sure, but I do know that there are supposed to be some differences in dialogue when the voices are enabled.I guess I'll have to double-check that... For Antares and Horologii it's even harder. These are not homeworlds, - these are territories in UrQuan SoI, where allied Utwigs and Supox may come to attack evil asses. I spent few hours for writing/testing algorithm of calculating coordinates of these regions for cases, when Utwigs and Supox reside elsewhere. So I'll have to pick nearby constellation and a lone star and place there, - specially for Supox and Utwigs... ::) Oh, it was that, whoops. In that case I think you could just do something like picking the Ur-Quan constellations nearest to wherever Utwig and Supox end up. Something like that.Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 16, 2015, 08:57:01 pm Quote some files overriding the defaults Yeah, most probably. Some dialogue files duplicate (with minor differences), others have texts only in sc2/content/base/comm/.Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 20, 2015, 07:20:41 pm I need to learn and practice Go language for my next project, so I used that to write a script for smart-search through the project for star-names.
I got 242 hits - all of them in communication files (click to show/hide) Now 242 is too much to handle it manually. It's also risky (to make mistakes). So, I decided to make another Go script to make smart-replaces in those *.txt files, and to make a cunning solution in related *.c files... For example, I'll turn Utwig's words Code: Indeed, it seems that you should proceed to the second moon of the sixth planet of Zeta Hyades into Code: Indeed, it seems that you should proceed to the second moon of the sixth planet of $${StarName:ImortantStarIdx=22} It will be much harder with non-important stars being mentiond. Like Code: Starbase Commander: The Ur-Quan came roaring through VUX space, and tried to push past the Indi and Mira star systems. orCode: Syreen: They all appear to be originating from the direction of the Horologii constellation. Will have to deal with them manually...Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 21, 2015, 01:44:56 pm Published Git repo https://sourceforge.net/u/uqm-logarithm/sc2/ci/master/tree/ .
Work being done under MS VC2010. (with all my great respect to Linux community, sorry) Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 21, 2015, 02:53:17 pm From these 242 mentions there are 2 kinds of cases:
** Simple - will be able to deal with them atomatically. ** Hard ones - will need to handle them manually. Mentions of constellations (22) and non-important stars (8 ). I'll deal with simple cases first. After that will need to describe assumptions for the hard ones. If anyone wishes to participate - fill in the table here: https://sourceforge.net/u/uqm-logarithm/sc2/ci/master/tree/tools/for-relocation/data/mentioned-assumptions.xls The context game-texts are in same XLS (on first sheet). Title: Re: UQM stars/races relocation mod? Post by: logarithm on November 22, 2015, 01:45:36 pm Finished and tested simple mentions (of important stars) with both communication files and lander messages. Dealing with Strings in C is really tricky and not easy at all - negative side of low level languages.
Finished analyzing mentioned constellations and semi-important stars. Also extracted some more assumptions about fleets and homeworlds. Actually felt like a historican/archivist while reading through all that info. 8) Pleasant romantic work. Hardest cases for positionining will be >> 3 constellations in Arilou SoI (originally Chandrasekhar, Circini, Columbae). Will have to apply some simple maths here. >> Horologii and Antares are already dealt with. >> Lacaille and Krueger are to be placed in intersection of Pkunk and Ilwrath. >> "the snake-like creature who has swallowed the elephantine beast" >> Mira and Indi - inside Vux fleet, closer to Sol Aldready have good math functions for most cases. The others mentions will be really easy to resolve. I'll solve the hard-mentions extraction in the following manner: ** Will create 2 enumerations for them, similarly as important stars are enumerated (in gendef.h): important constellations and semi-important stars. ** There will be 2 dictionaries: [important constellation idx -> general constellation idx] and [semi-important star idx -> ptrStar], which will be filled as a result of relocation in a dedicated procedure solving assumptions. ** For non-relocational mode I'll fill those maps with semi-hardcoded stuff. ** The communication files will get inlined with variables (similarly like I dealt with important stars) Code: $${StarName:ImortantStarIdx=%d} $${StarNameUC:ImortantStarIdx=%d} $${StarName:SemiImortantStarIdx=%d} $${StarNameUC:SemiImortantStarIdx=%d} $${ConstelName:ImortantConstelIdx=%d} $${ConstelNameUC:ImortantConstelIdx=%d} Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on December 01, 2015, 12:06:43 am Does that mean that the hints towards the location of the Slylandro are not difficult or, perhaps, are even already dealt with?
Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 01, 2015, 05:24:26 am Yeah, it was easy one.
(click to show/hide) I'm currently in the middle of changing industrial project. Had to work overtime for whole weekend. Not much progress with the mod, thus. In the mod currently finishing structuring 9-steps galaxy formation procedure, which involves steps like fleets placement, important stars placement, etc. Procedure will have two modes: step-by-step form original galaxy, and step-by-step form random one. It's filled with defensive structures, with intension to detect errors early. Once this procedure works fine for original map, I'll go on with making galaxy randomizer... Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on December 01, 2015, 04:37:59 pm Eh? That's just the probes speaking the coordinates of the Slylandro homeworld, right? I meant the hints you get from other races, especially the ZFP, but also Thraddash and possibly Spathi. (Speaking of Spathi, the Arilou SoI would need to be near both Spathi and Umgah, since you get a hint about the Arilou from the Spathi, and they have contact with the Umgah.)
Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 06, 2015, 08:45:43 pm CelticMinstrel
Yeah, I've dealt with those things. Everything mentioned here (https://sourceforge.net/u/uqm-logarithm/sc2/ci/master/tree/tools/for-relocation/data/mentioned-assumptions.xls) is dealt with. As for distance assumptions in general (which are specified here (https://sourceforge.net/u/uqm-logarithm/sc2/ci/master/tree/sc2/content/relocation/galaxy-coord-assertions.spec)). I will fill it more later. If you have anything to add there right now, I would be very grateful, if you do it in format used in the spec file. The assumptions regarding Spathies are tricky. Melnormes mention, that they practiced colonization in Algol system (which is in Druuge SoI) and they are also aware of the Vux-related megabeast (which is by the north edge of galaxy). So the distance for them is not so much of a barrier. On other side, they didn't know about ZFP, until Mmrnmhrm (or Chenjesu (don't remember)) made an expedition to the centre of galaxy. Thus, I think these distance assumptions are not always to be dealt so strictly. But I've added the distance assumption between Spathi and Arilou (not yet committed). ----------------- I had some unsuccessful trials with my code. Introduced some serious changes and hoped to debug/compile this in one blow. Well, that approach works with most of languages/projects, but not here. I got 10k or cyclicly reoccurring compile-time bugs with absolutely nonsensical descriptions... So I've lost few days on step-by-step reintegration of my solution into the project, and still have to spend 1-2 more days on that... An unpleasant part of work. Actually, it's so damn cool, when you don't have the deadlines, like ones in industry. Title: Re: UQM stars/races relocation mod? Post by: Death 999 on December 11, 2015, 05:43:05 pm With the non-important systems, can't you place those names based on the important things they're conceptually linked to?
Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 11, 2015, 09:29:34 pm Death 999
Sorry, didn't understand you. Currently I separate 3 categories of stars: ** important ones - homeworlds and artefacts ** semi-important stars/constellations - mentioned in dialogues ** non-important ones - can be freely randomized If you meant semi-important stuff - it will get templated in dialogue files, get randomized names, will respect names and locations of important stars and fleets... ----------------------------------- If anyone wishes to help - I would really benefit from having a single C-file program, compilable with gcc, runnable from Cygwin shell, and which would ** draw a graphical square map for hyperspace with a grid (galaxy size is 10000x10000; no need to zoom - just simplest top-down view) ** have a function to draw array of POINTs ** have a function to erase array of POINTs Need it to test dozens of upcoming stars positioning algorithms. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on December 14, 2015, 06:03:56 am The assumptions regarding Spathies are tricky. Melnormes mention, that they practiced colonization in Algol system (which is in Druuge SoI) and they are also aware of the Vux-related megabeast (which is by the north edge of galaxy). So the distance for them is not so much of a barrier. On other side, they didn't know about ZFP, until Mmrnmhrm (or Chenjesu (don't remember)) made an expedition to the centre of galaxy. Thus, I think these distance assumptions are not always to be dealt so strictly. But I've added the distance assumption between Spathi and Arilou (not yet committed). The distance for the Spathi/Arilou relation can be fairly large too - as I recall they just mention seeing a "star" that appears for three days each month (which refers to the Quasispace portal). As for the megabeast, I would suspect they know of it more from rumour (via Umgah and/or VUX, or even Thraddash) than personal experience. I wasn't aware about the Algol thing though; I'm quite surprised to hear that the Spathi ventured that far from their sphere of influence. I wonder if it was their own initiative, or something to do with the first Alliance-Hierarchy war (it's not that far from the Mycon after all, right?).The only SC1 race that (directly) knew anything about the ZFP was the Chenjesu. If I recall correctly, the infodumps that Hayes has to offer include a mention of this. My guess is that the Spathi probably didn't know know of them because 1) the Spathi a fearful race who is unlikely to go out of their way to find other sentient races and 2) the ZFP may have gained hyperspace technology only very recently (for example, during or just before the first Alliance-Hierarchy war). Title: Re: UQM stars/races relocation mod? Post by: Death 999 on December 16, 2015, 11:50:28 pm Death 999 Sorry, didn't understand you. I don't see the things I remember replying to. I think I could have had a very out-of-date page access. Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 18, 2015, 11:37:23 pm Quote I wasn't aware about the Algol thing though; I'm quite surprised to hear that the Spathi ventured that far from their sphere of influence. Probably that's mistake by original devs. Or diplomatic trick(lie) by Melnormes - they mentioned this story about Spathies...-------------- I've done quite some work for reorganizing code of galaxy initialization into 10-steps chain: (1) Initialization of initial fleets (2) Initialization of important stars (3) Initialization of important constellations (4) Initialization of semi-important stars (5) Initialization of non-important constellations (6) Initialization of non-important constellation-stars (7) Initialization of non-important solo-stars (8 ) Initialization of quasi-space locations (9) Initialization of important coordinates (10) Compilation of all previous steps results into a starmap Most steps also produces dictionaries, which are required for templating dialogue files and for future relocation algorithms. All this kitchen also requires to be saved/loaded with game saving/loading. Also did alot of defensive programming, since my testing power is quite low. Current structure works for original map, and contains placeholders for relocation algorithms, which should fit in easily. I also made a prototype of graph-layouting algorithm based on springs. Works for simple cases, but fails to draw a house (medium-complexity case). I think it should suffice, if not, I'll refine it when introduce/test it in game. --------------------------------------- Current plan: (1) Finish templating of mentions in dialogue files of important constellations, semi-important stars. 90% done. (2) Extract misplaced starmap initialization logics from game main-menu. The latter one is an unpleasant surprise. globdata.c has a InitGameStructures function, which initializes fleets and also turns on the START_INTERPLANETARY activity - Code: GLOBAL (CurrentActivity) = IN_INTERPLANETARY | START_INTERPLANETARY; - which leads to call of ExploreSolarSys() in Starcon2Main(...). ExploreSolarSys wants starmap and Sol to be already defined. And all this is happening BEFORE game is actually started or loaded from main-menu. I'll either have to introduce an ugly workaround for this, or redesign game initialization procedure, which is really-really complex. Both paths are painful. :-\ Most probably I'll just workaround this mess... Only after those things are done, I can finally start filling in relocation algorithms (some of which are already successfully prototyped). Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 20, 2015, 01:09:49 am Alright. The communication-templating stuff is done.
-------------------- The initialization nightmare looks like this: Code: [USER: run game] The structure is really bad, but no blaming devs - I can easily imagine how it emerged. That's what I call "Live Workaround Tree" (LWT). Almost all big-enough projects has similar degrading effect, when refactoring is considered to be too late and expensive... And I will not even try to fix the mess - it's just too complex. Thus workaround is the only possible choice - the only way to grow something on the LWT is to grow another workaround on it.Starcon2Main BackgroundInitKernel getInitialFleetsDict LoadMasterShipList x*load_ship - initialize all INITIAL states of fleets, loads some heavy resources cycle { StartGame TryStartGame RestartMenu DoInput(DoRestart) -> loop main-menu, until "Start" or "Load" is chosen [USER: enter "Load"] } InitGameStructures // init Fleets some more in their INITIAL states // set starting loc of Player Flagship ExploreSolarSys DoInput(InputFunc = DoIpFlight) DoIpFlight(LastActivity == CHECK_LOAD) SolarSysMenu(LastActivity == CHECK_LOAD --> MenuState.CurState = GAME_MENU) DoInput(InputFunc = DoSolarSysMenu) DoSolarSysMenu(MenuState.CurState = GAME_MENU, Save|Load = Load) GameOptions (LastActivity == CHECK_LOAD) PickGame DoInput(DoPickGame) -> loop in load-menu until save-entry is chosen [USER: choose save-entry to load] SaveLoadGame ConfirmSaveLoad LoadGame // update state of fleets // set loc of Player Flagship So, about the solution. I'm aiming 2 modes for game start: (A) init original starmap & fleets - considered to be fast (B) init randomly relocated starmap & fleets - considered to be slow (especially due to fleets graph-layouting via springs) These modes are already done. Now to integrate them into LWT mess I need to introduce 2 more modes for game init, which will be orthogonal to (A)/(B): (1) fake initialization - done before game is actually started or loaded (near BackgroundInitKernel and InitGameStructures) (2) true initialization The (1) should always be called in ORIGINAL MODE (A) before game is started/loaded. It will be used to load permanent resources into game. Later in procedure it is overwritten by (2). The (2) may be in both ORIGINAL(A) and RELOCATIONAL(B) modes. It should be called only after player pressed "Start New Game". Game loading will need to be dealt additionally. Cases: (click to show/hide) (click to show/hide) (click to show/hide) Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 23, 2015, 03:13:56 pm I've decided to postpone dealing with the initialization hacking, until I have some real relocation algorithms working.
--------------------------------------- I integrated my graph layouting prototype for placing fleets and enforcing distance assumptions between them. As expected, first prototype fails to solve the layouting. For 24 participants and 132 assumptions I get 2-5 assumptions failing to resolve, (click to show/hide) (click to show/hide) This layouter algorithm is the hardest task in the whole endeavour, I should arm myself with patience... Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 24, 2015, 06:10:07 am After fixing few bugs in the layouting algorithm it started working quite nicely, resolving alpha config (132 assumptions) very fast.
I was quite afraid to get drown in endless-fruitless trying to refine algorithm, failing in the end after 1 month, and surrendering whole endeavour. So afraid, that when it finally started working fine (after few fixes), I was like (click to show/hide) I thoroughly analysed all relations between all fleets and important locations and made a matrix of assumptions (https://sourceforge.net/u/uqm-logarithm/sc2/ci/master/tree/tools/for-relocation/data/fleets-dist-assumptions.xls) with full specification here (https://sourceforge.net/u/uqm-logarithm/sc2/ci/master/tree/sc2/src/uqm/starmap/graph-assumps-data.c). I bet it's at least 95% complete, and of course it's content is subject of discussions. This complete-assumptions-config contains 25 participants and 250 assumptions between them, which is quite heavy. On my 3Ghz CPU layouter consumes only 1 core, and solves it in 10-100 seconds, and it won't be easy to refine it further. Btw, I tried to use graphical library to output some texts (like layouting iterations counter), and failed Code: void DrawTextInCorn(char* txt, Color c) { If anyone knows proper magics to make it work, please teach me. It would be good to show user some progress info, while layouter works...TEXT t; BatchGraphics(); SetContextFont (TinyFont); t.baseline.x = 100; t.baseline.y = 100; t.align = ALIGN_CENTER; t.CharCount = strlen(txt); t.pStr = txt; SetContextForeGroundColor (c); font_DrawText (&t); printf("Phase drawn %s\n", txt); UnbatchGraphics(); } ... DrawTextInCorn("Text", PCMENU_SELECTION_TEXT_COLOR); I also decided to reuse the layouter in later steps to place on starmap important stars, some semi-important stars and some important constellations. And that's the plan. ----------------------------- [Upd:] Solved the text-drawing problem. Problem was in font, which was not loaded. In the not-yet-hacked initialization fleets get initialized before SC2 kernel (and fonts) is loaded. Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 25, 2015, 07:26:58 pm Somehow, solving the font problem (I was trying to draw text without font being initialized) made layouter work much faster. I also moved forward reusing layouter for placement of other objects (not only fleets). Naturally refining it's algorithm. Now result is pretty cool - it averagely completes in <1 second, rarely giving maximum 4 seconds.
Code: Last generation completed in 377 iterations, 0 seconds. Current average (for 100 generations): i 939, t 0. Overall max: i 5076, t 3 I also keep track of some issues, which were mentioned here, and which I noticed myself: Code: Issues in assumptions: #001 Shofixty epic return (from mission to Mycon -> back home through Vux and Yehat spaces): path may be non-straight line #002 Chenjesu expedition through Spathi to discover ZFP: path may be non-straight line. #003 Rainbow worlds will not form arrow #004 Supox may be among other fleets, but noone talks about them Solved by #005. #005 Utwigs may be among other fleets, but noone talks about them Solved by UTWIG_FAR_FROM_SOCIAL_RACES macro. Solves also #004. #006 Druuge may be among other fleets, but noone talks about them Solved by DRUUGE_FAR_FROM_SOCIAL_RACES macro. Solves also #004. #007 Any race may neighbour other race, but pretend not knowing each other Solved by #004. Solved by #005. Solved by #006. #008 UrQuan not in center reduces need to encounter them (MUST BE SOLVED) Solved by URQUAN_SOICENTER_DISTANCE_FROM_EDGE = 4000 macro. #009 If "BugSquirt" sounds a bit like "Betelgeuse" (Deutch), then new Syreen location name will not sound like that anymore. #010 Beast hunted by Zex - it will not reside in constellation, which is like "snake ate elephant" #011 Constellation-stars should form pretty geometric forms. #012 Solving #007 and #008 makes generated galaxy quite deterministic. (click to show/hide) Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 27, 2015, 10:31:45 pm Integrated tools for solving collisions of stars/constellations (while making layout). Finished layouting for 4 steps: fleets, important stars, important constellations, semi-important stars. As layouting may fail in some very rare random cases, introduced fail-tolerance and reset-retry logics. Added some more benchmarking tools.
Although I tried to be careful with memory allocation (malloc/free), benchmark showed a memory leak, and on Windows I can't localize it. The tools below conflicts with src/libs/compiler.h and other libs. Code: #include <windows.h> The failed benchmark consists of 1000 attempts to layout 4 steps: fleets, important stars, important constellations, semi-important stars. It fails on 350th-400th step with out-of-memory.#include <psapi.h> size_t getPeakRSS() { PROCESS_MEMORY_COUNTERS info; GetProcessMemoryInfo( GetCurrentProcess( ), &info, sizeof(info) ); size_t peak = (size_t)info.PeakWorkingSetSize; } size_t getCurrentRSS(){ PROCESS_MEMORY_COUNTERS info; GetProcessMemoryInfo( GetCurrentProcess( ), &info, sizeof(info) ); return (size_t)info.WorkingSetSize; } Otherwise works pretty fine - reset-retry frequency is near 0.1%, average generation time is below 1 second. I'll leave it like that for now, as I don't think it will ever cause any problem to gamer - the starmap generation is a very rare thing gamer will do. Next tasks are (A) generation of non-important constellations (B) generation of non-important solo-stars and constellation-stars (C) random distribution of names to constellations/stars For (A) and (B) the main challenge will be to make distribution even. Probably gonna reuse layouting-via-springs, but under different sauce now. Another idea was to separate starmap into big amount of overlapping windows, and to solve distribution-evenness problem in scope of each window. It's like an indexing strategy (one of), used in some DBs. As for pretty constellation patterns... well, I would do that if someone cooperated, and made a simple txt file containing all constellations profiles. Each profile should contain a bunch of coordinates for each star in it, centered on constellation centre as (0,0). Quite easy to do programmatically btw, - even Excel would be enough to do it... Otherwise, I don't think I'll bother with that, until first complete version of fully working relocation mod is released. Title: Re: UQM stars/races relocation mod? Post by: Death 999 on December 28, 2015, 05:25:36 pm One put the Syreen homeworld on top of the Burvix, which seems a little odd. I guess that's just a matter of adding a new but very loose constraint.
Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on December 28, 2015, 08:38:52 pm For #9, just force the Syreen location to be named Betelgeuse regardless of where it ends up being placed.
For #10, in theory you can probably just force the constellation containing the beast to have the same name as in the original game. I don't recall if the constellation actually formed a snake-beast-like shape though. Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 29, 2015, 10:54:10 pm One put the Syreen homeworld on top of the Burvix, which seems a little odd. I guess that's just a matter of adding a new but very loose constraint. Chronology:(1) Burvix lives in Arcturus, communicates with Druuge and Utwig. (2) Syreen lives in Beta Copernicus I. (3) Syreen homeworld got destroyed by Mycon. (4) Burvix got destroyed by Kohrah. (5) Syreen submits to Ur-Quan, in exchange they find a world where Syreen can live - Betelgeuse. Thus there's almost no assumptions about where Syreens should be, and who they should neighbour (except, that they should neighbou Ur-Quans), - because they got new home just very recently. Spathi may know about it from insider info channels, because they became part of hierarchy. And this home don't even need to be near human space (according to dialogues)... Although, I don't think Syreen's battle/intelligence value is high for player. Thus placing them too far from Sol might make them just worthless - so probably need the Sol <-> Syreen assumption anyway... Not sure. And please, correct me if I'm wrong. For #9, just force the Syreen location to be named Betelgeuse regardless of where it ends up being placed. For #9 - I could do either that, or just remove Bugsquirt stuff and let Spathies name real location. Another solution (really funny) would be to give a funny second name to every star/constellation, and depending what new name for Syreen home is randomly chosen - put fun into Spathi mouth. If I was a school teacher, it would be quite easy - I would give a task to each student to invent funny names for 2-3 stars... ;DFor #10, in theory you can probably just force the constellation containing the beast to have the same name as in the original game. I don't recall if the constellation actually formed a snake-beast-like shape though. For #10 - not sure I remember correctly, - it wasn't anything about name. The Lyncis constellation actually looks like a snake which ate something big. One way to solve this would be changing dialogue (excluding hint about snake and elephant). If I keep Syreen in Betelgeuse and Vux Beast in snake-like constell - it just would kill the idea of relocation and randomization. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on December 30, 2015, 12:09:57 am Another solution (really funny) would be to give a funny second name to every star/constellation, and depending what new name for Syreen home is randomly chosen - put fun into Spathi mouth. Could be a lot of work, but I think this would be a good thing to aim for. Of course this does mean that you can't use the original voice acting, though.For #10 - not sure I remember correctly, - it wasn't anything about name. The Lyncis constellation actually looks like a snake which ate something big. One way to solve this would be changing dialogue (excluding hint about snake and elephant). It would be nice to be able to keep that hint, though... but I guess the approach you suggested for Spathi won't work here. I suppose if it's too difficult to keep the hint valid, then it's better to remove it altogether than leave it in.Title: Re: UQM stars/races relocation mod? Post by: logarithm on December 31, 2015, 01:46:37 am CelticMinstrel
Actually, making fun names from at least 5-10 of solo stars might be enough. All solo stars are below. If anyone wishes to contribute - welcome - think of 5-10 funny star-names.)) (click to show/hide) Title: Re: UQM stars/races relocation mod? Post by: logarithm on January 03, 2016, 09:32:05 pm Solved non-important constellations placement. Made an XY-overlapping-windowing indexer, which solves tasks of empty spaces detection and even distribution of constellations. Also applied collision resolver (which is also used near graph-springs-layouter) to make sure constellations don't get too close to each other.
(click to show/hide) Non-important solo stars will most probably be treated like single-star-constellations, which means that placement of non-important solo stars is 95% done. Also completed naming for constellations. And for solo-stars will use same solution, which makes it ~80% done. Overall progress: V (1) Initialization of initial fleets V (2) Initialization of important stars V (3) Initialization of important constellations V (4) Initialization of semi-important stars V (5) Initialization of non-important constellations TODO (6) Initialization of non-important constellation-stars 90% (7) Initialization of non-important solo-stars TODO (8 ) Initialization of quasi-space locations 90% (9) Initialization of important coordinates V (10) Compilation of all previous steps results into a starmap Resolved 1 memory leak, but it's still not healthy. Benchmark still dies on 300th-400th iteration. Quasi space locations placement will be solved using logics similar to constellations placement - using combination of XY-overlapping-windowing indexer and collisions solver. All hardest tasks are solved, and now just need to apply the tools made, and integrate this whole stuff into game initialization logics. As for the latter, I was also thinking about making a sub-menu for "New Game" -> "Start with original locations" or "Start with randomized locations". Quite tired by now, as I spent sick leave (from work) and holidays to implement hardest stuff. I have 1 week of vacation left now, and hope to release first good version by end of it - starting from next week things will go very slow again. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on January 06, 2016, 11:28:41 pm Actually, making fun names from at least 5-10 of solo stars might be enough. All solo stars are below. If anyone wishes to contribute - welcome - think of 5-10 funny star-names.)) Okay, here goes. Some of these might not be all that great. I personally think Groombridge shouldn't be included, though; I see it as a unique location.
I think it's easier to think of fun names for the longer ones, at least for me. Maybe someone else can come up with some fun names for some of the shorter ones. Title: Re: UQM stars/races relocation mod? Post by: Krulle on January 07, 2016, 01:36:54 pm Depending on what you want to do, you could also randomly select a topic, and rename the moved solo stars for this topic.
Thus naming the reallocated solo stars all like Oregano, Tomato, Pepperoni, Pollo, Salami, ... or Reggae, Ska, Folk, Ondo, Orchestra,.... (click to show/hide) Just an idea, and please kill me for suggesting more work. BTW: Thanks, I love to see a project which does something and thus keeps this community alive. I also agree that Groombridge is special, and I still hope to see an implementation of the chat FF and PR3 wanted to implement. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on January 08, 2016, 04:23:21 am I also agree that Groombridge is special, and I still hope to see an implementation of the chat FF and PR3 wanted to implement. It's also the point of the rainbow world arrow.Title: Re: UQM stars/races relocation mod? Post by: logarithm on January 08, 2016, 08:35:23 am Well, all stars having importance index will remain having original content. Including Rainbow-containing and Melnorme-containing stars. Do you want to keep the "Groombridge" name for that Rainbow-containing star? What's so special about this name? :)
Oh, btw, I've decided to make Sirius always be near Sol. I guess everybody knows, that Sirius is the closest neighbour star. Thanks for supporting words and those contributions. Sometimes it's really important to see, that I'm not alone in my endeavour. I was hoping to do the final sprint this week, but failed bumping (like silly) on the underestimated complexity of gluing stars with constellations, while avoiding collisions, and making all this random and look nicely. I'll have to backup to the slow pace, where I have much more time to think things over-and-over again, before implementing them at weekends. Besides I spent vacation for rest, and hanged on the new UnderRail game, which is quite nice. I'm currently thinking about 2 alternative paths of doing things. (click to show/hide) (click to show/hide) Maybe there is an easier way to make things look nice?, but I can't see it. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on January 09, 2016, 07:13:30 am Well, all stars having importance index will remain having original content. Including Rainbow-containing and Melnorme-containing stars. Do you want to keep the "Groombridge" name for that Rainbow-containing star? What's so special about this name? :) I have no idea if there's any special significance to the name "Groombridge".Oh, btw, I've decided to make Sirius always be near Sol. I guess everybody knows, that Sirius is the closest neighbour star. If you mean in real life, Alpha Centauri is actually a bit closer than Sirius. However, real life doesn't matter since it's explicitly established that the constellations don't correspond to real-life ones. If you mean because everyone already knows it's the closest star in the SC2 universe, then sure, that seems fine to me.One serious problem I'll need to solve here, is avoiding having Supox HW to accidently appear out of Supox SoI. One solution to this would be altering the position of the SoI to ensure the homeworld is within it. That could even be applied to all races, except the Ilwrath whose homeworld can (should?) be outside their SoI.Also, while we're talking about constellations, one of the ones in/near Orz space (Pavonis, I think?) is missing an Alpha, as I recall. Are you going to retain that oddity? (There are two ways to do it - either pick a random constellation near Orz SoI and delete the Alpha, or don't place an Alpha Pavonis) Mind you, I don't think it's terribly important, and I don't recall it ever being referenced in-game, either. (3) Avoiding collision of 2 constellations can't be solved by simply putting 2 points (for constellation centres) and circles around them, and checking, that circles don't intersect, or bumping them away, if they intersect. I guess I'll have to do the following: for each constellation pick all nearby constellation, and make sure all it's stars are far enough away from stars of all nearby constellations. Bumping away might include constellation rotation, but I don't see a proper mathematical solution for this yet - how to determine if constellation rotation is better than moving it away. Probably, should use a specific version of springs-based layouter here again... Making it respect problems of (2) makes it more complex. Rather than a bounding circle, you could maybe use a bounding polygon, or simply ensure that no lines between the stars of one constellation cross any of the lines between the stars of the other constellation. In the latter case I think the lines to use would be specified by the constellation's shape - you wouldn't need to check every possible line between the stars of each constellation.Even though I say "simply", it's probably harder than it sounds. Title: Re: UQM stars/races relocation mod? Post by: Krulle on January 12, 2016, 02:03:42 pm Also, while we're talking about constellations, one of the ones in/near Orz space (Pavonis, I think?) is missing an Alpha, as I recall. Are you going to retain that oddity? (There are two ways to do it - either pick a random constellation near Orz SoI and delete the Alpha, or don't place an Alpha Pavonis) Mind you, I don't think it's terribly important, and I don't recall it ever being referenced in-game, either. Pavonis is the star constelletaion where you can find an engine.In Orz/Androsynth space there's the circular Vulpeculae constellation around a Giant, Alpha Vulpeculae, so that's not the one you're searching. I haven't found a constellation without an "Alpha-Star".... ( http://mooses.nl/uqm/wip/js-starmap/ ) edit: http://www.resonant.org/games/sc2/0/resource.pdf , page 9 following shows all systems, sorted by constellation name. No "Alpha" seems to be missing, but I may have missed it myself when scrolling through the document. Title: Re: UQM stars/races relocation mod? Post by: CelticMinstrel on January 12, 2016, 10:55:27 pm I looked over the wiki. It's Corvi I was thinking of, not Pavonis.
Title: Re: UQM stars/races relocation mod? Post by: Krulle on January 14, 2016, 12:16:32 pm Stupid me.
The list I linked does include Corvi Alpha, but without a list of ressources. Instead it reads: "(Victim of interdimensional fatigue)". Somehow I always missed that one constellation is without an "alpha". So, near Slylandro, and not near Orz... It may well be that I attributed it to the border of the map. Or never actually paid attention to this. |