Cool Pog Tricks

I'm not sure if I know any good tricks, I'm more of the type of person who just gets in the mood, then doesn't remember what he did after doing some pretty creative stuff.

Hmmm, a candidate for SoupDragon to try out sticky threads?

I'll second that idea.

I think they're just globals with a reference to their parent's id in their key, but that's idle speculation.

I'll second that speculation.

Originally posted by GrandpaTrout

Caveats are especially welcome - cause they eat hours of time.

Here is one. Lists can be passed between threads. Groups CANNOT. Groups only exist in one threads address space. Somehow lists cross.

I also find that passing groups into the iAI.SpecificAttackOrder is a sure way to fault Flux. I think it happens when my combat handler thread exits. The thread memory must go invalid, taking the group with it. The iAI code must not like invalid handles. Not sure how to deal with that, beside not using groups, or never letting the thread exit. We will need to be careful that any shutdown code locks everything atomic before halting.

-Gtrout

That's odd, but not all that surprising. Note this from the SDK...

"A handle should be maintained to the top group of the group tree. In other words the only time the handle can be safely forgotton is when a newly created group is added as a sub-group to another.
You will need to call Group.Destroy on all the top group handles in order to prevent memory leakage.
Remember a single group is also the top group of what is a one group tree. "

So letting go of groups is a bad idea. It looks like groups are designed for more short-termed things, like combat (note the ABB_Common package), not for long-term organisation.

I now wish I had been using revision control when I tried it. I rewrote the code and defect or flux bug is now lost to history. I believe I did try destroying the group before exiting the thread. It was fatal. It might be you would have to purge all orders first. I thought it strange at the time because combat seemed to be a goal of groups, so why the bug? Maybe I was doing something terribly wrong.

A few ideas that would be very handy here:
1. A list of all properties for each object type.
2. Special behavior of the object types.

Some #2 items. I have not been able to get deathscripts to work with PBC bolt objects. They do work with REM missiles, but sometimes the player gets trapped with the dead sim. Cargo pods become targetable subsims when you child attach them to a ship. Countermeasure flares do not become targetable. Some can be fixed immobile. Some cannot. I will dig up a list of Object types. We can try to fill in the behavior. (like a group crossword!)


-Gtrout

originally posted by GrandpaTrout
I was doing some integer math when I stumbled on this bug:

GetNumber()
{
return 600;
}

number = GetNumber() +10 - 60;

The value of number was 600. Not 550. When I changed the line
to be:

number = GetNumber() + 10;
number = number - 60;

Then number was 550.

Might as well get 'em all in one place.

Haven't really used groups, so no idea on your thread point, but I do remember thinking it seems a sim can be in only one group at a time -- Group.AddSim() removing it from any group it's already in. Might be wrong, though.

A few ideas that would be very handy here:
1. A list of all properties for each object type.
2. Special behavior of the object types.

Property names are fairly easy to gather by trawling ini files and iwar2.dll; the real crossword puzzle work is in getting half-decent read/write and effect notes. I have quite a lot already done for subsims, and a bit for ships; what format do you have in mind? Reconstructing the class hierarchy would be helpful, too, but takes a fair bit of guesswork.

I have not been able to get deathscripts to work with PBC bolt objects.

Do death scripts require a hisim? Maybe you can't cast icBullet to hisim? Probably not that simple: I had thought all hsims could be cast to hisims.

[edit]Oops.

Another behaviour of sets and lists, specifically when using them as globals or object properties: Not sure why. The working version ought to be atomic{} if more than one process might try to do it at once.
[/edit]

Yes, lists sometimes behave as local copies, and sometimes as references.

Any text format on the properties list. Soup might have a suggestion for how to get info uploaded quickly by members. I will have enough free time this weekend to reformat my site. It could go there. Small file space limit however, so once we start seeing models and stuff, it will not be enough room.

-Gtrout

A test I just ran. Culling does not set off a deathscript.

-Gtrout