path finder + strange propulsions

[izno]

Hello!

I just discover your project team. It's long time I know WZ2100 and I'm studying developper, so I couldn't resist to check-out on yhe SVN. Different points took my attention:

-The path finder part of code (wich contain an a* implementation) can probably be improved for performance. One of those modifications could be saving a pre-full array for each kind of propulsion wich contain places where a kind of propulsion given can never know (like mountains for wheel) for the current map. Better: modifying this if a pre-war element is destructing. This look better than test those places each time. [fpath.c => BOOL fpathBlockingTile(SDWORD x, SDWORD y, PROPULSION_TYPE propulsion) ]. What do you think about that?

-Lot of propulsions wich don't appear in game are in code (like ski!): did you add it (and mean you will add this) or it was already written in pumpkin studio (and not used)? Important point is propellor wich is not in game is in pathfinder (increase number of tests to know if unit can go in a place or not).

I'm really happy to see people working hard on their free time to improve the game, and would like maybe help for development (actually, the facts different technologies are used here look also very interesting). Congratulation for your work!

Julien

PS: English is not my mother tongue, sorry if some sentences are not good

[Buginator]

Hi, we would be glad to have any help you can offer!

Currently, as you have noticed, the path finding code isn't doing a very good job at what it should be doing.
It has issues, and is in need of fixing.

That said, improvements have been made (mostly in svn trunk), so you may want to check that out also.
http://svn.gna.org/viewcvs/warzone/trunk/

"PROPELLOR" & "SKI" are indeed in the original source code. It looks like they had planned to add more things also, but they either ran out of time, or maybe they wanted to save it for a sequel.

[izno]

Hi, we would be glad to have any help you can offer!

Sure

Thanks for link with every commits.

An other point: I played with a friend in team against all AI (6): after little time, we didn't see ennemy on same place on each computer (my friend saw me attacked, but not me!), and also, if one of us broke pre-war buildings, the other saw it as not broken sometimes (and if the broker built building where was this pre-war one, the other couldn't see it for the whole game). I think I saw on the website the multiplayer mode needed some changes (concerning the network communiaction of events).

Other problem we noticed: at the begining trucks built and repair quickly, but wait long time before moving after a long time of playing (this time also increase with the distance between truck and building place, It's why I checked the pathfinding code).

I will read much more the code and wiki and then see with other developpers on wich part of code my help can be the most useful.

Julien

EDIT:
Maybe it's not the good place to write bugs, but I add one: if power ressource is available, sometimes 2 truck of different color go to build a derrick. If the closest begin to build it and this derrick is quickly destruct, the second still coming, and built another one, even if it's on fire! Probably a check miss in code (I will try to find where does it come from)

[Per]

We would very much like help making the path-finding better. There is a lot of stuff that can probably be cached aggressively and save lots of CPU time, and there is lots that can be done to improve droid collision detection. I would very much recommend looking at trunk, rather than 2.1 branch, though, since the path-finding code is cleaned up a lot there.

The 'propellor' propulsion is used in trunk for naval (water tiles only) movement, so it is no longer unused.

[izno]

per=> I only look on trunk

For the bug I add by editing my previous post (truck building derrick on fire), I'm not in good conditions right now to make test and create a real patch for svn, but following code could probably solve it:


in action.c line 1802: give the struct type as argument to the function 'validLocation()' (maybe there is other way in function to find building type, but I couldn't find it). I will call this argument structType in the following code.

add in structure.c (for example at line 4065):

Code: Select all

//don't build derrick if oil began to burn after the building order was given
if (structType == REF_RESOURCE_EXTRACTOR && fireOnLocation(x, y)) 
	{
				valid = false;
				goto failed;
				//add debug info or reason of failed if necessary
	}

I repeat it: I'm not in situation to make any tests, so this have to be tested (I don't know yet enough the code to do very good job immediatly )

An important point I would like to say: this giant SWITCH doesn't like pretty, what about replace it by a function pointer? And more: removing this UGLY GOTO? xD

Let me know if you want to implement it now (anybody on this forum), or if it will wait the time I can make it right by myself.

Julien

[Buginator]

Hi, we would be glad to have any help you can offer!

Sure

Thanks for link with every commits.

An other point: I played with a friend in team against all AI (6): after little time, we didn't see ennemy on same place on each computer (my friend saw me attacked, but not me!), and also, if one of us broke pre-war buildings, the other saw it as not broken sometimes (and if the broker built building where was this pre-war one, the other couldn't see it for the whole game). I think I saw on the website the multiplayer mode needed some changes (concerning the network communiaction of events).

Yeah, we know about this, and there is a fix for it in trunk, and 2.1 branch.
Though, I am not sure the fix fixes everything involved with this issue.

Other problem we noticed: at the begining trucks built and repair quickly, but wait long time before moving after a long time of playing (this time also increase with the distance between truck and building place, It's why I checked the pathfinding code).

I will read much more the code and wiki and then see with other developpers on wich part of code my help can be the most useful.

Julien

If this is with trunk, then, it should have been a bit better than 2.1 branch. Was there allot of units in the game?

For the bug I add by editing my previous post (truck building derrick on fire), I'm not in good conditions right now to make test and create a real patch for svn, but following code could probably solve it:

Check the AI code (*.slo & *.vlo) files, and you can see that the AI was using another routine, and the onfire check was removed because of speed issues.

An important point I would like to say: this giant SWITCH doesn't like pretty, what about replace it by a function pointer? And more: removing this UGLY GOTO? xD

Let me know if you want to implement it now (anybody on this forum), or if it will wait the time I can make it right by myself.

Julien

[/quote]
Lots of stuff isn't pretty in warzone, and it is full of 'goto's, and lots of other head scratching code.
Take a look at game.c for some interesting coding.

Overall though, if you fix something, then you can post the code to the GNA patch tracker, or the ML, and people will check it out, and comment on it.

[Troman]

Another thing that needs a fix is when AI truck is ordered to build a derrick but your truck starts before the AI truck, when the AI truck arrives your truck is already building a derrick and AI truck helps you to build it. When the derrick is finished it stays there for a second confused ... : "WTF, where did my derrick go?", I always find that hilarious xD

[Per]

fireOnLocation() is currently quite slow, though. See https://gna.org/patch/?1096 for a patch to speed it up and fix one problem with it (AI can cheat and build on burning oil fields). You can put information you find regarding missing checks for burning oil in that ticket so that it doesn't get lost.

[izno]

OK,

I didn't saw that AI is in another routine. I will make some tests to know if this can be done by human also. If yes (it look possible regarding the code), I will put informations from my previous post in ticket.

If this is with trunk, then, it should have been a bit better than 2.1 branch. Was there allot of units in the game?

Pretty a lot, yes, but with 2.1 release

and the onfire check was removed because of speed issues.

Ok, I will try to be up to date on change you did for some reasons

Take a look at game.c for some interesting coding

What are all those GAME_SAVE_VXX ??? Did you add some or most come from Pumpmkin sources? This file is enough big to feed a continent during 1 year!

Julien

Edit: my english is little poor... Can you confirm me "tile" is the unity of space used? (like a square) Thx

[Buginator]

Another thing that needs a fix is when AI truck is ordered to build a derrick but your truck starts before the AI truck, when the AI truck arrives your truck is already building a derrick and AI truck helps you to build it. When the derrick is finished it stays there for a second confused ... : "WTF, where did my derrick go?", I always find that hilarious xD

Heh, I noticed this in the past, and everyone thought the game had no CO-OP!
At which point, you promptly kill the offending truck and derrick.

OK,
I didn't saw that AI is in another routine. I will make some tests to know if this can be done by human also. If yes (it look possible regarding the code), I will put informations from my previous post in ticket.

Nope, it isn't possible for humans to build on the burning oil derrick.

What are all those GAME_SAVE_VXX ??? Did you add some or most come from Pumpmkin sources? This file is enough big to feed a continent during 1 year!

Julien

Edit: my english is little poor... Can you confirm me "tile" is the unity of space used? (like a square) Thx

Yeah, most all the code is still Pumpkin original.
Just wait until you see some comments they put in the code.

And yes, a tile is 1 square on the map. Maps can be up to 252 x 252 in size. (maybe it is 254x254... I forget)