Source Code Contribution: AI Scripting Platform & Interf

[dj_oldfield]

I would like to build source code for TAS... but should probebly run some things past everyone and see if I can get some info before putting too much time into it.

Interface Contributions: I would like to redo the interface pannel... the transparent approach is difficult to see... and I would like to add more controls. I was thinking of doing a SKINS based approach... because I have no graphics tallent what-so-ever... and perhaps you designers out there would be willing to pretty up my work :).

I want to fix the mouses back and forward motions to scroll up and down the map... fix the map to pan to where you click... and use +/- keys to zoom... but I do not know if anyone has already done this... or if this is even desired.

I want to link the left and right buttons to turn objects durring placement... with space being a problem... I thought that this might be a welcome addition.... so that you can control where building exists are.

I wish to write an new AI Nerve center, scripting language, and runtime dispatch system which will:
Allow teh creation of AI Scripts for all levels of focus (From step by step unit control, to Unit Move/Build/Guard Commands, Construction plans, waypoints, and finally conquest scripting). Build scripts could be represented in text, but would be reduced in size durring runtime. Units could communicate with each-other using these commands as well.

I would like to write this as a seperate library, however I need to be able to work with someone for testing purposes. I can't even test the current source code because it is seeking a file in a directory named "boost" which I am currently unable to locate. Either way, I do not wish to modify any of the current source code linked to units... with exception to enabling the new source code to dispatch the commands. It would be helpful to work on this with someone who has already worked with this code.... anybody interested?

[Maelstrom]

Welsom to spring. Good to see some more developers around.

Any help with the source code is helpfull.

There is a new GUI underway supposedly, but I dont know the status of that. There is a thread about it in the General Section.

There is different view mode avaliable that move really differently. Perhaps you could make a new one of them with the functionality you speak of.

Turning buildings has already been discussed, and is unfortunetley impossible. Unlesds you want to totally re-write the pathfinding scripts, then Im affraid we are stuck with the current building rotations.

Go talk in the AI section about re-writing the AI interface. people might just complain about having to re-write their whole AI's, but you never know...

Im sure there is someone around here who would be happy to help you develop some of these things.

[dj_oldfield]

If so then perhaps they can be imported... they seemed to be compiled however... or atleast from the header files I observed that...

Further comments will be posted in the AI section.

[Gnomre]

I think you need to install luabind to be able to compile, since they're in the process of integrating full LUA support for unit scripts and other stuff like that.

The +/- keys control gamespeed already, btw... I think there are already keys bound to zoom in and out. PgUp and PgDn from memory, but I could be wrong there. That said, having *all* the keys defineable by the user in an INI file or something would be excellent.

Maelstrom, I don't think pathing would necessarily need to be recoded... I mean, it has to do it on the fly to an extent anyway, so what does it matter which way the building is oriented? He'd just have to make sure to rotate the yardmaps accordingly. On that note, the left/right keys pan the camera as well, so it might be better to pick a different key.

[Maelstrom]

Well I got the impression from this thread here on rotatable buildings:
http://taspring.clan-sy.com/phpbb/viewtopic.php?t=1925
That rotatable buildings would be quite hard to implement, and cause pathing apparently works in a grid fashion, making rotatable buildings would require a re-writing of the pathing. but if I read it wrong though, and it is possuble, that would be really cool.

[Gnomre]

I don't see why it'd require a rewrite. I mean, if I manually flipped a vehicle plant and its yardmap and put it in spring, everything would be honky-dory. I don't see why it'd be any different than doing it during play.

[sp2danny72]

the boost things you can get from http://www.boost.org

[SwiftSpear]

I don't see why it'd require a rewrite. I mean, if I manually flipped a vehicle plant and its yardmap and put it in spring, everything would be honky-dory. I don't see why it'd be any different than doing it during play.

Rotating horizontal/vertical probably wouldn't do much damage, but rotating to various diagonals would be horribly destructive to pathfinding abilities.

dj_oldfield: I LOVE to have more coders around willing to fix problems that everyone whines about. However, most of the things you mentioned either already have a fix that isn't well documented, or is supposed to be halfway through finished for the next version.

I really wish the SY's would read these threads every once in a while so they could say things like "go ahead and work that up, we're more then willing to impliment it if you get it working." but I don't think I've ever seen an SY respond to a development thread.

Sounds like you need to talk to someone who knows thier stuff anyways, or else you're going to end up doing alot of work that someone else is already in the middle of finishing right now. SJ was talking earlier about how nice it would be to have more coders contributing, I'm sure they'ed be glad to let you help them out.

[dj_oldfield]

KEY ASSIGNMENTS:
I think that I like the idea of creating a key-map configuration file... as well as choosing the configuration of the mouse. Although I don't think that I would be able to impliment the settings visually in the game for a while... I think Ill get started first creating this with a win app to go with the config file... so that we can use this right off the bat. It also seems like something that people take quite seriously!

ROTATING OBJECTS:
It appears that the rendering device is handling the paths for us... so perhaps if buildings use the same base class as the actual units do... I can bind the buildings to simular rules? Anyway... I just played TACC and found myself once again annoyed that I had my units stumbling over power plants to get out of their buildings. Space can be problem enough... but single exits are more annoying.

OTHER STUFF:
I don't think that it would be a total waste of time to build something and have someone else build it sooner... I imagine that it would be more annoying if it never got built. Anyway... perhaps it will help me to fine tune my skills... perhaps it will help Spring to incorporate a little of both... either way, I just think that it sounds fun to be able to write code and see this game use it!

[/b]

[SJ]

Most keys are already switchable in uikeys.txt, in the new gui they should all be definable (if jou.. ever finishes it)

Rotatable buildings would be possible with some work if you limit it to 90 degree rotations.

I dont think anyone is working on rotatable buildings although a new gui is in the work.

[dj_oldfield]

90 degrees is actually what I already had in mind. It seems however that buildings are actually derived from the CUnit class... and my assumption (although I may be wrong) is that mobile units are also... don't know though because I can't get this to compile until I figure out what boost wants!

I was thinking... couldn't the properties pertaining to oreantation be copied from the class which handles mobile units? If I copied these properties into the CUnit class as virtual ( create __declspec properties to replace any variables if needed )... create an overload for the constructor in CBuilding.... taking an oreantation parameter... it seems taht it would essentially be handled then by the source code which is already intact... right?

[SwiftSpear]

90 degrees is actually what I already had in mind. It seems however that buildings are actually derived from the CUnit class... and my assumption (although I may be wrong) is that mobile units are also... don't know though because I can't get this to compile until I figure out what boost wants!

I was thinking... couldn't the properties pertaining to oreantation be copied from the class which handles mobile units? If I copied these properties into the CUnit class as virtual ( create __declspec properties to replace any variables if needed )... create an overload for the constructor in CBuilding.... taking an oreantation parameter... it seems taht it would essentially be handled then by the source code which is already intact... right?

I always thought the mobile units just rotated overtop of thier footprints, with the collison sphere modifying pathing... Comparitively buildings acctually have the footprint deciding the pathing and collision information. I could be totally wrong however, which I hope is the case if it makes your job easier.

[dj_oldfield]

I hope that you are wrong myself ... but I doubt it! It sounds like you know your way around this source code better then I... and if you are right then that means that I am going to have quite a project on my hands :).

Then again... I can't imagine how I would produce the AI technology without getting to know the source code for the units... perhaps such an undertaking would be an excellent icebreaker?

Either way... I want the camera to move BACK TO FRONT instead of zooming on mouse forward and back... I looked and the camera control class does not even seem to support a back/front aproach. Is this out of preference? does this annoy anybody but me?

[dj_oldfield]

I know that this is going to make me seem very novice (in the game development world I am novice... but I have been programming for a very long time) but I could save some time if anyone can point me to a boost configuration which runs for winxp and VS .NET. I have never used Boost before... and it doesn't seem like it should be challenging... but I just don't know why it seems easier to have includes for non-existant files. My assumption is that they want you to spend a while getting to know their source code so that you can build your own configuration headers... but that idea is very unappealing... Ill do it... but I prefer to be using my time on other things if there is a better option.

[SwiftSpear]

I hope that you are wrong myself ... but I doubt it! It sounds like you know your way around this source code better then I... and if you are right then that means that I am going to have quite a project on my hands :).

Then again... I can't imagine how I would produce the AI technology without getting to know the source code for the units... perhaps such an undertaking would be an excellent icebreaker?

Either way... I want the camera to move BACK TO FRONT instead of zooming on mouse forward and back... I looked and the camera control class does not even seem to support a back/front aproach. Is this out of preference? does this annoy anybody but me?

Never even downloaded the source code; I just know how the units behave, and how playing with different variables in their script loadups makes them behave differently.

[edit] don't know anything about boost at all, sorry, I'll see if gnome is around, I'm sure he knows about it.

[dj_oldfield]

I hope that you are wrong myself ... but I doubt it! It sounds like you know your way around this source code better then I... and if you are right then that means that I am going to have quite a project on my hands :).

Then again... I can't imagine how I would produce the AI technology without getting to know the source code for the units... perhaps such an undertaking would be an excellent icebreaker?

Either way... I want the camera to move BACK TO FRONT instead of zooming on mouse forward and back... I looked and the camera control class does not even seem to support a back/front aproach. Is this out of preference? does this annoy anybody but me?

Never even downloaded the source code; I just know how the units behave, and how playing with different variables in their script loadups makes them behave differently.

That is actually a relief! This does not seem entirely difficult... but I may yet be mistaken. Well... I can't even get this to compile yet... so Ill let you know! anyway... I think that everything goes back to the CUnit class... so I imagine I should be able to find some sort of way to ship some of the functionality into buildings.

[SinbadEV]

I just play the game and poke at map making and source code and generally hang about... but you said something I don't understand.

On MY computer, the scroll wheel zooms in and out and mouse up/down pans the screen up and down and left/right pans the screen left and right... I think you might be stuck in the FPS camera, SHIFT+J to change to TA view, TOtal War view, or rotatable overhead view and the mouse will work the way you want it to as described above...

http://taspring.clan-sy.com/wiki/Using_ ... a_Controls

except for the pan to click thing... I don't understand whay you mean, do you mean like, click the ground somewhere and the camera moves there?

[SJ]

Just download boost from boost.org and add the include directory in the boost folder to the include folders that visual looks in.

[zwzsg]

While you're working on how to turn buildings 90°, you'll sure have to deal with turning their "yardmaps", that is, the grid squares that they are blocking. While you're around that part of the source, can you please change it so as to:
- Let the script commands set YARD_OPEN to TRUE; and set YARD_OPEN to FALSE; do their job.
- Let a y in yardmap FBI tag be interpreted as "always free".

As I asked for in the yardmap thread.

All my hopes lie onto you!

[dj_oldfield]

While you're working on how to turn buildings 90°, you'll sure have to deal with turning their "yardmaps", that is, the grid squares that they are blocking. While you're around that part of the source, can you please change it so as to:
- Let the script commands set YARD_OPEN to TRUE; and set YARD_OPEN to FALSE; do their job.
- Let a y in yardmap FBI tag be interpreted as "always free".

As I asked for in the yardmap thread.

All my hopes lie onto you!

The only thing that makes me curious is if these script commands are directly linked to the procedure calls. I will be diving into the source again tonight... I am going to see if I can get the building rotation working this week... (which might be a pipe dream... who knows)... so Ill have an answer for you shortly.