Speciality Modding

So, did some testing with patrol zones, and stumbled onto something weird. Added the following patrol zones to Omicron Minor.

[zone] nickname = Zone_St01_pop_1 pos = 8000, 0, 24000 shape = SPHERE size = 10000 sort = 80 toughness = 10 density = 8 repop_time = 25 max_battle_size = 8 pop_type = background relief_time = 35 faction_weight = ku_n_grp, 10 encounter = area_assault, 10, 0.29 faction = ku_n_grp, 1 [zone] nickname = Zone_St01_pop_2 pos = 8000, 0, 10000 shape = SPHERE size = 10000 sort = 80 toughness = 10 density = 8 repop_time = 25 max_battle_size = 8 pop_type = background relief_time = 35 faction_weight = li_n_grp, 10 encounter = area_assault, 10, 0.29 faction = li_n_grp, 1 ```Everything works fine. Then I changed pos = 8000, 0, 10000 -> pos = 8000, 42900, 10000 and pos = 8000, 0, 24000 -> pos = 8000, 43200, 24000. Strange things happen. Every 10 seconds, the ships stand still for about 2 seconds, and they all fly to the exact center of the zone and freeze. This is probably because the zone doesn't intersect the y=0 horizontal plane. If it does, though, everything works fine, except the ships will always fly toward the y=500 plane, no matter what the y coordinate of the zone is (as long as the zone intersects this plane, as it seems). Changing the y coordinate to -43200 and -42900 didn't help. Changed size to 50000 -> works fine. Changed size back to 10000, changed height to -9000 -> everything works fine, however changing size to 9500 -> strange behavior (freeze at center, etc) Forgot to mention, I didn't tested it in other systems, I don't think that's the problem though. Anyone found a fix? EDIT: so I looked up the offset that controls the height patrols will fly to:

Content.dll v1.1 11811C 500f y coordinate patrols with behavior = wander will return to, unless patrol zone doesn’t intersect with that height, in which case strange behavior will occur (freezing at center, etc.)

Of course, this doesn't fix it, and it's a universal value. Greets, Gold

Just like last year, I have it done on the last day of the year. For the download, see first post.

Thanks anyway. Then the workaround is just to set NPCs not to loot nanobots/batteries at all.

Not really, sadly. For the longest time I just used guess-and-check numbers without knowing for sure what was what - the notes shown in the full file linked above were solely from observations made. (It wasn’t until a few years ago that M0tah pointed out to me that the graph corrosponded with adoxa’s reversed Personality struct floating around here somewhere)

I can say bumping up the Strafe column seems to help them actually strafe more, and in general bumping up transitions out of things like Idle seems to help keep them more active. Unfortunately it’s been quite a while since I’ve actually worked with any of this.

When we were messing around again back in 2014/15 (for the first time in… years) M0tah found a native function within FL to reload the state graph, and implemented it into FLHook. It was pretty handy for messing around. Unfortuantely the source in Flak’s repo seems a bit out of date, but there should be a copy somewhere…

The minor damage occours on the items (only some… like cloaks).

Greets

So I noticed some peculiar behavior and was hoping someone would be able to shed light on this.

PhySys::GetCollisions seems to return all collision events, even those that involve beam weapons. Oddly, though, it doesn’t put a CBeam pointer in the second slot, instead it puts a pointer to what appears to be garbage. All I could notice was that the pointer would point to another pointer which would point to another pointer and so on until the last pointer goes to 0x0. All data around those pointers is 0xcdcdcdcd, so invalid.

I tried looking into how FL handles the CollisionEvent list, but it doesn’t seem to make any special case for those events, even though the second pointer obviously doesn’t work. Is there a straightforward way of identifying those “broken” events short of just trying to cast them to a CObject and seeing if it breaks?

Even better would be figuring out a way of tracing back which CBeam did it.

EDIT: So apparently if a beam weapon’s ammo has zero mass, it shows up in the CollisionEvent list, but does not refer to the proper object instance.

It all looks great. It’s just too bad that this game hasn’t had a Redux for it as so many other older games have had these days.

Ah, sure. Remember this too.

FINALLY !

In ENIGMA V.4 ATG we are using the “88FlakAIWingmenProject”-method to provide “Wingmen-Support” to the Players.

Since the “Leader” of these NPC-wings is set invisible via the cloak effect, I actually found the cause of this problem lately by uncloaking them.
So here it is:
Since the "mission_property " of the follow-trigger-ship is set to “can_use_berths” it actually does block the ports and leave it wide open for sometimes a long period of time because: THEY DON´T ACTUALLY DOCK AND DISAPEAR like other random NPCs.

I “solved” a good amount (not all) of these blocking-probs by setting the mission_property of the follow-trigger-ship (and others) to “can_use_med_moors”.
Warning: Can break your Mod regarding Wingmen-Groups when their patrol_paths do not end or start at a dockable base with “medium mooring” dockpoints.

Don´t know if this is of any use for others, but I just thouhgt I let u know where issues are from… at least in my case…

Greetings
J.R.

[d]Seems to be client flhook commands arent working with this.[/d]
I will recheck.
Works well - something was with my PC.

@Fenris_Wolf no source. This thing works strange with indirect connection to the internet. So try to ask Kosacid by email

Thanks adoxa, I am using something similiar with PortableFL, didn’t know about Alt+PrntScn though!

Time to bust out Hexedit? Been a while since I’ve even touched it, and floating point numbers! I’ll get on it, still building this rig! My parents delayed me slightly by needing the room I am working on it in.

Hello,

I am aware of this limit and this is what surprises me. As you can see in the steps, adding more items do not cause the problem to happen, but one very specific amount will.

The exception thrown when this very specific amount of items is reached is the following: 0xC0000005: Access violation writing location 0x00000000.

Once I create the new vessel, the total count of items combined across all charfiles is:

177 cargo items
194 equipment items
which is a total of 371 items.

370 will work, 372+ will work. exactly 371 items will cause the account to be unloggable until someone removes one item.

I have attempted this on another account and you can hold 371 items, but with yoda’s account files, it won’t work.

It works 🙂 thanks again adoxa!

Wow, great fix! This always bothered me but never actually tried to fix it, good job!

EDIT:
Just to remember the idea, no reaction expected.
[c]power_modifier[/c] as a range from 0 to 1, indicating occasional power loss, as if electrical activity in a field or cloud can shortcut power supply or fuel supply for the engine.

For example, [c]power_modifier = 0.05[/c] in [c]Zone_Bw08_asteroid_field[/c] would mean every, say, 10 seconds, there is a 5% probability to lose power for a short period of time, about 1 second, could be random, maybe even affected by the value of [c]power_modifier[/c].

In combination with adoxa’s [c]drop out of cruise once power reaches 0[/c] hack, this could also mean a ship ocasionally loses the ability to cruise. Optionally, it could also affect shields, causing them to temporarily fail.

LOL, I also got this problem too.

Luckily I did a search and discovered this topic before start to talk about it.

Thank you.

I’m looking forward to see if someone will reimplement FLHook with LISP which invented by John McCarthy and Paul Graham.

😄