Help with logic needed

[Blacki]

I'm assuming AGI is multi-threaded because otherwise the logic would have worked in the first place.

The only thing that was done to make it work was moving the reset command from the bottom to the top.
So for some reason before it gets to the reset command it restarts the IF statement.   It's the only explanation I can come up with.



(The "virtual processor" thing was only hypothetical.  I'm not saying there is such a thing, I'm just using the term to try to explain how the multi-threading works.)

[Nick Sonneveld]

perhaps the flag affects the other commands that are called in the statement.. i would check that first before assuming multi-threaded code.

- Nick

[Nick Sonneveld]

ok.. just checked.. not that.   I know it's not just jumping around code though.

- Nic

[Nick Sonneveld]

All I know is that you're assuming too much here.. I would check other factors before assuming there's support for code that isn't there.

- Nick

[Adam]

perhaps the flag affects the other commands that are called in the statement.. i would check that first before assuming multi-threaded code.

- Nick

I think the way the interpreter executes commands (changing flags, animates objects, etc) could use some clarification.   From what I understand about execution, flag settings, and WHEN you set them, more than anything else, are responsible for how your code gets executed at run-time.  At times I find myself scratching my head about when I should initialize my flags.. after that, it's a matter of tracing where your code is executing (a rather familiar habit)

Adam    

[Blacki]

Can anyone explain what has happened then??

[Joel]

Most likely, the cause is somewhere else in the code. Something that we can't see (or something more simple that we're overlooking). AGI is definitely not multi-threaded in the sense of executing more than one AGI command at the same time. That would make things extremely difficult because you would not be able to make any assumptions about the order of execution at all.

Besides, typically when there's a concurrency issue, it wouldn't show up every time the program was run. Also, in a typical implementation of threads, you're only guaranteed that your thread won't be preempted at the atomic level (one machine instruction). Even the simple if-statement:

Code: [Select]

if (f115)
{
 reset(f115);
}

is not atomic (your thread might be preempted right after the test "isset(f115)"), so if this were a concurrency issue there really wouldn't be any way to solve it at all, especially since AGI logic lacks typical thread synchronization mechanisms such as critical sections, etc.

[robingravel]

if (isset(f115))
{
 reset(f115);
}

Robin Gravel

[Joel]

if (isset(f115)) and if (f115) are equivalent.

[Andrew_Baker]

Ultimately, the AGI interpreter is not the best game engine in the world.  It is very, very simple to use the make simple games, but it was never designed for this level of complexity.

Additionally, I also agree with substituting an object for an ego when doing ego animations, but that's just because it makes my code less kludgy.

[Chris Cromer]

Shesh, this topic was started back in August. I wonder how long it will take for it to die.

[Nick Sonneveld]

I didn't think topics "died" as such.  That's kinda suggesting that whenever somebody posts a new topic, we all try to bludgeon it to death with our replies until we don't hear anything from the original author.  

- Nick

[Chris Cromer]

Well I don't think Bjoern is haveing any problem with V in the rooms with shooting...

This topic just took a life of it's own about something completely different.