Announcement

Collapse
No announcement yet.

DEBUG-> SLIC: HasAdvance

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DEBUG-> SLIC: HasAdvance

    Ok, its not really a bug, but it's a pain in the arse which looks like it can be fixed quite easily. HasAdvance( ) takes the advance argument as a string, which makes it a pain for coding loops and stuff where a database number would be handy.

    To fix it seems to me to be somewhat easy to fix since the builtin C function HasAdvance takes an int, which is looked up by this SLIC function. slicfunc.cpp.


    Code:
    SFN_ERROR Slic_HasAdvance::Call(SlicArgList *args)
    {
    	if(args->m_numArgs != 2)
    		return SFN_ERROR_NUM_ARGS;
    	
    	sint32 player;
    
    	if(!args->GetPlayer(0, player))
    		return SFN_ERROR_TYPE_ARGS;
    
    	if(args->m_argType[1] != SA_TYPE_STRING)
    		return SFN_ERROR_TYPE_ARGS;
    	
    	sint32 adv;
    	for(adv = 0; adv < g_theAdvanceDB->NumRecords(); adv++) {
    		if(g_theAdvanceDB->Get(adv)->m_name == args->m_argValue[1].m_int)
    			break;
    	}
    	if(adv >= g_theAdvanceDB->NumRecords()) {
    		return SFN_ERROR_NOT_ADVANCE;
    	}
    
    	if(player < 0 || player >= k_MAX_PLAYERS)
    		return SFN_ERROR_OUT_OF_RANGE;
    
    	if(!g_player[player]) {
    		return SFN_ERROR_DEAD_PLAYER;
    	}
    
    	m_result.m_int = g_player[player]->HasAdvance(adv);
    	DPRINTF(k_DBG_SLIC, ("Slic_HasAdvance: %d\n", m_result.m_int));
    	return SFN_ERROR_OK;
    }
    To make it back compatible, it would need to accept strings and ints, but that shouldn't be a problem should it?

    Code:
    SFN_ERROR Slic_HasAdvance::Call(SlicArgList *args)
    {
    	if(args->m_numArgs != 2)
    		return SFN_ERROR_NUM_ARGS;
    	
    	sint32 player;
    
    	if(!args->GetPlayer(0, player))
    		return SFN_ERROR_TYPE_ARGS;
    
    	sint32 s;
                    bool res;
    	s = 2; // 2 == string
    	if(args->m_argType[1] != SA_TYPE_STRING){
    		res = args->GetInt(1, type);
    		if(!res) {
    			return SFN_ERROR_TYPE_ARGS;
    			s = 0;	// neither int or string
    		} else {
    			s = 1;	// 1 == int
    		}
    	}
                    sint32 adv;
    	if(s == 2){		// string. look up the DB reference
    		
    	        for(adv = 0; adv < g_theAdvanceDB->NumRecords(); adv++) {
    			if(g_theAdvanceDB->Get(adv)->m_name == args->m_argValue[1].m_int)
    				break;
    	        }
            } else {
    		if(s == 1)	// DB reference, contine as normal
    			adv = m_argType[1];
    	}
    	if(adv >= g_theAdvanceDB->NumRecords()) {
    		return SFN_ERROR_NOT_ADVANCE;
    	}
    
    	if(player < 0 || player >= k_MAX_PLAYERS)
    		return SFN_ERROR_OUT_OF_RANGE;
    
    	if(!g_player[player]) {
    		return SFN_ERROR_DEAD_PLAYER;
    	}
    
    	m_result.m_int = g_player[player]->HasAdvance(adv);
    	DPRINTF(k_DBG_SLIC, ("Slic_HasAdvance: %d\n", m_result.m_int));
    	return SFN_ERROR_OK;
    }
    Last edited by Immortal Wombat; November 6, 2003, 21:25.
    Concrete, Abstract, or Squoingy?
    "I don't believe in giving scripting languages because the only additional power they give users is the power to create bugs." - Mike Breitkreutz, Firaxis

  • #2
    I think there might be an easier way to do that. c++ has this rather neat feature called 'overloading' which means that you can define two or more functions with the same name but different argument types. When you call the function the compiler sorts things out for you.

    So you could just redefine the original function but put an int in where it had a string.

    Comments welcome.
    Last edited by Peter Triggs; November 6, 2003, 21:50.

    Comment


    • #3
      I agree with you Peter. Better to use overloading than to change the original. But the SlicArgList-parameter could be somewhat of a problem...
      So much to do in so little time...

      Comment


      • #4
        As far as I know you can only do overloading if you have two different parameter lists. But all the c++ slic function have the same parameter list. So I doubt you can do this C++ style overloading. Ben's suggestion leads us finally to overloaded slic functions, and actual I don't care how it is done. But to fix the StringCompare function we have to do it this way anyway, because the function must accept strings and string ids and strings from build ins. And you can't handle this by simply overloading it.

        -Martin
        Civ2 military advisor: "No complaints, Sir!"

        Comment

        Working...
        X