As in the title, I'd like to leave some zones in a sector free from any station. I use them as landamarks, etc.
I mapped them as "testzone" instead of 'standardzone' but this does not prevent the engine to build there at game's start.
I've looked anywhere in the md for some factionlogic activator/deactivator but have no clue.
Adding factionlogic="false" to the zone has no result.
Thanks for any help
How to stop god.xml to build in certain zones?
Moderators: Scripting / Modding Moderators, Moderators for English X Forum
-
- Posts: 1638
- Joined: Wed, 15. Nov 06, 10:21
-
- Moderator (Script&Mod)
- Posts: 13486
- Joined: Sun, 15. Feb 04, 20:12
Re: How to stop god.xml to build in certain zones?
That's a tricky one. I'd start by backtrack BuildStation in all faction*.xml searching for the part where the sectors to build in are found. Then exclude those you want to stay empty.
Cheers Euclid
Cheers Euclid
"In any special doctrine of nature there can be only as much proper science as there is mathematics therein.”
- Immanuel Kant (1724-1804), Metaphysical Foundations of the Science of Nature, 4:470, 1786
- Immanuel Kant (1724-1804), Metaphysical Foundations of the Science of Nature, 4:470, 1786
-
- Posts: 1638
- Joined: Wed, 15. Nov 06, 10:21
Re: How to stop god.xml to build in certain zones?
The difficulty is to isolate the zones. While sectors can be excluded with the factionlogic in mapdefaults, there is no way to have the same finetuning about single zones. It seems to me that X4 does not see zones as Rebirth. Indeed I made a script to add some landmarks in each zone and the result is practically every station be considered a zone, not only those you set in sectors.xml and zones.xml.
Btw do you remember once we talked about doing sectors as big as a system. I told that the engine can not handle but I was wrong. In my test universe it did not work bc it lacks the various setups but in normal game it works. I've implemented superhighways that link two zones instead of two sectors and after removing the script that made always to look for another sector when a superhighway is involved, npc use them normally.
I get an error in the log about too big distance for the move.gate script, that's the only one. At line 520, I still don't get what is triggering that. But for the rest it is doable...and I am doing it. Not real systems of million kms but local systems yes in the 100.000-500.000km (scaled down).
In this scenario, zones become as relevant as sectors so my need to finetune the single zones, but see that the game is set on sectors instead.
Btw do you remember once we talked about doing sectors as big as a system. I told that the engine can not handle but I was wrong. In my test universe it did not work bc it lacks the various setups but in normal game it works. I've implemented superhighways that link two zones instead of two sectors and after removing the script that made always to look for another sector when a superhighway is involved, npc use them normally.
I get an error in the log about too big distance for the move.gate script, that's the only one. At line 520, I still don't get what is triggering that. But for the rest it is doable...and I am doing it. Not real systems of million kms but local systems yes in the 100.000-500.000km (scaled down).
In this scenario, zones become as relevant as sectors so my need to finetune the single zones, but see that the game is set on sectors instead.
-
- EGOSOFT
- Posts: 2171
- Joined: Mon, 23. Nov 15, 18:02
Re: How to stop god.xml to build in certain zones?
main difference between XR and X4 with regard to zones is that there are less predefined zones in X4, and more zones created on the fly as tempzones if ships are moving through them, or as normalzones if more permanent things like stations are in them.
haven't worked much with god.xml, but looks like it mostly uses location nodes similar to jobs which ask the engine to look for positions in sectors that match certain characteristics rather than placing things in predefined zones, with exceptions for things that someone wanted in a static position consistent between playthroughs.
re: move.gate, not sure which action you mean, but the script expects to move between sectors so, in a scenario where gates or superhighways move between different parts of the same sector, the script would likely need adapting or bypassing altogether. just pathing from one position to another might find gates or superhighways (at least i know this works when pathing between positions in different sectors), but not sure since the engine might have the same assumptions deeper in.
haven't worked much with god.xml, but looks like it mostly uses location nodes similar to jobs which ask the engine to look for positions in sectors that match certain characteristics rather than placing things in predefined zones, with exceptions for things that someone wanted in a static position consistent between playthroughs.
re: move.gate, not sure which action you mean, but the script expects to move between sectors so, in a scenario where gates or superhighways move between different parts of the same sector, the script would likely need adapting or bypassing altogether. just pathing from one position to another might find gates or superhighways (at least i know this works when pathing between positions in different sectors), but not sure since the engine might have the same assumptions deeper in.
-
- Posts: 1638
- Joined: Wed, 15. Nov 06, 10:21
Re: How to stop god.xml to build in certain zones?
Thanks for the answer. I've seen how parts of Rebirth's methods are still usable in the maps, where you can add obiects and even stations, but stations have no construction plan you can add (while in Rebirth's map you could add the plan in the properties), I tested various tags and the only one that the engine accepts is <map visible="0" or 1 and/or true/false which is also contained in the asset's macro itself, still an interesting variation to add (I built ownerless custom ore-mine stations that are not map visible, for the player to claim...when I eventually find a way to make the claim possible).
In this, god.xml is a much more interesting way to add things and randomize according to parameters that are not only the zone but resources, security, economy etc. Problem is, the engine reasons about sectors not zone, so for instance if I set security in the mapdefaults and recall it through god, it considers that param on the whole sector, no way to restrict it to a specific zone (except for the possibility to add single stations to specific zones, which is also useful to have a not random setup of the map).
A similar control over zones for security/economy etc. would instead be very useful for a different setup of the map as I am doing/testing. I think it could be of great interest for future development of X games because when you have control over zones the map opens to endless opportunities inside a single sector. I've already done it in the current version of my XRSGE mod (where a sector is in the 30.000/50.000km spread area), if you want to take a look at: https://www.nexusmods.com/x4foundations/mods/1140
Now I am doing sectors as big as 300.000 km and they work fine. Having done superhighways that link two different zones and not two different sectors, this works fine in current gameplay. Because if you do sectors so big or even more, then you need a mean to reach such distances and high travel speeds are not a good solution, above 18.000 m/s the calculations add a lot of lag to the game.
The other thing I had to do is oc to enlarge the skybox, but that is needed anyway in big clusters too (btw in vanilla game the too small skybox is noticeable in clusters such as Earth/moon, stars becoming bigger and closer when you move through superhighway, it is a thing that maybe devs want to look at, fast to fix). I made the skybox E10 but E09 is probably enough for vanilla clusters.
So coming to the point, in-sector superhighways are the best solutions for such gigantic sectors and they seem to work fine after removing this part of code that instructs to look for (different) destination sector, line 34 of move.gate. If not removed, the big ships (only L and XL..strange) remain stuck at gate's entrance, calculating route I suppose:
<patch sinceversion="4">
<do_if value="$gatedestination and (this.sector == $gatedestination.sector)">
<debug_text text="'%s %s %s already in destination sector. resuming movement.'.[@this.assignedcontrolled.idcode, @this.assignedcontrolled.knownname, this.assignedcontrolled]" filter="savegame"/>
<!-- NB: this signal only works because move.gate is always called from move.generic -->
<signal_objects object="this.assignedcontrolled" param="'move.generic_reinitialize'"/>
</do_if>
</patch>
Then I get this recurrent error (the only one)
[General] 924.36 ======================================
[=ERROR=] 924.36 Error in AI script move.gate on entity 0x2171fda: Move-to action got a very large position (zone) (-322458.500000 3117.325195 -18321976.000000). [Matthias]
* Action: <move_to>, line 520
[General] 924.36 ======================================
[General] 924.36 ======================================
[=ERROR=] 924.36 Error in AI script move.gate on entity 0x2171fda: Move-to action got a very large position (zone) (-322458.500000 3117.325195 -18317852.000000). [Matthias]
* Action: <move_to>, line 525
[General] 924.36 ======================================
[General] 924.36 ======================================
[=ERROR=] 924.36 Sound::LoadRiffWave() cannot process data for Asset 'sfx\ui\monitor\event\ui_mon_eve_change'!
[General] 924.36 ======================================
[General] 924.36 ======================================
[=ERROR=] 924.36 P:\dev\P1\src\libs\xsfx\source\xsfx\openal\sound_openal.cpp:320: ERR: 40962 AL_INVALID_ENUM
[General] 924.36 ======================================
Any clue how I can solve it and if it is important or not, maybe I can simply ignore it? Don't know about lag in advanced game when a lot of ships are in the game.
Thanks!
Edit: maybe I can only exclude the superhighways from the do_if instead of deleting it all, it is still relevant for normal gates.
Also, maybe the part I removed is not the cause of the error?
In this, god.xml is a much more interesting way to add things and randomize according to parameters that are not only the zone but resources, security, economy etc. Problem is, the engine reasons about sectors not zone, so for instance if I set security in the mapdefaults and recall it through god, it considers that param on the whole sector, no way to restrict it to a specific zone (except for the possibility to add single stations to specific zones, which is also useful to have a not random setup of the map).
A similar control over zones for security/economy etc. would instead be very useful for a different setup of the map as I am doing/testing. I think it could be of great interest for future development of X games because when you have control over zones the map opens to endless opportunities inside a single sector. I've already done it in the current version of my XRSGE mod (where a sector is in the 30.000/50.000km spread area), if you want to take a look at: https://www.nexusmods.com/x4foundations/mods/1140
Now I am doing sectors as big as 300.000 km and they work fine. Having done superhighways that link two different zones and not two different sectors, this works fine in current gameplay. Because if you do sectors so big or even more, then you need a mean to reach such distances and high travel speeds are not a good solution, above 18.000 m/s the calculations add a lot of lag to the game.
The other thing I had to do is oc to enlarge the skybox, but that is needed anyway in big clusters too (btw in vanilla game the too small skybox is noticeable in clusters such as Earth/moon, stars becoming bigger and closer when you move through superhighway, it is a thing that maybe devs want to look at, fast to fix). I made the skybox E10 but E09 is probably enough for vanilla clusters.
So coming to the point, in-sector superhighways are the best solutions for such gigantic sectors and they seem to work fine after removing this part of code that instructs to look for (different) destination sector, line 34 of move.gate. If not removed, the big ships (only L and XL..strange) remain stuck at gate's entrance, calculating route I suppose:
<patch sinceversion="4">
<do_if value="$gatedestination and (this.sector == $gatedestination.sector)">
<debug_text text="'%s %s %s already in destination sector. resuming movement.'.[@this.assignedcontrolled.idcode, @this.assignedcontrolled.knownname, this.assignedcontrolled]" filter="savegame"/>
<!-- NB: this signal only works because move.gate is always called from move.generic -->
<signal_objects object="this.assignedcontrolled" param="'move.generic_reinitialize'"/>
</do_if>
</patch>
Then I get this recurrent error (the only one)
[General] 924.36 ======================================
[=ERROR=] 924.36 Error in AI script move.gate on entity 0x2171fda: Move-to action got a very large position (zone) (-322458.500000 3117.325195 -18321976.000000). [Matthias]
* Action: <move_to>, line 520
[General] 924.36 ======================================
[General] 924.36 ======================================
[=ERROR=] 924.36 Error in AI script move.gate on entity 0x2171fda: Move-to action got a very large position (zone) (-322458.500000 3117.325195 -18317852.000000). [Matthias]
* Action: <move_to>, line 525
[General] 924.36 ======================================
[General] 924.36 ======================================
[=ERROR=] 924.36 Sound::LoadRiffWave() cannot process data for Asset 'sfx\ui\monitor\event\ui_mon_eve_change'!
[General] 924.36 ======================================
[General] 924.36 ======================================
[=ERROR=] 924.36 P:\dev\P1\src\libs\xsfx\source\xsfx\openal\sound_openal.cpp:320: ERR: 40962 AL_INVALID_ENUM
[General] 924.36 ======================================
Any clue how I can solve it and if it is important or not, maybe I can simply ignore it? Don't know about lag in advanced game when a lot of ships are in the game.
Thanks!
Edit: maybe I can only exclude the superhighways from the do_if instead of deleting it all, it is still relevant for normal gates.
Also, maybe the part I removed is not the cause of the error?