also add that negative grid points are not allowed or something along those lines, when i tried negative grid points i had problems getting it to work at least luke jr told me that was the reason
Do you have the map where you tried that? because I've tried with a map that had only negative points and one that has a point in each quarter and all works fine.
Can you test the following on your system. Otherwise, I think its a "format-0.1.dtd" vs "map-0.1.dtd" problem. I'll close the bug in sourceforge
Your_mom wrote:also add that negative grid points are not allowed or something along those lines, when i tried negative grid points i had problems getting it to work at least luke jr told me that was the reason
Do you have the map where you tried that? because I've tried with a map that had only negative points and one that has a point in each quarter and all works fine.
Can you test the following on your system. Otherwise, I think its a "format-0.1.dtd" vs "map-0.1.dtd" problem. I'll close the bug in sourceforge
Then explain why it was only a problem with large multipliers?
Maybe this is a non-x86 bug?
How large were the multipliers?
To my knowledge, there's nothing special about negative coordinates. Except for the initializing of the basic grid datastructure, only differences in coordinates are relevant in the code. (All that, of course, plus/minus my memory loss.)
z-man wrote:To my knowledge, there's nothing special about negative coordinates. Except for the initializing of the basic grid datastructure, only differences in coordinates are relevant in the code. (All that, of course, plus/minus my memory loss.)
Is it possible that some datatype is signed on x86, but unsigned on x86_64? I doubt it, but that would be one possible explanation... (with the obvious flaw that then negative coords would crash at *any* size)
I'm just unable to reproduce the bug in any form, so I'd like to know:
-who has observed this crash and was it first hand or second hand?
-is that person available to help debug (ie at least has a compiler for his OS/architecture)?
-what architecture was used?
-what version of the game was used?
-what map was used?
-What size multiplier was used?
-other condition that seem relevant?
and if this is reproducable on every attempts, or just some times?
philippeqc wrote:-what version of the game was used?
whatever random CVS was that day o.o
When you get the change to test, can you try to compile a new "fresh cvs" version. Question to see if it was a problem with that version, or a problem in all versions.
philippeqc wrote:-what map was used?
inaktek
I assume its inaktek 0.7.0?
philippeqc wrote:-What size multiplier was used?
0 or 1
philippeqc wrote:-other condition that seem relevant?
Adding 700 to all coordinates (making them positive) fixed the problem.
What other condition leading to the test are relevant? I assume its was a server/client game. Can you try on a local game to replicate the error with the same map? In the client/server context, is it only the server that crash? Can you try to have the client and/or the server (all combinaisons) on a non x86_64 architecture?
philippeqc wrote:and if this is reproducable on every attempts, or just some times?
Hopefully I'll know shortly after I wake up. ;)[/quote]
Do you observe the same conditions with the 2 maps I've posted in some previous message?
philippeqc wrote:-what version of the game was used?
whatever random CVS was that day o.o
When you get the change to test, can you try to compile a new "fresh cvs" version. Question to see if it was a problem with that version, or a problem in all versions.
Yea... I don't keep old versions around...
philippeqc wrote:
philippeqc wrote:-what map was used?
inaktek
I assume its inaktek 0.7.0?
No idea...
philippeqc wrote:
philippeqc wrote:-other condition that seem relevant?
Adding 700 to all coordinates (making them positive) fixed the problem.
What other condition leading to the test are relevant? I assume its was a server/client game. Can you try on a local game to replicate the error with the same map? In the client/server context, is it only the server that crash? Can you try to have the client and/or the server (all combinaisons) on a non x86_64 architecture?
I could, but map code shouldn't be affected by the server too much..
SavePos and RestorePos are basically a one level stack. You can push a coordinate there during the construction of a wall. When you pop the coordinate back, you are able to build a new trunc of wall from that saved coordinate.
line is a keyword for a 2 point wall.
Rectangle create a box bounded by the 2 set of coordinate given. If you give it x1, y1, x2, y2, it will make a box having the corners:
(x1,y1) (x1,y2) (x2,y2) (x2,y1)
[maybe not in this order, but the box is identical]
While you can put any amount of rectangles on a map, I recommend you only use one, and only for the outer boundaries of your arena, if you want a rectangular one that is aligned on the x and y axis. If you use some elsewhere, you might create dead zone. They are quite inconvenient when it comes to winzones appearing over them.
Rewroked advanced section about Axes
Inserted better description about spawn point that was posted on the forum
Added Appendix I on map writing best practice
Added Appendix II on how to name resources
Added a table of content
If you already read the older version of the tutorial, I think section 6 still can be worth reading. I talks about the advanced usage of Axes and Axis. By itself, its
1) a complex topic
2) that was badly presented
3) I think the current presentation quality has risen to something that could be considered "semi-intelligible"
4) nobody has used any of those features yet in any maps that I've seen.
That being said, for those who dont want to cvs the document, I've attached a copy here.
Thanks, I'll put this in CVS in the docs folder, in a new txt subdirectory. It's sort of a preliminary solution; I hope we can get a better HTML generation system everyone can understand.
After seeing Jonathans' spiral map, I remembered something about improving the quality of experience for players.
The rule I've read is something like this: "Make actions consistent, but sometime, add an unpredicted element".
So, in a FPS, if you shot a crate, the content should be of the proper size. You shouldn't find long bazookas in short box.
But if crates usually give something positive to the player, like ammo, health or weaponry, and sometimes nothing, then it gets regular and predictable. So instead, have the 37'th crate explode in the face of the player. Then dont repeat this until the 83'th crate.
After a few crates, the player get confident, then a bored by the crates. By putting an unexpected element, you revive the interest of the crates for the player.
I'll use Jonathan's map as for me, its the first map that has a start and an end, in the same fashion of many maps in FPS (in single player mode)
By itself, surviving 1000 loops is not an easy challenge. And I've still to manage it. But its easy to just get in a "have to turn, have to turn" brain pattern. To keep a player on its toes, one could:
-after the 32'th lap, suddently make the spiral unwind in the opposite direction
-on the 56'th lap, put a small bent in one of the corridor.
That said, Jonathan and Your_mom, its just a pitty that the engine isnt ready to set a victory condition upon escape, or wandering death zone, because you made some great map.
-ph
None of this is mine, I think it came from Gamasutra.