Encounter problem
-
Shouldn’t:
faction_weight = fc_f_grp, 1
faction_weight = li_n_grp, 1
faction_weight = fc_rob_grp, 1
faction_weight = fc_ap_grp, 1be:
faction_weight = fc_f_grp, 0.250000
faction_weight = li_n_grp, 0.250000
faction_weight = fc_rob_grp, 0.250000
faction_weight = fc_ap_grp, 0.250000 -
… only the fc_rob_grp now appears …
If you remove those from your encounter, do the other faction appear?
If still no, maybe check the loadouts and modify the encounters / check if factions can use the encounters. -
Shouldn’t:
faction_weight = fc_f_grp, 1
faction_weight = li_n_grp, 1
faction_weight = fc_rob_grp, 1
faction_weight = fc_ap_grp, 1be:
faction_weight = fc_f_grp, 0.250000
faction_weight = li_n_grp, 0.250000
faction_weight = fc_rob_grp, 0.250000
faction_weight = fc_ap_grp, 0.250000Never known anything else used except whole numbers for this. If you look at any of the original encounters then only whole numbers are used. Later in the script the numbers should equal 1, so what you’re saying is right, just not in that section
-
faction_weight = fc_f_grp, 1
faction_weight = li_n_grp, 1
faction_weight = fc_rob_grp, 1
faction_weight = fc_ap_grp, 1This is basically saying that only 1 of each will spawn (althought the contents of your encounter ini files can override this, a dozen could spawn if you have it written that way).
encounter = area_defend_custom2, 19, 0.350000
faction = li_n_grp, 0.250000
faction = fc_f_grp, 0.250000
faction = fc_rob_grp, 0.250000This needs to be edited so the 3 groups total 1.000000
i.e.
encounter = area_defend_custom2, 19, 0.350000
faction = li_n_grp, 0.340000
faction = fc_f_grp, 0.330000
faction = fc_rob_grp, 0.330000encounter = battleship_robots, 19, 0.010000
faction = fc_f_grp, 1.000000The odds of this one appearing are 1%. You could probably spawn it 100-300 times before seeing it. Set it to the vanilla high average 0.350000 for testing purposes. Once it works you can lower it again.
Then you need to say what this zone is spawning around. Is it a dockable object or deep in space? The answer to that is crucial to how you defined these lines in the encounter:
pilot_job = defend_leader_job
make_class = wanderer -
This works for me, so if it doesnt work for you your problem lies in the factions or the encounter params.
Try this:
MAKE SURE - your encounter params are all listed for the encounters as well.If these are wrong or incorrect you will have and get nothing in terms of encounters.
[Zone]
nickname = Zone_BR07_pop_ambient_12
pos = 0, 0, 631
rotate = 0, 0, 0
shape = SPHERE
size = 75422
comment = Rogue Robot Pop
sort = 1
toughness = 19
density = 9
repop_time = 25
max_battle_size = 15
pop_type = Background
relief_time = 35
population_additive = false
faction_weight = fc_f_grp, 10
faction_weight = li_n_grp, 10
faction_weight = fc_rob_grp, 10
faction_weight = fc_ap_grp, 10
encounter = area_defend_custom2, 19, 0.350000
faction = li_n_grp, 0.250000
faction = fc_f_grp, 0.250000
faction = fc_rob_grp, 0.250000
encounter = area_heavy_patrol, 19, 0.150000
faction = li_n_grp, 1.000000
encounter = area_horde, 19, 0.350000
faction = fc_f_grp, 1.000000
encounter = battleship_robots, 19, 0.010000
faction = fc_f_grp, 1.000000
encounter = area_evac_monkey, 19, 0.140000
faction = fc_ap_grp, 1.000000 -
population_additive = This determines wether NPCs from overlapping zones will spawn and interact with the other zone, yes this does mean you could be getting shot at from NPCs from 2 different zones at the same time.
Iirc “True” is very bad if one of the zones is a roid/neb, and “Background” pop_types should always be “False” as FL concideres them to be the dross of the zone types, and are only there to fill in the spaces between the other zones, and because of this you don’t want them interacting with other zones.faction_weight = goes from 1 to 20, think of it as a measure of how badly they want to spawn first, with 1 being the cowards letting everybody else go first, and 20 being the nutjob with no common sense that dives in without looking. Set them all to “1” and they will still spawn, just so long as there’s nobody else around to “scare” them.:P
This needs to be edited so the 3 groups total 1.000000
FL is quite happy if you have less than 1.000000, exceding it is what FL doesn’t like, it will fire a syntax error into your CPU and move the decimal point one place to the left, giving you even less chance of spawning than you thought.
@ Tunicle, problems with the loadout usually means (99 times out of 100) a CTD, check the faction_prop to make sure they actually have the pilots & ships of the correct class to appear in the encounter, this is a classic mistake as far as FLE users are concerned, as FLE will let you use any faction in any encounter, even if they don’t have ships.
-
My first suggestion would be to make sure your encounters called aren’t using “behavior = patrol_path” in the encounter file. Unless you use patrol_path explicitly in path-type zones, this will be an instant server crash. Considering I see an “area_heavy_patrol” in there, I’d check that first. =P
My second suggestion would be to watch the "sort = " value. Depending on how this value is set, it can either make the zone work perfectly or crash your server. It is the value FLServer uses to determine the priority of overlapping zones; for instance, patrol paths, which should always have the highest priority, increment from 99 downwards - the first path will have 99 sort, a path that intersects it will have 98 sort, a third path that intersects the first two would have 97 sort, etc. This is also used by FLServer to determine the priority of which zone spawns first - a high-sort zone will be considered before a low-sort zone. Thus, if this is a big “ambient” populator that covers the whole system, you should probably have sort in the lower 10s, or maybe even just set to “0”
Aside from those two things, not sure what the problem could be. On a side note, I don’t think faction_weight or pop_type actually has any effect - it’s not called from any bit of hard-code, and removing those lines entirely from every zone makes no change.
-
Tunicle…
A lot of shooting in the dark here, because you haven’t laid out all your ini’s for us to see, and a lot of things affect encounters…
faction_weight doesn’t matter, I haven’t seen any noticeable effect from changing or removing them completely either, but it should be set to integer values (1, 5, 20 usually if I remember?) but definitely not fractions. You can remove them all for testing purposes anyway.
Your zone toughness = 19 and your encounter difficulties are all set to 19, this is fine…
But only your robots spawn?
A brief alert… If your encounter spawns enough ships of the first faction to satisfy the density = 9, then no more will spawn until you kill some, and the first faction may spawn again before other factions, so this may mask the problem. So set density = 30 and max_battle_size = 30 temporarily to find out.
If this doesn’t improve matters…
What happens if you disable the robots temporarily and try each faction alone?
If they don’t spawn then…
In npc_ships do you have npc_class = (legality, ship class, d1, d2, … d19 for all factions and ships involved?
Also check for spelling mistakes in your encounter names, faction_prop.ini npcship = lines, and npcships.ini for ship archetype and ship loadout spelling, this is the most common problem in my case
If those are all OK, then…
Do all of your other factions than the robots have d19 ships defined, with the correct ship archetype and loadout?? (faction_prop.ini gives npcship, npcships.ini gives ship type & loadout, pilot level & ship_class should match ship class (fighter/gunboat/cruiser/battleship) and also gives encounter difficulty. Also double-check loadouts.ini / loadouts_special.iniFailing this then feel free to attach your faction_prop.ini, npcships.ini, loadouts.ini, loadouts_special.ini
I think I repeated myself here but I’m tired and can’t see clearly enough to correct myself, it’s 04:50!
G’night!
-
Hi, thanks for asking.
We have tried everything and followed all leads and still a crash anytime up to 2.5 hours after start. We have altered all settings, coded things in and out and eventually still a crash. Everything else works in other systems and all encounters etc. work so we are stumped.We have noticed 1 thing. One of the NPC’s drop sunslayer ammo and when tractored in they do not show in cargo. We are looking at this but other than this slim chance nothing else seems amiss.
If that fails we will recode the system and hope and write it off as one of those things.
-
Are all entries for the weapon/ammo present and correct in the weapon good and equip files? Does the good files properly reference the equip files. Just an immediate thought… you would no doubt get errors in pretty much all the checkers out there and a line(s) in the flserver log file thought, so i’m inclined to think this isn’t your prob.
-
In regards to the sunslayer all the coding lines are present and where they should be, the only thing changed recently was just after i added why485’s effects. Tiger put a new torpedo model in for the SS and moved the flame effect hardpoint back a little so you see the torp and then the flame.
Shortly after this the sunslayer ammo failed to show on any of the bases its coded on, i tried reverting it back the way it was and back to an earlier version of on eof the earlier mods and no joy.
Similarly we have a nomad capship encounter containing a nomad battleship and 6 gunboats. The battleship appears fine the gunboats vanished.
Personally i didnt actually think there was an error with encounters in the system for which Tuni has been talking about here.
The one id been working on is in nomadia and found one of the encounters to cause a crash and removed it, a day later and it was crashing again so checked them all again and i now belive it is a loadout erre on the base that te encounter is around. Tiger is working on that now.
If coding for any of the above is required just give us a shout and we’ll post it up.
ps. no errors flagged for any of the above on FLEC, FLIA, FLSCAN, datastorm.
-
Does jumping into that system and flying around that base/encounter for a bit, and then filtering the flspew log with FLEC reveal anything remotely useful? It tends to give zone info to some extent if there is an issue…