Version 0.322 - selection highlighting, grid, ship movement
Moderator: Committer
Re: Version 0.322 - selection highlighting, grid, ship movement
here is a diff of the build 3387 and the 2 files i added.
i had to comment out several instances of
i don't know why.
also there was no implementation of the creation of a CombatShipPtr structure that needed to be added to the SceneNode in oder to use OpenSteer.
I modified the ShipPlaced Function but had to use void* pointers to get it running.
maybe you make an better implementation of this if you whish.
i had to comment out several instances of
Code: Select all
SetChildClippingMode(...);
also there was no implementation of the creation of a CombatShipPtr structure that needed to be added to the SceneNode in oder to use OpenSteer.
I modified the ShipPlaced Function but had to use void* pointers to get it running.
maybe you make an better implementation of this if you whish.
- Attachments
-
- diff3387withShipMove.zip
- (21.13 KiB) Downloaded 53 times
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Version 0.322 - selection highlighting, grid, ship movement
What do you mean by "had to"? What happens if you don't?strooka wrote:i had to comment out several instances ofi don't know why.Code: Select all
SetChildClippingMode(...);
And more importantly, what is the patch supposed to be doing? Summarize its purpose in a few sentences...
Re: Version 0.322 - selection highlighting, grid, ship movement
It Shows the MoveCombatShip function As mentioned above and its additions that Must Be Set to use it.
I had to disable the functions SetChildClippingMode After updating to the newest svn Version in several Files, altough there is an Definition in gg::wnd of it.
Does sb have this Error, too?
I had to disable the functions SetChildClippingMode After updating to the newest svn Version in several Files, altough there is an Definition in gg::wnd of it.
Does sb have this Error, too?
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Version 0.322 - selection highlighting, grid, ship movement
It's still not clear what the purpose of this function is.strooka wrote:It Shows the MoveCombatShip function As mentioned above and its additions that Must Be Set to use it.
This still doesn't say why you needed to "disable" functions. What happens if you don't?I had to disable the functions SetChildClippingMode After updating to the newest svn Version in several Files, altough there is an Definition in gg::wnd of it.
I assume you mean it won't compile... My first guess would be that you haven't recently updated and rebuilt GG.
What is "sb" ?Does sb have this Error, too?
Re: Version 0.322 - selection highlighting, grid, ship movement
"somebody", I guess.Geoff the Medio wrote: What is "sb" ?
Re: Version 0.322 - selection highlighting, grid, ship movement
it makes a linear animation of a moving ship to the destination.
your implementation just displace the ships, but in my implementation they really move from one point to another when the user selects the ships and points to a destination.
oh good i'll update GG i guess that is the error.
your implementation just displace the ships, but in my implementation they really move from one point to another when the user selects the ships and points to a destination.
oh good i'll update GG i guess that is the error.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Version 0.322 - selection highlighting, grid, ship movement
When posting diffs, please exclude changes to CMakeLists.txt and Makefile.
The void* and reinterpret_cast stuff isn't acceptable. It'll have to be redone with proper type safe function signatures.
struct CombatInfo contains the system object in CombatInfo::objects and you don't need to get it from the main universe. Even if you did, there's no reason you should need to be const-casting it to a non-const System pointer.
You don't seem to actually need to add CombatShipTypes; just have some hard-coded checks in the Ship class functions that use it (eg. Ship::TurnRate), and avoid adding the new file and global object in Ship.h
Why did you add duplicate defintions of void ExtractMessageData(const Message& msg, CombatData& combat_data) ?
You don't need to include CombatSystem.h in Message.h to pass CombatInfo by reference. Just declare a struct CombatInfo in Message.h and include CombatSystem.h in CombatSystem.cpp
There don't need to be OptionsDB entries for specific ship design / model turn rates and speeds and such.
What do you mean by "your implementation just displace the ships" ? I wasn't aware there was any ship movement functionality at all yet, aside from ship placement orders at the start of combat...
There must be a better way than checking for "ship" in the name of a movable object to determine if it's a ship. Can Ogre::MovableObject* be dynamically casted to a combat ship pointer of some sort?
You don't seem to actually use PathingEngine::m_obstacles in CombatWnd so why doe it need to be public? Even if it does need to be available, add an accessor function rather than making the member struct public.
The void* and reinterpret_cast stuff isn't acceptable. It'll have to be redone with proper type safe function signatures.
struct CombatInfo contains the system object in CombatInfo::objects and you don't need to get it from the main universe. Even if you did, there's no reason you should need to be const-casting it to a non-const System pointer.
You don't seem to actually need to add CombatShipTypes; just have some hard-coded checks in the Ship class functions that use it (eg. Ship::TurnRate), and avoid adding the new file and global object in Ship.h
Why did you add duplicate defintions of void ExtractMessageData(const Message& msg, CombatData& combat_data) ?
You don't need to include CombatSystem.h in Message.h to pass CombatInfo by reference. Just declare a struct CombatInfo in Message.h and include CombatSystem.h in CombatSystem.cpp
There don't need to be OptionsDB entries for specific ship design / model turn rates and speeds and such.
What do you mean by "your implementation just displace the ships" ? I wasn't aware there was any ship movement functionality at all yet, aside from ship placement orders at the start of combat...
There must be a better way than checking for "ship" in the name of a movable object to determine if it's a ship. Can Ogre::MovableObject* be dynamically casted to a combat ship pointer of some sort?
You don't seem to actually use PathingEngine::m_obstacles in CombatWnd so why doe it need to be public? Even if it does need to be available, add an accessor function rather than making the member struct public.
Re: Version 0.322 - selection highlighting, grid, ship movement
after updating to the newest GG version i can't start FO anymore, cause i get a sysmalloc error
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Version 0.322 - selection highlighting, grid, ship movement
Make sure you've got the right versions of libraries in place and are linking against the same versions. After rebuilding GG you might need to reinstall it or something similar.
Re: Version 0.322 - selection highlighting, grid, ship movement
okWhen posting diffs, please exclude changes to CMakeLists.txt and Makefile.
i'll leave it to youThe void* and reinterpret_cast stuff isn't acceptable. It'll have to be redone with proper type safe function signatures.
i needed the system pointer somewhere, but i found that i can get it, too through:struct CombatInfo contains the system object in CombatInfo::objects and you don't need to get it from the main universe. Even if you did, there's no reason you should need to be const-casting it to a non-const System pointer.
const System* system = universe_objects.Object<System>(system_id);
i thought it would be good for the program testers to implement such a structure. once all variables are set it could be in program coded.You don't seem to actually need to add CombatShipTypes; just have some hard-coded checks in the Ship class functions that use it (eg. Ship::TurnRate), and avoid adding the new file and global object in Ship.h
it's some old code.Why did you add duplicate defintions of void ExtractMessageData(const Message& msg, CombatData& combat_data) ?
well thx for the tip with theese predeclaring. but the server communication isn'n my part, i'll delete it in my implementation.You don't need to include CombatSystem.h in Message.h to pass CombatInfo by reference. Just declare a struct CombatInfo in Message.h and include CombatSystem.h in CombatSystem.cpp
there is a function already defined in the newest svn: void CombatWnd::RepositionShipNode(int ship_id, const Ogre::Vector3& position)What do you mean by "your implementation just displace the ships" ? I wasn't aware there was any ship movement functionality at all yet, aside from ship placement orders at the start of combat...
i could get the any structure through getUserAny which is a member func of MoveableObject, it contains the CombatShip structure, but for this it must be implemented in the CombatSetupWnd.There must be a better way than checking for "ship" in the name of a movable object to determine if it's a ship. Can Ogre::MovableObject* be dynamically casted to a combat ship pointer of some sort?
AddShip adds it to the any struc actually but it isn't actually called when placing a ship.
i had to handle with void* pointers maybe somebody else finds a better implementation.
okYou don't seem to actually use PathingEngine::m_obstacles in CombatWnd so why doe it need to be public? Even if it does need to be available, add an accessor function rather than making the member struct public.
Re: Version 0.322 - selection highlighting, grid, ship movement
the CombatWnd::LClick func could look like:
Code: Select all
...
std::map<Ogre::MovableObject*, SelectedObject>::iterator it;
for(it = m_current_selections.begin(); it != m_current_selections.end(); ++it)
{
std::string ship_name = it->first->getName();
//determine wether a ship is selected and call move function
std::string::size_type found;
found = ship_name.find("ship");
if(found != std::string::npos)
{
CombatShipPtr combat_ship = Ogre::any_cast<CombatShipPtr>(it->first->getUserAny());
MoveCombatShip( combat_ship, intersection.second );
}
Re: Version 0.322 - selection highlighting, grid, ship movement
Based on tzlaine's comments, I'm pretty sure that's just intended for the initial ship placement and adjustments. It allows you to drag ships around. It's probably not meant to be used for actual ship movements.strooka wrote: there is a function already defined in the newest svn: void CombatWnd::RepositionShipNode(int ship_id, const Ogre::Vector3& position)
Re: Version 0.322 - selection highlighting, grid, ship movement
my object files were corrupted.
because i had a later version of GG, but not compiled and installed, everyting went fine till the headers were incompatible.
once compiled as obj file with the old version. there was a crash when calling code from the old compiled .cpp files.
because i had a later version of GG, but not compiled and installed, everyting went fine till the headers were incompatible.
once compiled as obj file with the old version. there was a crash when calling code from the old compiled .cpp files.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Version 0.322 - selection highlighting, grid, ship movement
You presumably don't need to search in the name; just attempt to cast (or interpret?) the any as a CombatShipPtr. If the cast works and you get a non-null pointer, then it's a ship. If the cast doesn't work, it's not a ship. You can usually test the results of such dynamic casting with something likestrooka wrote:Code: Select all
... std::string ship_name = it->first->getName(); //determine wether a ship is selected and call move function std::string::size_type found; found = ship_name.find("ship"); if(found != std::string::npos) { CombatShipPtr combat_ship = Ogre::any_cast<CombatShipPtr>(it->first->getUserAny()); ...
Code: Select all
if (CombatshipPtr combat_ship = Ogre::any_cast<CombatShipPtr>(it->first->getUserAny())) {
// do stuff
}
If you want code you submit to be used, you'll have to do major rewrite fixes like this yourself.i'll leave it to youThe void* and reinterpret_cast stuff isn't acceptable. It'll have to be redone with proper type safe function signatures.