View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015628||Runner||[All Projects] Variables||Public||2014-08-07 18:52||2017-12-06 09:46|
|Reporter||ParodyKnaveBob||Assigned To||Steven Campbell|
|Priority||High||Severity||C - General||Reproducibility||100%|
|Platform||Windows||OS||Windows Vista||OS Version||SP2|
|Target Version||Fixed in Version|
|Summary||0015628: Variables: Room Creation Code returns unpredictable results for objects and events|
|Description||When I first started taking notes (finally) to report this bug, I looked at object_index, event_type, and event_number in Room Creation Code on a small project I'd been building on for quite awhile, and I got the following results:|
object_index - 0
event_type - 11
event_number - 87
In preparing a demo project for this report, however, I started with a new, blank file -- one room, no objects -- and this is what I got:
object_index - 0
event_type - 0
event_number - 0
If I were to use a general script for something -- in which I'd built debugging information to better locate issues -- and it needed to alert me of an error, instead of telling me it's in no-object's no-event or some-specialized-event-id, I would be told it's in the first object's Create Event -- but only for that project. There's no telling what numbers I'd get for other projects (as seen in the first output example above). This unpredictability can potentially lead to a lot of wasted time tracking bugs' phantom locations -- especially when using object_get_name() on an object_index to display a human-readable name that a programmer doesn't realize is wrong!
|Steps To Reproduce||1. New project.|
2. New room.
3. Room Creation Code:
show_debug_message("object_index:" + string(object_index));
show_debug_message("object name: " + object_get_name(object_index));
show_debug_message("id:" + string(id));
show_debug_message("event_type:" + string(event_type));
show_debug_message("event_number:" + string(event_number));
4. Run in debug mode.
5. Observe 0's (probably) for all values except object name, which is "undefined" in angle brackets.
|Additional Information||In my repro steps, I included id, too, but I see that gives a pretty distinct value at least.|
|1.4 Found In||1.99.182|
|2.x Runtime Found In|
|2.x Runtime Verified In|
|There shouldn't really be any reason for people to use object_index in room creation code but I'll assign this on as it should definitely report something other than <undefined>.|
In general, I would agree that explicitly trying to use object_index unscoped/unprefixed in Room Creation Code is rather pointless, but like I said in the report, if a person creates a script which is designed with generalized debug information, the confused debug info errantly reports an invented object and event.
If a room reported itself as object noone, that would at least make more sense. As for the event, it might be wise anyway to have additional event values for Room Creation Code and Instance Creation Code.
|I just realized, as a suggestion about event constants, you could group object Create Event, Room Creation Code, and Instance Creation Code all under the ev_create event_type but with different event_number entries -- like ev_create_object, ev_create_room, ev_create_instance.|
|Related to 0027235 perhaps?|