@IK its not as simple as just making a release. The performance changes seem to have revealed a flaw in the way tasks are handled which causes a random crash bug. In order to fix this bug and improve performance all this is going to need to written again effectively because it has grown so complex.
Having said that NTai without the single/solo build is going to be a big step backwards.
NTai XE10.1b
Moderators: hoijui, Moderators
Having said that the solobuild and single build mechanisms are complex and untidy, and they don't catch all instances. They would need to be rewritten in a new design at some point anyway if only for better conformance witht he new task systems.
In the mean time, I doubt the tasks systems are at fault. The only issue I can imagine they could be causing is related to STL containers resizing themselves causing shared_ptr objects to become corrupt.
Having said all that you might notice that the other AIs dont have this, and our AIs did fine for at least a year before I first introduced the idea of exclusion zones or single/solobuild.
Are there any suggestions on how to reimplement solo and singlebuild that wont fall flat on its face when you add extra threads?
In the mean time, I doubt the tasks systems are at fault. The only issue I can imagine they could be causing is related to STL containers resizing themselves causing shared_ptr objects to become corrupt.
Having said all that you might notice that the other AIs dont have this, and our AIs did fine for at least a year before I first introduced the idea of exclusion zones or single/solobuild.
Are there any suggestions on how to reimplement solo and singlebuild that wont fall flat on its face when you add extra threads?
Surely a central build manager is required. The threads themselves would make requests to the central build manager which could lock the creation of unit types. I realise this central point would mean all the threads converge to requests from a single point and as such the concurrent processing would be less effective but i see no other way to achieve what you are looking for. IMO the central build manager should look after
Single/Solobuild rules
Antistall
b_rule assignment
maintain the blocking map
expose a list of all current build projects
The threads can then take care of
Finding a build position
can request the nearest build project
I've never built an AI before but from what you've said that's how I'd construct it...
Single/Solobuild rules
Antistall
b_rule assignment
maintain the blocking map
expose a list of all current build projects
The threads can then take care of
Finding a build position
can request the nearest build project
I've never built an AI before but from what you've said that's how I'd construct it...
Because aside from a wider range of event call outs, it would be much easier to implement.
Max build was not implemented because of complexity issues. Single build and solo build are comma separated lists of values, where would the max build value go?
Of course you can start adding in saying "unit, maxbuild, unit, maxbuild" and so on, which complicates the parsing of the code.
Or you could move it into a different part and use sections, which also makes the code more complicated and long winded. It also makes tool kit more complicated at the same time. All of this at a time when I have little time to spend with NTai anyway and I'm looking for the features that are easiest to implement in the least time possible.
Max build was not implemented because of complexity issues. Single build and solo build are comma separated lists of values, where would the max build value go?
Of course you can start adding in saying "unit, maxbuild, unit, maxbuild" and so on, which complicates the parsing of the code.
Or you could move it into a different part and use sections, which also makes the code more complicated and long winded. It also makes tool kit more complicated at the same time. All of this at a time when I have little time to spend with NTai anyway and I'm looking for the features that are easiest to implement in the least time possible.
I thought you would have a tdf parser that was already built and an object that represented the data for a unit IE its max metal min metal etc. Surely adding another property to that Class using an existing parser would be trivial?
I know nothing about the gadget stuff at all. But as long as it covers all the events such like build started etc it should be fine. It must also be able to cover a unit being destroyed, a unit being destroyed whilst being built and a unit that is abandoned in mid build etc. Is there anywhere I can read up on this?
I know nothing about the gadget stuff at all. But as long as it covers all the events such like build started etc it should be fine. It must also be able to cover a unit being destroyed, a unit being destroyed whilst being built and a unit that is abandoned in mid build etc. Is there anywhere I can read up on this?
Lua gadgets have all the events AIs have and a few extra. For details look in the lua scripts forum.
And no, if you look at the format of the config files singlebuild is a tag that takes a list of unit names. There're no sections to hold unit properties e.g:
etc, although this would be more flexible in the long run it would have taken longer to code, which conflicted with the number 1 priority at the time which was small features that were fast and easier to implement with little hassle at all.
And there is no dedicated class for holding unit properties. So far NTai uses a property orientated model rather than a subject orientated model.
So a property holds info about the units it affects rather than the unit holding info about the properties that effect it. Indeed the other way around may be more flexible and better in the longrun but it was easier to implement at the time and faster to implement too with immediate results.
And no, if you look at the format of the config files singlebuild is a tag that takes a list of unit names. There're no sections to hold unit properties e.g:
Code: Select all
[armcom]
{
property1=value1;
property2=value2;
}And there is no dedicated class for holding unit properties. So far NTai uses a property orientated model rather than a subject orientated model.
So a property holds info about the units it affects rather than the unit holding info about the properties that effect it. Indeed the other way around may be more flexible and better in the longrun but it was easier to implement at the time and faster to implement too with immediate results.
They're the same VFS the AI and lua can see. NTai loads files through the VFS calls, so if NTai can see it so can lua.
I may well be refactoring some things soon as I want to clean up a lot of things so I have a more presentable portfolio to show off, which may well show up at runtime as either better performance or better stability.
Also, I may not be able to play spring on my laptop but if Im looking for crashes, seeing what's happening can be useful but I'm hoping its not necessary to debug. Ill compile spring tonight and try to debug NTai and see if the ATI driver issues scope is purely graphical.
I may well be refactoring some things soon as I want to clean up a lot of things so I have a more presentable portfolio to show off, which may well show up at runtime as either better performance or better stability.
Also, I may not be able to play spring on my laptop but if Im looking for crashes, seeing what's happening can be useful but I'm hoping its not necessary to debug. Ill compile spring tonight and try to debug NTai and see if the ATI driver issues scope is purely graphical.
none.
At the moment there is no AI<->Lua communication of any kind. This will not be possible untill 0.76b1.
NTai would continue to push through with the build and send it off to the engine. While floating around engine land it'll pass through the lua gadgets where your little gadget yanks it by the ear and throws it in the bin. NTai recieves a UnitIdle call and moves onto the next task.
Its not the best solution as it cant sit watching over NTais decision making process ommitting the unit from ever being considered, but that's something that'll be possible in 0.76. Ill set up an NTai gadget and a lua version of the IModule class with call ins that you can extend NTai with and implement things as you like.
But right now making the source code look presentable takes priority.
At the moment there is no AI<->Lua communication of any kind. This will not be possible untill 0.76b1.
NTai would continue to push through with the build and send it off to the engine. While floating around engine land it'll pass through the lua gadgets where your little gadget yanks it by the ear and throws it in the bin. NTai recieves a UnitIdle call and moves onto the next task.
Its not the best solution as it cant sit watching over NTais decision making process ommitting the unit from ever being considered, but that's something that'll be possible in 0.76. Ill set up an NTai gadget and a lua version of the IModule class with call ins that you can extend NTai with and implement things as you like.
But right now making the source code look presentable takes priority.
It sounds like your in danger of running into a world of problems with an implementation of this kind. your AI will basically spend all its time looking for build positions before the gadget throws the build in the bin. I really think this is a bad move. Efficiency wise you have to think of the biggest cost which is first and foremost finding a build position. If at any point you are going to discard a build plan it should be done as early as possible, the gadget can only do it at the end.
Well I'm adding a CUnitTypeData class in the next commit, which will give me somewhere to put all this data and perhaps a few helper functions from CUnitDefHelper.
I've modified CUnitDefLoader to create the objects at the same time it does the work with the unitdef list from the engine. I'm using boost::shared_array for it, and I'm going to start using weak_ptr for retrieving the shared_ptr which should prevent some of the earlier issues with memory leaks and double referencing in shared_ptr.
That and I'll be commenting as I go along so it'll be easier to read.
I've modified CUnitDefLoader to create the objects at the same time it does the work with the unitdef list from the engine. I'm using boost::shared_array for it, and I'm going to start using weak_ptr for retrieving the shared_ptr which should prevent some of the earlier issues with memory leaks and double referencing in shared_ptr.
That and I'll be commenting as I go along so it'll be easier to read.
I've made a very large commit to the svn.
Aside from adding a lot of whitespace, I added a CUnitTypeData class and shifted a large portion of the AI over to using it, including using weak_ptr and shared_ptr for it. I also managed to refactor out the CUnitDefHelp class into the unittypedata class, and cleaned up some loading code some more.
Some minor mixups where fixed in the antistall code, however that only applies to simulative antistall (value 7), which isnt used (toolkit gives the value 3). Other values include 5, which is 3 but with an extra stricter check.
Aside from adding a lot of whitespace, I added a CUnitTypeData class and shifted a large portion of the AI over to using it, including using weak_ptr and shared_ptr for it. I also managed to refactor out the CUnitDefHelp class into the unittypedata class, and cleaned up some loading code some more.
Some minor mixups where fixed in the antistall code, however that only applies to simulative antistall (value 7), which isnt used (toolkit gives the value 3). Other values include 5, which is 3 but with an extra stricter check.
seems to be a problem loading the unit ID, its trying to load tasklist for name empty string so never builds anything
Code: Select all
[-]|9:17:27| < Frame: 0 > error loading tasklist :: :: buffer empty, most likely because of an empty listoops, forgot to initialize a value. Rather than retrieving the units name, trimming it and putting it into lowercase everytime I want to use it, I decided I'd do it once in CUnitDataType Init function and then save it, and add a GetUntName() method. Only I forgot to initialize the value so naturally the vast majority of unitnames floating around NTai are "",
Committed fix to svn.
Committed fix to svn.