Version 0.322 - selection highlighting, grid, ship movement

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#31 Post by strooka »

very good :))

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#32 Post by strooka »

here is a diff of the build 3387 and the 2 files i added.
i had to comment out several instances of

Code: Select all

SetChildClippingMode(...);
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.
Attachments
diff3387withShipMove.zip
(21.13 KiB) Downloaded 53 times

User avatar
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

#33 Post by Geoff the Medio »

strooka wrote:i had to comment out several instances of

Code: Select all

SetChildClippingMode(...);
i don't know why.
What do you mean by "had to"? What happens if you don't?

And more importantly, what is the patch supposed to be doing? Summarize its purpose in a few sentences...

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#34 Post by strooka »

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?

User avatar
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

#35 Post by Geoff the Medio »

strooka wrote:It Shows the MoveCombatShip function As mentioned above and its additions that Must Be Set to use it.
It's still not clear what the purpose of this function is.
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.
This still doesn't say why you needed to "disable" functions. What happens if you don't?

I assume you mean it won't compile... My first guess would be that you haven't recently updated and rebuilt GG.
Does sb have this Error, too?
What is "sb" ?

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Version 0.322 - selection highlighting, grid, ship movement

#36 Post by pd »

Geoff the Medio wrote: What is "sb" ?
"somebody", I guess.

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#37 Post by strooka »

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.

User avatar
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

#38 Post by Geoff the Medio »

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.

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#39 Post by strooka »

after updating to the newest GG version i can't start FO anymore, cause i get a sysmalloc error :(

User avatar
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

#40 Post by Geoff the Medio »

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.

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#41 Post by strooka »

When posting diffs, please exclude changes to CMakeLists.txt and Makefile.
ok
The void* and reinterpret_cast stuff isn't acceptable. It'll have to be redone with proper type safe function signatures.
i'll leave it to you
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.
i needed the system pointer somewhere, but i found that i can get it, too through:
const System* system = universe_objects.Object<System>(system_id);
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
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.
Why did you add duplicate defintions of void ExtractMessageData(const Message& msg, CombatData& combat_data) ?
it's some old code.
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
well thx for the tip with theese predeclaring. but the server communication isn'n my part, i'll delete it in my implementation.
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 is a function already defined in the newest svn: void CombatWnd::RepositionShipNode(int ship_id, const Ogre::Vector3& position)
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?
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.
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.
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.
ok

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#42 Post by strooka »

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 );
                        }
 

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Version 0.322 - selection highlighting, grid, ship movement

#43 Post by pd »

strooka wrote: there is a function already defined in the newest svn: void CombatWnd::RepositionShipNode(int ship_id, const Ogre::Vector3& position)
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.

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#44 Post by strooka »

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.

User avatar
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

#45 Post by Geoff the Medio »

strooka 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());
...
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 like

Code: Select all

if (CombatshipPtr combat_ship = Ogre::any_cast<CombatShipPtr>(it->first->getUserAny())) {
    // do stuff
}
although I don't know exactly how Ogre::any_cast works, so it might be more tricky than, for example, trying to dynamic_cast a base class pointer to a derived class pointer and checking if the cast was successful with an if.
The void* and reinterpret_cast stuff isn't acceptable. It'll have to be redone with proper type safe function signatures.
i'll leave it to you
If you want code you submit to be used, you'll have to do major rewrite fixes like this yourself.

Post Reply