location structs were a later addition to the game, and the entity struct was never re-factored to use location structs
this isn't during initialization.
Thus my point about the dangers of mutable state.
If these were immutable, then initialisation is the only time they could change, and all you'd need would be a constructor and a copy-assignment operator.
Then refactor the code to make things like this go away?
at this point its how long to refactor vs how long to to simply complete the project with the current systems, including time wasted on typos and "forgot to edit" errors - its that close.
the refactor would basically change how location and probably orientation, collision radius, and frustum cull radius are stored for everything in the game. definitely non-trivial with 120K+ lines of game specific code. i could probably do it in 4-5 days. whereas its unlikely i'll waste another 4-5 days on similar errors before the game is done. especially since having been burned recently, i'm now back to carefully double checking that type of code when i write it.
Speaking as someone who has seen your code posted here before, the amount of time and the errors don't surprise me in the slightest...
i wasn't really that disappointed, 40 some odd fixed or new features (about 2000 lines of code), with only 3 runtime errors out the box. granted 3 of 30 hours spent finding the errors sucked, but that's really rare. when i started coding, like everyone, non-trivial bugs were an everyday occurrence. nowadays, it can be months between something like this happening. you know i've only had 3 or 4 lockup or crash to desktop type bugs in 3 years of working on this? i try to keep things simple, try anticipate every possible problem, and try to test thoroughly. in 30 some odd game releases over the years, i'm averaging under 1 bug per release (not including typos and spelling error in text displays).
but you guys are right, if a location struct were simply a member of caveman, animal, and object structs, i could just pass around locations - eliminating the possibility of error while copying data back and forth to and from parameter structs. that's what a location struct is right now, a struct for passing location parameters to functions. beats having to pass mx,mz,x,y,z, and rad separately all the time.
but you guys are right, if a location struct were simply a member of caveman, animal, and object structs, i could just pass around locations - eliminating the possibility of error while copying data back and forth to and from parameter structs. that's what a location struct is right now, a struct for passing location parameters to functions. beats having to pass mx,mz,x,y,z, and rad separately all the time.
you could still have getters/setters for locations in your entity structs and do the necessary copying there. No individual member assignments everywhere and your old code keeps working. or a union in your entity types might work for you.
at this point its how long to refactor vs how long to to simply complete the project with the current systems, including time wasted on typos and "forgot to edit" errors - its that close.
I would hope this shouldn't be that big a deal to refactor. 4-5 days? That might suggest you have a lot of duplicated code. (Why did you make the "Location" struct in the first place, if not use be able to re-use code and manipulate position data in a consistent way?)
you know i've only had 3 or 4 lockup or crash to desktop type bugs in 3 years of working on this?
I think I have several a day when working on my game! If I'm doing something wrong, I catch it quick.
You can add compile-time checking for bad initialization with static_assert.
It's hard for compilers to check your logic, they don't know what you're trying to do.
you could still have getters/setters for locations in your entity structs and do the necessary copying there. No individual member assignments everywhere and your old code keeps working. or a union in
the syntax difference might make typos less common...
location L
L.mx=mx
L.mz=mz
L.x=x
L.z=z
some_function(&L)
mx=L.mx
mz=L.mz
x=L.x
z=L.z
== vs ==
set_loc(&L,mx,mz,x,z)
some_function(&L)
get_loc(&L,&mx,&mz,&x,&z)
looks like less typing too.
(Why did you make the "Location" struct in the first place, if not use be able to re-use code and manipulate position data in a consistent way?)
as an easier way to pass locations as parameters. instead of passing mx,mz,x,z all the time.
really, a location struct should have been a component of animal, bandmember and object structs from the get go. then i could have used generic routines to the max extent possible.
so right now, its kind of a hybrid - generic new stuff that uses location structs, and older stuff that stills stores locations as separate mx,mz,x,z variables.
the getter and setter functions to streamline conversion is looking like a pretty good idea. probably the next best thing to rewriting it all using location structs for everything.
4-5 days? That might suggest you have a lot of duplicated code.
mostly its just a big game, that's all. but the older code, not having a common location component for PCs, NPC/monsters, and world objects does have some duplicated code - basically three versions depending on which "class" (PC, npc/monster, or worldobj) you're talking about. in OO terms there are only 3 classes of game objects: player controlled entities, computer controlled entities, and inanimate objects (buildings and dropped inventory items).
.
I think I have several a day when working on my game! If I'm doing something wrong, I catch it quick.
'
this ts the fourth time i've gotten into or back into game programming in my life. each time i do it, once i get the graphics library working well, its mostly just glorified word processing. simple code helps. simple algos help. good modular design helps (a lot!). bulletproof design is the real trick though - you design you code so errors (range, null ref, etc) are not possible in the first place. typically, scope is so large there's little time for pushing the envelope with fancy code and advanced algos (which might tend to crash more during development, until all the kinks are worked out). i always try to path test all changes immediately, or in batches of changes and testing, now that link times have gone long towards the end of the project. but the game is so big i don't bother path testing trivial changes like reducing the base hit points of a dire wolf by 1 or something like that anymore. i just make sure the code is correct, and take it on faith the game will reflect such changes. of course, such changes are still watched for during long term play testing. but i wont start a playtest game (one click! <g>) and punch up a dire wolf encounter on the playtest menu (alt-F12) just to hunt dire wolves, to see if i can tell a difference. especially since it only shows target damage as a percentage (IE dmg: 26%), not as "dmg: 5 of 10" or something like that.
I think I have several a day when working on my game! If I'm doing something wrong, I catch it quick.
speak of the devil...
just got a crash to desktop
script code with error:
s+ s s 2
' error: this cats s onto s! there shouldn't be a space between the second s and 2!
should have been:
s+ s s2
' correct: cat s2 onto s
translates to:
code with error:
strcpy_s(s,100,s);
// error: this cats s onto s! there shouldn't be a space between the second s and 2!
should have been:
strcat_s(s,100,s2);
// correct: cat s2 onto s
the s+ (string add or string append or string cat) keyword in Cscript expects two string tokens as parameters. so it picked up the two s's and ignored the 2.
and it would appear that strcat_s(s,100,s); causes a crash to desktop! <g>
and now everyone is going to be trying it...
FYI, s and s2 were locally declared variables in a function call: char s[100],s2[100]; and both were initialized to valid values - IE "TORSO " and "18". it was part of the code for the stats screen that shows the new hit location damage by section.
