|
Pages: 1 2 [3] 4
|
 |
|
Author
|
Topic: UQM stars/races relocation mod? (Read 19090 times)
|
logarithm
Zebranky food
 Offline
Gender: 
Posts: 32
|
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).
|
|
|
|
« Last Edit: November 22, 2015, 02:11:17 am by logarithm »
|
Logged
|
|
|
|
|
|
CelticMinstrel
Enlightened
Offline
Posts: 522
|
Does that mean that the hints towards the location of the Slylandro are not difficult or, perhaps, are even already dealt with?
|
|
|
|
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
Yeah, it was easy one.
https://sourceforge.net/u/uqm-logarithm/sc2/ci/master/tree/sc2/src/uqm/comm/slyland/slyland.c--- a/sc2/src/uqm/comm/slyland/slyland.c
+++ b/sc2/src/uqm/comm/slyland/slyland.c
@@ -24,6 +24,7 @@
#include "options.h"
#include "uqm/battle.h"
#include "uqm/setup.h"
+#include "uqm/hyper-consts.h"
static const NUMBER_SPEECH_DESC probe_numbers_english;
@@ -381,8 +382,8 @@
SIZE dx, dy;
// Probe's coordinate system is {-Y,X} relative to B Corvi
- dx = LOGX_TO_UNIVERSE (GLOBAL_SIS (log_x)) - 333;
- dy = 9812 - LOGY_TO_UNIVERSE (GLOBAL_SIS (log_y));
+ dx = LOGX_TO_UNIVERSE (GLOBAL_SIS (log_x)) - SLYLANDRO_HOME.x;
+ dy = SLYLANDRO_HOME.y - LOGY_TO_UNIVERSE (GLOBAL_SIS (log_y));
NPCPhrase (THIS_IS_PROBE_40);
sayCoord (dy);
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...
|
|
|
|
|
Logged
|
|
|
|
CelticMinstrel
Enlightened
Offline
Posts: 522
|
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.)
|
|
|
|
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
CelticMinstrel
Yeah, I've dealt with those things. Everything mentioned here is dealt with.
As for distance assumptions in general (which are specified here). 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.
|
|
|
|
« Last Edit: December 06, 2015, 10:31:11 pm by logarithm »
|
Logged
|
|
|
|
Death 999
Global Moderator
Enlightened
Offline
Gender:
Posts: 3874
We did. You did. Yes we can. No.
|
With the non-important systems, can't you place those names based on the important things they're conceptually linked to?
|
|
|
|
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
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.
|
|
|
|
« Last Edit: December 12, 2015, 12:51:59 am by logarithm »
|
Logged
|
|
|
|
CelticMinstrel
Enlightened
Offline
Posts: 522
|
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).
|
|
|
|
|
Logged
|
|
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
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 -
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).
|
|
|
|
« Last Edit: December 20, 2015, 12:28:17 am by logarithm »
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
Alright. The communication-templating stuff is done.
--------------------
The initialization nightmare looks like this: [USER: run game]
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
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.
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:
Old system:
(a) User launches game
(b) Fleets get initialized
(c) Starmap is predefined
(d) User press "start game"
(e) Fleets get additionally initialized
(f) Player flagship placed into starmap
New system:
(a) User launches game
(b) Fleets get initialized (1)
(c) User press "start game"
(d) Fleets get re-initialized (2)
(e) Starmap gets initialized (2)
(f) Player flagship placed into starmap (2)
Old system:
(a) User launches game
(b) Fleets get initialized
(c) Starmap is predefined
(d) User press "load game"
(e) Fleets get additionally initialized
(f) Player flagship placed into starmap
(g) User picks a save-entry to load
(h) Fleets states get updated
(i) Player flagship location updated
New system:
(a) User launches game
(b) Fleets get initialized (1)
(c) User press "load game"
(d) Fleets get additionally initialized (1)
(e) Player flagship placed into starmap (1)
(f) User picks a save-entry to load
(g) Fleets initial-states get loaded (2)
(h) Fleets current-states get loaded (2)
(i) Starmap is loaded (2)
(j) Player flagship location updated (2)
Old system:
(a) Starmap is predefined
(b) User press "load game"
(c) User picks a save-entry to load
(d) Fleets states get updated
(e) Player flagship location updated
New system:
(a) Starmap is in memory
(b) User press "load game"
(c) User picks a save-entry to load
(d) Old starmap is disposed, new loaded
(e) Fleets initial-states get loaded
(f) Fleets current-states get loaded
(g) Player flagship location loaded
|
|
|
|
« Last Edit: December 20, 2015, 03:44:47 am by logarithm »
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
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,
// priority | participant #1 | participant #2 | min | max
{ 1, FLEET_CENTER_HUMAN, PLAYER_HOME_COLONY, 1000, 2500 },
{ 1, FLEET_CENTER_HUMAN, HOME_CHMMR, 500, 2500 },
{ 1, FLEET_CENTER_HUMAN, FLEET_EDGE_PKUNK, 500, 2500 },
{ 1, FLEET_CENTER_HUMAN, FLEET_EDGE_ILWRATH, 100, 1000 },
{ 1, FLEET_CENTER_PKUNK, FLEET_EDGE_ILWRATH, 200, 500 },
{ 1, FLEET_EDGE_THRADD, FLEET_EDGE_KOHRAH, 500, 2500 }, // Thradds are Kohrah neighbours, and may silly attack them
{ 1, FLEET_EDGE_MYCON, MYCON_TRAP, 1000, 2000 }, // MYCON will travel for Organon
{ 1, SYREEN_HOME, SYREEN_VAULT, 1500, 2500 },
{ 1, FLEET_EDGE_INNER_URQUAN, SYREEN_VAULT, 500, 1500 },
{ 1, FLEET_EDGE_INNER_URQUAN, FLEET_CENTER_ZOQFOTPIK, 0, 1000 },
{ 1, FLEET_EDGE_INNER_KOHRAH, FLEET_CENTER_ZOQFOTPIK, 0, 1000 },
{ 1, FLEET_CENTER_URQUAN, FLEET_CENTER_BLACK_URQUAN, 50, 700 },
{ 1, FLEET_EDGE_ARILOU, FLEET_EDGE_THRADD, 500, 1500 }, // As Arilou mentioned have played with species in Draconis
{ 1, FLEET_EDGE_ARILOU, FLEET_EDGE_SPATHI, 1000, 3500 },
{ 1, FLEET_EDGE_VUX, SHOFIXTY, 1000, 2500 },
{ 1, FLEET_EDGE_YEHAT, SHOFIXTY, 1000, 2500 },
{ 1, FLEET_EDGE_VUX, FLEET_EDGE_YEHAT, 100, 1500 },
{ 1, FLEET_EDGE_UMGAH, FLEET_EDGE_SPATHI, 100, 2500 },
{ 1, FLEET_EDGE_UTWIG, FLEET_EDGE_SUPOX, N_A, 1000 },
{ 0, FLEET_EDGE_ANYFLEET, FLEET_EDGE_KOHRAH, 500, N_A },
{ 0, FLEET_EDGE_ANYFLEET, MYCON_TRAP, 1000, N_A }, // Let's noone interfere with MYCON, while they check Organon
{ 0, FLEET_EDGE_ANYFLEET, SYREEN_HOME, 100, N_A },
{ 0, FLEET_EDGE_ANYFLEET, FLEET_CENTER_HUMAN, 100, N_A },
{ 0, FLEET_EDGE_ANYFLEET, SHOFIXTY, 100, N_A },
{ 0, FLEET_EDGE_ANYFLEET, PLAYER_HOME_COLONY, 100, N_A },
{ 0, FLEET_EDGE_ANYFLEET, FLEET_EDGE_SPATHI, 100, N_A },
{ 1, FLEET_EDGE_SPATHI, HOME_CHMMR, 200, 2000 },
{ 1, FLEET_EDGE_ZFP, HOME_CHMMR, 4000, N_A },
{ 1, FLEET_EDGE_ZFP, FLEET_EDGE_SPATHI, 1000, 2000 },
{ 1, FLEET_CENTER_SLYLANDRO, FLEET_EDGE_THRADD, 1000, 2500 },
{ 1, FLEET_CENTER_SLYLANDRO, FLEET_EDGE_ZFP, 1000, N_A },
{ 1, FLEET_CENTER_SLYLANDRO, FLEET_CENTER_HUMAN, 5000, N_A },
This layouter algorithm is the hardest task in the whole endeavour, I should arm myself with patience...
|
|
|
|
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
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
I thoroughly analysed all relations between all fleets and important locations and made a matrix of assumptions with full specification here. 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
void DrawTextInCorn(char* txt, Color c) {
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);
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...
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.
|
|
|
|
« Last Edit: December 24, 2015, 11:01:54 pm by logarithm »
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
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.
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:
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.
|
|
|
|
« Last Edit: December 25, 2015, 07:29:02 pm by logarithm »
|
Logged
|
|
|
|
|
Pages: 1 2 [3] 4
|
|
|
|
|
Pleasant romantic work.
