New DLL callbacks - any requests?

[Red Spot]

You have the dll set the AIP, so your dll/code should already be aware of it.

[GSH]

AIPs can self-switch now if desired.

-- GSH

[Red Spot]

Forgat about that one ...

[General BlackDragon]

Similar to the Goto vector version, vector versions of these would be nice.

DLLEXPORT void DLLAPI Mine(Handle me, Vector &pos, int priority = 1);

DLLEXPORT void DLLAPI Retreat(Handle me, Vector &pos, int priority = 1);

DLLEXPORT void DLLAPI Dropoff(Handle me, Vector &pos, int priority = 1);

[General BlackDragon]

Not sure if I mentioned this yet or not, A parellel to SetSkill, the ability to get the current skill of the unit.

DLLEXPORT int DLLAPI GetSkill(Handle h);

[General BlackDragon]

Requesting a few more things:


// Like SelfDamage()/Damage()/DamageF(), but sets the damage causer to him.
// This allows the DLL to implicate someone else taking credit for a kill on them,
// if this damage does the job of killing them.
DLLEXPORT void DLLAPI OtherDamage(Handle me, Handle him, float amt);

[Commando]

GetExplosion, basically returning the name of the explosion, a ship is damaged by.

Would be useful in creating special explosions, like EMP explosions, via dll.

[Commando]

Not sure what it would be called but being able to have a DLL prevent you from building an object could be useful. For example, having a unit only buildable if an ivar value is a specific amount. Basically a way for mod makers to create their own scrap system, if they choose to do so.

For clarification. A dll callback that interacts with the build requirement system as well as the scrap requirement system.

For example

1. As long as the player has a custom extractor (ibscup_33), ivar33 increments upward for the player. Up to a value specified in the odf.
2. If the unit is lost, ivar33 reverts back to 0.
3. The player wants to build a new tank, but it requires ivar33 to be 50 or higher, if the player tries to build with this value too low, it is rejected due to the dll callback.

In the above example, all of the behavior being handled by the dll.

[mase]

You could replace the factory/constructor with a factory/constructor that can't build that building if the conditions are not met.

[Commando]

True, figured a dll callback would be cleaner as you don't have to have x number of different factory variant odfs to account for all of the combinations.

[Commando]

Would it be possible for a dll to check if a client/host are out of sync? Currently I'm seeing quite a few resyncs in G66.

Unfortunately I have no way of knowing if the dll is triggering the resyncs or something in the engine is.
Being able to log what the dll is doing, and within the same log, being able to log the game is out of sync, will give clues what is going on at the time.

[GSH]

Would it be possible for a dll to check if a client/host are out of sync?

Not easily. Periodically (every 1.6 or 3.2 seconds at 10tps), clients send checksums of where every gameobject was during those 16/32 turns. And, that checksum is only 32 bits; impossible to unscramble those bits back to ~4096-32768 bytes of original data. Server checks against its checksums, and if different, reports what client(s) are out of sync. The DLL's state is not part of that checksummed data, but any decisions made by differing DLLs tend to cause gameobjects to be out of sync quickly.

-- GSH

[General BlackDragon]

Could always swap out the G66 DLL for a Stock DLL to see if it still happens. If I had the source to RD's G66 I could check to make sure it's not DLL caused.

[Red Devil]

the incorrect folder and, hence, the incorrect dll was being used, hence, the resyncs; correct one is resync free.

[General BlackDragon]

Ah, that explains it.