New DLL callbacks - any requests?

[Nielk1]

Would it be possible to "up" the simulation speed? Such that bots could fight each other in faster than realtime.
This would be for machine learning purposes.

If you are doing that wouldn't you just run the game's CPU cycles faster than you told it you were?

[mase]

Would it be possible to "up" the simulation speed? Such that bots could fight each other in faster than realtime.
This would be for machine learning purposes.

If you are doing that wouldn't you just run the game's CPU cycles faster than you told it you were?

A fast (in bz2 terms) CPU should be capabable of running BZ2s game logic faster then realtime however the simulation speed is limited
so as to be realistic. Otherwise the game would run as fast as the cpu is. Also if you can switch of the graphics completely that would
save cpu cycles. Dough I think this is not necessary because if you tab out of the game, the graphics stop. Here is a link for explanation: http://www.flipcode.com/archives/Main_L ... teps.shtml

Is there a way other then the map to specify the DLL to be used? It would make it much easier for DLL makers if the DLL could just be
specified in the shell or through a recy variant, so that one does not have to release a new map (or copy an existing) for every new DLL.

[Red Spot]

You can always put a flag in your cfg and make your dll able to deal with different scenario's, as pretty much every 'dll-modder' already does.
Its basicly the same as the AI-skill you set pre-game.

[Red Devil]

there is the game.gofast command, but i believe that is for recording playbacks; still the code might be useful.

agreed about allowing dll's to be specified in the shell; been wishing for that for many years now, but it may be a problem, like playing a strat on a DM map with powerups popping up all over the place. sure, it would allow less duplication of maps by combining path points into one map, but sometimes keeping things separate is a good thing. mpic/mpih path points referenced in mpi dll's can control the spawning of buildings and units, but there may be other considerations i can't really think of right now (too early).

[Nielk1]

Would it be possible to "up" the simulation speed? Such that bots could fight each other in faster than realtime.
This would be for machine learning purposes.

If you are doing that wouldn't you just run the game's CPU cycles faster than you told it you were?

A fast (in bz2 terms) CPU should be capabable of running BZ2s game logic faster then realtime however the simulation speed is limited
so as to be realistic. Otherwise the game would run as fast as the cpu is. Also if you can switch of the graphics completely that would
save cpu cycles. Dough I think this is not necessary because if you tab out of the game, the graphics stop. Here is a link for explanation: http://www.flipcode.com/archives/Main_L ... teps.shtml

Is there a way other then the map to specify the DLL to be used? It would make it much easier for DLL makers if the DLL could just be
specified in the shell or through a recy variant, so that one does not have to release a new map (or copy an existing) for every new DLL.

I don't understand what you want. (And I do understand the principles of basic programming design, I do it every day.) There is no reason to speed anything up with BZ2 if you plan to play it. The DLL runs at a lock step X many turns per second, however, its still running its logic at however fast your CPU can run. In BZ2, there is a ton of "down time" for the CPU. The DLL could be made to take 20 times longer in CPU cycles and still run at the atrociously low step rate that BZ2 uses. Your question, or whatever you want, just doesn't make sense, it doesn't fit the logical situation. BZ2 does have a "high TPS" mode, but that is still quite slow compared to modern games. Really, if you tried to give AI instructions at the speed you want, they would be schizophrenic. The higher TPS only assists in physics as it is since the AI tends to run even slower than tick.

DLLs are too complex to simply swap out like that. However, a DLL could run a script, such as LUA or Python and that script could be specified by the map configuration. I would suggest if that was done you instead specify some custom delegates to enhance a script rather than completely replace it when it comes to customizing gamemodes. When I say complex, I don't mean that scripts are less or something, I mean that there is a lot of code you would end up repeating over and over if swapped the entire script.

[mase]

I don't understand what you want. (And I do understand the principles of basic programming design, I do it every day.) There is no reason to speed anything up with BZ2 if you plan to play it. The DLL runs at a lock step X many turns per second, however, its still running its logic at however fast your CPU can run. In BZ2, there is a ton of "down time" for the CPU. The DLL could be made to take 20 times longer in CPU cycles and still run at the atrociously low step rate that BZ2 uses. Your question, or whatever you want, just doesn't make sense, it doesn't fit the logical situation. BZ2 does have a "high TPS" mode, but that is still quite slow compared to modern games. Really, if you tried to give AI instructions at the speed you want, they would be schizophrenic. The higher TPS only assists in physics as it is since the AI tends to run even slower than tick.

I don't want to play the game myself, I want the AI to play it without any human interaction.
Why would one make the DLL take longer?
The HightTPS mode is not what I'm after. That just means (according to my knowledge):
If the game is advanced by 100 ms, how many intermediate steps will there be in calculating the new gamestate
and how often will the DLL be capable of reacting to the new gametate. So this is about accuracy.
If you go from point A to Point B at a certain velocity in game then two things need to happen:
The new position needs to be calculated using the physics system and the visual world need to be updated.
All of these steps need CPU / GPU cycles.
Now the question is: How many CPU cycles do I need in order to advance the game by 100 ms in physical time,
that is, setting 100 ms as the time variable in the physics equations. This will take a certain wall clock time. Lets say my CPU takes 20 ms for that. That means that I could advance the game by 100 ms every 20 ms but if I do that, the game will run super fast and the user will not be capable of coping with that. Since we don't want the game to depend on how fast the cpu runs we make it such that advancing the physical world by 100 ms will always take about 100 ms. Every game does that in order to not be dependant on the users cpu speed. What I want is to remove this limitation. The AI does not need this limitation, it does not care about wall clock time and could simply play the game at maximum speed. It also does not care about the graphical world, so that can be put off too.

[GSH]

Mase-
You suffer from a fundamental misunderstanding of how BZ2 -- and a lot of other games -- work. BZ2 steps simulation at 100ms increments. Doesn't matter if it's human or AI. Everything is updated when 100ms has elapsed, and it updates each item once, and by 100ms. There are no extra intermediate steps. Rendering is decoupled from that 100ms loop, so that it can run much faster than the 1/10 of a second that 100ms has elapsed.

Any game with physics should NOT run physics as fast as possible. Read this for one of many best practices articles from commercial games programmers. (Disclaimer: the author of that was once employed at Pandemic Studios, and I worked with him.) A fixed timestep (100ms at the default 10tps) is what BZ2 uses. Other games are at 30tps (~33ms per timestep, but once again, they only update once in that timestep).

If you just want to run things as fast as possible, then we've already told you the answer: the game.gofast console command turns off rendering and pumps the simulation as fast as possible - no waiting for the full 100ms to elapse. The time you spent writing up a long post could have been better served by trying what we told you. And if game.gofast isn't what you want, then you could have said so -- and what you want is now a feature request that's really not very well defined.

-- GSH

[General BlackDragon]

I'd like a way to get a unittask's state. You know how say, a sentry or scout will switch from attack state to retreat state, and turn away from what it's shooting when it gets shot a couple of times? I'd like for the DLL to be able to see what state a unit is in, so it could do something when a unit is in a particular state.

[mase]

I have tried game.gofast and it does what I want, I was just responding to Nielk's post
and that's also the reason why I don't understand why he says it doesn't make sense.
Not waiting 100ms wallclock time to update the physics world by 100ms is what I want.

[General BlackDragon]

A callback to see if a pathpoint esists:

bool DoesPathExist(name Name)

[General BlackDragon]

A GetPerceivedTeam(Handle) would be useful.

[Red Spot]

A callback to see if a pathpoint esists:

bool DoesPathExist(name Name)

Just check the needed pathpoints at start, set a flag when its there.

[Red Devil]

a GetWhoLookingAt() and a GetWhoLookingAtMe() callback would be helpful.

[Nielk1]

a GetWhoLookingAt() and a GetWhoLookingAtMe() callback would be helpful.

If added, I suggest a comment that notes its specific to the LookAt command. We don't need new DLL makers getting too confused now.

[mase]

Currently there seems no way to get Information about points on an object.

Returns the point of this object. For example for an assault tank would return the position and orientation of his turret.

Matrix GetPoint(Handle h, Name point)